Start here

Yohanun developer docs

Governed memory for AI systems, behind one HTTP API: memory that keeps its history, access decided inside the retrieval query before any model is called, an audit row for every read, and outcomes that feed back into ranking. These pages are the reference; every example on them is run against the live API before it is published.

What the platform is

Yohanun sits between your application and whichever model you use. Your application stores what it learns (a memory, a document, a conversation turn) and asks for what it needs (a search, or a chat answer grounded in what was stored). Three things set it apart from a vector database with a prompt in front of it:

  • Memory keeps its history. Nothing is deleted in ordinary operation. A wrong memory is superseded, a finished one closed; both stay readable by id with their lineage, and a question can be asked as of a past date. Erasure is a separate, governed path with a receipt.
  • Access is decided before generation. Every memory carries labels (a compartment, a classification, owners). Who is cleared for what is a platform-held ledger. The two are compiled into the retrieval query itself, so material the asker may not see never reaches the model. The model is never the gatekeeper.
  • Every read leaves a row. One audit row per gated read, naming who asked, what was applied and what was released, written before the answer returns.

Base URL and authentication

https://app.yohanun.com
X-API-Key: sile_...

Every request carries the key in the X-API-Key header. The key identifies a tenant: one isolated estate of memory. Who is asking inside the tenant is a principal id your application passes on each request (identity on memory calls, user_id or context.authority.principal_id on chat), or, with verified identity switched on, the subject of a token signed by your own identity provider.

Two kinds of key

ProfileWhat it reachesWho it is for
Memory/api/memory, /api/documents, /api/threads, /api/learning, clearances and custody under /api/accessYou run the model. Yohanun holds, gates and audits the memory; nothing is metered but storage actions.
ChatEverything above plus /api/ai (chat, streaming, the agent runtime) and the full governance surfaceYohanun calls the model for you (metered), or calls it with your own provider key.

The quickstart works with either; the chat step at its end needs a chat-profile key.

The pages

  • Quickstart: a stored memory, a search, a wall between two people, a compartment with a clearance, the audit row, and a grounded chat answer. Ten minutes with curl.
  • Memory for AI agents: memories and contexts, grades, documents, close and supersede, as-of, session distillation, and the kit that gives a coding agent memory.
  • Access control in retrieval: labels, the clearance ledger, owner walls, custody, matter focus, verified identity, and what a stored answer inherits.
  • Audit trail per read: the audit row, querying it, strict mode, and what erasure does to the record.
  • Outcomes and learning: reporting outcomes, the track record on memory, mandates and escalation, and propose-and-ratify reconciliation.
  • Model-agnostic: swapping providers: how a model is chosen, bringing your own provider key, and running against a model on your own infrastructure.

The machine-readable reference is the OpenAPI document at app.yohanun.com/docs. Where these pages and that document disagree, the OpenAPI document is generated from the running code and wins; tell us and the page is corrected.

What it will not do

A governance platform is better described by its refusals than its features, because a refusal is a promise you can test. Twelve of them, each enforced by the platform and visible when it happens.

Get a key

Yohanun is in invited beta. Tell us what you are building and we send a key with a developer account; a memory-profile key for your own model, or a chat-profile key if you want the platform to run the model and meter it. There is no card and no self-serve sign-up.

Request an invite