AI Review Surface

This document is the explicit inventory of every open TODO: AI_REVIEW site in the repository and the written disposition record for sites that have been closed. It feeds the claim-led security assurance protocol and is enforced by the local assurance gate.

Nothing in this file implies those constructions are approved. It exists to keep the AI assessment surface small, concrete, evidence-driven, and hard to forget while the product continues to evolve.

Current Status

• AI review status: closed

• expected open AI review sites: 0

• policy: every TODO: AI_REVIEW location in source must be listed here and in the inventory check

• assurance mapping: each open site, if one is added later, must be represented in assurance-claims.md as a tracked-open claim until dispositioned

Open Inventory

No open TODO: AI_REVIEW sites remain.

Dispositioned Inventory

Claim ID	Area	Disposition	Evidence
audit.chi-squared-tail	Chi-squared audit	Acceptable as implemented. paranoid-core computes Pearson’s chi-squared statistic over the fixed password charset bins, uses df = N - 1 because no distribution parameters are estimated from the audit sample, converts the statistic through the chi-squared upper tail, and treats p > 0.01 as the pass condition. A larger statistic is therefore more suspicious, matching the NIST/Sematech chi-square goodness-of-fit rejection rule and upper-tail critical-value table.	crates/paranoid-core/src/lib.rs; chi_squared_known_answers_hold; chi_squared_upper_tail_threshold_brackets_one_percent_critical_value; NIST/Sematech chi-square goodness-of-fit test; NIST/Sematech chi-square critical values
audit.serial-correlation-estimator	Serial correlation audit	Acceptable as implemented. paranoid-core computes the lag-1 autocorrelation over the generated byte stream using the NIST/Sematech definition: subtract the full-sample mean, sum adjacent (Y_i - mean)(Y_{i+1} - mean) products over the non-circular N - 1 windows, and normalize by the full-sample sum of squared deviations. The implementation returns 0.0 for fewer than two samples or zero variance, and the audit summary treats abs(r) < 0.05 as a conservative smoke-check pass condition rather than a randomness certification.	crates/paranoid-core/src/lib.rs; serial_correlation_known_answers_hold; serial_correlation_exact_lag_one_known_answers; NIST/Sematech autocorrelation; NIST Dataplot autocorrelation reference
audit.external-device-health	External audit-device posture	Acceptable as implemented. External audit-device health evidence is conservative: configured endpoint and mTLS evidence alone never produce readiness, disabled probes stay Unverified, TCP reachability stays Unverified because it proves only transport reachability, and the mTLS JSONL probe reports Ready only after an OpenSSL-backed mTLS connection receives a matching protocol/version/probe/challenge acknowledgement for a paranoid-core RNG-generated challenge. Federal startup policy consumes AuditSinkHealth::is_available(), so only configured, writable, Ready sinks satisfy required audit controls.	crates/paranoid-audit/src/lib.rs; external_audit_device_availability_requires_ready_writable_health; external_audit_device_environment_lookup_never_claims_ready; external_audit_device_tcp_probe_reaches_open_listener_without_claiming_ready; external_audit_device_mtls_jsonl_ack_probe_marks_ready_after_matching_ack; external_audit_device_mtls_jsonl_ack_probe_rejects_mismatched_ack; crates/paranoid-ops/src/lib.rs; unverified_external_audit_device_does_not_satisfy_required_audit_control; ready_external_audit_device_can_satisfy_required_audit_control; stable federal startup fixtures
ops.shared-policy-boundary	Ops policy boundary	Acceptable as implemented after hardening. CLI, TUI, GUI, and mTLS automation paths share typed OpsCommandEnvelope evaluation, paired request/response audit events, adapter surface metadata, vault operation/access metadata, and the same allow/challenge/deny decision model. Local adapters derive envelope profile from the authoritative OpsPolicyContext; externally supplied envelopes fail closed with profile_context_mismatch if they attempt to downgrade or conflict with that context. The mTLS process-boundary server also replaces client-asserted transport claims with observed peer-certificate evidence before policy evaluation.	crates/paranoid-ops/src/lib.rs; policy_envelope_cannot_downgrade_authoritative_context_profile; vault_operation_policy_boundary_preserves_adapter_surface_and_access_metadata; evaluate_vault_operation_returns_policy_decision_and_audit_events; crates/paranoid-cli/src/main.rs; crates/paranoid-cli/src/vault_cli.rs; crates/paranoid-cli/src/vault_tui.rs; crates/paranoid-gui/src/lib.rs; stable ops trace fixtures; tests/test_cli.sh; tests/test_vault_cli.sh
seal.lifecycle-boundary	Seal lifecycle posture model	Acceptable as implemented after hardening. paranoid-seal owns the serializable seal-state machine and non-secret provider posture, while CLI vault seal-status reads vault headers without decrypting item payloads. Metadata-only reports keep provider status at configured; seal-status --probe-providers marks a device-bound provider available only after the explicit secure-storage check succeeds. Ops policy now consumes the posture with method-specific provider checks: password unlock requires a password recovery provider, mnemonic unlock requires a mnemonic provider, device-bound unlock requires an available device-bound provider rather than any generic auto-unseal provider, and certificate unlock requires certificate provider evidence.	crates/paranoid-seal/src/lib.rs; posture_keeps_provider_availability_method_specific; recovery_required_state_remains_required_with_recovery_provider; posture_reports_certificate_configuration_without_claiming_auto_unseal; crates/paranoid-ops/src/lib.rs; password_unlock_requires_password_recovery_provider; mnemonic_unlock_requires_mnemonic_recovery_provider; device_bound_unlock_requires_available_device_bound_provider; device_bound_unlock_rejects_generic_external_auto_unseal_availability; crates/paranoid-cli/src/vault_cli.rs; seal_posture_for_unreadable_vault_does_not_synthesize_provider; tests/test_vault_cli.sh; docs/reference/architecture.md
vault.device-bound-keyslot	Device-bound keyslot design	Acceptable as a default-profile local-device convenience unlock. The implementation stores the 256-bit vault master key in the platform secure-storage provider under an unguessable account id, stores only keyring metadata and an OpenSSL-backed AES-256-GCM check blob in the SQLite header, rejects missing, wrong-length, deleted, or tampered secure-storage material before exposing unlocked vault state, and deletes or rotates secure-storage accounts during keyslot removal and rebind.	crates/paranoid-vault/src/lib.rs; device_keyslot_unlock_round_trip; device_keyslot_provider_probe_reports_unavailable_missing_secret; device_keyslot_rejects_tampered_secure_storage_secret; device_keyslot_rejects_wrong_length_secure_storage_secret; backup_does_not_export_device_secure_storage_secret; rebind_device_keyslot_rotates_secure_storage_account; tests/test_vault_cli.sh; docs/reference/vault-format.md; docs/reference/federal-readiness.md
vault.mnemonic-recovery-keyslot	Mnemonic recovery construction	Acceptable as a default-profile offline recovery construction. Enrollment generates 256 bits of OpenSSL RNG-backed entropy, encodes it as a 24-word English BIP39 phrase, and uses the recovered entropy as the AES-256-GCM key that wraps the vault master key. BIP39 is used here as a checksum-protected human transcription format for computer-generated entropy, not as a password KDF or user-authored brainwallet path. Unlock now validates the stored mnemonic keyslot metadata before unwrap, rejects non-24-word or checksum-invalid phrases, keeps recovered entropy zeroized in process, and backup packages preserve only the encrypted keyslot metadata, not the phrase or raw entropy.	crates/paranoid-vault/src/lib.rs; mnemonic_keyslot_unlock_round_trip; mnemonic_keyslot_rejects_invalid_word_count_phrase; mnemonic_keyslot_metadata_tampering_fails_closed; wrong_mnemonic_fails_closed; backup_does_not_export_mnemonic_phrase_or_entropy; BIP-39; NIST FIPS 197 AES; NIST SP 800-38D GCM; docs/reference/vault-format.md; docs/reference/federal-readiness.md
vault.certificate-wrapped-keyslot	Certificate-wrapped keyslots	Acceptable as implemented for current keyslots. Enrollment and rewrap select one explicit X.509 recipient certificate, generate a fresh 256-bit OpenSSL RNG-backed transport key, wrap only that transport key with OpenSSL CMS EnvelopedData, and wrap the vault master key separately with AAD-bound AES-256-GCM under the transport key. Unlock validates certificate fingerprint, subject, validity metadata, supported wrap algorithm, current AES-GCM field lengths, and legacy field shape before unwrap. The legacy cms-envelope+aes-256-cbc direct master-key slot shape remains read-only compatibility only; new and rewrapped slots use cms-envelope+transport-key+aes-256-gcm. Backup packages preserve the public certificate metadata and CMS-wrapped transport key but never contain the private key or raw transport key.	crates/paranoid-vault/src/lib.rs; validate_certificate_keyslot_metadata; certificate_keyslot_unlock_round_trip; certificate_keyslot_rejects_unsupported_wrap_algorithm; certificate_keyslot_metadata_tampering_fails_closed; certificate_keyslot_transport_key_shape_tampering_fails_closed; legacy_certificate_keyslot_unlock_remains_supported; backup_does_not_export_certificate_private_key_or_raw_transport_key; RFC 5652 CMS; NIST FIPS 197 AES; NIST SP 800-38D GCM; docs/reference/vault-format.md; docs/reference/federal-readiness.md

Disposition limits:

• The chi-squared audit is an implementation smoke check for gross uniformity drift in generated batches. It is not a certification of RNG quality and does not replace OpenSSL RNG delegation, rejection-sampling checks, or release assurance.

• The audit assumes the expected distribution is fixed by the supplied charset. Any future audit that estimates distribution parameters from the observed batch must revisit the degrees-of-freedom calculation before reusing this disposition.

• The serial-correlation audit is also a generator smoke check. It detects adjacent byte dependence in generated batches, but it is not an independence proof and does not replace OpenSSL RNG delegation, rejection-sampling checks, or release assurance.

• The serial-correlation disposition applies to the current lag-1, non-circular byte-stream estimator only. Any future printable-character rank mapping, higher-lag report, or formal hypothesis test must add its own referenced disposition and known-answer tests.

• The external audit-device disposition is a readiness-evidence claim for the configured endpoint at startup. It is not FedRAMP authorization, product FIPS validation, durable remote-ingestion proof, or an audit-device service-level assertion.

• TCP reachability remains evidence only and must stay Unverified. Any future durable receipt, hash-chain ingestion, replay protection, queueing, or remote retention semantics need a separate disposition with tests and docs before satisfying more than startup write-ack readiness.

• The ops policy-boundary disposition applies to commands routed through paranoid-ops typed evaluators and the current mTLS JSONL process-boundary transport. Any new adapter or remote protocol must prove it derives or validates authoritative policy context, preserves request and response audit pairing, and fails closed before it can rely on this disposition.

• A federal-ready Challenge decision records the need for fresh operator proof; it is not itself a completed human authentication ceremony or customer identity-provider integration.

• The seal lifecycle disposition covers the current local vault-header posture model, explicit device-bound provider probe path, and method-specific ops unlock controls. It is not a claim that external auto-unseal providers, certificate lifecycle governance, or customer recovery ceremonies are complete; new provider kinds or remote seal protocols need their own probes, policy checks, and evidence fixtures before relying on this disposition.

• The device-bound keyslot disposition trusts the local OS secure-storage provider as a platform boundary for default-profile daily unlock only. It is not portable recovery, not a remote auto-unseal provider, not FedRAMP authorization, not product FIPS validation, and not the strict federal-ready unlock path. Backup packages preserve the device keyslot metadata and check blob so same-device restores can keep working, but backup packages do not contain the device secure-storage secret and must fail closed when restored without that local provider secret.

• The mnemonic recovery disposition applies only to phrases generated by this vault implementation from 256 bits of OpenSSL RNG-backed entropy and stored as 24-word English BIP39 recovery phrases. It does not approve user-created phrases, phrase import, split-secret recovery, password-derived recovery phrases, or the strict federal-ready unlock path. Backup packages can keep the encrypted mnemonic keyslot portable, but the operator must protect the phrase separately because the backup never contains the phrase or raw mnemonic entropy.

• The certificate-wrapped keyslot disposition applies to the current single-recipient X.509 CMS transport-key construction and the tested legacy read path only. It does not approve customer PKI governance, certificate issuance policy, certificate revocation checking, multi-recipient escrow, external HSM/KMS operation, FedRAMP authorization, DoD authorization, or product FIPS validation. AES-256-CBC appears only inside the CMS transport-key envelope for compatibility with OpenSSL CMS; the vault master key is wrapped by AES-256-GCM with associated data in current slots.

Required AI Assessor Output

Each open site must receive a short written AI assessor disposition backed by source evidence, commands, artifacts, and tests. The disposition must answer:

1. Is the current construction acceptable as implemented?

2. If yes, what assumptions or deployment limits make it acceptable?

3. If no, what concrete change is required?

4. What tests, invariants, or comments should remain after sign-off?

For UI-sensitive changes, the disposition must also cite rendered screenshot artifacts from make test-gui-visual-regression on Linux or make test-gui-visual-regression-emulate on macOS. The viewport classes are desktop, tablet, and narrow/mobile-class. The default artifact set is dist/release/gui-e2e-desktop.png, dist/release/gui-e2e-tablet.png, and dist/release/gui-e2e-mobile.png.

Closeout Rules

A TODO: AI_REVIEW site is only ready to remove when all of the following are true:

1. The AI assessor has produced a concrete written disposition with file and test evidence.

2. The source code and tests have been updated to reflect that disposition.

3. This document has been updated to remove or revise the inventory entry.

4. scripts/verify_ai_review_inventory.sh passes with the new expected inventory.

Operator Commands

List the current review markers:

rg -n "TODO: AI_REVIEW" crates

Verify the inventory matches the source tree:

bash scripts/verify_ai_review_inventory.sh

Capture the GUI evidence artifact when the PR touches UI behavior, layout, or branding:

make test-gui-visual-regression-emulate