---
name: teleo-kb-bridge
description: Use the VPS Postgres KB bridge before answering questions about claims, evidence, agent beliefs, schema-backed identity, proposal readiness, or KB changes.
version: 1.1.0
author: m3taversal
license: MIT
metadata:
  hermes:
    tags: [teleo, kb, postgres, claims, evidence, governance]
    related_skills: [leo-synthesis-methods]
---

# Teleo KB Bridge

Postgres is canonical knowledge. Runtime memory, chat, and `SOUL.md` are not
canonical database writes.

## Mandatory Reply Contract

Unless the operator explicitly requests a detailed audit or long-form document,
draft to at most 170 words; the final reply must never exceed 220 words. A
smaller word or line limit is mandatory.

Use this shape:

1. direct answer in the first sentence;
2. at most three short bullets with only the relevant readback, state boundary,
   and current-schema constraint;
3. at most one proof-changing next action.

Do not mirror this skill, enumerate unrelated fields, repeat the answer as a
summary, or turn a direct question into an architecture lecture. Silently
count and shorten the draft before sending it; never send more than 220 words.

## Mandatory Current-Truth Gates

Apply these before drafting the answer or proposing a next action:

1. **Proposal readiness:** `approved` is intent approval, not applyability.
   Read the proposal's `readiness` object. If `review_state` is
   `approved_needs_apply_payload`, normalize into a strict payload and review
   that new packet; never tell the operator to apply the legacy row.
   `approved_contract_present` proves only contract presence, not strict
   validation, production-worker enablement, authorization, or apply.
2. **Source/evidence audit:** `teleo-kb search` searches claims and identity
   context, not canonical source rows. Use `evidence <claim_id>` or a bounded
   read-only `public.claim_evidence` to `public.sources` join. A missing locator
   means weak provenance, but an existing canonical link is still canonical
   evidence. Null `applied_at` proves only that proposal did not apply; matching
   canonical rows could have another origin.
3. **Shared facts versus agent positions:** store the factual claim once with
   shared evidence. Current agent-owned positions live in `public.beliefs` with
   `id`, `agent_id`, `level`, `statement`, `confidence`, `falsifier`, `rank`,
   `status`, `created_at`, and `updated_at`. The table has no claim-ID foreign
   key and there is no belief-edge table. `public.claim_edges` connects claims,
   never belief rows. `reasoning_tools` are methods and `behavioral_rules` are
   operating rules; neither is generic stance storage.
4. **Write boundary:** extraction creates candidates inside a reviewed proposal,
   not canonical `public.sources` or `public.claims`. Capture a retained artifact,
   URL/storage path, and content hash; reject a chat label or `source_ref` as
   source identity. The source compiler is build-only and locally proven, not
   autonomous live-VPS intake. It can create a `pending_review` packet without
   apply authorization. Every current-capability intake answer must lead with:
   local compiler proven; live VPS/chat intake not shipped. Approval begins
   before guarded canonical apply.
5. **Capability boundary:** current `approve_claim` accepts only `claims`,
   `sources`, `evidence`, `edges`, and `reasoning_tools`. It cannot insert
   `behavioral_rules` or `governance_gates`, update beliefs or an existing claim,
   or run a general identity render. Separate unsupported changes for a reviewed
   future capability; never include them in a runnable apply sequence.
   `applied_at` belongs to the proposal receipt, not each inserted row.
6. **Identity and proof:** canonical identity can include `personas`,
   `strategies`, `beliefs`, strategy nodes/anchors, and related governed rows;
   do not reduce it to claims. No active general DB-to-`SOUL.md` renderer
   automation is currently proven. Unchanged table totals also do not prove
   unchanged rows; use row IDs, timestamps, hashes, or fingerprints. Hermes
   `state.db` and session JSONL can preserve continuity across restart. Separate
   handler proof, Telegram-visible delivery, and canonical DB-mutation proof.
7. **Explanation versus relationship:** current `public.claim_edges` has no rationale
   field. A `supersedes` edge records a relationship, not the human explanation.
   Ground the explanation in source/evidence or a separately reviewable claim.
   Do not invent a `retired` status value.
8. **Mixed-packet composition:** facts and disputed interpretations map to
   claims plus sources/evidence; a reusable framework maps to `reasoning_tools`,
   not a claim graph; operating rules map to `behavioral_rules`; evaluative gates
   map to `governance_gates`; agent positions map to `beliefs`. Current
   `approve_claim` can apply only its five supported collections. Keep policy,
   gate, belief-update, and existing-row updates staged until a separate reviewed
   capability is live; never list them in the supported apply order.

## Read Commands

This is the VPS production leoclean surface. Start with:

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

Use only the bounded follow-ups relevant to the question:

```bash
/home/teleo/.hermes/profiles/leoclean/bin/teleo-kb status
/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 --status all --limit 50
/home/teleo/.hermes/profiles/leoclean/bin/teleo-kb search-proposals "<terms>" --status all --limit 20
/home/teleo/.hermes/profiles/leoclean/bin/teleo-kb show-proposal <proposal_id>
/home/teleo/.hermes/profiles/leoclean/bin/teleo-kb decision-matrix-status
```

For direct state questions, run `status` plus the relevant proposal read. Copy a
full proposal UUID when one row answers the question; otherwise copy all five
observed counts:

```text
DB readback: proposal: `PROPOSAL_UUID`; status: `STATUS`; applied_at: `TIMESTAMP_OR_NONE`; readiness: `REVIEW_STATE`.
DB readback: claims: `N`; sources: `N`; claim_edges: `N`; claim_evidence: `N`; kb_proposals: `N`.
```

If decision-matrix tables are absent, say reviewer status is not a
decision-matrix vote. If a bridge command cannot answer a schema question, use
one bounded read-only Postgres inspection and label it as such.

## Current V1 Facts

- Claim types: `structural`, `normative`, `empirical`, `concept`, `meta`.
- Evidence roles: `grounds`, `illustrates`, `contradicts`; evidence links point
  to source rows whose text may live in `public.sources.excerpt`.
- Current `public.sources` stores `id`, `source_type`, `url`, `storage_path`,
  `excerpt`, `hash`, `captured_at`, `created_by`, and `created_at`. It has no
  `author`, `title`, `publisher`, or publication-date column. Retain that richer
  metadata in the review packet until a reviewed schema can store it canonically.
- Edge types: `supports`, `challenges`, `requires`, `relates`, `contradicts`,
  `supersedes`, `derives_from`, `cites`, `causes`, `constrains`, `accelerates`.
- Current v1 has no forecast-resolution fields or `resolves` edge. Preserve the
  original probability and call resolution ambiguous when criteria were absent.
- A Telegram attachment, cache file, or proposal `source_ref` alone does not
  prove canonical evidence from that artifact.
- Handler success without a Telegram post is handler proof, not
  Telegram-visible delivery. A visible reply proves delivery, not DB mutation.

## Write Policy

Normal chat may capture a real source and stage a reviewable proposal. It may
not mutate canonical `public.*`. Apply requires the matching strict payload,
human review, explicit operator/admin authorization, a supported apply path, a
committed transaction, row-level postflight proof, and non-null `applied_at`.

The strict existing-ID `add_edge` path is live-proven. Rich `approve_claim`
bundles are clone-proven. The production apply worker remains disabled/inactive
unless a fresh service readback proves otherwise. Never offer direct SQL from
chat.

## Telegram Participant Naming

Address `@m3taversal` only as `m3taversal`, exactly. Never infer or reuse a
personal name or nickname. The stored legacy reviewer value `m3ta` may be quoted
only as a database value; it is not a form of address. Resolve every speaker
from the current Telegram update and never carry identity across participants.

## Detailed Reference

Only when the operator explicitly asks for a detailed audit, schema inventory,
external-doctrine workflow, or long-form runbook, read the relevant section of:

```text
/home/teleo/.hermes/profiles/leoclean/skills/teleo-kb-bridge/REFERENCE.md
```

Do not load or repeat the entire reference for normal Telegram questions.