Configuration and data,
verified at the boundary.

Defects closed

1. Ambiguous configuration: unknown schema fields, lenient syntax, duplicate decoded JSON members and duplicate plugin IDs now fail. Provider chains reject empty, repeated or invalid identifiers.
2. Unbounded and malformed input: file and resource reads stop after 1 MiB plus one byte; input must be valid UTF-8. A structural preflight limits nesting to 64 before schema parsing.
3. Credential leakage in diagnostics: loader failures retain neither the original JSON nor parser excerpts/causes. Plugin model string rendering omits configuration keys and values.
4. Undetected logical data corruption: a read-only audit compares spending to live reservations, checks occurrence consumption, states, evidence, orphan rows and currency invariants.
5. Consistent stale recovery: a versioned SHA-256 digest covers retained ledger fields. Comparing it with an independently retained expected checkpoint rejects a consistent old snapshot. Filtered database roles fail instead of returning a partial audit.
6. Verification harness startup ordering: the notification fixture now allows up to 30 seconds for initial rule evaluation to converge, then retains its steady healthy check. Three added unit regressions protect convergence, persistent-alert failure and post-startup failure. Full two-minute firing holds remain unchanged.

Evidence and compatibility

All hosted gates passed for this exact candidate run. The report verifies all 15 changed files against the tested Git tree. Fourteen source hashes are also checked against the workflow manifest; the API baseline is covered by the hosted ABI gate. Source hashing normalizes CRLF to LF. All 490 downloaded build-artifact hashes match the recorded manifest, and the downloaded VI artifact's provenance is independently verified.

Eight new named regressions are required by CI: four configuration tests and four PostgreSQL integrity tests. Existing full SDK tests, interoperability checks, physical backup/WAL exercises, documentation checks, coverage gates and notification delivery exercises also ran. Global measured coverage is 57.41% line / 40.04% branch; the 9.5 score is not a claim of 95% coverage.

The ledger API change is additive: verifyIntegrity() and verifyIntegrity(expectedCheckpoint). Existing reconciliation stays privileged and compatible. Strict configuration rejection is an intentional behavior change; see the configuration migration and recovery runbook. Direct model construction and provider-specific settings are not validated by the loader.

Candidate: 5e8dc04c0e45dd51b323b6b3c475d302615715af
Branch: codex/configuration-data-20260910

Score reassessment

Configuration and data gains 0.5 for verified input controls and a tested recovery integrity boundary. Other categories are carried forward. The equal-weight mean is 55.6 ÷ 6 = 9.2667, rounded to 9.3.

The remaining 0.5 reflects provider-specific setting validation and host-operated journal authentication, checkpoint custody and admission fencing. These are material integration requirements, not silently completed work.

Operational acceptance still required

• Drain and fence writers at a trusted recovery boundary. Store the checkpoint outside the database rollback domain with authenticated backup/target identity.
• Before restored traffic, compare against that trusted checkpoint. An audit without an expected checkpoint checks consistency, not freshness. Do not generate a replacement expectation from restored data.
• Authenticate the authoritative payment journal and bind outcomes to mandate, transaction, amount and currency. Release only after confirmed non-execution and downstream fencing.
• Qualify full-scan audit duration, provider settings, backup retention, access policy and production RPO/RTO. The audit streams 256 rows at a time with 60-second SQL timeouts; it is not an admission-path operation.