Skip to main content

daimon 0.31.0: rules that stand until a human ends them

· 4 min read

Some facts in a project are not beliefs. "Never deploy the payments service on a Friday" is not something the agent should re-derive each session, weigh against newer context, or quietly forget under budget pressure. It is a standing constraint, and until now daimon had no home for one: a rule stated once landed in the belief partition, did not carry, and was first in the drop order when the briefing ran over budget. 0.31.0 adds pinned rulings.

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.