Infrastructure Plan Schema
{
meta: {
planId: string // Unique identifier (e.g., "plan-1")
generatedAt: string // ISO 8601 timestamp
version: string // Schema version (e.g., "0.1-draft")
status: "draft" | "approved" | "deployed" // Lifecycle state
}
inputs: {
userGoal: string // User's stated objective or workload description, matches user query exactly
subGoals?: string[] // Inferred architectural constraints and priorities derived from the user's request and research phase. Examples: "Cost-optimized: user chose defaults, avoid premium networking", "Security-first: encrypt all data, use managed identity", "Minimal complexity: single region, no VNet". These help evaluators understand intentional tradeoffs. Should be short list of 0-3 points.
insightsApplied: string[] // For each insight that influenced this plan, cite the insight ID and explain how and why it was applied. Set to an empty array if no insights were applied. Document any unapplied insights in plan.overallReasoning.tradeoffs.
}
plan: {
resources: {
name: string // Logical resource name (CAF-compliant)
type: string // ARM resource type (e.g., "Microsoft.Storage/storageAccounts")
subtype?: string // Exact subtype (e.g., "Blob Storage", "Azure Function")
location: string // Azure region (e.g., "eastus")
sku: string // SKU tier (e.g., "Standard_LRS", "Consumption")
properties?: Record<string, unknown> // Resource-specific properties
reasoning: {
whyChosen: string // Justification referencing WAF pillars (see phases/2-research-best-practices.md and phases/3-research-resources.md) or requirements
alternativesConsidered: string[] // Other options evaluated
tradeoffs: string // Key tradeoffs in this choice
}
dependencies: string[] // Names of resources this depends on (empty if none)
dependencyReasoning?: string // Why these dependencies exist
references: { title: string, url: string }[] // Links to Azure docs
}[]
overallReasoning: {
summary: string // Overall architecture rationale
tradeoffs: string // Top-level tradeoffs and gaps
}
validation: string // Deployment coherence statement
architecturePrinciples: string[] // Guiding principles (e.g., "Highly available", "Secure")
references: { title: string, url: string }[] // Architecture-level doc links
}
}Insights Schema
type ExistingResource = {
id: string // Full ARM ID for actual state; logical or parameter reference otherwise
type: string // ARM resource type (e.g., "Microsoft.Network/virtualNetworks")
name: string
role: "reference-and-integrate" | "retain" | "ignore"
must_not_recreate: true
integrationPoints: string[] // Connections or dependencies involving the new workload
}
type Insight =
| {
id: string // Stable identifier (e.g., "insight-001"); cited from inputs.insightsApplied
pattern: string // Observed fact from the tenant scan or referenced workload
implication: string // Recommended planning action derived from the pattern
existingResource?: ExistingResource
}
| {
id: string // Stable identifier for a resource-only entry
existingResource: ExistingResource
pattern?: string // Include with implication when the resource produces a broader insight
implication?: string
}
type Insights = Insight[]In referenced mode:
- Include exactly one entry for every inventoried existing resource, uniquely identified by
existingResource.id. - Preserve the full ARM ID in
existingResource.idfor actual-state resources. - Use an empty
integrationPointsarray when the resource has no integration points. - A resource-only entry may omit
patternandimplication; when recording a broader insight, include both.