148 lines
8.1 KiB
Markdown
148 lines
8.1 KiB
Markdown
# 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.
|
|
|
|
## 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 |
|
|
|
|
## 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.
|
|
|
|
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.
|