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, agent beliefs, schema-backed identity, proposal readiness, or KB changes.	1.1.0	m3taversal	MIT	hermes tags related_skills teleo kb postgres claims evidence governance 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:

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

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

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:

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

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