---
name: teleo-kb-bridge
description: Use the VPS Postgres KB bridge before answering questions about claims, evidence, edges, schema-backed soul/context, KB approval, or KB edit workflow.
version: 1.0.0
author: m3taversal
license: MIT
metadata:
  hermes:
    tags: [teleo, kb, postgres, claims, evidence, governance]
    related_skills: [leo-synthesis-methods]
---

# Teleo KB Bridge

The canonical Teleo knowledge base is Postgres, not runtime memory.

This is the VPS production leoclean surface. Before answering a KB-specific
question, run the local bridge:

```bash
/home/teleo/.hermes/profiles/leoclean/bin/teleo-kb context "<question>"
```

Use narrower bridge commands when needed:

```bash
/home/teleo/.hermes/profiles/leoclean/bin/teleo-kb search "<terms>"
/home/teleo/.hermes/profiles/leoclean/bin/teleo-kb show <claim_id>
/home/teleo/.hermes/profiles/leoclean/bin/teleo-kb evidence <claim_id>
/home/teleo/.hermes/profiles/leoclean/bin/teleo-kb edges <claim_id>
/home/teleo/.hermes/profiles/leoclean/bin/teleo-kb list-proposals
/home/teleo/.hermes/profiles/leoclean/bin/teleo-kb show-proposal <proposal_id>
```

## Answer Discipline

For KB questions, prefer the bridge over raw database access. A good default is:

1. `teleo-kb context "<question>"`;
2. at most three `show` / `evidence` / `edges` / `show-proposal` follow-ups for
   the most relevant IDs;
3. final answer with what is grounded, what is weak, and what evidence or
   proposal would improve it.

Use raw `docker exec ... psql` only as a narrow read-only fallback when the
bridge cannot answer a schema or implementation-status question. If you use
that fallback, say it was a read-only inspection. Do not present raw SQL as the
normal user workflow.

## Claim / Body / Concept Map Loop

When a user challenges a claim as too broad, too light, unfalsifiable, or
poorly linked, do this loop:

1. fetch the headline claim with `teleo-kb show <claim_id>` or `search`;
2. fetch evidence and edges with `teleo-kb evidence <claim_id>` and
   `teleo-kb edges <claim_id>`;
3. separate what the KB actually says from your synthesis;
4. decide whether the right change is: attach evidence, add edges, revise the
   claim, supersede the claim, split the claim into multiple claims, or create a
   concept-map/reasoning-tool proposal;
5. stage a reviewable proposal when the requested correction is clear enough.

For "was this implemented?" or "did you apply that?" questions, answer in this
shape:

```text
Status: applied | pending | missing | partially applied
Canonical rows: <what exists in public.*>
Staged proposals: <proposal IDs/statuses>
Rows/edges/evidence needed: <concrete list>
Next admin action: approve/apply the proposal, request edits, or create the missing proposal.
```

Do not call an approved proposal "implemented" until canonical `public.*` rows
and edges show the applied state.

## Memory vs KB Rule

Do not treat runtime memory as canonical truth.

```text
agent memory = local/runtime continuity
Postgres KB = canonical collective knowledge
```

If a correction changes collective truth, it belongs in the KB graph, not only
runtime memory.

## VPS DB Objects

Relevant DB objects live in the VPS Postgres container and should normally be
reached through `teleo-kb`:

- `kb_stage.kb_proposals` - durable proposal ledger;
- `kb_stage.pending_kb_proposals` - proposals with `status = 'pending_review'`;
- `kb_stage.document_evaluations` - lightweight document evaluation decisions;
- `public.claims`, `public.sources`, `public.claim_evidence`, `public.claim_edges` - canonical tables.

## Write Policy

Canonical KB writes are locked. The bridge can create reviewable proposals, but
it does not directly mutate canonical `public.*` rows from normal chat.

If a reviewer explicitly asks for proposal status reconciliation or canonical
application, inspect the proposal first, use the narrowest available bridge or
admin apply path, and retain before/after readback. If no `teleo-kb apply-*`
command exists, say that the proposal is staged and needs reviewer/operator
apply tooling rather than inviting ad hoc SQL from chat. Do not treat a chat
statement, runtime memory, or a staged proposal as canonical truth.

Never end a normal Telegram answer by offering to run direct `INSERT`, `UPDATE`,
or transaction SQL from chat. Even if the user is authorized, the product flow is
review-first:

```text
Next admin-panel action: show the staged proposal, dependency groups, and
before/after rows; let a reviewer approve, reject, edit, or run a dedicated
apply tool with retained readback.
```

If the current bridge lacks a dedicated apply command, say exactly that and stop
at a reviewable apply plan. The next thing Leo may offer from chat is to draft or
refresh the admin review packet, not to mutate canonical tables directly.