176 lines
9 KiB
Markdown
176 lines
9 KiB
Markdown
---
|
|
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>"
|
|
```
|
|
|
|
Treat the emitted `Current Runtime Contracts` / `operational_contracts` block as
|
|
binding deployed-code readback. Follow its `required_lead`, schema guards,
|
|
capability tier, and reply budget. It overrides recalled or generic architecture.
|
|
|
|
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.
|