Ledger + zv1
A decision memory only compounds if recording is nearly free and recall is automatic. That's what zv1 adds: the assistant can write to the Ledger from the conversation where the decision actually happened, and read from it in every conversation after — including the ones where you're about to repeat a mistake.
Recording from chat
Decisions rarely happen inside Ledger — they happen in the conversation where you're changing a flow, reading an eval, or talking through a call you just made in a meeting. Tell zv1 and it drafts the entry:
"Record this: we're shortening the triage prompt to the three routing rules. We expect the Caliper eval to hit at least 85% accuracy within two weeks."
zv1 shapes that into a decision entry — summary, rationale, the structured expectation bound to the eval — and shows it to you as an approval card before anything is written. Every Ledger write goes through approval: you see exactly what's about to enter the permanent record, and nothing lands without your yes. Same flow for settling: when you tell zv1 the evidence is in, it proposes the settlement with the lesson drafted, and you approve it.
It also works in the other direction — when you state something durable in passing ("turns out the nightly export lands at 2am, everything downstream is day-fresh at best"), zv1 can offer to capture it as an observation, so facts that would have evaporated in chat scroll end up in the record.
Recall — "what did we decide about X, and were we right?"
Ask, in any tool, and zv1 reads the record:
"Have we tried changing the triage prompt before?"
It lists the prior entries, how they settled, and cites them by id — so the answer comes with receipts. And it consults before acting: when you ask zv1 to change something, it can check the Ledger for prior attempts touching the same Compass pages first, and lead with "two earlier attempts at this regressed accuracy — here's what settled." That's the moment the memory pays for itself.
zv1's own expectations
The strongest habit: when zv1 proposes a change and you approve it, have it record the decision with its own pre-registered expectation in the same breath. The assistant stakes a claim about what its change will do, and the eval settles it later — right or wrong, on the record. An assistant whose suggestions carry settled track records is one you can calibrate your trust in; one whose suggestions vanish into chat history is not.
MCP tools
Entries are written through the MCP server, the same tools zv1 uses — there's no REST endpoint for recording or settling one. (Metrics are different: readings come in over the REST endpoints, because the systems that produce numbers rarely speak MCP.) With a token carrying Ledger scopes, any MCP client (Claude Code, Cursor, Codex, your own agent) gets:
Read (ledger:entries:read):
ledger_entries_listreadList entries, filterable by status, kind, origin, or the Compass page they touch. The consult-before-acting query.
ledger_entries_getreadOne entry in full — all six fields, attached evidence, and the supersede chain.
Write (ledger:entries:write):
ledger_entries_createwriteRecord a decision, lesson, or observation. Asks for your approval first — the model proposes, you confirm.
ledger_entries_settlewriteSettle an open decision with its lesson. Also approval-gated, and refuses cleanly if the entry already settled — settlement happens once.
Plans (how plans work):
ledger_plan_listreadThe calendar for a date range (decisions plus their dated items, filterable to one person), or one decision's plan.
ledger_plan_addwriteAdd dated work to an open decision, or a standalone date. Can repeat weekly. Asks for your approval first.
ledger_plan_updatewriteMove, rename, reassign, link, or mark an item done or skipped while its decision is open.
Superseding is deliberately not exposed to models. Overturning recorded history is a human-only move — an agent can propose that an entry looks outdated, but only a person can replace it.