Records and owners
When an agent's session ends, its context goes with it. Anything Keystone needs to keep past that point, it keeps in records, and each kind of record belongs to one program, called its owner.
It works much like the books of a well-run organization. Each department keeps its own ledger. Other departments read it and refer to it, and when they need an entry changed, they ask the department that keeps it.
In Keystone, the owner validates every change to its records, stores the result, and answers questions about it. Other programs read the record and cite it, and when they need it changed, they ask the owner. That one rule is what lets a fresh agent, or a person, pick up work that someone else started.
One owner per fact
Each step a piece of work takes has an owner:
| Fact | Owner |
|---|---|
| Why the work exists, and links to the plans, directives, reviews, and merges that serve it | Goal (ksgoal) |
| A plan or reusable workflow, and each run of it: order, dependencies, checkpoints, and human gates | Planner (ksplanner) |
| A directive: the exact instructions sent to an agent, and who approved them | Dispatch (ksdispatch) |
| An agent run and what it produced | Run (ksrun) |
| A model call: its route, result, tokens, cost, and whether it finished | Hub (kshub) |
| A review: what was checked, what was found, and whether current evidence supports landing the change | Assurance (ksassurance) |
| Which execution is acting, and the one-use authority for an action such as a merge | Identity (ksidentity) |
| A merge: what was proposed, what GitHub reported, and how it settled | Ledger (ksledger) |
Other owners keep what informs the work and what the project learns from it:
| Fact | Owner |
|---|---|
| Project decisions, tasks, and evidence | Memory (ksmem) |
| A context pack, and why each source is in it | Context (ksctx) |
| An agent's report of friction, or of an unusually effective result | Signal (kssignal) |
| A research mission, from queue to findings | Scout (ksscout) |
The command reference lists the rest, including the owners of conversation sessions and spending plans.
The rule shows most clearly at the handoffs. Ledger performs merges, but the one-use authority a merge spends belongs to Identity, so Ledger asks Identity to record the spend. Later, Dispatch closes the directive that started the work by reading Ledger's record of the merge. Dispatch can read that record and cite it, and it has no way to change it.
Records a later process can check
A record is only useful to the next process if the next process can trust it. So owners write every record as canonical JSON and identify it by the SHA-256 digest of its bytes. Canonical means the same content always produces the same bytes, so two programs, even ones written in different languages, compute the same digest for the same record.
Records also form histories. Each entry is appended to the end and names the digest of the entry before it. If anyone edits, inserts, or reorders an entry, the chain breaks, and the next reader notices, because readers check the chain every time they load it.
Some facts live outside Keystone. Git holds your repository's objects, GitHub holds pull requests and merges, and a model provider keeps its own account of a call. Keystone records what it observed from those systems, and a later check can compare its records with theirs.
Together, these let a fresh process work out what happened without the agents that did the work. In one test, seven Keystone programs each rebuilt the same final state of a merged change from their own records, and verification still passed after the change's remote branch had been deleted.
No central database
Keystone has no central server holding every kind of record. Each owner keeps its own store on disk, and its command-line tool can inspect it. So a new process can resume where another one died: the state it needs is already in the owner's records, and the conversation that started the work doesn't have to be alive.
Views carry their basis
Studio and the ksvantage status commands show you views built from owner records. The views keep no records of their own, so they can be rebuilt at any time, and a source that is missing or stale is labeled that way.
A view can still go out of date while you're looking at it. Say Studio shows a result waiting for your review. You open it, read the diff, and step away. Meanwhile the agent pushes another change. When you come back and choose Accept, your decision would apply to a diff you never saw.
To catch that, a view you can act on carries its basis: the digests of the records it was built from. When you act, the owner compares that basis with its current records. If anything changed, it refuses the action as stale, and you refresh and look again. Review actions in Studio check their basis today, and the other views are adopting the same check.