IAwiz87 · IAwiz87 · Jul 20, 2026
diff --git a/README.md b/README.md
@@ -141,7 +141,7 @@ The current implementation was exercised with:
 |---|---|
 | Root `terraform validate` and format check | Passed |
 | Terraform native mock tests | Root 2/2, KMS 6/6, ALB 5/5 passed without credentials |
-| OPA 1.18.2 | 42/42 tests passed |
+| OPA 1.18.2 | 57/57 tests passed |
 | Conftest | Generated hybrid plan passed; generated classical-only plan was denied with 2 failures; malformed plan was blocked |
 | Checkov 3.3.8 / Trivy 0.69.2 | Zero blocking findings; scanner images pinned by digest |
 | Live AWS KMS | `ML_DSA_65` created, KMS sign/verify passed, OpenSSL 3.5.7 verification passed, key entered `PendingDeletion` |

diff --git a/ROADMAP.md b/ROADMAP.md
@@ -2,6 +2,8 @@
 
 QuantumForge expands measurement before remediation surface. New cloud deployment modules should not outrun the inventory, policy, test, and evidence systems needed to evaluate them.
 
+This roadmap distills future work into concrete engineering items. Have an idea, or want to claim an item below? Open an issue or see [CONTRIBUTING.md](CONTRIBUTING.md) before starting a PR. Weighting rationale for the risk-scoring items lives in [docs/SCORING_METHODOLOGY.md](docs/SCORING_METHODOLOGY.md), not here.
+
 ## Shipped foundations
 
 - [x] AWS Provider 6.x compatibility and committed lockfiles
@@ -12,31 +14,53 @@ QuantumForge expands measurement before remediation surface. New cloud deploymen
 - [x] Real AWS ML-DSA KMS sign/verify lifecycle harness
 - [x] Real ALB hybrid PQ-TLS plus classical-fallback runtime harness
 - [x] Separate inherent risk, migration urgency, remediation effort, and evidence confidence
+- [x] Impact promoted to a first-class, co-primary scoring dimension alongside HNDL exposure and data classification (`impact_weight` in `risk_score.rego`)
+- [x] Deadline pressure as an independent 0-100 scale blended into migration urgency (80/20), replacing the additive-and-clamped model that collapsed differentiation inside the critical tier
+- [x] Calendar-anchored deadlines derived from CNSA 2.0 equipment categories, recomputed from the current time so a stale hand-entered "months remaining" field can't quietly rot
+- [x] Overdue assets (`migration_deadline_months < 0`) as valid, maximally-urgent input rather than rejected input
+- [x] Classification/impact divergence flagged for review rather than silently double-counted
+- [x] Dependency-fan-in advisory hint for possibly-underrated `impact` values (`dependent_asset_count`)
+- [x] `migration_work_queue`: a single ranked list across all valid assets by risk, then urgency, with remediation effort used only as a tiebreaker — the previously-unscheduled "PQC Migration Priority Matrix generator" (see Priority 2 below)
 - [x] Owned, approved, expiring exception records
 - [x] Attested evidence bundles and an S3 Object Lock publishing interface
 - [x] Versioned vendor-neutral crypto-inventory schema
 
 ## Priority 1: discovery coverage
 
-Expand source-specific collectors and converters into the canonical inventory schema:
-
-1. cloud API collectors for keys, certificates, CAs, TLS policies, VPN/IPsec, and ownership tags
-2. Cryptographic Bill of Materials (CBOM) and application dependency ingestion
-3. active and passive protocol observations
-4. certificate expiry, signature, key-size, and chain metadata
-5. data-flow, environment, business impact, and secrecy-lifetime enrichment
-6. SaaS and manual attestations with explicit confidence
-7. Kubernetes, container-image, and service-mesh inventory
-
-Unknown or incomplete evidence must remain visible. A failed collector cannot become an empty or compliant inventory.
+Expand source-specific collectors and converters into the canonical inventory schema. Unknown or incomplete evidence must remain visible — a failed collector cannot become an empty or compliant inventory.
+
+1. **Cloud API collectors for keys, certificates, CAs, TLS policies, VPN/IPsec, and ownership tags** — extends beyond the current Terraform-plan-only collection to assets never provisioned through Terraform.
+   - [ ] AWS: ACM, KMS custom key stores, and Secrets Manager rotation policies via the AWS SDK, populating `source: "cloud_api"` (already in the schema's `source` enum, currently only emitted in fixtures/design, not by a real collector)
+   - [ ] Azure: Key Vault and Managed HSM inventory via the Azure SDK
+   - [ ] GCP: Cloud KMS and Certificate Manager via the Cloud SDK
+   - [ ] Carry ownership/environment tags into `metadata` rather than dropping them, matching the Terraform-plan collector's existing behavior
+   - [ ] Add `policies/inventory/validate_test.rego` cases for the new collector outputs
+2. **Cryptographic Bill of Materials (CBOM) and application dependency ingestion**
+   - [ ] Define a CycloneDX-CBOM-to-inventory converter emitting `crypto_function: "library"` / `"protocol"` records with `source: "cbom"`
+   - [ ] Handle unknown/unparseable CBOM entries as `classification: "unknown"`, never dropped
+3. **Active and passive protocol observations**
+   - [ ] Normalize TLS handshake captures (cipher suite, key exchange group) into the schema's `protocol` and `algorithm` fields
+4. **Certificate expiry, signature, key-size, and chain metadata**
+   - [ ] Populate `certificate_not_after` and `key_size_bits` from CA/certificate stores already discoverable via existing collectors, rather than requiring a new source
+5. **Data-flow, environment, business impact, and secrecy-lifetime enrichment**
+   - [ ] Build an enrichment step that fills `data_flow`, `secrecy_lifetime_years`, `data_classification`, and `impact` from ownership/CMDB records so these aren't purely manual entry
+   - [ ] Feed `dependent_asset_count` (Priority-2-adjacent, see gap notes in `docs/SCORING_METHODOLOGY.md`) from the same enrichment pass once a real dependency graph exists
+6. **SaaS and manual attestations with explicit confidence**
+   - [ ] Structured attestation template mapping directly to `source: "manual_attestation"` plus a required `evidence_confidence`
+7. **Kubernetes, container-image, and service-mesh inventory**
+   - [ ] cert-manager and service-mesh mTLS certificate inventory, feeding the same schema ahead of any Kubernetes remediation module (see Priority 3)
 
 ## Priority 2: governance automation
 
-- generate migration work queues from risk and urgency while keeping effort separate
-- require independent approval and immutable history for exceptions
-- add policy/version metadata to every decision
-- add dashboards for inventory coverage, stale observations, unknown algorithms, and expiring exceptions
-- add automated NIST Cryptographic Module Validation Program (CMVP) watchlist comparison after a stable machine-readable source and baseline snapshot exist
+- [x] Generate migration work queues from risk and urgency while keeping effort separate — implemented as `migration_work_queue` in `policies/scoring/risk_score.rego`, sorted by `inherent_risk_score` desc, then `migration_urgency_score` desc, with `remediation_effort` used only as a tiebreaker. This is the previously-unscheduled "PQC Migration Priority Matrix generator" (see the restored section below) — folded in here rather than left as a separate, disconnected idea.
+- [ ] Require independent approval and immutable history for exceptions
+  - [ ] `policies/governance/exceptions.rego` already requires owner/approver/rationale/compensating controls; add a check that `owner != approver` for a real independent-approval guarantee
+  - [ ] Exception renewals must append a new record rather than mutate `expires_at` in place — add a test asserting the same `id` cannot appear twice with different `expires_at` values (distinct from the existing `duplicate_exception_ids` check, which only catches exact-ID collisions)
+- [ ] Add policy/version metadata to every decision
+  - [ ] Stamp `assessment.policy_version` (git SHA or semver) into `risk_score.rego`'s and `exceptions.rego`'s output objects so an old evidence bundle can be tied back to the exact policy version that produced it
+- [ ] Add dashboards for inventory coverage, stale observations, unknown algorithms, and expiring exceptions
+  - [ ] Start from `assessment.invalid_inventory`, `priority_matrix`, and `migration_work_queue` as the data source; no new Rego needed to start, just a rendering layer
+- [ ] Add automated NIST Cryptographic Module Validation Program (CMVP) watchlist comparison after a stable machine-readable source and baseline snapshot exist (see restored section below for the specific source)
 
 ## Priority 3: platform remediation modules
 
@@ -53,6 +77,22 @@ Only add deployment modules when the target API is generally available and can b
 
 Azure, GCP, on-prem, SaaS, and application assets can already be represented in `schemas/crypto-inventory.schema.json`; representation does not imply deployable PQC support.
 
+Every new Terraform module should follow the pattern already established by `hybrid-pqc-kms`/`hybrid-pqc-alb`:
+
+- [ ] Variable `validation` blocks constrain inputs to NIST-approved algorithms/constructions — never rely on documentation alone
+- [ ] `terraform validate` and `terraform fmt -check -recursive` clean before merge
+- [ ] A discovery policy update so `policies/discovery/classify.rego` recognizes the new resource type
+- [ ] A README module table entry and a Validation Status row
+
+## Other Build Guide items not yet scheduled
+
+Called out in the [PQC Readiness Program Build Guide](docs/PQC_Readiness_Program_Build_Guide.md) but not currently sequenced. Two of the four items previously listed here have moved: automated CMVP watchlist comparison is now tracked under Priority 2 above, and the Migration Priority Matrix generator is implemented (see Shipped foundations and Priority 2). The remaining two:
+
+- **CBOM generation in CI** — wire CycloneDX-CBOM generation into `census.yml` rather than leaving it a manual step ahead of the CBOM ingestion work in Priority 1.
+- **Executive crypto-census briefing generator** — auto-produce the board-ready "% of estate quantum-vulnerable" summary directly from `assessment` (inventory + scoring output), rather than a manually assembled deck.
+
+CMVP watchlist comparison specifically means scripting the cross-reference against the [NIST CMVP Modules in Process list](https://csrc.nist.gov/projects/cryptographic-module-validation-program/modules-in-process/modules-in-process-list) instead of doing it manually — tracked as the last bullet under Priority 2.
+
 ## Contribution rule
 
 Every new collector or module must include:
@@ -64,3 +104,12 @@ Every new collector or module must include:
 - live verification when claiming platform behavior
 - unconditional cleanup and a cost estimate for paid tests
 - updated inventory, policy, and evidence documentation
+
+## Status legend
+
+| Symbol | Meaning |
+|---|---|
+| [x] | Shipped |
+| [ ] | Planned, not started |
+
+This roadmap reflects current thinking and will shift as platform PQC support (especially Azure and GCP) matures and as discovery coverage expands. Open an issue if you want to propose reordering or adding an item.
diff --git a/docs/GOVERNANCE.md b/docs/GOVERNANCE.md
@@ -2,16 +2,24 @@
 
 ## Risk model
 
-`policies/scoring/risk_score.rego` keeps four decision dimensions separate:
+`policies/scoring/risk_score.rego` keeps decision dimensions separate:
 
-- `inherent_risk_score` (0–100): exposure to data stolen now and decrypted after future quantum advances, data classification, and business impact
-- `migration_urgency_score` (0–100): inherent risk plus a deadline-pressure weight
-- `remediation_effort`: `low`, `medium`, or `high`; it never reduces risk
-- `evidence_confidence`: `1.0`, `0.7`, or `0.4`; it is reported independently rather than multiplying risk downward
+- `inherent_risk_score` (0–100): HNDL exposure window, data classification, and business impact, summed
+- `migration_urgency_score` (0–100): a weighted blend of `inherent_risk_score` (80%) and a separate 0–100 `deadline_pressure_score` (20%) — not an additive bonus clamped at 100, so two assets can share the same inherent risk yet still rank differently by how close their deadline is
+- `remediation_effort`: `low`, `medium`, or `high`; it never reduces risk — the only place it affects ordering is as a tiebreaker in `migration_work_queue` between assets that already tie on risk and urgency
+- `evidence_confidence`: `1.0`, `0.7`, or `0.4`; reported independently rather than multiplying risk downward
+- `needs_divergence_review`: flags assets where `data_classification` and `impact` tiers diverge by 2+ levels, since the two are summed as if independent but correlate in practice — advisory only, never changes the score
+- `impact_may_be_underrated`: flags assets whose optional `dependent_asset_count` suggests a higher blast radius than the manually assigned `impact` tier — advisory only, never overrides the manual value
 
-Scoring consumes the same canonical inventory contract as discovery. Before scoring, enrich each asset with the schema-defined optional fields `secrecy_lifetime_years`, `data_classification`, `impact`, `migration_deadline_months`, and `remediation_effort`. Results are keyed by `asset_id`. Missing, malformed, negative, or unsupported enrichment appears in `invalid_inventory` and is not silently scored with optimistic defaults.
+The full weighting rationale, the deadline-pressure bucket boundaries, and worked examples are in [SCORING_METHODOLOGY.md](SCORING_METHODOLOGY.md).
 
-See [`examples/inventory/scoring-ready-inventory.json`](../examples/inventory/scoring-ready-inventory.json) for a schema-valid end-to-end input.
+An asset's deadline can come from either input: an explicit `migration_deadline_months` (which may be negative — an asset that has already missed its deadline is valid input, not an error), or an optional `regulatory_category` mapped to the CNSA 2.0 equipment-category calendar and recomputed from the current time on every evaluation so it never goes stale. An explicit `migration_deadline_months` always takes precedence when both are present.
+
+`migration_work_queue` produces a single ranked list across all valid assets — sorted by `inherent_risk_score` descending, then `migration_urgency_score` descending, with `remediation_effort` used only to break ties — implementing the roadmap's migration-priority-matrix generator. `priority_matrix` still groups assets by tier for a coarser view.
+
+Scoring consumes the same canonical inventory contract as discovery. Before scoring, enrich each asset with the schema-defined optional fields `secrecy_lifetime_years`, `data_classification`, `impact`, `migration_deadline_months` or `regulatory_category`, `remediation_effort`, and optionally `dependent_asset_count`. Results are keyed by `asset_id`. Missing, malformed, or unsupported enrichment appears in `invalid_inventory` and is not silently scored with optimistic defaults.
+
+See [`examples/inventory/scoring-ready-inventory.json`](../examples/inventory/scoring-ready-inventory.json) and [`examples/inventory/calendar-anchored-inventory.json`](../examples/inventory/calendar-anchored-inventory.json) for schema-valid end-to-end inputs.
 
 ## Exceptions
 

diff --git a/docs/INVENTORY.md b/docs/INVENTORY.md
@@ -46,7 +46,7 @@ check-jsonschema \
 
 The collector emits the standard `{schema_version, assets}` document, normalizes KMS `SIGN_VERIFY` to `signing`, carries Terraform tags into metadata, and records one observation timestamp for the full collection. Missing owner or environment tags remain explicit as `unassigned` or `unknown`; downstream enrichment should resolve them rather than silently dropping the assets.
 
-Risk enrichment remains inside the same schema through optional `secrecy_lifetime_years`, `data_classification`, `impact`, `migration_deadline_months`, and `remediation_effort` fields. `examples/inventory/scoring-ready-inventory.json` demonstrates an asset that can be validated and scored without discarding information during conversion.
+Risk enrichment remains inside the same schema through optional `secrecy_lifetime_years`, `data_classification`, `impact`, `migration_deadline_months` (or the calendar-anchored `regulatory_category` alternative), `remediation_effort`, and `dependent_asset_count` fields. `examples/inventory/scoring-ready-inventory.json` and `examples/inventory/calendar-anchored-inventory.json` demonstrate assets that can be validated and scored without discarding information during conversion. See [docs/GOVERNANCE.md](GOVERNANCE.md) and [docs/SCORING_METHODOLOGY.md](SCORING_METHODOLOGY.md) for what each field feeds into.
 
 ## Next inventory data sources
 

diff --git a/docs/PQC_Readiness_Program_Build_Guide.md b/docs/PQC_Readiness_Program_Build_Guide.md
@@ -305,6 +305,9 @@ Collected records are normalized into the versioned inventory envelope and class
    tier(asset) := "medium" if migration_urgency_score(asset) >= 35; migration_urgency_score(asset) < 60
    tier(asset) := "low" if migration_urgency_score(asset) < 35
    ```
+
+   > **Note:** this snippet is the Phase 2 origin design and is kept as-written for history. The shipped `policies/scoring/risk_score.rego` has since evolved past it — `deadline_weight`'s additive-and-clamped formula collapsed differentiation once `inherent_risk_score` hit 80, so `migration_urgency_score` is now an explicit 80/20 blend against a separate `deadline_pressure_score` scale, deadlines can be calendar-anchored to a `regulatory_category` instead of only a hand-entered `migration_deadline_months`, and `tier` is now derived from `inherent_risk_score` rather than the blended urgency score. See [docs/SCORING_METHODOLOGY.md](SCORING_METHODOLOGY.md) for the current model and rationale.
+
 2. Write unit tests covering boundary conditions on every tier threshold before deployment:
    ```bash
    opa test -v policies/scoring/