What the AI Learns
Before generating, the AI analyses every existing form schema in the group and extracts five categories of pattern: naming conventions, section structure, control type selection, binding paths, and action configuration. The generated form uses these patterns without deviation.
1. Naming Conventions
The AI reads all FormCode values and derives the naming pattern:
// Existing FormCodes in the GuardRails group:
// GuardRail_Edit, GuardRail_View, GuardRail_RateLimit_Edit,
// GuardRail_ContentFilter_Edit, GuardRail_TopicBlock_Edit, GuardRail_AccessControl_Edit
// Pattern learned: {GroupSingular}_{SubType?}_{Action}
// GroupSingular = 'GuardRail' (not 'GuardRails')
// Action suffix = 'Edit' for property forms
// Generated FormCode for IP allowlist:
// GuardRail_IpAllowlist_Edit
2. Section Structure
The AI finds the section IDs and titles most commonly used across property forms and replicates them. Minor naming differences between forms are resolved by majority vote:
// Sections found across existing property forms:
// GuardRail_Edit: [ { id: 'details', title: 'GuardRail Details' }, { id: 'settings', title: 'Policy Settings' } ]
// GuardRail_RateLimit_Edit: [ { id: 'details', title: 'Rate Limit Details' }, { id: 'settings', title: 'Rate Limit Settings' } ]
// GuardRail_ContentFilter_Edit:[ { id: 'details', title: 'Filter Details' }, { id: 'settings', title: 'Filter Settings' } ]
// Pattern learned: two sections, IDs 'details' and 'settings'
// Title = '{form-specific prefix} Details' and '{form-specific prefix} Settings'
// Generated sections:
// [ { id: 'details', title: 'IP Allowlist Details' }, { id: 'settings', title: 'IP Allowlist Settings' } ]
3. Control Type Selection
The AI maps user field requirements to control types by looking at how similar fields are implemented in peer forms:
| Field Type Requested | Control Type Used in Group | AI Uses |
|---|---|---|
| text (short) | text | text |
| text (long) | textarea | textarea |
| select / dropdown | select | select |
| date | date-picker | date-picker |
| boolean toggle | toggle | toggle |
| number | number | number |
4. Binding Path Patterns
The AI observes whether the group uses $json or $context source, and what path depth pattern is used:
// Binding patterns found in existing forms:
// { source: '$json', path: 'ruleName' }
// { source: '$json', path: 'rateLimit.requestsPerMinute' }
// { source: '$context', path: 'currentUser.tenantId' }
// Pattern learned:
// - Editable fields: source = '$json', path = camelCase field name
// - Context reads: source = '$context' for user/tenant data
// Generated binding for the 'ipRange' field:
// { source: '$json', path: 'ipRange' }
5. Action Configuration
The AI clones the action block from the most recently modified property form in the group, then replaces the payload field list with the new form's fields:
// Action pattern learned from GuardRail_Edit:
// actions: [
// {
// id: 'save',
// label: 'Save',
// type: 'submit',
// config: { endpoint: '/api/guardrails/save', method: 'POST' }
// },
// {
// id: 'cancel',
// label: 'Cancel',
// type: 'navigate',
// config: { target: 'GuardRail_List' }
// }
// ]
// Generated actions for IP Allowlist form:
// Same structure — only the save endpoint path segment changes:
// { endpoint: '/api/guardrails/ip-allowlist/save', method: 'POST' }
collapsible: true on the settings section), the AI picks this up and applies it to the generated form. Visual layout preferences embedded in existing schemas propagate automatically.