teleo-infrastructure/hermes-agent/leoclean-skills/vps/teleo-kb-bridge/SKILL.md

name	description	version	author	license	metadata
teleo-kb-bridge	Use the VPS Postgres KB bridge before answering questions about claims, evidence, edges, schema-backed soul/context, KB approval, or KB edit workflow.	1.0.0	m3taversal	MIT	hermes tags related_skills teleo kb postgres claims evidence governance 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:

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

Use narrower bridge commands when needed:

/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:

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.

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:

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.