Standing rulings​

A ruling is the refutation ledger's positive polarity. A refutation records what was ruled out; a ruling records what stands. Same ledger, same lifecycle machinery, opposite claim, and the polarity is derived from the founding event, never from a field a writer could set.

daimon ruling propose records a candidate. An agent can propose with --by agent, and a candidate is all an agent can ever produce: activation requires daimon ruling ratify from a human at an interactive terminal. This is the same authority rule the rest of daimon holds. Identity and authority are derived, never self-asserted.

Once active, a ruling renders at the top of every briefing, on every surface, as a compact section:

Standing rulings (human-ratified — honor these):
§ never deploy the payments service on a friday

That section is skeleton furniture. It survives budget pressure that trims every other section, it renders before the first checkpoint of a fresh project exists, and when the opt-in LLM briefing is active the section is prepended verbatim, never re-narrated by a generative pass.

The design choices worth stating plainly​

Ratification is content-bound. ruling ratify records a hash of the exact text it displayed to you, and activation refuses if the stored text changed between the prompt and your confirmation. What you approve is what activates, byte for byte.

An agent proposal cannot change what renders. Agents may propose a revision or a retirement of an active ruling, but the active text stands untouched until a human settles the proposal, and the fold enforces this below the CLI, so even a hand-edited ledger cannot promote an agent's words into your briefing.

The echo loop is closed at the write boundary. A section that renders into every session would otherwise be a copy machine: the next capture re-extracts the ruling text as a fresh belief, which decays, drifts, and renders twice. 0.31.0 filters exact echoes at checkpoint admission. The drop is counted under its own reason code and visible in daimon status, never silent, and the filter fails open: an unreadable ledger can never cost you a capture.

The section is bounded and never silently truncated. Rulings are capped (seven by default, DAIMON_RULING_CAP to change it) and each ruling's text is bounded at write time. If a ledger ever holds more active rulings than the cap, the briefing says how many were withheld and where to see them.

Rulings never decay. Retirement is a human ceremony, and daimon forget reaches ruling text by value like everything else on the ledger.

Also since 0.29​

The local viewer shipped in 0.30.0. daimon serve opens a read-only localhost viewer: briefing, ledger, per-session pages, search-as-recall, a check strip, and a print view. 0.31.0 adds the rulings lane beside the refutations lane, each polarity under its own vocabulary.

A typed relation ledger shipped in shadow mode, with adjudication verbs and history rendering in the viewer.

0.30.2 fixed a real forget defect: forget by value only matched a refutation's subject field, leaving four of its five plaintext fields unreachable by value. Found during this release's design review, fixed and shipped ahead of the feature that made it matter.

Getting it​

uv tool install 'daimon-briefing[pretty]'

Upgrading:

uv tool upgrade daimon-briefing

Plugin users: /plugin, update daimon, then reload.

The refutation ledger​

daimon refute add records a scoped verdict against a subject, with evidence cited at the point of assertion. An agent's assertion stays a candidate until a human runs daimon refute ratify. daimon refute guard checks a proposed action against the active ledger before you repeat something already settled, and daimon refute overturn is how a verdict comes back off the books when the evidence changes.

Two design choices are worth stating plainly.

Nothing in the ledger is reaped on a schedule. A refutation is worth more with age, not less: the fact that an approach failed eight months ago is exactly what you want surfaced when someone proposes it again. So daimon refute search reads the complete ledger with no age decay, unlike checkpoint recall.

And the guard is advisory. It surfaces the prior verdict; it does not block the action. An agent can still proceed. What changes is that the record of what it was told exists either way, so a repeated mistake is now traceable to a decision rather than to ignorance.

The skills a host could not see​

The plugin ships two skills, daimon-briefing and daimon-end. They sat one directory below where the loader looks, so nothing failed and nothing warned. They were simply absent from the session's skill list.

0.29.0 puts them where hosts look, confirmed on a real install rather than inferred. The same release adds daimon why, the read side of an item's evidence, to the skill an agent actually reads. It had been documented for people and invisible to agents.

Also in this release​

Codex rollout stems now resolve to the spawned session id.

The CLI reference is regrouped by what you are trying to do rather than by subsystem.

A new claims page lists every number we publish about daimon itself, each with the command that measures the same thing on your own install. Those commands run locally and send nothing. Your numbers stay on your machine.

Getting it​

uv tool install daimon-briefing

Upgrading:

uv tool upgrade daimon-briefing

Plugin users need /plugin and a reload. The plugin cache is pinned per version, so the skills fix arrives with the release commit rather than with the PyPI publish.

An agent that forgets a success re-derives it in a few hundred tokens. An agent that forgets a failure re-attempts it: the refactor that broke prod, the "obvious cleanup" that was load-bearing, the dependency upgrade that was abandoned twice for the same reason. You pay for the same dead end every time a fresh session walks into it confidently.

The field just noticed​

Three papers landed on this in the last two months.

An ICML 2026 AI4Research workshop paper (arXiv:2606.21024) names the object directly: negative knowledge. Its diagnosis of automated research systems applies word for word to coding agents: failures "appear as local debugging signals but rarely become durable research objects." Their fix is a memory layer "explicitly designed for failure," with typed records and a curator separated from the agent that failed, "to reduce self-assessment bias." The concept paper the space needed. It also, honestly, leaves the operational questions open: no staleness policy, no expiry model, and its own tables show a failure record from one system misleading another (negative transfer). The concept is established. The lifecycle is not.

A field report from a production team (arXiv:2607.13091) turned accepted review comments into persistent behavioral rules, with a qualification heuristic worth stealing verbatim: "Would this mistake plausibly recur in a different context? If yes, it becomes a rule." Their candor is also worth stealing: no control group, small sample, and this warning, which every memory system should frame and hang on the wall: "a noisy review culture can poison the rule set faster than the validation step can catch."

And PROJECTMEM shipped the closest thing to our design: an append-only, git-native, plain-text event log with a deterministic pre-action gate, "memory that does not merely answer the agent but acts on its next action." They call the category Memory-as-Governance. It is the right name. (Related, on the write side: GovMem governs memory promotion with a promote / reject / needs-review decision, which is structurally the same gate we will describe below on the human side.)

So the ground is not empty, and we are not claiming a first. What we can offer is a design that has been running in a real repo for a month, with the scar tissue to show for it.

How we do it: author, promote, fire​

Our version is two tools with a human in the middle.

Agents author during work. When a session abandons an approach, keeps deliberate weirdness on purpose, or steps on non-obvious coupling, the agent records it as a candidate scar right then, under an authoring contract: a dead end needs evidence of the attempt and the abandonment, a landmine needs both coupled sites named, and first-person transcript prose gets dropped because a feeling is not a claim about code. Every active scar in daimon's repo was written this way, during the session that earned it.

About automatic harvesting, honestly. We also built a zero-LLM harvester that mines session checkpoints for candidates, because cold-start repos have no sessions to author from. Its field record so far is mostly noise: the first tally was 4 candidates, 0 promotable, and the false-trigger log is longer than the keep list. A qualification filter shipped in response, enforcing the same structural obligations at machine-write time, and its results are still accumulating. We tell you this because the receipts are the point: we measured our own tooling, it missed the bar, we gated it, and now we measure the gate too. A memory system that cannot reject its own writes is the poisoning vector the behavioral-rules paper warns about.

A human promotes. Candidates land in .scars/candidates/, never in the active set. Promotion is a deliberate human act. This is the same conclusion the behavioral-rules paper reached from the other direction: their rule quality "depends on human review quality," and bad rules amplify errors. An auto-promoted failure memory is a poisoning vector with a workflow diagram.

Scar fires. Scar is the enforcement half: promoted scars carry anchors, and when an agent is about to edit anchored code, the scar is injected before the edit tool runs. Not at commit time, when the mistake is already made and staged. Before the edit.

That last distinction is not ours alone; it is PROJECTMEM's own roadmap. Their future-work section describes "moving it to the agent's tool-call boundary (a pre-action hook)" so the gate can warn "the instant a change begins to resemble a previously-failed one—intervening before the edit, not at commit time." That is the gate Scar ships today. To be equally plain about the other column: PROJECTMEM has a published paper and a couple hundred stars; Scar has three. This is a design note, not a maturity claim.

The two pieces we have not seen anywhere else​

A falsification condition on every scar. Each scar records expires.condition: the specific change that would make it obsolete, plus a review date the linter enforces. The condition itself is authored discipline today, not yet machine-checked; the point is that it exists at authoring time. Negative knowledge rots differently than positive knowledge; a fact that goes stale is wrong, but a warning that goes stale is friction that trains everyone to ignore warnings. Neither paper above has an expiry model. One grows its rule set monotonically and never removes anything. The workshop paper does not treat staleness at all. Writing down the condition under which a warning should die is, as far as we can tell, still unclaimed ground.

The fence. Dead ends and landmines are failure memory. The third scar type is not: a fence protects code that looks wrong on purpose. The sub-second timeout that looks too tight but bounds a real budget. The duplicated block that two systems must not share. Failure memory tells an agent "do not repeat this attempt." A fence tells it "do not clean this up." No failure-record schema we have found represents that, and it fires constantly in practice, because cleaning up intentional weirdness is exactly what a capable agent wants to do.

What we are not claiming​

There is no measured prevention rate. Not ours, and not anyone's: PROJECTMEM names "failures-prevented-per-commits" as the missing benchmark of the whole category, and the behavioral-rules paper titles a section "The Missing Benchmark." We agree, and we are not going to fill the gap with a vibe. What we have are receipts of individual catches: a scar that flagged a regex denial-of-service risk that had passed both unit tests and review, and a fence that fired mid-build and changed a wizard's timeout floor the same afternoon. Anecdotes, labeled as anecdotes.

If you want the failure half of your agent's memory to exist at all: Scar ships the authoring contract as a loadable skill and fires the promoted scars, daimon drafts cold-start candidates from session checkpoints, and the format is a page of YAML and prose you could implement yourself in an afternoon. The dead ends you have already paid for are the cheapest knowledge you will ever ship.

We wanted that feature. Independent re-observation should strengthen a memory — that is how evidence works everywhere else. But before building it we went looking for the ways it breaks, and what we found changed the design, the release, and one security assumption we had been living with. All of it shipped today in v0.22.0.

The echo in our own house​

Daimon injects prior memory into new sessions: a briefing at session start, a daimon recall: line when a prompt matches past work. That injected text becomes part of the new session's transcript. The serializer then reads that transcript to extract what the session learned.

See the loop? An item from session A gets injected into session B's transcript, and session B's extraction can "observe" it there — not because the fact was re-derived from real work, but because daimon quoted itself. On our own corpus, thirteen transcripts carry injected prior items. A naive corroboration counter ("different session saw it again") would count daimon's own echoes as independent witnesses, and the items recalled most often would accumulate the most confidence. Recall frequency would become truth.

It got worse before it got better. While mapping the injection surfaces we found that our quote verifier checked verbatim quotes against the unstripped transcript. A quote copied from daimon's own injected line passed verification and was stored as verbatim, quote_verified: true — a prior session's item laundered as freshly witnessed. That hole did not wait for the corroboration feature; it shipped as a standalone security fix the same day it was found, and verification now refuses any quote whose only support lies inside daimon's own output. Failed echoes get their own rejection reason (echo-only), so the echo rate is now measurable instead of invisible.

The proof that says the naive version cannot be patched​

This is not just our bug. A recent paper — Securing LLM-Agent Long-Term Memory Against Poisoning: Non-Malleable, Origin-Bound Authority with Machine-Checked Guarantees — proves, with machine-checked TLA+ theorems, that defenses based on a memory item's content or its derivation history are unsound. Attackers launder untrusted origins through three channels: the agent's own summarization, trusted-tool echoes, and manufactured corroboration — planting agreeing sources so that agreement reads as verification.

That third channel is exactly the self-reference loop above, named as an attack primitive with an impossibility result behind it. The paper's repair: write-time origin binding is necessary, and origin-bound authority with Sybil-resistant corroboration-gated elevation is sufficient. In plain words: fix where a claim came from at the moment it is written, and only count agreement when independence can be proven from those origins — never assumed from the agreement itself.

What v0.22.0 ships​

Our implementation of that prescription, in a local-first CLI:

• Origin bound at write. Every item is stamped with the session and author that first wrote it, at the admission boundary, on the same never-rewritten rail as its identity. A model that emits its own origin fields gets them stripped — a memory cannot issue itself a witness.
• Independence proven from origins. A re-observation counts only when the original writer is a different session, the new observation is locally verbatim with a verified quote (which, after the echo fix, structurally excludes daimon's own output), the match is strong enough to certify rather than merely deduplicate, and the two observations do not share transcript message bindings.
• An auditable count, never a stored score. Corroborations are events in the append-only log, one per independent witness. The count is derived at read time. Contradiction outranks: a superseded or world-checked item loses its badge, and reopening it does not restore counts earned before the contradiction.
• A separate axis, not a trust promotion. Items independently seen twice render as [≈ corroborated ×2] beside their trust tag. The trust class itself never moves on recurrence — that still takes re-verification evidence or an explicit human decision.
• Wired into nothing, on purpose. The badge affects no ranking and no recall scoring, and a test enforces that scoring code cannot even import the corroboration reader. The self-reinforcing loop — promotion raises salience, salience raises injection, injection manufactures the next corroboration — closes exactly where a counter feeds ranking, so that wire stays cut until field data says otherwise. We ship the measurement before anything acts on the measurement.

What it does not do​

Honesty section, as always. Corroboration only accrues on items written from v0.22.0 forward — origins are never guessed retroactively, because a wrong guess would make dependent observations look independent. A resumed session that replays the same conversation under a new id is refused where hosts preserve message ids, but a host that mints fresh ids can make one conversation look like two. An attacker who controls the content of two separate sessions can still manufacture two origins — the design raises the cost of fake agreement from one recall line to two compromised sessions; it does not make fake agreement impossible. And teammate checkpoints do not corroborate in this version: a synced copy of a claim is still one witness, and the gates that would make cross-author counting Sybil-resistant are designed but deliberately not enabled yet.

The full release also carries the write-gateway hardening this work sat on top of: value-keyed deletion end to end, a write-audit guard over every command, and inbound team content passing the same scope, redaction, forget, and trust gates as local writes.

If your agent's memory tells you something twice, ask it who told it first. daimon can now answer.

All three arrive in the same font, in the same confident tone, with no way to tell them apart. That is the actual problem with agent memory, and it is not solved by remembering more.

Two populations, two failure modes​

Daimon tags every item it carries with a trust class, visible on the line itself:

- [✓ verbatim] PR #60 awaiting review  — "review requested 2026-07-01"
- [~ inferred] The retry storm was caused by a shared deadline across three calls

The tag is not decoration. The two classes fail in genuinely different ways:

• A verbatim item can be stale — the world moved on since the quote was said — but it cannot be misremembered. The quote is what was said.
• An inferred item can be stale and wrong. The model may have misread the session at the moment it wrote the summary down.

That difference should change how you act on a line. A stale quote needs a world check. A wrong inference needs to be thrown away. Collapsing both into "the memory says" destroys the distinction exactly when you need it.

The checker has to be dumber than the thing it checks​

A trust class is worthless if the model assigns it to itself. A model that hallucinates a quote will also happily label the hallucination verbatim.

So the model never gets a vote. At serialize time every candidate quote is checked against the rendered transcript by a deterministic verifier: pure string operations, no LLM, no judgment. A quote that matches gets the stamp. A quote that does not match is downgraded to ~ inferred on the spot and kept, not deleted. The claim survives; the certification does not.

This is the principle the whole design rests on. The checker must be dumber than the thing it checks, because anything smart enough to be fooled by the extractor is not a check.

The harder problem: a perfect quote can be perfectly false​

Here is the part we got wrong for months, and the reason this post exists.

Verbatim matching certifies transcription, not truth.

The failure that taught us: an agent finished a long session and wrote "serialization succeeded" into its own memory. It had not succeeded. The next session read that line, believed the memory layer was healthy, and built on a foundation that was not there.

Every step of that is faithful. The model did say it. The transcript records it exactly. The quote verifier found it in the transcript and stamped it ✓ verbatim, correctly. The trust class did its job and the memory was still false, because the thing being certified was that the sentence was said, not that the event happened.

Outcomes need a witness, not a quote​

As of 0.20, claims that assert a completed outcome get held to a second standard.

If an item's text asserts something finished — succeeded, merged, deployed, tests green, shipped — it has to cite a concrete signal from that same session: a tool result, an exit status. Something the session actually produced rather than something the model concluded.

An outcome claim that cites a real signal stays verbatim. An outcome claim with no citation, in a session that did surface signals, gets downgraded to ~ inferred. The quote and its verification stamp stay attached, because the transcription is still honestly attested. It is the outcome that is unwitnessed.

An unwitnessed outcome is a report, not a fact.

Two deliberate limits on that rule, both in the direction of doing nothing rather than guessing:

• Hedges are not assertions. "will be merged" is a plan. "whether the deploy succeeded" is a question. Neither is touched.
• Signal-free sessions never downgrade. Some hosts surface no parseable tool results at all. Grounding is impossible there, and absence of evidence about the host is not evidence against the claim.

What none of this fixes​

Trust classes tell you where a claim came from. They tell you nothing about whether it is still true.

A ✓ verbatim quote with a real tool-result behind it is fully attested and goes stale the moment someone merges the PR it describes. Provenance is not currency, and pretending otherwise would be the same mistake one layer up.

That is why every briefing opens with a VERIFY BEFORE TRUSTING block rather than a summary, and why 0.20 adds an opt-in spot-check that re-reads external state at briefing time and visibly flags carried claims the world has since contradicted. We are measuring how often that fires before we say anything about how big the problem is.

Try it​

uv tool install 'daimon-briefing[pretty]'

The full mechanics live on the trust classes page, with carry and staleness for the currency half and receipts for what happens if a checkpoint is edited after it is written. Code and issue tracker: Daily-Nerd/daimon.

The MCP server: memory for hosts we can't hook​

Daimon's capture loop attaches to hosts through hooks. Plenty of MCP-capable tools have no hook surface — until now they simply couldn't see daimon's memory. daimon mcp serve fixes the reading half:

daimon mcp serve   # JSON-RPC over stdio, blocks until EOF

Four tools, all read-only: daimon_recall (search with full provenance — trust class, author, supersession state, origin project), daimon_brief (the latest briefing, trust-tagged), daimon_projects (everything daimon has memory for), and daimon_status (capture health). Pure standard library, zero new dependencies — same deal as the rest of daimon.

Read-only is a design position, not a limitation. Writes stay with the capture pipeline, where every verbatim claim is mechanically checked against a real transcript. An agent can read memory over MCP; it cannot assert new memories into it. And the server inherits daimon's cross-project discipline: reads are project-scoped, and a project with no checkpoint gets told exactly that — never another project's content.

The MCP reference has the registration snippets for Claude Code, Windsurf, Cursor, and any generic stdio config.

daimon forget ships: deletion with a tombstone​

Announced as merged in the last post — now released. daimon forget removes an item from the live checkpoint, the recall index, and the audit trail's content, while the event stream keeps a content-hash tombstone. With receipts enabled, the post-removal checkpoint is re-signed. You can prove the deletion happened without keeping what was deleted. Mechanics on the item lifecycle page.

The chunk cache: retries stop re-buying finished work​

Serialization extracts memory from transcripts in chunks, and until now a failed run threw away every chunk that had succeeded — the retry paid for all of it again, in time and tokens. 0.19 adds a content-addressed cache for chunk extractions: a heal or retry reuses every chunk whose content is unchanged and only pays for what's actually missing. First slice of a longer incremental-serialization arc.

And the docs site itself​

Quickstart (install to first briefing in one page), concept pages for the ideas that make daimon different — trust classes, carry and staleness, receipts, item lifecycle — host guides, configuration, team memory. Every page in Spanish as well as English, written for Spanish-reading developers rather than machine-dumped. This blog (with RSS) is the canonical home for announcements; the README now just points here.

Upgrade​

uv tool install --force 'daimon-briefing[pretty]'

Full details in the changelog. If something breaks, the issue tracker reads every report.

What shipped this week​

daimon 0.18.0 is on PyPI (uv tool install 'daimon-briefing[pretty]'). The headline experiment: opt-in per-item scene traces, indexed for recall. It ships behind a flag while we A/B it against our own benchmark — if the numbers don't earn it, it doesn't go default-on. That's the deal we make with every feature.

daimon forget is merged and ships in the next release: item removal with a tombstone event. The item leaves the live checkpoint, the recall index, and the audit trail's content — but the event stream keeps a content-hash tombstone, and with receipts enabled the post-removal checkpoint is re-signed. Deletion you can prove happened, without keeping what was deleted. The item lifecycle page covers the mechanics.

The docs went bilingual. Every page — quickstart, concepts, hosts, configuration, team memory — is available in Spanish. Not machine-dumped: written for Spanish-reading developers, because the es-speaking agent-dev community deserves first-class docs, not an afterthought.

Windsurf is live-validated. The capture loop (native-transcript serialize) has now been tested end-to-end in real Windsurf use, joining Claude Code. Codex ships next; Gemini waits on an upstream fix.

Why this project exists, in one paragraph​

Your agent forgets everything between sessions, and most memory systems "fix" that by storing text a model wrote about what happened — with no way to tell which parts are quotes and which parts are guesses. daimon marks every remembered item as verbatim (an exact quote, mechanically verified against the transcript by a deterministic checker — no LLM grading its own homework) or inferred (allowed to evolve, flagged for verification). A recent survey of agent-memory research calls claim-level provenance an open problem; we think the answer is to make memory provable, and that is the axis everything here is built on.

More soon — releases, war stories from the field, and deep dives into how the verification machinery works. Subscribe via RSS or follow the repo on GitHub.