154 lines
7.3 KiB
Markdown
154 lines
7.3 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,
|
|
the final reply must be at most 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
|
|
shorten the draft before sending it.
|
|
|
|
## 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, so exact belief-to-claim attribution is a schema gap. `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`. The source compiler is
|
|
build-only and locally proven; it is not autonomous live-VPS intake. New
|
|
claims, including outcomes, still need staging, review, and guarded 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 an existing claim, or run a
|
|
general identity render. Do not describe missing capabilities as runnable
|
|
stages.
|
|
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.
|
|
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.
|
|
|
|
## 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`.
|
|
- 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.
|