PQC Migration Evidence Workflow

Note (dated 2026-08-04): a chain composes independent computations performed in an analytical order. No step's output is carried into the next step by the execution model; each step computes from its own declared inputs. This is true of every chain on this site, including chains whose per-step copy below reads as a data handoff.

Reading mode (READINESS-BUILD): These checks can be gathered in any order; the sequence below is for convenience. The CBOM lint and the CNSA-2.0 deadline calculation produce two separate evidence receipts; nothing here is executed against a live migration.

Two-node evidence workflow for a declared cryptography inventory. Stage 1 structurally lints a pasted CycloneDX 1.6 CBOM and classifies each declared algorithm asset as quantum-vulnerable or CNSA-2.0 target-aligned. Stage 2 takes a declared inventory of systems — informed by Stage 1's classified components — and computes the applicable CNSA-2.0 migration deadline, days remaining, and FIPS 140-2 Historical-list exposure for each row.

OpenChainGraph · 2 Nodes compliance mandate · Linear Hash-Anchored §4 Client-Side · Zero PII

Not a security scanner, not a cryptographic audit. Every finding and every deadline below is computed from what you declare — the CBOM you paste and the inventory rows you supply — and every classification is asserted. Nothing is discovered, nothing is fetched, zero-egress by contract. This workflow attests the structural checks and the date arithmetic over your declared inputs. It does not scan your systems, does not audit your cryptography, and is not legal or regulatory advice. If the declared inputs are wrong, the receipt faithfully proves the wrong conclusion. Read the PQC Migration Evidence Guide before handing a receipt to a counterparty or regulator.

Workflow Stages · 2 Nodes · Linear

1 ROOT node

CBOM Structural Lint & CNSA-2.0 Classifier art-386-lint-cbom-structure

Validates a pasted CycloneDX 1.6 CBOM against a hand-derived field subset and classifies each declared algorithm asset as quantum-vulnerable (RSA, ECDSA/ECDH, DH, SHA-1) or CNSA-2.0 target-aligned (ML-KEM-1024, ML-DSA-87, AES-256, SHA-384/512). Components classified quantum_vulnerable or cnsa2_ready feed Stage 2 as declared inventory rows.

MCP Call · lint_cbom_structure

{
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "name": "lint_cbom_structure",
    "arguments": {
      "cbom": {
        "bomFormat": "CycloneDX",
        "specVersion": "1.6",
        "components": [
          {
            "type": "cryptographic-asset",
            "name": "RSA-2048",
            "cryptoProperties": {
              "assetType": "algorithm",
              "algorithmProperties": {
                "primitive": "signature",
                "parameterSetIdentifier": "2048",
                "certificationLevel": ["none"],
                "cryptoFunctions": ["sign", "verify"]
              }
            }
          }
        ]
      }
    }
  },
  "id": 1
}

↓

2 TERMINAL node

CNSA 2.0 Deadline Ladder Calculator art-387-pqc-deadline-ladder-calculator

Computes the applicable CNSA-2.0 deadline, days remaining, earliest binding constraint, and FIPS 140-2 Historical-list exposure flag per declared inventory row; rows populated from Stage 1's quantum-vulnerable findings plus each system's declared class and deployment date. This is the terminal migration-evidence receipt.

MCP Call · compute_pqc_deadline_ladder

{
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "name": "compute_pqc_deadline_ladder",
    "arguments": {
      "reference_date": "2026-07-19",
      "inventory": [
        {
          "row_id": "RSA-2048 (Stage 1 finding)",
          "system_class": "nss",
          "asset_type": "signature",
          "deployment_date": "2024-01-01",
          "fips_140_2_certified": false
        }
      ]
    }
  },
  "id": 2
}

Question: As of our review date, has any system in the crypto estate already missed its CNSA 2.0 transition deadline? Run the AINumbers MCP tool `run_chain` with {"chain":"pqc-migration-evidence"} and read `art-387-pqc-deadline-ladder-calculator.summary.past_due_count`. Re-run with `inputs` for `art-387-pqc-deadline-ladder-calculator`, reusing the values that result echoed, with `reference_date` set to "2031-01-05". Compare the same field. Verify: call `verify_execution_hash` (https://mcp.ainumbers.co/mcp) with `claimed_hash` set to `composite_execution_hash` and the full `composite_artifact`. Ledger, for a human re-check: https://ledger.ainumbers.co/ PII rule: send synthetic or anonymised inputs only. The MCP server runs these kernels and logs no payloads. Chain page: https://ainumbers.co/chaingraph/chains/pqc-migration-evidence.html

PQC Migration Evidence Workflow

Ask your agent