[Curriculum] Add QWED-Infra module — IaC verification trust boundaries

[rahuldass19]

Problem

The QWED ecosystem now spans three verification domains:

Domain	Package	Status in curriculum
Verification	qwed-verification (core Math, Logic, Code, SQL, etc.)	✅ Covered across Modules 0-13
Tax	qwed-tax v0.2.0	❌ Not referenced
Infra	qwed-infra v0.2.0 with ArtifactBoundaryGuard	❌ Not referenced

QWED Learning teaches how deterministic verification works and why fail-closed matters. But it only teaches this in the context of AI output verification. A student has no exposure to:

• Infrastructure-as-Code verification — verifying Terraform, IAM policies, network topologies, and cost estimates before deployment
• Artifact boundary verification — scanning release packages for secrets, debug files, and misconfigured build paths before they ship
• The 4-guard model — IamGuard, NetworkGuard, CostGuard, ArtifactBoundaryGuard and how they mirror the same deterministic fail-closed philosophy applied to infrastructure

This is a significant gap because:

1. Infra verification is the most mature QWED application of the "proof before trust" principle — InfraDiagnosticResult already enforces mandatory proof_ref on VERIFIED, exactly matching the architecture that Issue [Curriculum] Architecture sync — migrate VerificationResult model to DiagnosticResult + proof_ref #7 will teach
2. The ArtifactBoundaryGuard is QWED philosophy in its purest form — it is fully deterministic (no LLM, no heuristics), fail-closed (unparseable configs produce BLOCKED), and produces structured InfraDiagnosticResult output
3. Infrastructure is where QWED Principles 4 (fail closed) and 5 (explicit boundaries) are most tangible — a student can see an AWS IAM policy being blocked by IamGuard and understand why the boundary matters

Proposed content: new Module 14 — Infrastructure Verification

Module structure

Section	Content	Philosophy principles taught
14.1 The Infrastructure Trust Problem	Why AI-generated Terraform needs verification. AI agents writing IAM, networks, costs. Real-world cases (S3 bucket exposed, SSH open to internet, $23K/month GPU instance)	P2 (verification over generation), P5 (explicit boundaries)
14.2 The Four Guards	Overview of IamGuard, NetworkGuard, CostGuard, ArtifactBoundaryGuard. Each guard's purpose, what it verifies, and its fail-closed behavior	P4 (fail closed), P1 (deterministic over probabilistic), P8 (verification before execution)
14.3 IamGuard in Depth	Z3-based IAM policy verification. Symbolic proof of Allow vs Deny precedence. Wildcard matching via Z3 string theory	P1, P3 (proof before trust)
14.4 NetworkGuard in Depth	NetworkX-based VPC reachability analysis. Path tracing. Fail-closed on unsupported topologies (NAT, NACL, peering)	P4, P5
14.5 CostGuard in Depth	Deterministic cost estimation. Decimal arithmetic (not float). Fail-closed on unknown instance/volume types	P1, P6 (accountability over confidence)
14.6 ArtifactBoundaryGuard in Depth	Package file scanning. Secret detection. Build config verification. The release gate — "safe to ship"	P3, P4, P7 (evidence over assertions)
14.7 InfraDiagnosticResult	The 3-layer model already in production. How it enforces proof_ref on VERIFIED. Comparison with core DiagnosticResult	P3 (proof before trust), P9 (diagnostics ≠ explainability)
14.8 CI/CD Integration	Gating AI-generated IaC PRs. The DevSecOps pipeline with ArtifactBoundaryGuard as the final release gate	P8, P5
14.9 Lab: Verify a Terraform PR	Hands-on exercise: student writes a guard pipeline that blocks a PR containing an open SSH rule + leaked .env file	All 10 principles

Relationship to existing modules

• Connects to Module 9 (DevSecOps): Module 14 is the IaC-specific implementation of the DevSecOps CI/CD gate concept. Module 9 teaches the pattern; Module 14 teaches the application.
• Connects to Module 0 (Prerequisites): InfraDiagnosticResult is a concrete, running example of the "Proof vs Confidence" concept from Module 0. The proof_ref field is proof (literally) that trust requires evidence.
• Connects to Module 6 (Domains): Infrastructure verification is the next domain after Finance, Healthcare, Legal. It should fit naturally after Module 6 or as a standalone Module 14.

New references needed in existing modules

• README.md course map: Add Module 14 entry
• Module 0: Add optional reference — "If you finish the core course, continue to Module 14 to see QWED applied to infrastructure"
• Module 5 (Verification Landscape): Add qwed-infra to the comparison table
• Module 6 (Domains): Add Infrastructure as a new domain section
• Module 9 (DevSecOps): Reference qwed-infra as the IaC verification layer in the CI/CD pipeline

What qwed-infra v0.2.0 provides for exercises

• IamGuard.verify_access() — deterministic IAM Z3 verification
• NetworkGuard.verify_reachability() — NetworkX reachability analysis
• CostGuard.verify_budget() — Decimal-based cost estimation
• ArtifactBoundaryGuard.verify_package_boundary() — package file scanning + build config verification
• InfraDiagnosticResult — 3-layer output with mandatory proof_ref

Acceptance criteria

• New Module 14 content covers IamGuard, NetworkGuard, CostGuard, and ArtifactBoundaryGuard
• Lab exercise lets a student verify a real (or simulated) Terraform PR with at least 2 guards
• Module explains InfraDiagnosticResult and its relationship to core DiagnosticResult
• qwed-infra version pin in examples matches current (v0.2.0+)
• Module 14 references and connects to at least 3 existing modules (recommended: 0, 6, 9)
• Course map in README.md updated with Module 14 entry and time estimate
• All code examples in Module 14 run after pip install qwed-infra

Non-goals

• Rewriting architecture model or result types (Issue [Curriculum] Architecture sync — migrate VerificationResult model to DiagnosticResult + proof_ref #7)
• Changing import paths across the existing curriculum (Issue [Curriculum] Import path and package reality audit — make every code example runnable #8)
• Version pin synchronization (Issue [Curriculum] Version and ecosystem synchronization — resolve stale version references and architecture diagrams #9)
• Adding qwed-tax coverage (future work)

Why this is P2

The core curriculum (philosophy + qwed-verification) must first be aligned to current architecture (Issue #7), every example must run (Issue #8), and version references must be consistent (Issue #9). Only then does adding new ecosystem coverage make sense — otherwise, the new module inherits the same stale patterns.