# GCP Database-First Working Leo Proof - 2026-07-14

## One-Line Result

Leo can now take an ID-free challenge to a real claim, find it in a freshly
rebuilt private GCP database, inspect its body/evidence/edges, explain why it is
shallow, propose better claims, and keep the user in the review loop before any
database change. The bounded no-send run passed `18/18` runtime checks and
`6/6` reasoning outcomes.

This is strong GCP no-send handler proof. It is not Telegram delivery, a
production knowledge apply, continuous replication, or a GCP production
cutover.

## Problem We Were Solving

The system mixed several meanings of "Leo learned": conversation history,
rendered identity files, deployed instructions, proposal rows, and canonical
knowledge. That made it hard to tell whether an answer came from current
database facts, stale runtime context, or benchmark-specific training.

The target is database-first behavior:

1. A discussion is candidate input, not hidden training.
2. Leo retrieves current canonical claims and evidence before asserting KB fact.
3. Leo can challenge weak knowledge and draft candidate improvements.
4. Candidate changes remain reviewable and replayable before canonical apply.
5. Every read and write has a receipt tied to exact database state.
6. The database can be copied and verified without retraining Leo.

## What Makes Leo Leo

| Layer | Change rate | Role | Canonical knowledge? |
| --- | --- | --- | --- |
| Base model and Hermes runtime | Slow/versioned | General language and tool-using ability | No |
| Deployed skills, tool wrappers, and routing config | Versioned deployment | Tell Leo when and how to query, reason, stage, and apply | No |
| Rendered `SOUL.md` and identity/context files | Periodically generated or deployed | Compact runtime context and identity | No; derived/runtime input |
| `public.*` in canonical PostgreSQL | Dynamic and durable | Live claims, sources, evidence, edges, personas, beliefs, strategies | Yes |
| `kb_stage.*` | Dynamic and review-gated | Candidate proposals, review state, and apply state | No until applied |
| Hermes `state.db` and session JSONL | Dynamic runtime continuity | Remembers conversations and operational state | No |
| Current message/session context | Ephemeral | Immediate user intent and iteration | No |

Chat does not update model weights. A conversation can affect the current
reply and session continuity, but durable collective learning should become a
source-bound proposal and, after review and apply, canonical PostgreSQL rows.

## What Changed

### 1. Current VPS knowledge can be rebuilt quickly in GCP

`ops/restore_gcp_generated_postgres_snapshot.py` now restores a reviewed
PostgreSQL 16 custom dump into a bounded `teleo_clone_*` database over private
TLS. It verifies the source hash, client version, schema, rows, constraints,
roles, extensions, performance, rollback state, and live-service invariants.
Failure paths automatically remove partial clones.

This is a fast exact restore from the current canonical database. It is not yet
a full source-of-origin rebuild from every document, URL, post, and repository
artifact.

### 2. GCP retrieval is deterministic and source-bound

`cloudsql_memory_tool.py` now returns a retrieval receipt containing semantic
and artifact-state hashes, database identity, WAL consistency, claim IDs, and
source IDs. Receipts cover all read commands, including proposal and
decision-matrix reads.

Clean canonical clones no longer require the optional legacy `teleo_restore`
audit schema. `status` works without it, and a zero-hit search returns an honest
empty canonical result instead of crashing.

### 3. The real reasoning path was proved, not inferred

The exact prompt supplied no row IDs:

> Our claim that AI sandbagging creates M&A liability feels shallow. Without me
> giving you a claim ID, inspect the live claim and what actually supports it.
> Tell me what is weak, what new claim or claims you would propose, and how you
> would iterate with me before anything becomes live. Do not change the database.

The GCP Hermes turn performed exactly four successful read-only calls:
`search`, `show`, `evidence`, and `edges`. It retrieved claim
`2a7ae257-d01d-46f4-b813-63f81bb9c7c7` and both expected source rows, explained
why the legal claim was over-bundled and weakly grounded, proposed narrower
candidate claims, and asked for review before staging or apply.

The reply used the exact `m3taversal` handle contract and no forbidden alias.
No Telegram message was sent and no DB write was attempted.

### 4. The experiment cleaned itself up

The generated clone was deleted. A second cleanup receipt reports zero
remaining target databases. The disabled rollback database still has zero
connections. The live GCP Leo service remained PID `148735`, active/running,
with `NRestarts=0` throughout restore, model replay, and cleanup.

### 5. The merged GCP path survived deployment and restart

PR `#144` merged the database-first helper and skill. Their exact reviewed
hashes were installed on `teleo-prod-1`, then
`leoclean-gcp-prod-parallel.service` was intentionally restarted. It returned
active/running with a new PID (`304036`) and the deployed hashes remained in
place.

The first post-restart search caught one real integration regression: the old
wrapper used a full `status` read as a 30-second health probe. Stronger receipts
made that probe exceed its bound, after which `auto` mode could silently select
a different local tool. The wrapper now routes every supported GCP knowledge
command directly to Cloud SQL and fails closed on errors. Two regression tests
cover direct routing and no fallback.

A corrected live search then found the expected sandbagging claim plus both
expected source rows and hashes from persistent `teleo_canonical`. A subsequent
status read returned the same `1,837` claims, `4,145` sources, `4,916` edges,
`4,670` evidence rows, and `26` proposals as before deployment. Both commands
returned stable retrieval receipts. No Telegram message or DB write occurred.

## VPS Versus GCP

| Surface | Current result | Meaning |
| --- | --- | --- |
| VPS production DB | `39` tables, `52,167` rows, `29` proposals at capture | Newest measured canonical source for this run |
| GCP persistent `teleo_canonical` | Previously verified at `39` tables, `52,164` rows, `26` proposals | Older staging copy; not promoted or cut over |
| Disposable GCP clone | Exact `39/39`, `52,167/52,167`, zero mismatches | Proves current VPS state can be recreated privately in GCP |
| GCP Hermes no-send turn | `18/18` checks, `6/6` outcomes | Proves the rebuilt DB works through the real reasoning/tool path |
| Disposable clone after test | Absent | Proves lifecycle cleanup; it is not a fourth persistent source of truth |

This is not three Git branches. The persistent divergence is operational: the
VPS canonical DB is newer than the still-staging GCP canonical DB, while the
GitHub repository owns the code and deployment instructions. Reconciliation
means choosing an authoritative DB snapshot, restoring/verifying GCP from it,
then explicitly promoting or cutting over. It does not mean merging database
rows as if they were source-code branches.

## Proof Receipts

| Receipt | SHA-256 | What it proves |
| --- | --- | --- |
| `gcp-db-first-restore-current.json` | `06591cb97c7108f7932d042912e2dcad9eb54bbca5cde72ad53642beb79aa89c` | Private restore completed and live service stayed unchanged |
| `gcp-db-first-parity-current.json` | `0173ee6707016e8412e6dd4326d61f71b6ef862bbc5b819079d62680676729f2` | Schema, row, role, extension, and performance parity passed |
| `gcp-db-first-blind-claim-current.json` | `8a7cc3c1814eb385e858f12ef7579cd4524f37886c03fc6d9c61624b6aff2a52` | Real GCP Hermes reasoning passed with source-bound read receipts |
| `gcp-db-first-cleanup-current.json` | `cac7e34f45653fabb696d911b6ccc921d3f291bf8cbe05a429d757e717dcafb4` | Clone absent, rollback disabled, service unchanged |
| `gcp-db-first-live-deploy-restart-current.json` | `d70fdbac859b8c98d557f4df900139a93e6009e12f7b80c9adbd69a5655b9df7` | Merged deploy, fail-closed routing, restart, and live status/search readback passed |

## What This Unlocks

- We can test database changes by rebuilding a disposable copy instead of
  repeatedly changing Leo's prompt or session memory.
- We can compare answers against exact claim/evidence/source rows and detect
  when a response came from unsupported runtime context.
- We can move the same database-first behavior from VPS to GCP without exposing
  Cloud SQL publicly.
- We have a bounded path for future out-of-sample benchmarks: vague question,
  fresh retrieval, claim challenge, candidate proposal, user iteration, guarded
  apply, and row-level postflight.

## Still Not Proven

1. The same full challenge is visible in a current Telegram conversation.
2. A real user-approved candidate from this reasoning loop is staged, reviewed,
   applied, and read back end to end on production.
3. The entire canonical DB can be reconstructed from original source documents
   and repository artifacts rather than restored from a database snapshot.
4. VPS changes continuously replicate to GCP or GCP has been formally promoted.
5. Broad reliability across many unseen claim domains and repeated trials.
6. A model reasoning turn after the controlled GCP restart. The post-restart
   proof in this report is the real service plus live `teleo-kb` status/search
   path, not a new paid model response.

The next product-level proof is one natural Telegram challenge that reaches
the same database-grounded reasoning, followed by one explicitly approved
proposal lifecycle with exact source/claim/evidence/edge receipts. Those are
separate authorization and production-mutation steps; neither occurred here.
