# Methodology Changelog This log records document-level revisions to the NuWyre methodology. Section-level status changes (e.g., a stub being substantively drafted) update the section file's frontmatter and are noted here only when the overall document version bumps as a result. See [README.md](./README.md) "Two-tier status model" for the section-status vs document-status distinction. --- ## v1.1 (2026-05-24) — session 132 doc-reconciliation batch Phase 7.E session 132 doc-reconciliation. Methodology source updated to reflect the v2.0.0 / ML-DSA-65 dual-signing milestone (originally landed at sessions 97-104 in the spec layer; methodology source was trailing per the session 130 freshness audit). Three substantive amendments: - **§3.3 (manifest.json schema)** — manifest signing example updated to show the v2 dual-signature container (`signing.schema_version: 1` + `signatures: []` array; Ed25519 at index 0; ML-DSA-65 at index 1). v1 single-Ed25519 example preserved via the §3.13.1 historical backward compatibility commitment. - **§3.4 (signature.sig)** — verification procedure split into v2 (dual-sig path; both signatures must independently verify against pinned issuer keys) and v1 (legacy single-Ed25519; verifiers continue to accept indefinitely). Documents the layout `signature.sig = ed25519_sig_64_bytes || ml_dsa_65_sig_bytes`. - **§4 Check 1 (Manifest signature)** — verifier dispatches by `bundle_format` identifier: v2 requires both signatures verify; v1 requires the single Ed25519 verify. PASS / FAIL / `warn (dev_key)` semantics extended to the dual-sig contract. Per-event `forensic.ingestion_signature` (§2.1.4) REMAINS single Ed25519 in both v1 and v2 — the manifest-level ML-DSA-65 signature transitively protects the event corpus through the daily Merkle root. Three-leg anchoring (OpenTimestamps Bitcoin + RFC 3161 ≥2-of-3 TSA quorum + GitHub anchor commit) is UNCHANGED. Why now: post-quantum durability for the multi-decade retention horizon documented in §7. ML-DSA-65 is NIST FIPS 204 (finalized 2024-08-13 alongside FIPS 203 ML-KEM and FIPS 205 SLH-DSA) — one of two NIST-standardized post-quantum general-purpose digital signature schemes (FIPS 204 ML-DSA + FIPS 205 SLH-DSA). Pairing it with Ed25519 provides defense-in-depth AT THE ALGORITHMIC-CRYPTANALYSIS LAYER across two cryptographically-distinct foundations (elliptic-curve discrete logarithm AND module-lattice problems) against both present-day cryptanalysis and a future cryptographically-relevant quantum computer (NIST projections place CRQC capability in the 2035-2040+ timeframe, intersecting NuWyre's multi-decade retention horizon per §7). Key-custody compromise (extraction of both private keys from NuWyre's signing infrastructure) is a separate threat model addressed by the key-custody controls described in `docs/legal/system-description.md` §7. --- ## v1.0 (2026-05-16) — session 94 extension Phase 7.E session 94 substantive drafting continuation. **Four additional sections promoted from honest-stub to v1.0 substantive content** at the §5 gold-standard depth, bringing 9 of 11 sections to v1.0 substantive (up from 5 at the prior v1.0 entry): - **§3 (Evidence Format Specification)** — 25 → 522 lines. Now covers: bundle structure (ZIP file inventory), four bundle types (customer-export + audit-log-export + example-demo + sandbox-preview), manifest.json full shape, signature.sig + Ed25519 verification, events.jsonl + audit_log_events.jsonl JCS canonicalization, merkle_proofs.json walk-and-verify procedure, daily_roots.json cross-reference, evaluations.jsonl row_hash semantics, anchor receipt formats (OTS protocol bytes + RFC 3161 PKCS#7 + GitHub anchor JSON), audio/ directory content-addressing, cover.pdf + verify.md companion artifacts, reproducibility contract (deterministic regeneration), versioning + backward compatibility commitments, and SPEC_GOVERNANCE.md procedure. - **§6 (Detection and Response)** — 32 → 424 lines. Now covers: two-layer detection model (integrity detection of tampering vs compliance detection of policy-pack rule violations), chain-level anomaly detection (sequence gaps + signature failures + content_hash divergence + prev_event_hash break + anchor mismatch), operational response to integrity anomalies (freeze + preserve + investigate + notify + resolve cycle with audit-trail in audit_log_events), trigger-as-deterministic-filter + evaluator- as-judgment-layer pattern, severity taxonomy (info / low / medium / high / critical), cross-validation for high-severity findings, async pipeline mechanics (sub-30-second target latency for HIGH/CRITICAL), notification channels (Slack + Teams + email + SMS), agent suspension semantics + when-NOT-to-use guidance, post-detection forensic preservation, operator-side observability, and what detection + response does NOT do (no automated compliance decisions; no replacement for human review on high-stakes; no zero-FP/FN guarantee). - **§7 (Retention and Legal Hold)** — 23 → 435 lines. Now covers: retention class taxonomy (default + extended + litigation_hold + pii_minimized + phi_minimized) with operational-mechanics + customer-configurability table, per-organization + per-jurisdiction policy expression with cross-jurisdiction conflict resolution (longer-wins-for-hold + shorter-wins-for- deletion + tombstone-reconciliation), legal hold semantics (application + precedence + release + who-can-apply-or-release), tombstone-vs-deletion distinction with cryptographic implications, retention-sweep cron mechanics with audit-trail-per-operation + dry-run-mode, CMK interaction, operator-side retention actions (emergency deletion + customer-requested deletion + backup restoration), and what retention does NOT do (no automated regulatory compliance; no subpoena enforceability guarantees; no legal advice). **Legal-framing note**: retention-class selection per regulatory framework is the customer's counsel's responsibility; NuWyre provides the operational substrate + audit-log surface. Operator-specific legal framing is flagged as customer-counsel-led. - **§8 (Audio Handling)** — 44 → 467 lines. Now covers: audio binding mechanism (SHA-256 of raw audio bytes embedded in event.content.audio_ref + chain-integrity propagation), why hash-binding rather than embedded audio (chain compactness + bundle size + daily-tree size), what the binding proves, storage layout (Supabase Storage evidence-audio bucket with RLS per-org scoping + bucket-level encryption-at-rest), audio in bundle exports with size implications, retention independence from event retention (state wiretapping consent laws + HIPAA PHI + biometric privacy + jurisdiction-specific recording statutes), audio redaction without chain break (tombstone semantics preserving the hash), voice consent capture TCPA case (audio is 95% of the defense), voice platform-specific audio handling (Twilio Voice + OpenAI Realtime + Bland + Retell), what audio handling does NOT do (no transcription validation; no real-time audio analytics; no upstream-platform storage interaction; no format conversion), cryptographic implications of audio handling with tampering scenarios + detection mechanisms. **Sections still at honest-stub for v1.0** (deferred to post-first-customer): - §10 (Quarterly Review Log) — 44 lines; awaits first production- quarter review entries; cannot be substantively drafted without actual operational review data. - §11 (Worked Example) — 33 lines; requires actual customer scenario data; deferred to v1.2. - §99 (FAQ) — 27 lines; populates based on first-prospect- conversation common-question patterns. **Document state**: with §§1-9 at v1.0 substantive depth, the methodology now covers the full operational + cryptographic substrate from threat model through audio handling. A compliance buyer / GC / regulator reading the document end-to-end has the canonical reference for NuWyre's evidentiary posture. The remaining stubs (§10 + §11 + §99) are explicitly framed as ongoing-content-drafting items + are clearly labeled in the TOC. --- ## v1.0 (2026-05-16) Phase 7.E session 93 substantive drafting milestone. **Four critical sections promoted from honest-stub to v1.0 substantive content** at the §5 (Policy Evaluation) gold-standard depth: - **§1 (Threat Model)** — 62 → 270 lines. Now covers: scope statement (in-scope + out-of-scope + V1-explicit-exclusions), trust assumptions table (8 numbered assumptions with independent-verifiability notation), adversary model (Class A external + Class B compromised- credentials + Class C insider), threat catalog (12 canonical attack scenarios with detection mechanism + residual risk per threat), detection-vs-prevention boundary explicit framing, and residual-risks honest enumeration. Status promoted to v1.0. - **§2 (Integrity Model)** — 94 → 498 lines. Now covers: event-level integrity (content_hash JCS, event_hash four-field composition, genesis sentinel, Ed25519 ingestion signature), per-organization hash chain invariants, canonical encoding (RFC 8785 JCS) with KAT cross-language byte-equivalence notes, ingestion signing key full lifecycle (rotation + compromise procedures), daily Merkle root construction (canonical leaf-ordering + dual-subtree composition for audit-log-export), full anchoring window canonical semantics (preserved from prior partial draft), OTS Bitcoin anchoring with pending-state semantics, RFC 3161 TSA timestamping with ≥2-of-3 verification threshold rationale, GitHub anchor mirror with anchor-pending state explicit framing, tombstone redaction methodology, and a full putting-it-together integrity reconstruction walkthrough. - **§4 (Verification Procedure)** — 23 → 418 lines. Now covers: verifier distribution (Go binary + WASM), installation + source-buildable procedure, the 9-check pipeline with PASS- guarantees + FAIL-meaning + SKIPPED-semantics per check, report reading + exit code semantics, offline mode rationale, building from source for source-verifying organizations, and explicit statements of what verification establishes vs does not establish. - **§9 (Limitations and Honest Disclosures)** — 45 → 412 lines. The credibility section a hostile reviewer reads first. Now covers: cryptographic assumption dependencies (SHA-256 collision resistance + Ed25519 unforgeability + Bitcoin proof-of-work cost), third-party anchor dependencies (OTS calendars + RFC 3161 TSAs + GitHub repository), LLM evaluator judgment quality + bias considerations, what evidence bundles do NOT prove (upstream AI correctness + consent validity + regulator verdict + voice transcription), adapter trust boundary, operational dependencies the customer must maintain (bundle storage hygiene + public key verification + time-of-receipt documentation), standards-track maturity disclosures, V1 vs V1.1+ scope boundaries (real-time detection + customer-managed encryption + audit-log production + binary distribution + quarterly review log), "what happens if NuWyre disappears" continuity story, and a summary table of what NuWyre guarantees vs does not. **Sections still at honest-stub for v1.0** (Year 1 Q2-Q3 substantive drafting): - §3 (Evidence Format) — 25 lines; spec at `bundle-format-v1.md` is the canonical reference; methodology prose-summary expansion deferred. - §6 (Detection and Response) — 32 lines; substrate stable, prose expansion follows first-customer-deployment empirical patterns. - §7 (Retention and Legal Hold) — 23 lines; requires operator/legal domain content beyond what code-derived drafting can produce. - §8 (Audio Handling) — 44 lines; audio binding ingestion not yet productionized at scale; expansion follows Twilio recording- ingestion landing. - §10 (Quarterly Review Log) — 44 lines; awaits first production- quarter review entries. - §11 (Worked Example) — 33 lines; requires actual customer scenario data. - §99 (FAQ) — 27 lines; populates based on first-prospect- conversation common-question patterns. **Document state**: with §§1, 2, 4, 5, 9 at v1.0 substantive depth, the methodology is **credible-for-outbound** to compliance buyers who read the threat model + integrity model + verification procedure + limitations first (the canonical evaluation-order for a regulator or GC). Remaining sections ship as honest stubs clearly labeled in TOC; honest-stub framing is itself trust-building per §9 institutional-honesty discipline. --- ## v1.0-rc (2026-05-07) Initial release candidate. Methodology infrastructure ships with Phase 2 closure: - 11-section structure aligned to build plan v3.1.5 §9. - §5 (Policy Evaluation Methodology) substantively drafted at v1.1. - §§1, 2, 3, 4, 6, 7, 8, 9, 10 are honest stubs marked `(forthcoming)` in the published TOC and in their respective section files. Substantive content drafting is queued as the methodology v1.0 work item — Year 1 Q2-Q3 per operator's manual v1.1.2 §5. - §11 (Worked Example) deferred to v1.2 after Phase 3 produces real ingestion data per build plan v3.1.5 §9. - Generator infrastructure at `scripts/methodology/build.ts` (Puppeteer- based; consumes `packages/config/styles/tokens.css` for design tokens; fonts bundled at `scripts/methodology/fonts/` under SIL OFL 1.1). **Toolchain note.** v1.0-rc is rendered via Puppeteer (matching the cover-pdf pipeline) as an interim measure. Migration to pandoc + xelatex is queued per build plan v3.1.5 §10.5 and triggered when content density across multiple sections justifies the toolchain investment. Decision rationale recorded in `docs/runbook.md` under "Methodology PDF toolchain — current and future." **Sections changed since the previous methodology document (none — this is the initial release candidate):** N/A.