Atlas Forms
AI Prompt Context
The AI generator receives a rich context package before producing the form schema. This context is what enables pattern-consistent generation — the AI does not invent conventions, it learns and follows the ones already established in the group.
Context Package Structure
// The context package passed to the AI before generation
interface FormGenerationContext {
// Task description from the user
userRequest: {
groupId: string; // e.g. 'guard-rails'
description: string; // e.g. 'Property form for editing IP allowlist rules'
requiredFields: FieldRequirement[];
};
// Group metadata
groupDefinition: FormGroupDefinition; // Full group definition (see Guide 13)
// All existing form schemas in the group — sorted by FormID
existingForms: ExistingFormSummary[];
// The next available FormID in the group range
nextFormId: number;
// Database folder path for output file
outputFolder: string;
}
interface FieldRequirement {
name: string;
type: string; // 'text' | 'select' | 'date' | 'textarea' | ...
required: boolean;
validation?: string; // Free-text description e.g. 'CIDR format'
options?: string[]; // For select fields
}
interface ExistingFormSummary {
formId: number;
formCode: string;
schema: FormSchema; // Parsed full schema
}
User Request Section
This is the only part of the context the user directly controls. The description and requiredFields drive what the form does; everything else is read from the group automatically:
// Example user request that drives generation
{
"groupId": "guard-rails",
"description": "Property form for editing an IP allowlist rule. Allows admins to specify IP ranges that bypass or trigger GuardRail checks.",
"requiredFields": [
{ "name": "ruleName", "type": "text", "required": true, "validation": "Max 100 chars" },
{ "name": "ipRange", "type": "text", "required": true, "validation": "CIDR notation, e.g. 192.168.1.0/24" },
{ "name": "action", "type": "select", "required": true, "options": ["Allow", "Block"] },
{ "name": "expiryDate", "type": "date", "required": false },
{ "name": "notes", "type": "textarea", "required": false }
]
}
Group Definition Section
Provided automatically from the registered FormGroupDefinition:
{
"formGroupId": "guard-rails",
"label": "GuardRails",
"ownerApp": "BizFirst.Ai.ProcessSecurity",
"categoryId": 130,
"formIdRange": { "start": 13000, "end": 13099 },
"aiGenerationEnabled": true,
"defaultPrimaryUsage": "guardrails"
}
Existing Forms Summary Section
The AI receives the full parsed schema of every existing form in the group. This is the largest part of the context and is the primary source of pattern learning:
// Existing forms fed into the AI context (abridged)
[
{
"formId": 13001,
"formCode": "GuardRail_Edit",
"schema": {
"metadata": { "formId": 13001, "title": "Edit GuardRail" },
"sections": [
{ "id": "details", "title": "GuardRail Details", "order": 1 },
{ "id": "settings", "title": "Policy Settings", "order": 2 }
],
"controls": [ ... ],
"actions": [ ... ]
}
},
{
"formId": 13003,
"formCode": "GuardRail_RateLimit_Edit",
"schema": { ... }
}
]
What the AI Does NOT Receive
| Excluded | Reason |
|---|---|
| Forms from other groups | Cross-group context would dilute pattern learning and risk ID collisions |
| Tenant override rows | Tenant data is not a pattern source — base forms only |
| Database credentials | The AI writes SQL files; it does not connect to the database |
| Application business logic | The form schema defines UX and validation, not business rules |
Richer Context = Better Output
The more complete your existing forms are (clear section titles, consistent naming, well-specified validation), the better the AI's pattern learning and the higher-quality the generated form. Invest in clean existing forms and the AI pays dividends on every subsequent generation.