The leo-db-state series: what is actually in the canonical database, the path an approved change takes to become a row, and the receipts that prove each step happened. Read-only by construction.
—
Canonical claims
—
Domains
—
Recorded events
—
Contributors
Approve → apply path
VPS proven · GCP pending
1
Ground
Read canonical KB and runtime context
✓ VPS○ GCP
2
Propose
Strict deltas with evidence
✓ VPS○ GCP
3
Approve
Reviewer note and caveats persisted
✓ VPS○ GCP
4
Apply
Canonical public.* row mutation
✓ VPS○ GCP
5
Prove
Before/after row-level proof
✓ VPS○ GCP
Full path proven end-to-end on the VPS on 2026-07-09, strict proposal approved, applied into public.claim_edges, before/after rows recorded, runtime stable (plate 04). The GCP column turns green when Milestone 2's installation receipt lands.
Working Leo Definition From Chat Evidence. Cory/m3taversal appears to mean approved KB changes become canonical database state with proof, not only staged proposal text.
Cloud SQL runtime role, scoped secret/IAM, one successful IAP installation receipt proving the digest-bound no-send service is running.
Latest reviewed IAP attempt failed closed; that revision is held, not retried.
○ Pending
M3, Runtime security proof
In-container identity, allowed reads and function-only proposals, denied writes and escalation, no-send posture, restart, rollback, reinstall.
○ Pending
M4, GCP / VPS parity
Bounded database and behavioral comparison close enough for cutover.
○ Pending
M5, Telegram cutover & retirement
Separately authorized cutover, one approved message with receipt, soak, restore-test, credential revocation, VPS retirement.
Plates were generated from live database reads during the Working Leo convergence runs (2026-07-09/10). Plates 13–27 are committed in teleo-infrastructure/docs/reports/leo-working-state-20260709/; plates 01–12 await promotion from the run's outputs (tracked backlog). The archive preserves the full series unedited.
