One workspace, shared by you and your agents. Connectors bring raw evidence in, an agent curates and proposes over MCP, you accept, reject or re-instruct — a collaboration loop where the agent does the work and you make the calls. main is what you've both agreed is true, at every step. The agent writes the schema, the charters and the outputs — you judge the model, not the code.
Sources — Graph, files, git, Salesforce, another KB — fetch raw material and append it, unaltered, to the evidence ledger. Sinks carry accepted output back out.
Over MCP, reads the schema + evidence and stages record and schema edits onto a proposal ref, each with a summary and source links.
Every change is a commit. main is always valid; work happens on proposal refs; history is the audit log.
Owns the seams: runs connectors and validators, exposes the MCP surface, validates the whole tree on accept, and serves the review UI. It is the only writer to main.
Acceptance authority lives here. Review the diff — accept, reject, or re-instruct — by hand at first, codified into workflows you own as trust settles. Acceptance is the moment a proposal becomes truth on main.
A KB is just a git repo with this shape. It's portable, greppable, and diffable — no database, no opaque store. The schema — source and its compiled validator component — travels with the repo, so no domain is ever baked into the engine.
The records themselves — typed RON files, each conforming to its kind and linking to others. This is the memory.
The KB's kinds, fields, enums, links, saved queries and validation function — Rust source plus the compiled wasm component the engine actually runs, mechanically bound to each other at accept.
registry.ron is the checked projection of the schema the engine + UI read; sources.ron declares evidence sources and pins each tap.
The provenance trail: which evidence, which proposal, whose acceptance produced each change. The audit log, written in-tree on accept.
The raw evidence ledger — original provider bytes, content-hashed and immutable — is append-only and local, and lives outside the git ontology repo. Only curated facts ever land in the tree.
A tiny example: three kinds, six records, three saved queries. Your KB uses your kinds — nothing here is built into kyyn.
Your kinds of things, and how they link.
The records, linked to each other.
Typed questions, saved in the KB.
Every change recorded — a plain git repo.
Each pass moves evidence one controlled hop closer to trusted memory — and accepted memory back out into the world. The base is never in a half-valid state: a proposal is either accepted whole (and validated) or it isn't there at all.
A source connector fetches original bytes — the email, the transcript, the SOQL rows — and appends them to the evidence ledger. Content-hashed and immutable; interpretation happens later.
Reading schema and evidence over MCP, the agent drafts record edits and any schema changes they require, staging them together on a fresh proposal ref with a summary and source links.
In the review UI you see each record's before → after, its source, and any schema impact. Accept the proposal, reject changes you don't want, or send the agent back with a note — the loop re-runs from step 2.
On accept, the tree's own validator component runs over the entire resulting tree before the merge — deterministic, fuel-metered, unable to see anything but the tree. Pass, and main advances with a receipt; fail, and nothing moves. Pull is fail-closed too, replaying the same predicate.
Renderers run the KB's saved queries and shape the results into artifacts — a report, a page, a dataset. You accept the publication, and a sink connector delivers it: a file replaced, a ref pushed. Agents answer from the same accepted facts.
The invariant: main is a valid, typed tree after every accepted step — and only after acceptance. Re-instruction loops back to step 2 without ever leaving the base inconsistent.
The agent connects to kyyn over MCP. The per-kind CRUD tools are generated from the registry, so adding a kind to the schema grows the tool surface with zero engine changes. Every write stages into a proposal — never main.
Generated per kind. _set takes a complete RON record and stages it; schema_set stages the crate, registry, or sources.
proposal_validate is a dry-run of the accept gate. There is deliberately no accept tool — acceptance authority is yours, by hand or through a workflow you own; an agent can never grant it to itself.
brief is the read-this-first map of the KB. Your re-instruct notes come back to the agent as pending instructions to resolve.
Safety is its own page. How connectors and validators are contained, verified and kept honest is the Trust page's story.
Orange is where you decide. Green is what you've both agreed is true. The narrated version lives at /model.
Kyyn is in beta and under active development. Join the waitlist and we'll reach out as onboarding opens.