Instruction file imported from vincentgiraud/az-saas-planner (.github/instructions/compliance-stack-config.instructions.md). Copyright stays with the author.

Compliance-Ready Azure Stack — Shared Configuration

Configuration Schema

Every stack search begins with these parameters. Parse them from the user's input or prompt template. Use defaults when not specified.

Compliance Framework × Industry Matrix

When compliance_frameworks is auto, derive from industry + target markets:

† = Conditional framework. Applicability depends on company size, revenue, customer sectors, or data types. See Framework Applicability Conditions below. Frameworks without † always apply when the industry × market combination matches.

Compliance Framework → Azure Requirements

Framework Applicability Conditions

Frameworks marked with † in the Industry Matrix are conditional — they only apply when specific thresholds are met. The orchestrator MUST evaluate these conditions during auto-resolution (Step 0) using the discriminator parameters (customer_sectors, annual_revenue, company_size, data_sensitivity).

Condition Reference

Always-Apply Frameworks (no conditions)

Auto-Resolution with Conditions (2-step process)

When compliance_frameworks is auto, the orchestrator MUST:

1. Candidate lookup — Look up industry × market in the matrix. Collect all frameworks (including those marked †).
2. Condition filter — For each † framework, evaluate its condition from the table above:
   • Applies — Conditions clearly met → include in resolved list
   • Likely applies — Conditions cannot be ruled out (e.g., discriminator param is at default and could go either way) → include but flag: "⚠ {Framework} included based on defaults. Confirm: {specific question about the condition}"
   • Does not apply — Conditions clearly not met → remove with explanation: "ℹ {Framework} excluded: {reason}"
3. Present result — Show the user the resolved list with any flags before proceeding.

Azure Pricing Principles

ALL sub-agents MUST follow these when estimating costs:

1. Free tiers first — Always check if a free tier or free monthly allowance covers the workload
2. Dev/Test pricing — For startups in early stage, Azure Dev/Test pricing can save 40-60% on VMs and PaaS
3. Pay-as-you-go vs Reserved — Report PAYG as default; note reserved (1yr/3yr) savings separately
4. Microsoft for Startups — Flag eligibility for $1K-$150K Azure credits (Founders Hub program)
5. Region pricing varies — Always price in the selected primary_region; some regions are 10-30% cheaper
6. Hidden costs — Account for: egress bandwidth, storage transactions, log ingestion, DNS queries, SSL certs
7. Free tier overlap — Some free tiers apply per-subscription (not per-service); don't double-count

Common Free Tiers (as of 2026)

Note: These prices are approximate starting points. Sub-agents MUST verify current pricing via web search in the target primary_region before reporting to the user. Do not treat this table as authoritative — Azure pricing changes frequently.

Sub-Agent Output Format

Every sub-agent MUST structure its response using this format so the orchestrator can merge them:

## [Domain Name] Assessment

### Configuration Context
- Parameters used: [list relevant params from config]
- Compliance requirements addressed: [list frameworks]

### Recommended Services

#### Cost-Optimized Tier
| Service | SKU/Tier | Monthly Cost | Compliance Coverage | Limitations |
|---------|----------|-------------|--------------------:|-------------|
| ... | ... | $X.XX | GDPR ✓ SOC2 ✓ | ... |

**Subtotal: $X.XX/month**

#### Recommended Tier
| Service | SKU/Tier | Monthly Cost | Compliance Coverage | Limitations |
|---------|----------|-------------|--------------------:|-------------|
| ... | ... | $X.XX | GDPR ✓ SOC2 ✓ | ... |

**Subtotal: $X.XX/month**

#### Enterprise-Ready Tier
| Service | SKU/Tier | Monthly Cost | Compliance Coverage | Limitations |
|---------|----------|-------------|--------------------:|-------------|
| ... | ... | $X.XX | All ✓ | ... |

**Subtotal: $X.XX/month**

### Compliance Notes
- [Framework]: [How this domain satisfies requirements]

### Alternatives Considered
- [Service A vs Service B]: [Why B was chosen]

### Risks & Trade-offs
- [Risk]: [Mitigation]

Input Validation Rules

The orchestrator (az-saas-planner) MUST validate all parameters before proceeding. Sub-agents may assume inputs are already validated.

Enum Parameter Validation

For every parameter with a fixed set of valid values (industry, workload_type, compliance_frameworks, tech_stack, startup_stage, multi_tenancy, sla_target, data_sensitivity, expected_users_y1, data_volume, team_size, monthly_budget_cap):

1. Exact match — If the value matches a valid option (case-insensitive), accept it.
2. Fuzzy match — If no exact match, attempt a fuzzy match against the valid values:
   • Common misspellings: "Healthcar" → "Healthcare", "Fintech" → "FinTech", "ecommerce" → "E-commerce"
   • Synonyms: "Finance" → "FinTech", "Medical" / "HealthTech" → "Healthcare", "Legal" → "LegalTech", "Insurance" → "InsurTech", "Real Estate" → "PropTech", "HR" → "HRTech", "Government" → "GovTech", "Education" → "EdTech", "Regulation" / "Compliance" → "RegTech", "Life Sciences" / "Pharma" / "Biotech" → "BioTech", "Media" / "Advertising" / "AdTech" → "MediaTech", "Travel" / "Hospitality" / "Tourism" → "TravelTech", "Cybersecurity" / "InfoSec" / "SecOps" / "Security" → "CyberSecurity"
   • If a close match is found, present it to the user: "Did you mean '{match}'? [Yes / No, show valid options]"
3. No match — If no close match exists, reject and show the valid values:
   • "'{value}' is not a recognized {parameter}. Valid options: {list}. Please choose one, or use 'General SaaS' for unlisted industries."

Required Parameter Validation

• industry and primary_region are required. If missing, prompt the user before proceeding.
• For primary_region, accept either a recognized Azure region code or a geographic name. Apply the Geographic Name Resolution rules below.

Geographic Name Resolution

Users may provide a friendly geographic name instead of an Azure region code. The orchestrator MUST resolve it before passing to sub-agents:

1. Exact region code — If the value matches a known Azure region code (case-insensitive), accept it as-is.
2. Geo name lookup — If no region code match, attempt a case-insensitive match against the Geo-to-Region Mapping table below. If found, present the resolved region to the user for confirmation: "'{input}' → {azure_region} ({location}). Is this correct?"
3. No match — If neither matches, reject and show common geographic names:
   • "'{value}' is not a recognized Azure region or geographic name. Examples: Europe, US, UK, Asia, Australia, Canada, Brazil, Middle East, Africa — or use an Azure region code like westeurope, eastus."

Geo-to-Region Mapping

Auto-Resolution Safety Check

When compliance_frameworks is auto, apply the 2-step process described in Auto-Resolution with Conditions (under Framework Applicability Conditions):

1. Candidate lookup — Look up industry + target_markets in the Compliance Framework × Industry Matrix.
2. Condition filter — For each †-marked framework, evaluate its condition against customer_sectors, annual_revenue, company_size, and data_sensitivity. Classify as Applies / Likely applies / Does not apply.
3. If the lookup returns an empty set (no frameworks resolved after filtering), STOP and warn the user:
   • "No compliance frameworks could be determined for industry '{industry}' in markets '{markets}' with your company profile. Please specify compliance_frameworks explicitly, or adjust discriminator parameters."
4. Never proceed with an empty compliance framework list — this would produce a non-compliant stack.

Data Sensitivity Cross-Check

If data_sensitivity includes values that conflict with or extend the resolved compliance frameworks, flag the discrepancy:

• PHI without HIPAA → warn: "You indicated PHI data but HIPAA was not resolved. Consider adding HIPAA to compliance_frameworks, or set customer_sectors to include 'healthcare'."
• cardholder without PCI-DSS → warn: "You indicated cardholder data but PCI-DSS was not resolved. Consider adding PCI-DSS."
• financial without SOC2 or PCI-DSS → warn: "You indicated financial data — verify compliance framework coverage."
• financial in data_sensitivity without financial in customer_sectors → info: "You handle financial data. If your customers are financial institutions, consider setting customer_sectors to 'financial' to evaluate DORA applicability."

Model Override

Sub-agents leave model unset to use the user's default. To override per agent, add to its frontmatter:

model: "Claude Sonnet 4"        # faster, good for research
model: "Claude Opus 4.6"            # deeper analysis
model: ["Claude Opus 4.6", "Claude Sonnet 4"]  # fallback chain

MCP Tool Availability

Several sub-agents reference Azure MCP tools (e.g., azure-mcp/sql, azure-mcp/cosmos, azure-mcp/quota). These require the Azure MCP extension to be installed and configured.

• If MCP tools are available: Use them for live data (quota checks, resource lookups, best practices).
• If MCP tools are unavailable: Fall back to web search for the same information. Do not fail silently — note in the output that live data could not be retrieved and results are based on web search.