docs(milestone-15): specify durable readiness ledger and replay registry

[adamshen1007]

Summary

Specifies FounderOS Milestone 15: Durable Production-Provider Readiness Evaluation Ledger and Replay Verification Registry Foundation.

This is documentation-only. It defines durable registration, deterministic genesis initialization, restart recovery, and fresh-evaluator replay verification for exact Milestone 14 readiness packages while credentials, outbound transport, and real provider execution remain structurally absent.

Milestone 15 is specified but not implemented.

Architecture

• Explicit canonical genesis history, head, and marker authority
• Durable registration of exact verified Milestone 14 readiness packages
• Permanent ownership of all original and replay identity coordinates
• Immutable originals and append-only replay attempts
• Dual-time replay using originalEvaluationTime and replayEvaluatedAt
• Exact non-circular commitment domains
• One exact canonical ledger-head schema
• Immutable per-event marker archives plus one byte-identical replaceable fixed current marker as the sole visibility boundary
• Non-authoritative rebuildable derived HEAD and indexes
• Deterministic integrity verification and restart recovery
• Cooperative local file-backed persistence
• Strict privacy and no-execution enforcement

Authority Boundaries

• Reuses the exact Milestone 13 Delivery and Invocation authority
• Reuses the approved Milestone 14 evaluator and Decision-verification boundary
• Preserves knowledge-engine → knowledge-schema
• A durable readiness record is audit and replay evidence only, never execution permission
• Application, adapter, append, integrity, recovery, and validation-result envelopes remain ephemeral and non-persisted

Genesis and Ledger Head

• Clean processes derive byte-identical genesis history, head, and marker commitments
• Fixed current-marker installation is the sole genesis and event visibility boundary
• Genesis latest audit, semantic-event, and subject coordinates are exactly null
• Registration and replay heads use the same exact latest-coordinate schema
• Marker-embedded head, readHead(), and rebuilt derived HEAD are byte-identical

Identity Ownership

Original registration permanently owns:

• idempotency key
• ownership ID
• registration request ID
• transaction ID
• Decision ID
• registration semantic-event ID
• registration audit-entry ID
• registration marker ID

Replay permanently owns:

• replay idempotency key
• replay request ID
• replay attempt ID
• replay semantic-event ID
• replay audit-entry ID
• replay marker ID

Independent Review

Final published-head review:

• Critical: 0
• Important: 0
• Minor: 0
• Observations: 0

Reviewed effective patch fingerprint:

475455092ce349685fe1c85fd7451f8908080581e2bee1a3a3e92609deae4f9a

Final 15-file manifest:

• 254,963 bytes
• SHA-256: 7f91858ee63edcccef78a85b02c791c15d1e536f119965a0473567fbd1adffd9

Traceability

• 29 normative requirements
• 29 acceptance criteria
• 72 unique contiguous scenarios
• 0 requirements without scenarios
• 0 invalid scenario references

Validation

• git diff --check
• pnpm format:check
• pnpm lint
• pnpm build
• pnpm typecheck
• pnpm test

Results:

• 42 predecessor test files
• 1,038 predecessor tests passed
• CI run 27 completed successfully

Status

• ADR-0019: Proposed
• Milestone 15: Specified — not implemented

Explicitly Deferred

Runtime implementation, credentials, secret-store access, outbound transport, provider dispatch or ingestion, real providers, streaming, tools/functions, Agents, Hermes, MCP, routing/failover, distributed coordination, external observability, UI, deployment, and production enablement.

Review Gate

The published documentation patch has passed final whole-PR review and CI. Merge remains controlled by exact-head authorization and normal merge-commit verification.