From 4ca1de4550fc162395ae2ecd90f23736721087eb Mon Sep 17 00:00:00 2001 From: Steve Muchow Date: Wed, 20 May 2026 18:05:16 -0500 Subject: [PATCH] docs(q-and-a): add 12 Kognitos-point cross-references (5 tag-adds + 9 new rows) MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Apply 14 operations from the 2026-05-20 Kognitos 12-point audit cycle. Tag format: (kognitos point N) — lowercase, integer N, end of Answer cell. Tag-adds (5) to existing rows: - Point 8 — line 213 (Consumer access: adverse-action principal reasons) - Point 11 — line 187 (Privacy: Article 22) - Point 11 — line 294 (Vendor management: human-override path) - Point 12 — line 38 (Tamper-detection lead row) + Rosanne tail-sentence pointing at §10.53/§10.54/§4.1.3 so a post-quantum-aware reader doesn't read the present-tense integrity claim as time-invariant - Point 12 — line 46 (Tamper-detection: opposing-counsel attack row) New rows (9), Variant A for Points 3 and 10: - Point 1 — NTP-synced UTC timestamp → Implementation theme - Point 2 — Unique decision ID → Implementation theme - Point 3 (Variant A) — Authenticated human user identity → Audit committee - Point 4 — AI system identity and version → MRM theme - Point 5 — Model identity and version → MRM theme - Point 6 — Inputs received with source attribution → MRM theme - Point 7 — Specific policy / rule / prompt invoked → Crypto discipline theme - Point 8 — Hash-vs-plaintext epistemic scope → Privacy theme - Point 9 — Output produced (stream-finish binding) → Tamper-detection theme - Point 10 (Variant A) — Action in downstream systems → Legal evidentiary Placement: Option A (distributed by theme), preserving role-affinity scan. No introductory paragraph about Kognitos per Steve's directive. Boundary-of-the-claim discipline baked into every drafted cell. Variant B for Points 3 and 10 follows after PRD-3 lands Seam D (audit.actor.*) and the audit.downstream_action.* family. Source-of-record for the operations: E:/dev/MMP.Media/_assistant_drafts/wiki/market-research/ 2026-05-20-CONSOLIDATED-kognitos-qa-pack-for-steve.md Co-Authored-By: Claude Opus 4.7 (1M context) --- docs/q-and-a.md | 20 +++++++++++++++----- 1 file changed, 15 insertions(+), 5 deletions(-) diff --git a/docs/q-and-a.md b/docs/q-and-a.md index 0ccc3ae..20dade9 100644 --- a/docs/q-and-a.md +++ b/docs/q-and-a.md @@ -35,7 +35,7 @@ Most questions carry two or more icons because most readers share the same conce | ⭐ | Audience | Question | Answer | Spec | |---|---|---|---|---| -| ⭐ | 🔍 📋 🛡 🏛 | Can the institution alter history without detection? | No. The HMAC chain catches in-flight tampering at re-verification on ingest. The daily Merkle seal under HSM signature catches retroactive tampering. Two independent custody layers must both fail for a successful undetected alteration. | §4.1, §4.2, §4.3 | +| ⭐ | 🔍 📋 🛡 🏛 | Can the institution alter history without detection? | No. The HMAC chain catches in-flight tampering at re-verification on ingest. The daily Merkle seal under HSM signature catches retroactive tampering. Two independent custody layers must both fail for a successful undetected alteration. The integrity claim is present-tense: §10.53 IKM-ratcheting per epoch and §10.54 decadal re-sealing compose with §4.1.3 key rotation so the present-tense answer extends into long-retention horizons under cryptographic agility. (kognitos point 12) | §4.1, §4.2, §4.3, §10.53, §10.54, §4.1.3 | | ⭐ | 🔍 📋 🛡 | Can the vendor alter history without detection? | No. The HSM is bank-operated, or per-tenant-segregated when vendor-operated. The signing key is held by the institution and the regulator, not the vendor. The vendor cannot rewrite a sealed root without that key. | §10.5, §10.6 | | ⭐ | 🔍 📋 | How do we verify the chain independently of the institution's tooling? | The reference verifier is a single static binary with no network calls. It reads the ledger and the public key only. The institution exports the artifacts; the examiner runs the verifier locally. Exit-code semantics make pass/fail unambiguous. | §7, §10.12 | | | 📋 🛡 🛠 | What if the verifier itself has a bug? | The reference verifier ships with a published cryptographic conformance corpus (positive and negative test vectors under `spec/test-vectors/`) and is open source. A wary institution runs the conformance corpus against the binary before relying on it. The verifier is replaceable — any conformant implementation produces identical output for the same input. | §7, `spec/test-vectors/` | @@ -43,8 +43,9 @@ Most questions carry two or more icons because most readers share the same conce | ⭐ | 🔍 📋 | What stops the institution from rewriting `received_at` on the ledger after capture? | A ledger that mutates `received_at` after ingest is a control failure independent of the chain's cryptographic integrity; SOC engagements test the storage-integrity sample. The chain itself does not depend on `received_at` for integrity — it is forensic metadata only. | §4.2.2 trust posture; `audit-procedures.md` | | | 🔍 📋 | What stops a national bank from running a vendor-flag chain and presenting it under FFIEC posture? | §4.1.2 binary conformance — the verifier reads the header HKDF inputs and rejects when they do not match running v1 inputs. There is no silent mode in which a non-FFIEC chain passes FFIEC verification. | §4.1.2, §7 step 2 | | | 🔍 📋 | Does the spec resist algorithm-confusion attacks (JWT `alg=none`-style)? | Yes. §4.3 binds the algorithm into `sign_payload` as line 2. §4.3.2 dual-algorithm Variant B forces each algorithm in `signatures[]` to be computed over its own algorithm-named payload, rejecting a shared payload as non-conformant. §7 step 11 rejects algorithm/key-type mismatch with a named reason. | §4.3, §4.3.2, §7 step 11 | -| | 🛡 🛠 ⚖ | Can opposing counsel attack the chain as a whole? | The chain is three independent layers (per-event MAC, daily Merkle, HSM signature) plus the §7 verifier procedure. Defeating the chain requires defeating all three layers — cryptographically infeasible under §10 threat model. The §7 verifier is the affirmative answer to manipulation claims. | §1.1, §1.4, §7 | +| | 🛡 🛠 ⚖ | Can opposing counsel attack the chain as a whole? | The chain is three independent layers (per-event MAC, daily Merkle, HSM signature) plus the §7 verifier procedure. Defeating the chain requires defeating all three layers — cryptographically infeasible under §10 threat model. The §7 verifier is the affirmative answer to manipulation claims. (kognitos point 12) | §1.1, §1.4, §7 | | | 📚 🛠 | Is the integrity claim falsifiable in the Popperian sense? | Yes. Produce a tampered chain that the §7 procedure does not reject, and the claim is broken. §1.1 Daubert grounding states this explicitly. | §1.1 Testability | +| | 🛠 📋 🔍 | When the output is a streaming / chunked LLM response, what is the canonical thing the chain binds — a per-chunk hash or the assembled output? | The complete output assembled at stream-finish. One chain entry per stream-finish event, not per chunk; `audit.generation.output_sha256` binds the complete output canonical bytes (§10.47). Reviewer-edited outputs bind separately via `audit.review.edited_output_sha256` (§10.50); the original output hash remains on the §10.47 generation event so the override delta is reconstructable. C2PA Content Credentials composition (§10.52.1) handles AI-generated user-facing artifacts. DP-noised aggregates bind the noised value byte-for-byte under JCS (§10.51); the raw aggregate is the institution's separate audit substrate. (kognitos point 9) | §10.47; §10.50; §10.51; §10.52.1 | --- @@ -77,6 +78,7 @@ Most questions carry two or more icons because most readers share the same conce | | 🏛 | How does adoption affect the audit committee's reporting cadence? | The chain produces verifier output any time the audit committee asks for it. Standing reports continue unchanged; chain verification becomes an additional optional input. A committee that wants quarterly verification adds the verifier run to the institution's quarterly cycle. | §7, §10.12 | | | 🏛 🛡 | Does the chain support our SOX 404 ICFR opinion? | Conditionally. The chain is admissible for what it proves: integrity of captured events, custody of the signing key, soundness of the daily seal. It is NOT admissible as evidence that a model's decision was correct — model validation is a separate workflow. | §1.1 Daubert, §1.2 | | | 🏛 ⚖ | What does becoming a chain operator mean for discovery? | The chain is a permanent, hash-verifiable record of every AI decision. Redaction is pre-MAC at SDK only (§10.22); privilege claims must be pre-tagged (§10.70); litigation-hold and SAR exclusions are categorical, not entry-level. The GC reads one paragraph and understands the discoverability surface. | §1.2.1, §10.13, §10.22, §10.70 | +| | 🔍 📋 🛠 🔐 | The 2026 examiner-pressure question — when an AI accesses regulated data, can the chain prove which authenticated human user directed the work (not just which service account)? | Three composable surfaces today, with one institution-side dependency. (a) Reviewer identity (§10.50) — when a human reviews AI output, the review is cryptographically signed by the reviewer's per-reviewer key. (b) Operational-event signatories (§10.2) — institutional actors sign their operational events under the §10.17 schema. (c) SDK handshake identity (§4.1.1) — the application process authenticates via SPIFFE/SPIRE / mTLS / HSM bearer; this is WORKLOAD identity, not human identity. For the SSO-authenticated end-user (the HIPAA §164.312(a)(2)(i) anchor), the institution's CC8.1 names an enricher attribute under the `audit.*` namespace — coverage is institution-side dependent until that enricher is operational. A normative `audit.actor.*` family (Seam D) is candidate-normative for the next PRD and will close the dependency. (kognitos point 3) | §10.50; §10.2; §10.17; §4.1.1; CC8.1 actor-enricher convention | --- @@ -124,6 +126,9 @@ Most questions carry two or more icons because most readers share the same conce | | 📐 🛡 | What stops a carrier from running disparate-impact tests against a curated test population? | §4.4.5 `audit.disparate_impact.population_hash` is REQUIRED — SHA-256 of the canonicalized input population. The hash binds the population; representativeness is institution-side discipline reviewed by the MRM committee. The chain proves *which* population was tested, not that it was representative. | §4.4.5 | | | 📐 🛡 | What is "effective challenge" in chain-of-custody terms? | OCC 2026-13's effective-challenge framing maps onto §10.21 cross-vendor model-handover (challenger-independent integrity), §10.21.2 parallel-evaluator composition (challenger model bound under same chain), §10.50 HITL governance, and §10.18 CC8.1 cross-referencing. | §10.21, §10.21.2, §10.50, §10.18 | | | 📐 ⚖ | NCUA AI-driven credit decisions — does the chain compose with CECL / risk-based capital? | §10.11.1 ECOA adverse-action reasons + §4.4.5 underwriting features are credit-decision-relevant. The chain captures the decision; CECL / risk-based-capital aggregation reads decisions from the chain through the institution's CC8.1-named query pattern. | §10.11.1, §4.4.5, NCUA overlay | +| ⭐ | 📐 📋 🔍 | Vendor silently re-routes between providers during an outage — does the chain detect it, and does the routing event itself live in the chain? | Yes (normative). Multi-provider deployments emit `audit.routing.*` events as their own chain entries with `parent_run_id` / `parent_seq` linking to the downstream LLM call. Deployment-intent (§4.4.2) attaches to the model invocation entry, distinguishing `production` / `ab_test` / `canary` / `multi_region_drift` / `vendor_reroute_observed` / `regulatory_sandbox` / `disparate_impact_test_run`. `audit.deployment.policy_version` is REQUIRED whenever any `audit.deployment.*` attribute is present; `vendor_reroute_detection_policy_hash` is chain-bound on every invocation (not just on detected reroutes), so post-hoc policy edits are detectable. Verifier P-33 surfaces routing-pairing violations. (kognitos point 4) | §4.4.1; §4.4.2; §10.33 | +| ⭐ | 📐 📋 🔍 | What stops a silent model upgrade by a vendor from invalidating prior change-management evidence? | Two normative requirements. (a) `gen_ai.request.model` AND `gen_ai.response.model` are BOTH REQUIRED on any chain entry representing a model call (§4.4); a divergence between request and response IS the silent-reroute signal. (b) The SDK MUST refuse to emit a chain entry carrying any `gen_ai.*` attribute that lacks either model identifier — a misconfigured pipeline cannot silently produce chains that fail at audit time. `model_weight_hash` (§10.48) binds reproducibility (institution-supplied for closed-weight vendor models; on-disk hash for open-weight in-institution models). `audit.model_update.activate` (§10.33) REQUIRES references to `audit.model_validation.attestation` AND `audit.mrm_disposition.recorded` events under a validation-precedes-activation ordering the verifier enforces. (kognitos point 5) | §4.4; §10.33; §10.48; §10.34 | +| ⭐ | 📐 📋 🔍 | When the AI used RAG, how does the chain prove which documents were retrieved AND used, not just which were stored in the corpus? | Two-layer binding under the per-event MAC. (a) §10.47 four-tuple — system prompt SHA-256 + user prompt SHA-256 + retrieval-set Merkle root SHA-256 + output SHA-256 — bound on the generation event. (b) §10.49 per-document retrieval anchor events: each retrieved document is a separate chain entry with `audit.retrieval.document_anchor.*` attributes. `canonical_identifier_kind` covers PMID / DOI / ISBN / FDA-label / institutional-doc-id. The verifier dispatches the §10.49 cross-binding: every per-document anchor's `document_sha256` MUST be in the retrieval-set Merkle root; the leaf count matches the per-document anchor count. Merkle ordering is lexicographic by `document_sha256` (not relevance score) so byte-identicality holds across implementations. Institutions not operating RAG omit both. (kognitos point 6) | §10.47; §10.49; §4.4 | --- @@ -142,6 +147,8 @@ Most questions carry two or more icons because most readers share the same conce | | 🛠 | What is the RTO / RPO contract for the chain in DR? | RPO targets by failure class: HSM unavailability (per §4.3.1 — 36h FFIEC notification clock; per §10.16 mirror-lag posture); ledger unavailability (institution-side RTO per CC8.1); seal-region failover (§10.15 invariant 6 procedure, institution-side RTO). | §4.3.1, §10.15, §10.16 | | | 🛠 | What does the SDK do during a leap-second / NTP step-back where `captured_at` goes backwards? | The chain's integrity ordering uses `(run_id, seq)`, not wall-clock timestamps. Backwards `captured_at` within the §4.2.2 clock-skew threshold is an anomaly, not a FAIL. The verifier MUST NOT fail on backwards `captured_at` within threshold; monotonic-clock discipline for in-process ordering is RECOMMENDED. | §10.4, §4.2.2 | | | 🛠 | What is the contract for edge devices offline for 72 hours? | §10.36 normates supplemental-seal (Pattern A) or rolling-seal-window (Pattern B) for late-arriving entries. Edge-device buffering bounded by device storage; replay-on-reconnect MUST preserve `(tenant_id, run_id, seq)` ordering; `audit.routing.attempt` events MUST emit `audit.cross_border_transfer.*` when crossing regional boundaries. | §10.36, §10.32 | +| ⭐ | 🔍 📋 🛠 | How does the chain prove that the captured timestamp was not backdated or fabricated by the application host? | Three timestamps with three trust postures. `ffiec.chain.captured_at` is bound under the per-event MAC at SDK capture, so post-hoc edits surface at §7 step 9 as MAC mismatch; `mac_computed_at_utc` is RECOMMENDED forensic metadata; `received_at` is ledger-stamped at ingest and is the day-boundary discriminator (NOT in the SDK canonical bytes). The chain's ordering invariant is `seq` per `run_id`, not wall-clock time — leap-seconds and NTP step-back are anomalies, not FAILs. Trusted-time integration via RFC 3161 (§10.14) is RECOMMENDED for v1.0; eIDAS Article 41(2) presumptive-legal-effect composition rides alongside. (kognitos point 1) | §4.4 captured_at + mac_computed_at_utc; §4.2.2 trust posture; §10.4; §10.14 | +| ⭐ | 🔍 📋 🛠 | Can a single AI decision be reconstructed end-to-end across the prompt store, model invocation, human review, and downstream-system entry? | Yes. The chain's canonical decision identifier is `(tenant_id, run_id, seq)`. Parent-child agent flows carry `parent_run_id` + `parent_seq`; DAG-shaped multi-agent flows carry `dag_parents`. Cross-vendor handover (§10.21) and entity succession (§10.24) compose under the same parent-linkage primitive. The silent-restart attack — an SDK losing local state and emitting a second `seq = 1` for the same run — is closed by §10.25's three-place tail-acquisition contract (in-memory → local sidecar → ledger query) plus the single-writer-per-run rule and intra-process mutex discipline. (kognitos point 2) | §4.4; §10.25; §10.21; §10.24 | --- @@ -168,6 +175,7 @@ Most questions carry two or more icons because most readers share the same conce | | ⚖ ⭐ | Class-action e-discovery: can I get class-wide chain evidence in a discoverable, structured form? | §10.69 cohort-mode disclosure handles class-action evidence: court-defined cohort filter (zip, protected-class proxy, date range) produces a §10.31 subtree disclosure covering the class, with each member's §10.69 packet derivable. Test vector `077-078 cohort-mode` pins the byte form. | §10.69 cohort, §10.31 | | | ⚖ | Can the chain prove the institution did NOT disclose a class member's entries? | §10.69 `consumer_index.coverage_attestation` lists the per-customer entry count covered AND the count excluded by category, bound under the same HSM signature. A class plaintiff verifying the attestation cryptographically detects the EXISTENCE (not content) of withheld entries. | §10.69 | | | ⚖ | SEC subpoena interaction with attorney-client / work-product tagged entries? | §10.70 role-based dispatch surfaces the existence-attestation form to the SEC investigator (entries exist, are integrity-bound, are tagged) while the institution litigates privilege separately. SEC-specific overlay names §240.17a-4 WORM-equivalence and Reg BI / Reg S-P composition. | §10.70, SEC overlay | +| | 🔍 📋 ⚖ | After the AI made a decision, can the chain prove what changed in the system-of-record — the journal entry posted, the patient record updated, the notice sent? | Today: per-decision-class normative coverage, plus institution-side discipline for the general case. Insurance claims (§10.43 state machine: FNOL → reserve → adjudication → payment → recovery → close); insurance rate filing (§10.75); ECOA adverse-action delivery (§10.11 `delivery_method` + `delivery_timestamp`); FCRA reinvestigation outcome (§10.11.2 enum `verified` / `corrected` / `deleted`); GDPR Article 17 / CCPA deletion (§10.74 `audit.deletion_request.disposition`, `vault.tokenization_event`); multi-channel handoff (§4.4 `audit.channel.*`). General downstream system-of-record linkage (journal entry, account update) lives under the institution's CC8.1; a generalized `audit.downstream_action.*` family is candidate-normative for the next PRD. (kognitos point 10) | §10.43; §10.75; §10.11; §10.11.2; §10.74; §4.4 | --- @@ -176,7 +184,7 @@ Most questions carry two or more icons because most readers share the same conce | ⭐ | Audience | Question | Answer | Spec | |---|---|---|---|---| | ⭐ | 🔐 ⚖ | GDPR Article 17 right to erasure — the chain is append-only by design. How? | §10.74 crypto-erasure procedure: chain integrity is preserved (entries are not deleted); the subject's PII is held outside the chain in the token-vault per `privacy-by-design.md`; erasure unbinds the token-vault entry; the chain retains only the hash. Compliant with Article 17 because the chain holds no recoverable plaintext PII. | §10.74, §10.22.1 | -| ⭐ | 🔐 ⚖ | Where is the GDPR Article 22 right to explanation / meaningful human review event family integrity-bound? | §10.74 lifts §10.50 to REQUIRED for Article 22-covered decisions. `audit.gdpr.article_22.*` family covers human-intervention request received, human reviewer identity and review outcome, consumer-supplied contest details, institution response timing. The `audit.review.legal_basis_regime` attribute identifies the regime under which review is operating. | §10.74, §10.50 | +| ⭐ | 🔐 ⚖ | Where is the GDPR Article 22 right to explanation / meaningful human review event family integrity-bound? | §10.74 lifts §10.50 to REQUIRED for Article 22-covered decisions. `audit.gdpr.article_22.*` family covers human-intervention request received, human reviewer identity and review outcome, consumer-supplied contest details, institution response timing. The `audit.review.legal_basis_regime` attribute identifies the regime under which review is operating. (kognitos point 11) | §10.74, §10.50 | | ⭐ | 🔐 | How does the controller record lawful basis under Article 6(1)(a)-(f) on the chain entry itself? | §10.38 + §10.74: `audit.lawful_basis.basis_code` (closed enum `art_6_1_a..f`), `legitimate_interest_assessment_id`, `dpia_id`, `controller_identity`, `purpose_code`. REQUIRED on every chain entry representing a processing decision touching identifiable data. | §10.38, §10.74 | | | 🔐 | HIPAA composition — BAA, minimum-necessary, 60-day breach clock, hybrid entity, categorical exclusions? | §10.73 HIPAA composition section. BAA via §10.21 contract-binding (DRY); `audit.phi.disposition` (`redacted_at_sdk` \| `tokenized_via_vault` \| `excluded_from_capture` \| `no_phi_handling`); 60-day breach clock attribute family; hybrid-entity boundary discipline; categorical exclusions (psychotherapy notes, peer review) in §10.70 regime enum. | §10.73 | | | 🔐 | EU AI Act Article 86 right to explanation — sufficient model-decision rationale on demand? | §10.74 EU AI Act high-risk overlay names which attributes (§10.11.1 ECOA reasons, §4.4.2 deployment-intent, §10.47 prompt-output four-tuple, §10.50 HITL governance) compose into an Article 86 explanation packet. | §10.74 | @@ -191,6 +199,7 @@ Most questions carry two or more icons because most readers share the same conce | | 🔐 | NYDFS Part 500 §500.11 — does the chain reach the vendor's process or only the institution's? | §10.19 chain-coverage map names what the chain reaches; §10.21 cross-vendor model-handover + §10.40 cross-vendor chain-merge anchor close the vendor boundary via hash-anchor patterns. The institution's CC8.1 names which side of the boundary it operates. | §10.19, §10.21, §10.40 | | | 🔐 | The clinician's tablet TPM attestation includes device serial — is this a HIPAA device-fingerprinting vector? | §10.32 device-binding uses `device_id_hash` (canonicalized SHA-256 of the device serial) rather than the raw serial. The institution's CC8.1 names what device-binding fields are stripped before chain emission. FIPS-strong, HIPAA-tight. | §10.32, §10.35 | | | 🔐 ⭐ | Strict ISO 3166-1 pinning for source/destination jurisdiction? | §10.20: country code MUST be ISO 3166-1 alpha-2, two-letter uppercase, validated against the current published list. Sub-national region codes (ISO 3166-2, e.g., `"US-NY"`) go in the companion `region_subdivision` attribute. Verifier validates structurally; published-list validation is institution-side per CC8.1. | §10.20 | +| | 📐 🔐 ⚖ | A regulator-side examiner reading the chain alone cannot read the reasoning prose — only the hash. Why is this the correct posture? | By design. The chain binds the integrity, not the content — it proves what was rendered, not what was meant. The reasoning text is typically PII-bearing; §10.22 mandates pre-MAC redaction. The chain binds (a) hashes of the prose (§10.11 `output_hash`, §10.74 `explanation_text_hash`) and (b) structured reasons codes (§10.11.1 `audit.ecoa.adverse_action.reasons`, `feature_attributions`, `model_explanation_method`). The institution holds the plaintext under §10.69 retention discipline. Architectures whose reasoning is inherently in-chain (rules-engine trace, decision-tree path, neurosymbolic program) compose stronger Article 22 / Article 86 "meaningful information" answers than black-box LLMs whose reasoning lives only in the hashed prose — a planned `audit.reasoning.substrate_kind` marker (Seam B) will let the chain itself surface this architecture choice. (kognitos point 8) | §10.11; §10.11.1; §10.74; §10.50; §10.22; §10.69 | --- @@ -201,7 +210,7 @@ Most questions carry two or more icons because most readers share the same conce | ⭐ | 👤 ⚖ | I was denied a loan and I think AI made the decision. How do I ask for my chain evidence? | §10.69 customer-disclosure subprocedure produces an integrity-bound, customer-side independently-verifiable disclosure packet. §13 stakeholder navigation has a "Consumer / data subject exercising rights" entry routing through §1.2 → §10.11 → §10.11.1 → §10.11.2 → §10.23 → §10.69. | §10.69, §13 | | ⭐ | 👤 🛠 | How do I get the verifier? Is there a consumer-friendly build? | §10.69 packets ship with (a) reference to a consumer-runnable verifier — the §10.26 reference binary or a hosted verifier under spec governance — and (b) plain-language quick-start an English-language consumer with no cryptographic background can follow in under 30 minutes. | §10.69, §10.26 | | | 👤 ⚖ | Class-action commonality — can my counsel use chain artifacts? | §10.69 cohort-mode under court order produces a §10.31 cohort subtree disclosure covering the identified class, with each member's §10.69 packet derivable. Rule 23 commonality and predominance considerations apply informatively. | §10.69, §10.31 | -| | 👤 ⚖ | The adverse-action notice gave me "principal reasons" — does the chain prove they match the model's actual weights? | §10.11.1 `audit.ecoa.adverse_action.model_explanation_method` MUST; `audit.ecoa.adverse_action.feature_attributions` REQUIRED-when-applicable (where the model architecture permits SHAP/LIME/native coefficients). Institutions deploying models that genuinely cannot expose attribution name the exception in CC8.1. | §10.11.1 | +| | 👤 ⚖ | The adverse-action notice gave me "principal reasons" — does the chain prove they match the model's actual weights? | §10.11.1 `audit.ecoa.adverse_action.model_explanation_method` MUST; `audit.ecoa.adverse_action.feature_attributions` REQUIRED-when-applicable (where the model architecture permits SHAP/LIME/native coefficients). Institutions deploying models that genuinely cannot expose attribution name the exception in CC8.1. (kognitos point 8) | §10.11.1 | | | 👤 | What does the chain NOT protect me from? | §1.2 epistemic scope: chain does NOT prove factual accuracy, policy compliance, freedom from bias, or completeness of disclosure (§1.2(f) explicit). The honesty of §1.2 is a feature. | §1.2 | | | 👤 ⚖ | How do I know the institution didn't move my decision into a privileged-investigation bucket to hide it? | §10.70 backstop: when a consumer-side dispute (FCRA §611, GDPR Article 22, EU AI Act Article 86) or court order names a specific consumer's index, the institution MUST produce a redacted-with-existence-attestation count of excluded entries matching that index. The consumer learns whether exclusions apply. | §10.70 | | | 👤 🔐 ⭐ | EU supervisory access during cross-border investigation? | §10.70 role-claim enumeration extended with EU-supervisory roles: `eu-dpa-cleared`, `edpb-joint-investigation-cleared`, `eu-ai-act-market-surveillance-cleared`. GDPR Article 60 one-stop-shop composition via §10.21.3 cross-institution registry; AI Act Articles 70-74 information-sharing covered by the EU AI Act high-risk overlay. | §10.70, §10.21.3, §10.74 | @@ -262,6 +271,7 @@ Most questions carry two or more icons because most readers share the same conce | | 📚 | Tenant-id enumeration via `hkdf_inputs_digest`? | §3 clarification: `hkdf_inputs_digest` is intentionally enumeration-equivalent. Institutions whose tenant_id space leaks risk via enumeration SHOULD pseudonymize per §3.1 Pattern 1 (opaque hash-of-legacy). | §3, §3.1 | | | 📚 | Empty-day Merkle root `SHA-256(b"")` under weekly cadence? | §4.2 binding: the `sign_payload` binds the date, so an attacker cannot substitute one empty day for another. Test vectors cover "ten consecutive empty days under weekly cadence" and "two adjacent empty days differing only in date" to mechanically pin the binding. | §4.2, §4.3 | | | 📚 | Constant-time compare sites — enumerated explicitly? | §10.8 enumerates every constant-time-required compare site (fingerprint, MAC, prev_hash structural, Merkle root, signature, genesis_hash, hkdf_inputs_digest, key_fingerprint cache). Each named explicitly. | §10.8 | +| | 📚 📐 📋 | Does the spec admit prompt tampering after the fact? | No. Five surfaces compose under the same hash-binding pattern: §10.47 `audit.generation.system_prompt_sha256`; §4.4.1 `audit.routing.policy_version`; §4.4.2 `audit.deployment.policy_version`; §10.22 `audit.redaction.policy_id` + `policy_version`; §10.74 EU AI Act Article 86 `explanation_text_hash`. Every policy / prompt / rule is hash-bound under the per-event MAC; the institution-side prompt-registry resolves the hash + version to plaintext per CC8.1. Cross-vendor handover (§10.21) captures provider-side policy artifacts. (kognitos point 7) | §10.47; §4.4.1; §4.4.2; §10.22; §10.74 | --- @@ -281,7 +291,7 @@ Most questions carry two or more icons because most readers share the same conce | | 🔍 ⚖ | Deliberative-process privilege (FOIA exemption 5), grand-jury secrecy (Fed. R. Crim. P. 6(e)) in §10.70 regime enum? | §10.70 regime enumeration extended: `foia_exemption_5_deliberative_process`, `foia_exemption_7_law_enforcement`, `grand_jury_6e`, and state-sunshine analogs. §10.69 documented-exception table updated. | §10.70, §10.69 | | | 📋 🛠 | Underwriting output side — recommended rate, override, final charged rate? | §4.4.5 extended with `audit.underwriting.output.*`: `recommended_rate`, `recommended_tier`, `human_override_applied` (boolean), `human_override_authority`, `final_rate`. Bound under canonical bytes. | §4.4.5 | | | 📋 🛠 | Real-time underwriting feature-store as-of timestamp? | §4.4.5 `audit.underwriting.features.feature_store_as_of_utc` (RFC 3339 UTC) normative attribute. Distinguishes feature-store-lag scenarios from real-time decisions. | §4.4.5 | -| | 📋 🛠 ⚖ | Human-override path on the decision — recorded distinctly? | §10.50 + §4.4.5 `audit.human_review.*` family (`reviewer_id_hash`, `reviewer_role`, `reviewer_decision`, `reviewer_rationale`, `agreement_with_ai` boolean). Override is bound to the decision; chain proves human-overrider intervention. | §10.50, §4.4.5 | +| | 📋 🛠 ⚖ | Human-override path on the decision — recorded distinctly? | §10.50 + §4.4.5 `audit.human_review.*` family (`reviewer_id_hash`, `reviewer_role`, `reviewer_decision`, `reviewer_rationale`, `agreement_with_ai` boolean). Override is bound to the decision; chain proves human-overrider intervention. (kognitos point 11) | §10.50, §4.4.5 | | | 🔍 📋 ⚖ | SAR-filing 30/60-day clock binding on detection-moment timestamp? | §10.x `audit.bsa.sar.*` event family parallels §10.11.2 FCRA model: `detection_at_utc`, `subject_known` (boolean — determines 30 vs 60 day clock), `sar_filed_at_utc`, `sar_filing_id` (FinCEN tracking number), `narrative_hash`. | §10.x BSA SAR clock | | | 🛡 🔍 | Cross-institution wire SAR confidentiality (31 CFR §1020.320(e)) — propagation across registry? | §10.71 + §10.70 composition: cross-institution wire cross-anchors MUST NOT propagate `audit.privileged_investigation` tags across the registry. Each institution's SAR-tagging is local; one bank cannot tell another a SAR was filed. | §10.71, §10.70 | | | 📋 🛠 | Three-lines-of-defense ownership map for chain integrity? | §10.80 three-lines-of-defense ownership map (informative): first line = SDK adopter / chain-operations team owns capture + sidecar persistence + `(tenant_id, run_id)` allocation; second line = MRM committee + risk function owns deployment-intent policy + posture decisions; third line = internal audit owns verifier-output review + audit-procedures sampling. | §10.80 |