You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Updated automatically by the slice-completion procedure (see SLICE-COMPLETION-PROCEDURE.md).
The values below MUST be kept in sync with CHANGELOG.md "Unreleased" entries.
When a slice completes: update its row + commit + push (atomic with the slice's own commit).
Scope (READ CLAUDE.md "Scope Guard" block first)
FedPy is FedRAMP 20x + Rev5 evidence automation. Loops in Core are
in-scope for implementation. Loops in Overlay / Out-of-Core are
parallel compliance regimes preserved as research / roadmap reference
under docs/roadmap/ — not part of the FedRAMP authorization pipeline
and not on the implementation queue.
Overall (Core only)
Total core slices: 102 base + 1 SEC 8-K overlay = 103 counting overlay
Core loops total: 22 (A through S + T + W + X) + 2 CIRCIA extensions (G.G2.CIRCIA, M.M4.CIRCIA) + 1 SEC 8-K overlay (G.G2-SEC-8K)
Loops complete: 5 of 22 (LOOP-A, LOOP-W, LOOP-T, LOOP-B, LOOP-C); LOOP-C COMPLETE (9 of 9 slices done — C.C1, C.C2, C.C3, C.C4, C.C5, C.C6, C.C7, C.C8, C.C9); LOOP-E in progress (2 of 7 slices done — E.E1, E.E2); LOOP-J in progress (2 of 3 slices done — J.J2, J.J3; J.J1 pending)
Last shipped: LOOP-C.C9 (commit 315d5ad)
Next priority: D.D1 (Authorization Boundary Diagram emitter) — the first LOOP-D (Diagram Auto-Generation) slice and the next LOOP-B–K base implementation after LOOP-C completed. All 9 LOOP-C slices (C.C1 CMP → C.C9 Baseline Configuration) are shipped. D.D1 is unblocked — its depends_on (INV-1..S6 inventory chain, REO-0, LOOP-A.A4 submission-bundle) are all done — and it is the highest-leverage pending slice: per docs/DEPENDENCY-GRAPH.md it blocks D.D2 (Network Diagram), D.D3 (Data Flow Diagram), E.E6 (ConMon boundary-drift), G.G4 (AFR-MAS), F.F4, L.L1, and N.N2. D.D1 emits the FedRAMP Authorization Boundary Diagram from the real inventory.json boundary/edge data (SC-7 authorization boundary). LOOP-D → the remaining LOOP-E/F/G/H/I/J/K base slices → then LOOP-L through LOOP-Q → then LOOP-R (PQC), LOOP-S (DFARS, conditional), LOOP-X (Zero Trust), G.G2-SEC-8K, and the CIRCIA extensions, in dependency order. (Note: docs/DEPENDENCY-GRAPH.md lists C.C9 as depending on D.D1–D.D3; the C.C9 per-slice-doc implementation contract does not — C.C9 §4 Reference Architecture is grep-read from providers/*/reference-arch.ts source, not the visual boundary diagram — so C.C9 shipped ahead of LOOP-D per its own contract.)
C.C8 scope note (2026-07-10): C.C8 shipped the full slice end to end — the signed-by-bundle Authorization Request Cover Letter / package transmittal (out/auth-request-cover-letter.docx, PM-10), the CSP-side formal cover letter that ACCOMPANIES a FedRAMP authorization package when it is transmitted to the FedRAMP PMO or an agency AO — distinct from the AO-issued ATO Letter (which is the AO's RESPONSE to this letter). cloud-evidence:core/auth-cover-letter-emit.ts (pure buildCoverLetterBodyXml/renderAuthCoverLetterDocx + disk emitAuthCoverLetterDocx, with exported readers readIndexJson/readApMetadata + resolvers resolveThirdParty/resolveSubmissionDate) auto-links §3/§4 to the run's REAL LOOP-A corpus: §4 Package Contents reads out/INDEX.json (LOOP-A.A4 submission-bundle) and renders one row per artifact — filename + role + the REAL sha256-short (first 12 hex chars of the per-artifact digest) + bytes — alphabetically sorted for stable diffing (Q2), with the true artifact count + the INDEX.json SHA-256; §3 Independent Assessment (3PAO) Statement reads out/ap.json (LOOP-A.A2) metadata for the assessing 3PAO organization + the AP finalization date (last-modified). Each absent LOOP-A input degrades to a REQUIRES-OPERATOR-INPUT marker with a "run with --submission-bundle / --oscal-ap" cross-link (degrade, never block — REO Rule 4). The 7-section body (Letterhead → Addressee → §1 Subject → §2 Request Summary → §3 3PAO → §4 Package Contents → §5 Requested Action → §6 Primary Contacts → §7 Closing + Signature) follows the FedRAMP Agency Authorization Playbook v4.1 §3 structure; §1 quotes NIST SP 800-53 Rev. 5 PM-10(a) verbatim + cites SP 800-37 Rev. 2 §3.6 (Authorize). Operator identity fields — CSP exec signatory (§7), CSP mailing address (letterhead), AO addressee (with optional delegated-designee, Risk 5), 3PAO lead assessor — are operator-supplied via config.yaml#auth_request.* + config.yaml#org.address; the exec signature block is never auto-signed (Risk 6 — the .docx is Ed25519-signed by the pipeline; the wet/electronic exec signature is separate). The document is fully deterministic (no wall-clock time): the metadata UUID is deterministicUuid('auth-cover-letter:'+systemId+':'+runId) and the date line resolves submissionDate → an ISO date embedded in the runId → a REQUIRES-OPERATOR-INPUT "dated at signing" marker (Risk 4), so identical inputs yield a byte-identical .docx (passes unzip -t, 6 OOXML parts; smoke run: 12 package artifacts, 3PAO resolved, ready_for_signature). Orchestrator dispatch (spec reconciliation — the real emitSubmissionBundle is monolithic):--auth-cover-letter (env CLOUD_EVIDENCE_AUTH_COVER_LETTER) + --auth-request-type initial-ato|continued-ato|reauthorization. The per-slice §files called for INDEX-build → cover-letter → bundle-pack, but the shipped bundler builds INDEX.json + packs the tarball in ONE atomic call — so when co-run with --submission-bundle the orchestrator runs a pre-passemitSubmissionBundle (strict:false) to materialize INDEX.json, emits the letter reading it, then the normal bundle dispatch RE-packs the tarball (now the letter is enclosed + enumerated in the final INDEX.json) — realizing the spec's ordering intent. Standalone (no --submission-bundle) the letter reads whatever INDEX.json is on disk (a prior run) and degrades §4. One submission-bundle WELL_KNOWN role registered (auth-cover-letter-docx, conditional). REO: §3/§4 trace to real on-disk LOOP-A files (never fabricated artifacts or 3PAO names); the sha256-short values are real digest prefixes; ready_for_signature gates on exec signatory + AO addressee + 3PAO + ato-type. Spec reconciliation (LOOP-C-RISKS C-C8-7..9): (7) the per-slice §schema names INDEX.json as {artifacts, emitted_at, runId} but the REAL INDEX.json (core/submission-bundle.ts) is {artifacts[{filename,role,description,sha256,bytes,in_manifest,required}], built_at, run_id, ...} — readIndexJson consumes the narrow real fields + run_id and tolerates the extra columns (Risk 2); (8) the per-slice §schema names AP parties:[{name,org,role}] but the REAL ap.json (core/oscal-ap.ts) records organization parties as {uuid,type:'organization',name} with NO per-party role and NO named lead assessor — resolveThirdParty picks the operator-supplied 3PAO first, else the non-CSP organization party (AP convention: CSP first, 3PAO second), and the lead comes only from operator config; (9) the shared core/docx-primitives.ts was again NOT extracted (per-slice §files scope C.C8 to auth-cover-letter-emit.ts + the anti-pattern rule forbids refactoring out-of-scope files) — now 14 emitters to migrate when C-X-1 lands. Open questions resolved: Q1 §4 cites the per-artifact sha256s (not the tarball digest — chicken/egg: the letter is INSIDE the tarball) + notes the tarball SHA is in the post-bundle INDEX.json companion; Q2 §4 rows sorted alphabetically by filename; Q3 single AO addressee, PMO cc'd via §6; Q4 §5 references the Playbook review timeline (no hard-coded day count); Q5 §2 renders a per-ato-type request sentence (initial vs continued vs reauthorization). Tests: cloud-evidence 1568→1586 (+18: 11 §8 contract tests + 7 extras [3PAO resolution precedence, deterministic date fallback, real sha256-short + alphabetical sort, INDEX.json reader tolerance, §3 degrade path, config.sample.yaml round-trip, log event]).
C.C7 scope note (2026-07-08): C.C7 shipped the full slice end to end — the signed-by-bundle Risk Management Strategy (out/rms.docx, PM-9), an 11-section Word document that frames how the CSP manages risk end to end (framing → assessing → responding → monitoring, NIST SP 800-39 §2) and sits ABOVE the per-system SSP + the per-finding POA&M in the SP 800-39 §2.1 three-tier hierarchy. cloud-evidence:core/rms-emit.ts (pure buildRmsBodyXml/renderRmsDocx + disk emitRmsDocx, with exported readers readRiskRegister/readAcceptancePolicy/summarizePoam) auto-links §5/§6/§10 to the run's REAL risk corpus: §5 Risk Register Reference reads out/risk-register.json (LOOP-B.B5, RA-3) and embeds its top-line summary (entries_total / open_count / high_inherent_count / by_source + evidence SHA-256 — Q1: summary, not a full row dump); §6 Risk Acceptance Policy summarizes the .risk-acceptances.json (B.B3) + .compensating-controls.json (B.B4) signed snapshots (counts + SHA-256s); §10 POA&M Summary parses out/poam.json (LOOP-A.A1) into a severity histogram over poam-items (critical/high/medium/low/info), a count of overdue open items (deadline < now, status ≠ closed), and the oldest-open-finding age (from the earliest related observation collected to now — Q4: currently-open only). Each absent LOOP-B/A input degrades to a REQUIRES-OPERATOR-INPUT marker with a "Generate via LOOP-B/--oscal-poam" cross-link (Q2: degrade, never block — REO Rule 4). §4 Risk Response Strategy renders the NIST SP 800-39 Accept / Avoid / Mitigate / Transfer 4-row matrix (published terminology, REO Rule 3; Q3: FedRAMP is silent on a Moderate-vs-High preference, so the generic matrix applies). §7 cross-links to the C.C6 ConMon Strategy when out/conmon-strategy.docx is present, else a REQUIRES-OPERATOR-INPUT marker (Risk 5). §8 Risk Tolerance + §9 Executive Oversight are operator-supplied (config.yaml#rms.tolerance + rms.executive_oversight[]); executive names are never logged (only counts — Risk 6 / C-X-15). The document is fully deterministic (no wall-clock time): the metadata UUID is deterministicUuid('rms:'+systemId+':'+runId) and the §10 "now" for overdue/age derives from the POA&M metadata.last-modified (an input datum, injectable via opts.now for tests — Risk 3), so identical inputs yield a byte-identical .docx (passes unzip -t, 6 OOXML parts; smoke run: register linked, 5 POA&M items, ready_for_signature). Orchestrator --rms (env CLOUD_EVIDENCE_RMS) dispatches the emitter AFTER the ConMon Strategy emit + BEFORE signing (a console warning fires when the LOOP-B register is absent); structured input flows from a new config.yaml#rms.* section (tolerance/executive_oversight/agency_customer_count); one submission-bundle WELL_KNOWN role registered (rms-docx). REO: §5/§6/§10 trace to real on-disk LOOP-A/B files (never fabricated); an unknown poam severity throws PoamSeverityError (Risk 2 — no silent mis-bucket); ready_for_signature gates on tolerance + executive + register link + acceptance policy + system identity. Spec reconciliation (LOOP-C-RISKS C-C7-7..8): (7) the per-slice §schema names count_by_severity: {critical, high, moderate, low} + the §build-step-2 reads out/risk-acceptances.json/out/compensating-controls.json, but the REAL poam severity enum is critical/high/medium/low/info (core/envelope.ts — medium, not moderate) and the REAL B.B3/B.B4 snapshots are the dotfiles .risk-acceptances.json/.compensating-controls.json — summarizePoam buckets by the honest enum and readAcceptancePolicy reads the dotfile first (non-dotted accepted as a fallback), same posture as C-C5-7/C-C6-7; (8) the shared core/docx-primitives.ts was again NOT extracted (per-slice §files scope C.C7 to rms-emit.ts + the anti-pattern rule forbids refactoring out-of-scope files) — now 13 emitters to migrate when C-X-1 lands. Open questions resolved: Q1 §5 embeds the register summary (not full rows); Q2 LOOP-B absent → degrade with cross-link (not block); Q3 §4 uses the generic SP 800-39 matrix (FedRAMP silent Mod-vs-High); Q4 oldest-open age counts currently-open only; Q5 §11 + footer cite the SSP SHA-256 when present. Tests: cloud-evidence 1514→1533 (+19: 12 §8 contract tests + 6 extras [overdue/age computation, PoamSeverityError guard, §6 acceptance summary, §7 ConMon cross-link, config.sample.yaml round-trip, log event] + 1 typed-error case).
C.C6 scope note (2026-07-07): C.C6 shipped the full slice end to end — the signed-by-bundle Continuous Monitoring Strategy + Plan (out/conmon-strategy.docx, CA-7 / CA-7(1) / PM-31), a 13-section Word document that names WHICH controls are under continuous monitoring, at WHAT frequency, backed by WHAT scanning evidence, with WHAT escalation, reported to WHICH endpoint — the configuration LOOP-E reads for its monthly ConMon runs. cloud-evidence:core/conmon-strategy-emit.ts (pure buildConmonStrategyBodyXml/renderConmonStrategyDocx + disk emitConmonStrategyDocx) auto-derives §4 Controls Under Continuous Monitoring from the LIVE core/ksi-map.ts via readKsiCatalog() (greps the source for each KSI id + its real scope, the same trick as roe-emit.ts:readKsiScope, so no provider modules are pulled into the emit bundle; throws ConmonKsiScopeError if <20 KSIs resolve — the live map has 44), and derives the Automated column from each KSI's real scope (CLOUD → automated cloud-SDK evidence; HYBRID → automated signal + process artifact; PROCESS → tracker artifact; INHERITED → leveraged authorization — Q1). §5 Vulnerability Scanning auto-derives from the run's REAL KSI-*VDR* evidence files via readVdrScanners() — one row per provider block (= one scanner), the scanner name read from the collector's own <provider>.vdr.detection_capability_enabled finding summary, detection-enabled from finding.passed, findings/KEV counts from the vdr.summary evidence, last-collected from the envelope collected_at, plus the evidence-file SHA-256 (chain of custody); a disabled scanner is emitted (never omitted — Q4), and when no VDR evidence exists §5 renders a single REQUIRES-OPERATOR-INPUT row (never a fabricated scanner). §3 quotes the FedRAMP ConMon Strategy Guide v3.2 §3.1 VERBATIM + cites the ConMon Playbook v1.0 URL (the monthly cadence is the published FedRAMP baseline with a REQUIRES-OPERATOR-INPUT-VERIFY marker — the clean-room tree does not reproduce the Playbook's prose). §9 reporting endpoint keys off the impact level (Low/Moderate → USDA Connect.gov per the R2 finding; High → agency-direct); §11 escalation defaults to the published FedRAMP Rev5 / CISA BOD 22-01 baseline (KEV 21d / Critical 30d / High 30d / Moderate 90d / Low 180d) sorted SLA-days ascending (KEV first) with a note that the stricter of the FedRAMP SLA and the CISA KEV due date wins (Q2/Q3); §8 deviation-request process defaults to an RFC-0026-citation-only marker (no invented workflow); §12 collaborative ConMon enables only when the flag is set AND >1 agency customer. The document is fully deterministic (no wall-clock time): the metadata UUID is deterministicUuid('conmon-strategy:'+systemId+':'+runId) and §13 + the provenance footer cite the out/ssp.json SHA-256 (Q5) → identical inputs yield a byte-identical .docx (passes unzip -t, 6 OOXML parts; smoke run: 44 KSIs, 2 scanners, endpoint usda-connect.gov). Orchestrator --conmon-strategy (env CLOUD_EVIDENCE_CONMON_STRATEGY) dispatches the emitter AFTER the FIPS 199 emit + BEFORE signing; structured input flows from a new config.yaml#conmon.* section (team/escalation/deviation_request_process/reporting_endpoint/collaborative_conmon/agency_customers); one submission-bundle WELL_KNOWN role registered (conmon-strategy-docx). REO: §4 traces to the live ksi-map grep; §5 rows trace to real VDR evidence files (never synthetic scanner names); ready_for_signature gates on team + escalation + deviation-process (the §5 no-VDR gap is surfaced by the REQUIRES-OPERATOR-INPUT row + scanner_count=0, not by blocking signature). Spec reconciliation (LOOP-C-RISKS C-C6-7..8): (7) the per-slice §7 fixture names (KSI-VDR-IL.signed.json / KSI-VDR-AUS.signed.json) + the §schema flat {scanner_id, scanner_version, last_collected_at, asset_coverage_percent} are stale — the real VDR collector registers as KSI-AFR-VDR and emits KSI-AFR-VDR.json (the .signed.json variant filtered as a duplicate, same as C-C2-7/C-C3-7), with scanners as providers[].findings[] (rule <provider>.vdr.detection_capability_enabled + current_state) and no scanner_version/asset_coverage_percent field; readVdrScanners discovers any KSI-*VDR*.json (real name + the spec-named fixtures + .signed.json fallback, deduped preferring the plain .json), derives one row per provider block, and renders scanner-version/coverage as a REQUIRES-OPERATOR-INPUT-VERIFY note; (8) the shared core/docx-primitives.ts was again NOT extracted (per-slice §files scope C.C6 to conmon-strategy-emit.ts + the anti-pattern rule forbids refactoring out-of-scope files) — now 12 emitters to migrate when C-X-1 lands. Open questions resolved: Q1 §4 Automated column derived from the real KSI scope; Q2/Q3 §11 sorted SLA-ascending + stricter-wins note; Q4 §5 always emits a per-scanner row (disabled → visible gap); Q5 §13 + footer cite the SSP SHA-256 when present. Tests: cloud-evidence 1495→1514 (+19: 13 §8 contract tests + 6 extras [endpoint override, disabled-scanner, .signed.json dedupe, ConmonKsiScopeError, config.sample.yaml round-trip, log event]).
C.C5 scope note (2026-07-07): C.C5 shipped the full slice end to end — the signed-by-bundle FIPS 199 security-categorization worksheet (out/fips199.docx, RA-2 / SC-7), a 6-section Word document that shows the high-water-mark work behind the SSP system-characteristics.security-impact-level. cloud-evidence:core/fips199-emit.ts (pure computeOverallSC/buildFips199BodyXml/renderFips199Docx + disk emitFips199Docx) computes the system-level Security Category as the FIPS 199 §3 high-water-mark across the operator-supplied information types (§3), displays the SC = {(confidentiality, X), (integrity, Y), (availability, Z)} formula (§4), and cross-checks it against the real emitted out/ssp.json — §4.1 renders CONSISTENT / MISMATCH plus a per-objective agreement table. §1.2 quotes the FIPS 199 §3 LOW/MODERATE/HIGH potential-impact definitions + the loss definitions + the SC formula VERBATIM; §2 Methodology cites SP 800-60 V1 §3.1 + the high-water-mark practice; §6 approval signatures stay REQUIRES-OPERATOR-INPUT (RA-2.c — the AO/designee reviews + approves out-of-band; the toolkit never auto-signs, REO Rule 1.10). The new core/fips199-types.ts exports the NIST SP 800-60 Vol. 2 Rev. 1 SaaS-relevant information-type subset (Appendix C — 21 codes: C.2.x Services Delivery Support, C.3.1–C.3.4 Government Resource Management, and the full C.3.5.x Information and Technology Management family) as NIST-published constants (REO Rule 3 allowed exception) with a pinned SOURCE_VERSION. The document is fully deterministic (no wall-clock time): the metadata UUID is deterministicUuid('fips199:'+systemId+':'+runId) and the §1/footer provenance cites the out/ssp.json SHA-256 → identical inputs yield a byte-identical .docx (passes unzip -t, 6 OOXML parts). Orchestrator --fips199 (env CLOUD_EVIDENCE_FIPS199) + the repeatable --fips199-info-type "code:name:c:i:a:rationale" flag dispatch the emitter AFTER the PTA/PIA emit + BEFORE signing; structured input flows from a new config.yaml#fips199.* section (information_types[] + {c,i,a}_rationale + approver); one submission-bundle WELL_KNOWN role registered (fips199-docx). REO: the overall SC traces to a real computeOverallSC() invocation over operator-supplied types — NO hardcoded moderate/moderate/moderate default (zero types → a REQUIRES-OPERATOR-INPUT §3 row with the SP 800-60 V2 selection guidance verbatim, ready_for_signature=false); invalid impact values throw Fips199ImpactError (integrity + availability MUST be low/moderate/high — n/a is permitted only for confidentiality per FIPS 199 §3); a code outside the SP 800-60 V2 subset is accepted with an UNKNOWN-TYPE-CODE annotation (Q3). Spec reconciliation (LOOP-C-RISKS C-C5-7..8): (7) the real emitted security-impact-level is a per-objective OBJECT (security-objective-{confidentiality,integrity,availability}, each fips-199-<level>) plus an overall security-sensitivity-level string, NOT the per-slice-§schemas single-string enum — crossReferenceSsp reads the object shape (richer per-objective comparison), derives the overall from security-sensitivity-level/the objectives, and still tolerates the spec-assumed bare string; (8) the shared core/docx-primitives.ts was again NOT extracted (per-slice §files scope C.C5 to fips199-emit.ts/fips199-types.ts + the anti-pattern rule forbids refactoring out-of-scope files) — now 11 emitters to migrate when C-X-1 lands. Open questions resolved: Q1 §3 does not hard-reject 0 info types (graceful REQUIRES-OPERATOR-INPUT fallback, ready_for_signature gates on ≥1 type + 3 rationales + approver — same posture as cmp-emit); Q2 --fips199-info-type keeps the colon-separated form but treats everything after the 5th colon as the rationale (so rationales may contain colons); Q3 a code outside the SP 800-60 V2 subset is warned (UNKNOWN-TYPE-CODE) + accepted; Q4 §4 cites FIPS 200 as the baseline bridge but leaves the applied SP 800-53 baseline to the SSP (not restated); Q5 FedRAMP 20x Phase Two introduces no categorization steps beyond FIPS 199 as of the pinned catalogue (RFC-0026 silent on RA-2). Tests: cloud-evidence 1474→1495 (+21: 16 fips199-emit [12 per §8 + unknown-code + fixture + log-event + impactToken] + 5 fips199-types sanity).
C.C4 scope note (2026-07-07): C.C4 shipped the full slice end to end — two signed-by-bundle Word documents: the Privacy Threshold Analysis (out/pta.docx, always emitted — 4 sections: §1 System Overview, §2 PTA Determination [5-question form], §3 PII Inventory Evidence, §4 Determination & Signature) and the conditional Privacy Impact Assessment (out/pia.docx, emitted iff the PTA determination is positive OR piaForceMode='always-emit' — 9 sections satisfying PT-2/PT-3/PT-6/AR-2 on the FedRAMP SSP A04 Rev4 template structure). cloud-evidence:core/pta-pia-emit.ts (pure buildPtaBodyXml/buildPiaBodyXml/renderPtaPiaDocx + disk emitPtaPiaDocx) auto-derives the §3 PII-evidence table + PTA-Q1 (collectsPII) from the realout/inventory.json — readPiiInventory walks every asset and selects those tagged data_classification ∈ {pii, phi} (reading snake_case/camelCase/tag-key variants defensively), one evidence row each; resource names are redacted (last path/: segment masked to *** + a stable ref:<sha8> correlation hash) so the privacy doc never leaks PII (Risk 3). The PTA determination emits the PIA iff any of the 5 threshold questions is affirmative (or forced); piaForceMode='never-emit' suppresses the PIA even on a positive PTA and renders a §4 "verify with the privacy officer" warning (Risk 4); when NO asset carries any classification tag, §3 renders a REQUIRES-OPERATOR-INPUT-VERIFY warning that a PTA-negative determination can't be trusted on untagged inventory (Risk 2). Every PIA narrative (authority, purposes, categories, sources, sharing, consent, SORN reference, access/correction, retention, disposal, safeguards, §8 risk assessment) defaults to a verbatim REQUIRES-OPERATOR-INPUT marker — the emitter NEVER invents PII categories like "name, email, SSN" (REO Rule 4); a phi tag adds an advisory §8 HIPAA note (out-of-FedRAMP-scope, Open Q3). The §4/§9 signature cells stay REQUIRES-OPERATOR-INPUT (never auto-signed — REO Rule 1.10). Both docs are fully deterministic (no wall-clock time): UUIDs are deterministicUuid('pta:'+systemId+':'+runId) / deterministicUuid('pia:'+systemId+':'+runId), the template retrieval date is a pinned constant, and §1 provenance cites the inventory content SHA-256 → identical inputs yield byte-identical .docx. Orchestrator --pta-pia (env CLOUD_EVIDENCE_PTA_PIA) dispatches the emitter AFTER the IRP emit + BEFORE signing; structured input flows from a new config.yaml#privacy.* section (pia_force_mode + pta/pia objects, keys = the TS interface field names); two submission-bundle WELL_KNOWN roles registered (pta-docx + conditional:truepia-docx, via a new conditional? field on WellKnownArtifact so a missing PIA is never a missing-required-artifact). REO: every §3 row traces to a real inventory tag (redacted, never substituted); PIA categories empty-not-invented; both .docx pass unzip -t (valid OOXML, 6 parts) + a smoke run confirmed the raw resource names never appear. Spec reconciliation (LOOP-C-RISKS C-C4-7..8): (7) data_classification is a free-form asset tag read defensively (snake/camel/tag-key), NOT the hard pii/phi enum the per-slice §7 "confirm in inventory-emit.ts" assumed — so core/inventory-emit.ts needed NO modification (the free-form tag is applied by the inventory enrichers/operator tags and consumed the same way risk-score.ts reads it); (8) the shared core/docx-primitives.ts was again NOT extracted (per-slice §files scope C.C4 to pta-pia-emit.ts + the anti-pattern rule forbids refactoring out-of-scope files) — now 10 emitters to migrate when C-X-1 lands. Open questions resolved: Q1 §3 counts assets not records (the system doesn't enumerate individual PII records — stated in §3); Q2 multi-cloud PII aggregated into one PTA (PT-2 implies a single authority statement); Q3 a phi tag adds an advisory HIPAA note in PIA §8 (informational only, HIPAA is out of FedRAMP scope); Q4 the SORN reference accepts any operator string (URL preferred, Federal Register number accepted); Q5 the PTA-only emission is still bundle-signed (every emitted artifact is covered by the signed INDEX.json). Deferred (LOOP-C-RISKS C-C4-9): the tracker privacy_responses table / operator UI for PTA/PIA response capture lands with LOOP-E (no tracker subsystem consumes these emitters yet; structured input via config.yaml#privacy.* as a stop-gap — same posture as C-X-13 / C-C3-9). Tests: cloud-evidence 1457→1474 (+17: 16 PTA/PIA [14 per §8 + error-guard + redaction] + 1 log-event).
C.C3 scope note (2026-07-07): C.C3 shipped the full slice end to end — two signed-by-bundle Word documents: the Incident Response Plan (out/irp.docx, IR-8/IR-3/IR-4/IR-6, 11 sections structured per NIST SP 800-61 Rev. 3's CSF 2.0 life-cycle) and the Incident Response Test After-Action Report (out/irp-test-aar.docx, IR-3, 7 sections with the 5-phase timing matrix). cloud-evidence:core/irp-emit.ts (pure buildIrpBodyXml/renderIrpDocx + disk emitIrpDocx) auto-fills the §4 Detect table from the real signed KSI-INR-RIR.json evidence (readInrRirEvidence flattens providers[].findings[] into one detection-source row each — rule + pass/fail + current_state.summary — and derives a coverage percent from the pass ratio; <95% surfaces a warning row per Risk 4); §5 Respond renders the six CSF 2.0 Functions (Govern/Identify/Protect/Detect/Respond/Recover) as sub-sections (the --irp-spec-version=800-61r2 flag swaps in the withdrawn four-phase model); §9 Reporting Requirements bakes the FedRAMP Incident Communications Procedures SLAs (1h PMO + 1h agency + 4h CISA US-CERT) as REQUIRES-OPERATOR-INPUT-VERIFY baseline rows; §3 classification levels + §7 external contacts (FedRAMP info@fedramp.gov + CISA report@cisa.gov role-based addresses, no personal PII — Risk 3) + §8 escalation matrix (sorted severity-desc) default to verify-marked FedRAMP baselines; every operator narrative (team roster, communications plan) defaults to a verbatim REQUIRES-OPERATOR-INPUT marker. core/irp-test-aar.ts renders operator-supplied test scenarios (5-phase timing: detection/response/containment/eradication/recovery minutes since onset — NEVER fabricated; empty scenarios[] → a single REQUIRES-OPERATOR-INPUT row), flags failed scenarios in §4, routes high/critical lessons to a §6 POA&M footer note, and emits a 4-row §7 sign-off block whose signature/date cells stay REQUIRES-OPERATOR-INPUT (the toolkit never auto-signs a human attestation — REO Rule 1.10). Both docs are fully deterministic (no wall-clock time): UUIDs are deterministicUuid('irp:'+systemId+':'+runId) / deterministicUuid('irp-test-aar:'+runId+':'+testDate); testType/testDate default to REQUIRES-OPERATOR-INPUT rather than new Date() (REO Rule 1.7). The AAR anchors to the plan it tested by citing the SHA-256 of out/irp.docx when present (Q4). Orchestrator --irp / --irp-test-aar (envs CLOUD_EVIDENCE_IRP / _IRP_TEST_AAR) + --irp-spec-version dispatch the emitters AFTER the ISCP emit + BEFORE signing (IRP before AAR so the anchor resolves); structured input flows from a new config.yaml#irp.* section; two submission-bundle WELL_KNOWN roles registered (irp-docx, irp-test-aar-docx). REO: every §4 detection row traces to a real INR-RIR finding (never a fabricated "logging is configured" row); §5/§9 quote NIST SP 800-61 Rev. 3 §2.1 + IR-8/IR-3 verbatim; both .docx pass unzip -t (valid OOXML, 6 parts). Spec reconciliation (LOOP-C-RISKS C-C3-7..8): (7) the INR-RIR evidence file name is the real collector output KSI-INR-RIR.json, NOT the per-slice-§7 .signed.json (reader tries .json first, .signed.json fallback — same posture as C-C2-7), and the real envelope carries detection capabilities as providers[].findings[] with a top-level collected_at, NOT the §5-assumed flat evidence[].detection_source/coverage_percent (same posture as C-C2-9); (8) the shared core/docx-primitives.ts was again NOT extracted (per-slice §7 scopes C.C3 to irp-emit.ts/irp-test-aar.ts + the anti-pattern rule forbids refactoring out-of-scope files) — now 8 emitters to migrate when C-X-1 lands. Open questions resolved: Q1 --irp-spec-version defaults to r3 (current standard; no SSP auto-detection — avoids added complexity); Q2 §9 keeps a single CISA row with the "federal data" trigger stated in the row text (no separate involving/not-involving split); Q3 §7 emits an aggregate "Agency POC" row (REQUIRES-OPERATOR-INPUT — each agency customer has its own POC per the ISA/MOU); Q4 the AAR cites out/irp.docx SHA-256 when present; Q5 testType=red-team needs no separate authorization block this slice (deferred to the tracker sign-off flow); Q6 §5 Respond cross-references LOOP-G.G2 AFR-ICP by pointing recovery at the ISCP + naming the communications plan (§6) rather than duplicating the AFR artifact. Deferred (LOOP-C-RISKS C-C3-9): the tracker irp_tests table / operator UI for scenario + roster capture lands with LOOP-E.E7 (no tracker subsystem consumes these emitters yet; structured input via config.yaml#irp.* as a stop-gap). Tests: cloud-evidence 1433→1457 (+24: 14 IRP + 10 AAR).
C.C2 scope note (2026-07-07): C.C2 shipped the full slice end to end — two signed-by-bundle Word documents: the Information System Contingency Plan (out/iscp.docx, CP-2/CP-9/CP-10, 6 sections + 6 appendices per the FedRAMP SSP Appendix G ISCP Template + NIST SP 800-34 Rev. 1) and the Contingency Plan Test After-Action Report (out/iscp-test-aar.docx, CP-4, 6 sections per Appendix G Appendix F). cloud-evidence:core/iscp-emit.ts (pure buildIscpBodyXml/renderIscpDocx + disk emitIscpDocx) auto-fills the §4.2 Recovery-evidence table from the real signed RPL-family KSI files (readRplEvidence reads KSI-RPL-ABO/TRC/RRO/ARP.json, one row per KSI with pass/fail + collected_at + a SHA-256 evidence citation); §2.1 components + Appendix B vendor contacts compose the existing readers (readInventoryComponents/groupComponents imported from cmp-emit.ts; readSubprocessorContacts reads the real subprocessor-inventory.json rows); §1.3 quotes the NIST SP 800-34 §3.1 seven-step process verbatim; every recovery narrative (RTO/RPO, alternate site, activation authority/criteria, rosters) defaults to a verbatim REQUIRES-OPERATOR-INPUT marker. core/iscp-test-aar.ts renders operator-supplied test scenarios + lessons learned (NEVER fabricated — empty scenarios[] → a single REQUIRES-OPERATOR-INPUT row naming the runId), flags failed scenarios in §3, routes high/critical lessons to a POA&M footer note, and emits a 4-row §6 sign-off block whose signature/date cells stay REQUIRES-OPERATOR-INPUT (the toolkit never auto-signs a human attestation — REO Rule 1.10). Both docs are fully deterministic (no wall-clock time): UUIDs are deterministicUuid('iscp:'+systemId+':'+runId) / deterministicUuid('iscp-test-aar:'+runId+':'+testDate); testDate defaults to REQUIRES-OPERATOR-INPUT rather than new Date() (REO Rule 1.7). The AAR anchors to the plan it tested by citing the SHA-256 of out/iscp.docx when present (Q4). Orchestrator --iscp / --iscp-test-aar (envs CLOUD_EVIDENCE_ISCP / _ISCP_TEST_AAR) + four value flags (--iscp-rto-hours/--iscp-rpo-hours/--iscp-test-date/--iscp-test-type) dispatch the emitters AFTER the CMP emit + BEFORE signing (ISCP before AAR so the anchor resolves); structured input flows from a new config.yaml#iscp.* section; two submission-bundle WELL_KNOWN roles registered (iscp-docx, iscp-test-aar-docx). REO: every §4.2 row traces to a real signed evidence file (never a fabricated "backup is configured" row); Appendix B traces to real subprocessor rows (SA-9 inventory has no contact/phone, so those cells are REQUIRES-OPERATOR-INPUT, not invented); both .docx pass unzip -t (valid OOXML). Spec reconciliation (LOOP-C-RISKS C-C2-7..10): (7) the RPL evidence file name is the real collector output KSI-RPL-*.json, NOT the per-slice-§5 .signed.json (the collector filters .signed.json out as a duplicate; the reader tries .json first, .signed.json as fallback); (8) Appendix B reads the real subprocessor-inventory.json ({rows:[…]}), NOT the spec-named out/subprocessors.json (read as a fallback, both shapes tolerated); (9) the narrow KsiEvidence interface consumes the envelope's top-level collected_at + rollup.pass, NOT the §5-assumed findings[].metadata.last_collected_at; (10) the shared core/docx-primitives.ts was again NOT extracted (per-slice §7 scopes C.C2 to iscp-emit.ts/iscp-test-aar.ts + the anti-pattern rule forbids refactoring out-of-scope files) — now 6 emitters to migrate when C-X-1 lands. Open questions resolved: Q1 no per-row RFC 3161 TST in §4.2 (kept compact; chain-of-custody via the SHA-256 citations + bundle INDEX.json); Q2 the ISCP §2 is the canonical contingency narrative, seeded from out/ssp.jsonsystem-characteristics.description when present (readSspDescription); Q3 §4.2 groups by KSI ID (one row per RPL KSI, matching each envelope's own multi-provider aggregation); Q4 the AAR cites out/iscp.docx SHA-256 when present; Q5 testType defaults to REQUIRES-OPERATOR-INPUT (no tabletop default — avoids fabrication); Q6 Appendix C is framework-only REQUIRES-OPERATOR-INPUT (per-cloud runbook linking deferred — no config surface added this slice). Deferred (LOOP-C-RISKS C-C2-11): the tracker iscp_tests table / operator UI for scenario capture lands with LOOP-E.E7 (no tracker subsystem consumes these emitters yet). Tests: cloud-evidence 1409→1433 (+24: 14 ISCP + 10 AAR).
C.C1 scope note (2026-07-07): C.C1 shipped the core deliverable end to end — the signed-by-bundle Configuration Management Plan (out/cmp.docx), an 11-section CM-9 Word document. cloud-evidence:core/cmp-emit.ts (pure buildCmpBodyXml/renderCmpDocx + disk emitCmpDocx) auto-derives §4 Configuration Items from the real out/inventory.json (CM-8), grouped by (provider, assetType) with per-group counts + distinct locations; §7 Configuration Monitoring lists the real KSI domains grepped from core/ksi-map.ts (44 domains; the emitter throws CmpKsiScopeError if <20 resolve). Every process-narrative section — §3 CCB roster (NIST SP 800-128 §2.1 four roles), §6 change-control (CM-3/CM-4), §8 change windows, §9 rollback authority, §10 tooling — defaults to a verbatim REQUIRES-OPERATOR-INPUT marker; inferred cloud-native CM tooling (§10, from the inventory provider set) uses the distinct REQUIRES-OPERATOR-INPUT-VERIFY marker so the operator confirms actual use. The document is fully deterministic (no wall-clock time): the docProps/core.xml<dc:title> carries deterministicUuid('cmp:'+systemId+':'+runId) and the §1 provenance cites the inventory content SHA-256, so identical inputs yield a byte-identical .docx. Orchestrator --cmp (env CLOUD_EVIDENCE_CMP) + four value flags (--cmp-approval-narrative/--cmp-rollback-authority/--cmp-change-windows/--cmp-baseline-config-href, each with an env + a config.yaml#cmp.* fallback) dispatch the emitter AFTER the RoE emit + BEFORE signing; submission-bundle WELL_KNOWN role cmp-docx registered; config.yaml gained the cmp: section. REO: every §4 row traces to a real inventory asset (never fabricated); §7 traces to the live ksi-map; narratives are operator-supplied-or-marked; the operator/CSP is author-of-record (the system never auto-approves — CM-9.d). Spec reconciliation (LOOP-C-RISKS C-C1-6..8): (6) the LOOP-C-SPEC §4 "pre-slice" shared core/docx-primitives.ts was not extracted — the per-slice-doc §7 file list scopes C.C1 to cmp-emit.ts only, and the four shipped docx emitters (ssp-docx/roe-emit/section889-rep-docx/section889-report-docx) each keep local OOXML constants; C.C1 follows that precedent (cross-cutting C-X-1 remains a future refactor); (7) deterministicUuid takes a single seed string (not the (slice, systemId, runId) triple C-X-3 assumed) — composed as cmp:${systemId}:${runId}; (8) .docx is not in core/sign.tsSIGNED_EXTENSIONS (.json/.xml/.pem/.md/.pdf), so cmp.docx is a printable companion like roe.docx/ssp.docx — its integrity is anchored by the signed submission-bundle INDEX.json (which SHA-256s + Ed25519-signs every included file), not a per-file .sig. §5 cross-link to baseline-config.docx is a text reference (the C-X-9 active-hyperlink helper is deferred with the primitives). Open questions resolved: Q1 §3 emits only the four REQUIRES-OPERATOR-INPUT role rows when the roster is empty (no fabricated FedRAMP RBAC roster); Q2 §6 cites CM-3/CM-4 directly (LOOP-E.E5 Deviation Request flow not yet shipped); Q3 §4 aggregates by (provider, assetType) with a Location(s) column (compact + sampling-friendly, no per-region row explosion); Q4 account/subscription IDs not enumerated (current inventory shape exposes provider+location; a future enricher can add them); Q5 --cmp-baseline-config-href accepts any string (relative path or URL). Tests: cloud-evidence 1391→1409 (+18).
B.B5 scope note (2026-07-02): B.B5 shipped the full slice end to end across BOTH workspaces (COMPLETING LOOP-B, per the [[B.B4 scope note]] full-stack precedent). cloud-evidence: the pure aggregator core/risk-register.ts (buildRiskRegister/emitRiskRegister) JOINS the just-emitted OSCAL POA&M risks (B.B1+B.B2, band-derived from each risk's epss-percentile→likelihood + criticality→impact props), the signed B.B3 acceptance snapshot, the B.B4 compensating-control snapshot, and the new operator-entered organisational-risk snapshot into a signed out/risk-register.json + out/risk-register.xlsx (NIST RA-3 deliverable). Likelihood/impact use the NIST SP 800-30 Rev 1 qualitative tokens VERBATIM; inherent = INHERENT_RISK_MATRIX (Table I-2, pinned constant); residual drops one band per active compensating control (two for transfer/avoid). De-dup: an acceptance covering a poam-item suppresses the finding entry (prefer treatment=accept). A REQUIRES-OPERATOR-INPUT B.B1 source marker propagates through to the band (visible, never a silent zero). New core/risk-register-xlsx.ts renders the single "Risk Register" sheet (20 cols A..T, frozen header pane, red-fill on high/very-high inherent + bold-red on very-high residual, wrapped Description) via the dependency-free store-only OOXML writer (core/zip.ts); core/organisational-risk-reader.ts pulls organisational_risks over HTTP + writes the signed out/.organisational-risks.json snapshot. Orchestrator --risk-register (env CLOUD_EVIDENCE_RISK_REGISTER) runs AFTER the POA&M emit + BEFORE signing; --pull-organisational-risks <url> (env CLOUD_EVIDENCE_ORGANISATIONAL_RISKS_URL; defaults to the --pull-risk-acceptances tracker URL) runs the pull first; three submission-bundle WELL_KNOWN roles registered (risk-register-json/risk-register-xlsx/organisational-risks-snapshot); inventory-coverage.ts gained the risk_register_coverage sibling (G2-safe). Tracker (tracker/, Hono + better-sqlite3 + React): new organisational_risks table (server/schema.sql, additive CREATE TABLE IF NOT EXISTS); Hono CRUD routes (server/routes/risk-register.ts — create/list/detail/update/close + aggregated GET /api/risk-register + GET /api/risk-register/export.xlsx) with manual validation (no zod), server-side inherent computation from the same Table I-2 matrix (Q5), NIST-catalog + compensating-control cross-checks, and a ≥30-day-forward review_date gate; B.B5 permissions added to server/rbac.ts (create/close = iso/ao/admin [risk ownership], read = all); server/risk-register-xlsx.ts is a tracker-local copy of the renderer (separate workspace — cannot import cloud-evidence); React pages (client/src/pages/RiskRegister{,}.tsx + OrganisationalRisk{Create,Detail}.tsx + client/src/lib/risk-register-{api,view}.ts + App.tsx routes/nav). REO: every finding entry traces to a real OSCAL risk (JOIN, not generator); organisational rows are verbatim operator input (title 5-200, description ≥100, server-enforced); air-gapped/no-snapshot ⇒ organisational entries simply absent (logged, never fabricated). Open questions resolved: Q1 second By-Category sheet deferred (single sheet; tests pin sheet 1); Q2 aggregated endpoint lives on the tracker server (UI-facing), the orchestrator emits the offline artifact; Q3 aggregator reads only non-closed POA&M risks (remediated drop off); Q4 owner = role label (ISO/AO) for finding/acceptance, tracker user name for organisational; Q5 server computes inherent (deterministic), residual operator-set; Q6 per-period trend snapshot deferred to E.E1; Q7 frozen header via OOXML <pane>; Q8 expiration-warning column deferred. Spec reconciliation (LOOP-B-RISKS B.B5-11..13): (11) no SheetJS in either workspace — the spec's "SheetJS round-trip" is realised as valid-OOXML round-trip via the repo zip reader; (12) the XLSX renderer is duplicated tracker-side (separate npm workspace, no cross-import) — a future column change must touch both; (13) the tracker aggregated endpoint returns the tracker-resident subset (organisational + acceptance) — the authoritative finding-inclusive RA-3 register is the collector's out/risk-register.json. Tests: cloud-evidence 1372→1391 (+19: 13 aggregator + 4 xlsx + 2 reader), tracker 159→178 (+19: 10 routes + 9 view).
B.B4 scope note (2026-07-02): B.B4 shipped the full slice end to end across BOTH workspaces (the tracker subsystem is real, per the [[B.B3 scope note]]). Tracker (tracker/, Hono + better-sqlite3 + React): new compensating_controls table (server/schema.sql, additive CREATE TABLE IF NOT EXISTS — verified on fresh + existing DBs); Hono CRUD routes (server/routes/compensating-controls.ts — create-draft/list/uuid-exists/detail/verify/update-draft/activate/retire with manual validation, no zod); a compensating-control signing module (server/compensating-control-sign.ts) that REUSES the B.B3 resident Ed25519 key + RFC-8785 canonicalisation (risk-acceptance-sign.ts) and adds the two payload shapes — activation writes a second signature so AO sign-off is non-repudiable; server-side NIST 800-53 Rev 5 validation (server/nist-catalog.ts + committed copy server/data/nist-r5-controls.generated.json, O(1) Set lookup, AC-2(3)↔ac-2.3 normalisation); B.B4 permissions added to server/rbac.ts (create = iso/admin, activate = ao/admin [separation of duties — an iso implements but cannot self-activate], retire = iso/ao/admin, read = all); route mounted in server/index.ts; React pages (client/src/pages/CompensatingControl{s,Create,Detail}.tsx + client/src/lib/compensating-control-{api,view}.ts + App.tsx routes/nav). cloud-evidence:core/compensating-control-reader.ts pulls the tracker's active controls over HTTP, verifies every record's Ed25519 signature against the tracker's published public key, and writes the signed out/.compensating-controls.json snapshot (provenance-stamped); core/oscal-poam.ts fills each accepted risk's risk.remediations[] with lifecycle='completed' entries carrying the control's title/description + compensating-control-uuid + one nist-control prop per id + evidence link (getCompensatingControl re-checks status='active' AND unexpired — defence-in-depth — so a draft/expired/retired/unknown uuid surfaces as a REQUIRES-OPERATOR-INPUT: unknown uuid marker, never silently dropped); orchestrator --pull-compensating-controls <url> (env CLOUD_EVIDENCE_COMPENSATING_CONTROLS_URL; defaults to the --pull-risk-acceptances tracker URL) runs the pull before the POA&M emit; submission-bundle WELL_KNOWN role compensating-controls-snapshot registered; core/nist-r5.ts gained the shared isValidControlId/normalizeControlId primitives. REO: all registry content is verbatim operator input (title 5-200, description ≥200, server-enforced); NIST ids validate against the published catalog (invalid → 400 naming the offending value); signatures are real Ed25519; the system never auto-activates; a retired control cited by an active acceptance is 409-blocked (B.B4-4). Open questions resolved: Q1 catalog shipped as a static tracker asset; Q2 enhancements validated (AC-2(3)); Q4 expiration optional with a UI annual-review nudge; Q6 NIST ids in props not description; Q7 evidence_sha256 is in the signed payload (forward-compat for H.4-before-create). Spec reconciliation (LOOP-B-RISKS B.B4-10/11): the per-slice doc assumed Express + a fresh compensating-control-sign.ts keypair + .test.tsx DOM-render UI tests; reality is Hono + reused B.B3 signing key + pure compensating-control-view.ts logic unit-tested in tests/ (no jsdom). Tests: tracker 130→159 (+29), cloud-evidence 1354→1372 (+18).
B.B3 scope note (2026-07-02): B.B3 shipped the full slice (not core-only) — the risk-acceptance workflow lives end to end across BOTH workspaces. Tracker (tracker/, Hono + better-sqlite3 + React — a real subsystem that has existed since the initial commit; the prior slices' "no tracker subsystem" deferrals rested on a false premise): new signing_keys + risk_acceptances + risk_acceptance_compensating_links tables (server/schema.sql); a new Ed25519 signing subsystem the tracker never had (server/risk-acceptance-sign.ts — resident-key registry + RFC-8785-compatible canonicalisation byte-identical to cloud-evidence/core/sign.ts); Hono routes (server/routes/risk-acceptance.ts — create/list/detail/verify/approve/revoke/expire) with manual validation (the tracker has no zod); three FedRAMP separation-of-duties RBAC roles added (iso creates/revokes, ao approves, assessor reads — distinct from admin so an ISO cannot self-approve; server/rbac.ts + a widened users.role CHECK migration in server/db.ts, verified additive on both fresh + existing DBs); the hourly expiry enforcer (server/risk-acceptance-enforcer.ts, booted from server/index.ts); and React pages (client/src/pages/RiskAcceptance{,Create,Detail}.tsx + client/src/lib/risk-acceptance-{api,view}.ts + App.tsx routes/nav). cloud-evidence:core/risk-acceptance-reader.ts pulls the tracker's approved acceptances over HTTP, verifies every record's Ed25519 signature against the tracker's published public key, and writes the signed out/.risk-acceptances.json snapshot (provenance-stamped, camelCase G3); core/oscal-poam.ts flips a matching finding's risk to risk.status="deviation-approved", overrides the deadline to the acceptance expiration_date, and attaches acceptance-* + compensating-control-uuid props — only for status='approved' AND expiration_date>now() records (defence-in-depth: the reader re-checks expiry so an unswept row never propagates); orchestrator --pull-risk-acceptances <url> + --tracker-api-token (env CLOUD_EVIDENCE_TRACKER_URL / _TOKEN) run the pull before the POA&M emit; submission-bundle WELL_KNOWN role risk-acceptances-snapshot registered. REO: signatures are real Ed25519 over canonical JSON; business_justification is verbatim operator input (min 100 chars, server-enforced); AO approval requires the ao/admin permission + writes a second signature; the system never auto-approves and never fabricates an acceptance (air-gapped/no-snapshot ⇒ every risk stays open, logged risk-acceptance:missing-snapshot). Spec reconciliation: the per-slice doc assumed Express + zod + iso/ao role-list middleware + a pre-existing tracker/server/sign.ts — reality is Hono + manual validation + permission-based RBAC + no prior signing subsystem, so B.B3 added the signing primitive and mapped to permissions (LOOP-B-RISKS B.B3-11). UI-test approach: the tracker toolchain has no jsdom/@testing-library and vitest only collects server/**+tests/**, so the components' validation + role-gating logic was extracted to the pure client/src/lib/risk-acceptance-view.ts and unit-tested (tracker/tests/risk-acceptance-view.test.ts) instead of DOM-render tests (LOOP-B-RISKS B.B3-12). Deferred (LOOP-B-RISKS B.B3-EXT-1): fronting the resident private key with a KMS/HSM (it currently lives PEM-encoded in the signing_keys table, as password hashes + session tokens already do). Tests: tracker 99→130 (+31), cloud-evidence 1341→1354 (+13).
T.T5 scope note (2026-07-02): T.T5 shipped the realizable core deliverable — the signed NIST SP 800-218A SSDF-AI augmentation matrix (out/ssdf-ai-augmentation.json + .sig + .xlsx, plus out/ssdf-satisfaction-matrix.augmented.json + .sig; detached Ed25519 over RFC-8785 signature-blanked bytes, RFC 3161 coverage via the run manifest TSR). The real 800-218A augmentation catalogue is extracted VERBATIM from the published NIST PDFs (scripts/extract-800-218A.mjs via pdf-parse → data/ssdf-800-218A-{ipd,final}.json + docs/sources/ssdf-800-218A-delta.json; both source PDFs downloaded from CSRC and committed with .sha256 siblings). Final catalogue: 20 practices, 48 tasks, 86 R/C/N items, 6 new AI tasks. Spec reconciliation: (1) the published 800-218A uses per-task Recommendation/Consideration/Note item ids <task>.R/.C/.N<n>, NOT the spec §2.6/§4.1-assumed <task>.A<n> (LOOP-T-RISKS T.T5-16); (2) 800-218A re-introduces PW.3.1–3.3 + PS.1.2/1.3 + PO.5.3 that base SSDF v1.1 (42 tasks) does not carry, so they are base_task_present:false and, absent AI evidence, roll up requires-operator-input — never a silent pass (T.T5-17); (3) RFC 3161 coverage is the run-manifest TSR (no per-file .tsr), consistent with T.T2/T.T3/T.T4 (T.T5-21). The pure aggregator (core/ssdf-ai-extension.ts) joins the catalogue to the T.T2 matrix + the LOOP-O.O5 model-card registry (out/model-cards/*.json) and derives per-augmentation status (satisfied/partially-satisfied/not-satisfied/not-assessed/requires-operator-input/not-applicable) with the §6.6 table; the XLSX renderer (core/ssdf-ai-extension-xlsx.ts) emits Summary + per-product (columns A..O) + IPD-vs-final delta + statutory-lineage worksheets. Orchestrator runs T.T5 under the existing --ssdf-attestation gate after the T.T2 matrix + before T.T3; three submission-bundle WELL_KNOWN roles registered (ssdf-ai-augmentation-json, ssdf-ai-augmentation-xlsx, ssdf-satisfaction-matrix-augmented); ssdf_ai_augmentation_coverage sibling added to inventory-coverage.json (G2-safe); config.yaml#ssdf gained ai_augmentation_enabled/primary_catalogue/ai_products_in_scope. Realizable-core / graceful degradation (T.T5-20): LOOP-O.O5 is unimplemented, so no model cards exist; the orchestrator step is fully wired + tested against fixtures but no-ops (coverage:skipped, reason no-model-cards) in a normal run — the same posture as T.T2/T.T3/T.T4/W.W3/W.W4. NEVER fabricates AI evidence (REO Rule 4): an augmentation with no AI-specific evidence inherits its parent task. Deferred (tracked LOOP-T-RISKS T.T5-22): the React /ssdf/ai-augmentation worksheet page (no tracker subsystem in this repo). Shipping T.T5 completes LOOP-T (5 of 5).
T.T4 scope note (2026-07-01): T.T4 shipped the realizable core regulatory deliverable — the signed SSDF annual re-attestation cadence + material-change detector (out/ssdf-material-change-events.json + .json.sig, detached Ed25519 over the RFC-8785 signature-blanked bytes, covered by the run manifest + RFC 3161 TSR). Two pure engines per the per-slice §6: (1) core/ssdf-annual-attestation.ts — the regime-aware cadence policy table (m-22-18-mandatory/m-23-16-extended → 365-day general / 270-day EO-critical; m-26-05-tailored/post-m-26-05-future → 365-day; operator cadence_override_days wins) computing the producer's internal next-review date (NOT an expiry — the M-23-16 binding clause keeps an attestation in force until the producer notifies the agency; LOOP-T-RISKS T.T4-R1); (2) core/ssdf-material-change-detector.ts — diffs successive T.T2 matrix snapshots and emits typed MaterialChangeEvents (practice_regression satisfied→not-satisfied [suppressed by an active POA&M override — requires-operator-input is a coverage gap, not a regression, T.T4-R2], new_untestable_practice, major_version_bump, ai_augmentation_gap, regime_change, agency_added) with the §6 Step 7/8 notification-clock (14d / 30d / null) + triggers_reattestation policy; event ids are uuid-v5 content-derived for idempotent re-runs (T.T4-T13). The realizable persistence layer stands in for the spec's tracker/storage: prior matrix snapshots are content-addressed at out/ssdf-attestation-snapshots/<product>/<sha256>.json, the append-only run index at out/ssdf-attestation-ledger.jsonl. Orchestrator runs the detector under the existing --ssdf-attestation gate AFTER the T.T2 matrix emit + BEFORE T.T3/signing; three submission-bundle WELL_KNOWN roles registered (ssdf-material-change-events-json, ssdf-attestation-ledger, ssdf-attestation-snapshot); ssdf_material_change_coverage sibling added to inventory-coverage.json (G2-safe). config.yaml#ssdf.products[] gained the optional T.T4 cadence fields (regime enum, continuous_delivery, major_version_pattern, cadence_override_days, poam_extension_allowed, federal_agencies[]); an absent regime yields a requires-operator-input diagnostic (never a fabricated mandatory default, REO Rule 4). Deferred (tracked LOOP-T-RISKS T.T4-21..24): the four SQLite tables (ssdf_products/ssdf_attestation_submissions/ssdf_practice_overrides/ssdf_material_change_events), the REST routes + ssdf-service, the three React panes (status/products/material-changes) + RBAC roles, and the operator signed-PDF-SHA-256 / RSAA-submission-id capture + force-reattestation / withdrawal / legal-review actions — no tracker subsystem exists in this repo (no pg/express/react/better-sqlite3), the same posture as T.T2/T.T3/W.W3/W.W4. NEVER auto-signs the officer attestation and NEVER files with an agency / CISA RSAA (REO Rule 4) — those are human actions in the deferred tracker layer. The STATUS T.T4 table-row title was reconciled to the per-slice-doc / SPEC §3 title (the prior "Third-party software components attestation appendix" label was stale — that scope belongs to T.T5's AI extension, not T.T4).
T.T3 scope note (2026-06-21): T.T3 shipped the realizable core regulatory deliverable — the CISA Secure Software Development Attestation Common Form (OMB Control Number 1670-0052, expiration 03/31/2027) as an unsigned canonical PDF (out/cisa-common-form-1670-0052.pdf) + a signed canonical-JSON shadow (out/cisa-common-form-1670-0052.json + .json.sig, detached Ed25519 over the RFC-8785 signature-blanked bytes, covered by the run manifest + RFC 3161 TSR; the .pdf rides the same manifest via core/sign.ts's by-extension signing — no sign-glob edit needed). The four Section IV attestation selections are computed deterministically from the real T.T2 satisfaction matrix: each §IV(n) clause's selection ∈ {comply, comply-with-conditions, cannot-comply, not-yet-determined} reduces over the union of its in-scope tasks' statuses (a requires-operator-input/not-assessed task forces not-yet-determined — never a silent comply; a cannot-comply clause MUST cite ≥1 POA&M item or it throws MissingPoamReferenceError). Producer identity comes from config.yaml#ssdf.producer (validated up front — every missing required field is collected and thrown as MissingOperatorInputError); the signature/date lines are left blank for the corporate officer (REO Rule 1.10 — the system never auto-signs; T.T4 binds the officer signature). New orchestrator --ssdf-common-form (env CLOUD_EVIDENCE_SSDF_COMMON_FORM; implies --ssdf-attestation) runs after the T.T2 matrix + A.A1 POA&M emit and before signing; two submission-bundle WELL_KNOWN roles registered (ssdf-common-form-pdf, ssdf-common-form-json); per-product ssdf_common_form_fill_rate sibling added to inventory-coverage.json (G2-safe). Spec reconciliation: the T.T3.md §4/§5 idealised inputs (out/ssdf-practice-map.json + out/ssdf-evidence-binding.json; status enum implemented/…/not-applicable; the illustrative per-task CISA_PRACTICE_TO_SSDF table at 1.a–4.c granularity) are stale — the real input is the single ssdf-satisfaction-matrix.json (statuses satisfied/partially-satisfied/not-satisfied/not-assessed/requires-operator-input), and the authoritative CISA mapping is the T.T1 catalogue's COMMON_FORM_TASK_MAP (§IV(1)→Practice 1 … §IV(4)→Practice 4), surfaced per-task as common_form_section_ref; the 1.a–1.f / 4.a–4.c sub-items are verbatim form text rendered under each practice, not separately evidence-bound (LOOP-T-RISKS T.T3-19). Deferred (tracked LOOP-T-RISKS T.T3-20..22): the binary CISA template PDF + CISA/OMB logo assets the spec §7 lists are not fetched in this clean-room tree — the verbatim Section IV text is reproduced from the public record (per-slice §2.4) and the PDF renders a text-only header; PDF/A-3b font embedding falls back to dependency-free PDF 1.4 (spec §5.1-permitted); electronic signature binding + RSAA submission are T.T4. NEVER files with CISA/an agency (REO Rule 4) — the operator signs + submits.
T.T2 scope note (2026-06-20): T.T2 shipped the realizable core deliverable — the signed per-practice × per-task SSDF satisfaction matrix (out/ssdf-satisfaction-matrix.json + .sig + .xlsx, canonical-JSON + detached Ed25519, covered by the run manifest + RFC 3161 TSR), joining the committed T.T1 catalogue to the run's REAL evidence corpus: signed KSI envelopes (out/KSI-*.json, joined per-practice via fedramp_ksi_forward_map), risk-scores.json (B.B1 composite → per-practice open-risk), subprocessor-inventory.json (J.J2), supply-chain-risk-register.json (J.J3), sbom-report.json (E.E2), and poam.json (A.A1, control-based secondary join). Status per task ∈ {satisfied, partially-satisfied, not-satisfied, not-assessed, requires-operator-input}; a task with zero pointers is requires-operator-input (never a silent pass — enforced by the new npm run check:ssdf-no-silent-pass guardrail wired into check:reo). Orchestrator --ssdf-attestation (env CLOUD_EVIDENCE_SSDF_ATTESTATION) wiring runs the pass after all per-loop emitters + before signing; two submission-bundle WELL_KNOWN roles registered. Spec reconciliation: the T.T2.md §4/§5 idealised schema assumed per-TASK crosswalk_ksi[]/crosswalk_800_53_r5[] and 43 tasks; the committed T.T1 catalogue carries those crosswalks per-PRACTICE (fedramp_ksi_forward_map, nist_800_53_r5_controls) with Common Form refs per-task, and 42 active tasks (PW.3 withdrawn in v1.1). The matrix therefore joins evidence at the practice level and attributes the pointer set to each of the practice's tasks (documented in LOOP-T-RISKS T.T2-16). The tracker process-artefact pointer kind + per-agency tracker DB (T.T2.md §4 #11 / §11) are deferred (no tracker subsystem exists in this repo — no pg/express/react; tracked as T.T2-17). Cosign / build-attestation state is not collected as a standalone artefact in this repo, so PS.2/PW.6 release-integrity evidence keys off SBOM presence only (tracked as T.T2-18); the coverage boundary is surfaced in provenance.coverageDiagnostics.
W.W4 scope note (2026-06-18): W.W4 shipped the realizable core regulatory deliverable — the signed FAR 52.204-26 annual representation pair (canonical-JSON envelope + printable .docx) driven deterministically from the W.W2 screen's non-suppressed matches: the (c)(1) "provides" answer keys off the subprocessor-sheet + inventory provider-tag surfaces, the (c)(2) "uses" answer off every non-suppressed match (FAR 4.2102 "use" is broader than provision-to-Government); plus W.W3 incident linking (read from the section889-1bd-reports.jsonl ledger by match_id), the append-only section889-annual-reps.jsonl ledger (delta + flip detection), the LOOP-Q.Q1 marketplace-section889-badge.json feed (enabled iff both answers "does not" AND within validity), SR-1/3/5/6/11 control cross-reference, 365-day valid_until (FAR 52.204-8(d)), submission-bundle registration, and orchestrator --section889-annual-rep wiring. Mandatory operator fields (UEI, officer block, methodology doc) are validated before any write; the actual input is the real out/prohibited-vendors-screen-result.json (the spec §4.1 out/prohibited-vendors-matches.json name was stale — same posture as W.W3). The tracker DB table (section889_annual_reps) / REST routes / React review-sign-off UI / SAM-receipt paste-back + officer-keyring expiry checks described in the per-slice §5.3/§7 are deferred (no tracker subsystem exists in this repo — no pg/express/react); tracked as LOOP-W-RISKS W.W4-EXT-1..4. NEVER files the representation in SAM.gov (REO Rule 4) — the operator submits.
W.W3 scope note (2026-06-18): W.W3 shipped the realizable core regulatory deliverable — the signed FAR 52.204-25(d) report pair (canonical JSON + .docx) per (match × affected contract), federal-business-day deadline (core/section889-clock.ts composing bizdays.ts), statutory citations, append-only ledger (idempotency + audit), inventory-coverage augmentation, submission-bundle registration, orchestrator --prohibited-vendor-1bd-report wiring, and an injectable notification seam. The tracker DB / REST routes / React countdown UI / scheduled_notifications daemon described in the per-slice §5.4/§7 are deferred (no tracker subsystem exists in this repo — no pg/express/react); tracked as LOOP-W-RISKS W.W3-17. The STATUS row title was reconciled to the per-slice-doc title (the prior "SBOM crosscheck" label was stale; SBOM walking is owned by W.W2 per W.W3.md §3.2).
Dependency-metadata note (discovered 2026-06-10; RESOLVED 2026-06-18): the W.W2 row's Dependencies column previously read W.W1, J.J2, inconsistent with the W.W2 per-slice-doc frontmatter (W.W1, E.E2, J.J3, A.A1, A.A5, B.B1). The W.W2 row was reconciled to the frontmatter when W.W2 shipped (this session). No further action; see docs/loops/LOOP-B-RISKS.md risk B.B1-EXT-1.
Out-of-Core / Roadmap (NOT on the implementation queue)
Parallel compliance regimes; preserved as research material under
docs/roadmap/. See docs/roadmap/README.md for the scope-fence
rationale.
Out-of-core loop
What it is
Roadmap doc
LOOP-U Privacy frameworks
FERPA / COPPA / GLBA / CCPA / CPRA / GDPR / UK GDPR / NY SHIELD / 50-state breach matrix / Schrems II
PCI-DSS, CMMC, FedRAMP Tailored, TIC 3.0, SOC 2, ISMAP/IRAP/TISAX, StateRAMP, NSM-22, AI EOs, Section 508, FIPS 140-3, CISA CPGs, etc.
docs/roadmap/FIFTH-PASS-AUDIT.md
Note on LOOP-L through LOOP-Q (2026-06-07):ADDITIONAL-LOOPS-AUDIT.md
(2026-06-06) surfaced 6 net-new loops (L–Q). The human has ratified the
audit and all six are now fully specified (docs/loops/LOOP-{L,M,N,O,P,Q}-SPEC.md
25 per-slice docs under docs/slices/{L,M,N,O,P,Q}/ + 6 risks registers).
LOOP-M (Privacy/SORN/DPIA) and LOOP-O (AI/ML Governance) are now
confirmed applicable (no longer conditional on operator decisions).
Next-priority remains LOOP-B.B1 — risk scoring is still the highest-priority
enabling slice for I, F, E, and (now) N + O. LOOP-L.L1 is queued
immediately behind B.B1. A second-pass audit (docs/SECOND-PASS-AUDIT.md)
ran after L-Q specification to confirm nothing else is still missing.
Note on LOOP-R, LOOP-S, CIRCIA extensions (2026-06-07): A third-pass
audit (docs/THIRD-PASS-AUDIT.md) surfaced three additional bodies of
work that the second-pass audit missed: (a) Post-Quantum Cryptography
migration per NIST IR 8547 + OMB M-23-02 + NSM-10 + NSA CNSA 2.0
(LOOP-R, 3 slices, applicable to all CSPs because PQC migration is
federally mandated), (b) DFARS 252.204-7012 Cloud Equivalency for
DoD-prime customers (LOOP-S, 3 slices, conditional — only required
when the CSP has or pursues DoD-prime customers running Covered Defense
Information workloads on the CSO), and (c) CIRCIA Final Rule 72-hour
incident reporting extensions to G.G2 (Incident Communications
Procedures) and M.M4 (Privacy incident response) — these are
HIGH-PRIORITY because CIRCIA's effective date is May 2026 and any
CSP processing critical-infrastructure-related workloads is a Covered
Entity. CIRCIA extensions are tracked as overlay slices that MUST ship
in the same commit as the parent slice (G.G2 / M.M4) or be explicitly
tracked as a follow-up. The human may elevate CIRCIA extensions above
LOOP-B.B1 once basic CSP operations need to be CIRCIA-compliant.
LOOP-U (Privacy frameworks), LOOP-V (HIPAA Healthcare), LOOP-Y
(CJIS + IRS Pub 1075), and LOOP-Z (ISO 27001/27017/27018/27701 +
ENISA EUCS) were scope-fenced out of core FedPy and relocated to
cloud-evidence/docs/roadmap/loops/ + cloud-evidence/docs/roadmap/slices/.
They are preserved as research / roadmap reference, not as
implementation work. The FIFTH-PASS-AUDIT.md candidates
(LOOP-AA through LOOP-GG: PCI-DSS / CMMC / FedRAMP Tailored / TIC 3.0
/ SOC 2 / ISMAP/IRAP/TISAX / StateRAMP / NSM-22 / AI EOs / Section 508 /
FIPS 140-3 / CISA CPGs / etc.) are also roadmap-only.
Read docs/roadmap/README.md and the Scope Guard block in
cloud-evidence/CLAUDE.md before referencing anything in that folder.
The scope-fence policy is: do not propose moving these back to core
without an explicit mission re-statement from the user.
CIRCIA Extensions + Overlays (HIGH PRIORITY — May 2026 effective for CIRCIA; SEC 8-K is in force today)
Slice
Title
Status
Commit
Date
Spec
Per-slice doc
G.G2.CIRCIA
CIRCIA 72-hour incident reporting extension
pending
—
—
docs/CIRCIA-WORKFLOW.md
docs/slices/G/G.G2-CIRCIA-EXTENSION.md
M.M4.CIRCIA
CIRCIA + Privacy Act incident harmonization
pending
—
—
docs/CIRCIA-WORKFLOW.md
docs/slices/M/M.M4-CIRCIA-EXTENSION.md
G.G2-SEC-8K
SEC Item 1.05 Form 8-K cyber-incident disclosure overlay (four-business-day clock; applies when CSP is an SEC-registrant or subsidiary thereof)
proposed
TBD
—
docs/loops/LOOP-G-SPEC.md
docs/slices/G/G.G2-SEC-8K-EXTENSION.md
Per-loop risks registers
Each loop has a dedicated risks register listing implementation,
schedule, dependency, and external risks discovered during planning +
slice authoring. Update the register every time a slice surfaces a new
risk (per the Strong-Directive in cloud-evidence/CLAUDE.md).
Register
Loop
Path
LOOP-B risks
Risk + Remediation Engine
docs/loops/LOOP-B-RISKS.md
LOOP-C risks
Document Template Pack
docs/loops/LOOP-C-RISKS.md
LOOP-D risks
Diagram Auto-Generation
docs/loops/LOOP-D-RISKS.md
LOOP-E risks
Continuous Monitoring Agent
docs/loops/LOOP-E-RISKS.md
LOOP-F risks
3PAO Assessor Experience
docs/loops/LOOP-F-RISKS.md
LOOP-G risks
AFR Family
docs/loops/LOOP-G-RISKS.md
LOOP-H risks
Long-Term Storage + Multi-CSO
docs/loops/LOOP-H-RISKS.md
LOOP-I risks
Stakeholder Dashboards
docs/loops/LOOP-I-RISKS.md
LOOP-J risks
Supply Chain + Privileges
docs/loops/LOOP-J-RISKS.md
LOOP-K risks
Test Artifact Ingestion
docs/loops/LOOP-K-RISKS.md
LOOP-L risks
CRM + Leveraged-Authorization Inheritance
docs/loops/LOOP-L-RISKS.md
LOOP-M risks
Privacy Package Extension (SORN + DPIA)
docs/loops/LOOP-M-RISKS.md
LOOP-N risks
Threat Modeling + Adversarial Validation
docs/loops/LOOP-N-RISKS.md
LOOP-O risks
AI/ML Governance
docs/loops/LOOP-O-RISKS.md
LOOP-P risks
Insider Threat + PS-family
docs/loops/LOOP-P-RISKS.md
LOOP-Q risks
Marketplace + Post-ATO Publication
docs/loops/LOOP-Q-RISKS.md
LOOP-R risks
Post-Quantum Cryptography Migration
docs/loops/LOOP-R-RISKS.md
LOOP-S risks
DFARS 252.204-7012 Cloud Equivalency
docs/loops/LOOP-S-RISKS.md
Cross-cutting references
Reference docs that span every loop. Read these whenever planning
across loops, onboarding a new contributor, or answering a "where
does X term come from" question.
Doc
Purpose
Path
Dependency graph
Mermaid + tabular dependency map for every slice; critical path; parallelization streams
docs/DEPENDENCY-GRAPH.md
Glossary
A–Z of every FedRAMP / NIST / OSCAL / internal term used in the spec corpus (90+ terms)
docs/GLOSSARY.md
Implementation log template
Format + cadence for the per-slice "Implementation log" running journal
docs/IMPLEMENTATION-LOG-TEMPLATE.md
Additional loops audit
Audit of FedRAMP/NIST corpus for items missing from the LOOP-A..K roadmap; proposes LOOP-L..Q + §3 extensions
docs/ADDITIONAL-LOOPS-AUDIT.md
Second-pass audit
Post-LOOP-L..Q audit confirming nothing else is still missing after L-Q specification