Since 0.13.0 this repository gained 7,805 lines of code and its website gained three. protocol reverse — four verbs and 2,782 lines — had no mention anywhere on the site, and the status page still opened "current as of 0.10.0-horizons-dogfood-lab".

The page that was missing​

Lifecycles, decided as data — the status ladder is a YAML file decided by entity-core, a rung may cost evidence or open on a date, and every write is journalled.

It also states what that kernel does not do, because "entity runtime" invites the reading that it stores something. It performs no IO at all — a scan over its own sources refuses the tokens for filesystem, clock, network and randomness — so every byte written here is written here. The dependency buys a verdict, not a store.

The rest of the site​

More columns: swipe horizontally, or focus the table and use the arrow keys.

Counts, each re-derived rather than copied forward​

CLI verbs 17 → 20. Artifact lifecycles 8 → 12. This repository's own plan 59 → 101 artifacts. The document tree 45 → 49 files. The gate ten → twelve steps, in five files.

AGENTS.md also still claimed the billing suite runs 27 scenarios where its own guard asserts 29 — a count the gap register closed in two places and missed in a third.

A tag now cuts its own release​

.github/workflows/release.yml fires on a version tag, runs ci.yml itself — called rather than copied, so a tag cannot ship against a shorter gate than main does — and takes its notes from the tag's own section of the changelog.

Release notes render as GFM, where a single newline becomes a <br>, so a file hard-wrapped at 100 columns arrives broken after "added" and before "the". The file stays wrapped, because that is the right shape for something reviewed in a diff, and only the notes are joined.

The self-test earned its place immediately​

cargo xtask notes --self-test holds the eight shapes the reflow must not damage, and it runs before the notes are generated — because the failure it catches is silent, and nobody re-reads a release they already cut.

On its first run it failed. A line ending in two spaces is Markdown asking for a break, and the reflow was ending the paragraph but dropping the two spaces. The break survived only because GFM turns a bare newline into <br> — standing on the exact quirk the reflow exists to remove.

The same defect was in the original Python implementation in entity-runtime, whose own self-test had a case for it asserting the wrong expectation. Both are fixed.

The least comfortable release note here.

CI had been red for eleven consecutive releases — every tag from 0.13.0 to 0.23.1 — with a green local gate the whole time.

Two causes, both in the two jobs the gate did not run​

More columns: swipe horizontally, or focus the table and use the arrow keys.

The MSRV failure is the instructive one: it arrived through the lockfile. idna_adapter@1.2.2 pulled in icu_*@2.3.0, which need rustc 1.88. No commit of ours touched a line of Rust, and nothing local noticed for eleven releases.

The fix was to pin idna_adapter to a version that uses unicode-normalization instead — which also drops eight crates from the tree. The alternative was raising the declared MSRV, which would have quietly broken the promise the README makes to anybody building this.

The actual defect​

task check did not run msrv or website, while its own description said "everything CI runs".

That is the whole mechanism by which a red CI survives eleven releases behind a green gate. A gate that covers less than the gate it claims to be is worse than one that admits its scope — because the second kind makes you go and look.

It runs twelve steps now, and this list and the CI workflow are checked against each other whenever either changes.

Why cut a release for it​

No behavioural change at all. The tag exists so there is one commit in the history whose green is a fact rather than an assumption, and so every tag after it can be compared to something.

A small release, and both fixes are the same mistake wearing different clothes: a label that had drifted from the thing it names.

The pin​

aep-backend-markdown pinned entity-core at a tag two releases behind what existed.

Nothing this crate links actually moved — the source is byte-identical between the two tags, because the releases in between carried an examples-only change. So this changed no behaviour at all.

It was still worth fixing, for a reason that is not about this pin: a pin stale by label is a pin nobody trusts to be current by content either. The next person reading it has to go and check whether the drift matters, every time, which is exactly the work a pin exists to save.

The ladder​

outbound-claim started at drafted, not draft.

Every other shipped ladder starts at the built-in draft. An invented rung one letter from a built-in is a typo wearing a vocabulary's clothes — and it would have been inherited by everybody who copied the file.

This is the boundary the open vocabulary was designed to hold. The vocabulary is open to authors, not to near-misses. A status is accepted because some ladder declares it, never because it parses — but a ladder can still declare something its author did not mean to, and the first shipped example doing so is the one that teaches it to everybody else.

Every ladder in this repository models evidence flowing inward: something was observed, and an artifact's status records what we now know.

An outbound claim runs the other way. A number in a customer's inbox. A status page saying "resolved". An availability figure in a renewal deck. Those are assertions that already left the boundary, and nothing here modelled them.

The ladder​

$ protocol artifact lifecycle outbound-claim
outbound-claim starts at draft
  cleared -> sent
  corrected -> nothing
  correction-owed -> corrected
  draft -> cleared
  sent -> correction-owed, standing
  standing -> correction-owed

Sending is not undoable, and the ladder says so:

$ protocol artifact move outbound-claim:q3-uptime --to sent
outbound-claim:q3-uptime moved cleared -> sent (revision 3)

$ protocol artifact move outbound-claim:q3-uptime --to draft
outbound-claim:q3-uptime is sent; an outbound-claim may move to: correction-owed, standing

There is no path from sent back to draft. A ladder that allowed one would model retraction as an edit — the claim would simply stop having been made — and the customer would still have the email.

So a wrong claim moves forward, never back. correction-owed, then corrected, which is a new outbound act with its own evidence, costing two approvals where the original cost one. Fixing a claim costs a second claim. That is true in the world, and the ladder should not be kinder than the world.

Why correction-owed is a rung and not a flag​

The rung names the state precisely: sent, known wrong, audience not yet told.

It is the most expensive state an organisation can be in and the easiest one to leave undocumented, because nobody wants to write it down. A rung is a column protocol artifact board prints; a flag is a field nobody queries.

It is deliberately not terminal and deliberately not counted as approved — a claim in correction-owed is a live obligation, and anything treating it as finished would let the most important case disappear from a report.

There is no retracted. A retraction is itself an outbound claim — you have to tell somebody — so it is a corrected whose content is a withdrawal, not a rung that quietly makes the original stop counting.

The part that is actually the headline​

A whole new kind of artifact, with six rungs and two evidence requirements, arrived as one YAML file and no Rust change at all.

That is the sentence the entity-runtime programme was for. Ten releases earlier it would have been a pull request against this repository, a review, a release, and an upgrade for everybody. Now it is a file you write in your own tree.

Every behavioural document here is published as harness-neutral, and until this release exactly one transcript adapter existed. So "neutral" was a claim with no second case behind it.

A vocabulary tested against one harness is a vocabulary shaped like that harness, and nobody can tell which from the inside.

The second case​

A reader for a second transcript shape, so one trace-spec/1 specification now decides both. The specification did not change to accommodate it, which is the result the exercise was for.

Two things stated plainly rather than implied, because the difference matters:

• the committed fixtures are synthetic, and every place they are used says so;
• the verified reader for that harness's transcripts lives in metaharness, checked against thousands of real rollout files. This one is a neutrality probe on constructed bytes — it answers the vocabulary question and does not claim to read anybody's transcripts in production.

The claim this release earns is precise: the vocabulary is neutral. The driving path still has never met a second harness, and the limitations page says so.

Three counts, re-derived​

Three prose literals had drifted from the counts their own gates print. Each was corrected by running the command beside it rather than by picking the number that looked right:

More columns: swipe horizontally, or focus the table and use the arrow keys.

The middle one is the fix worth copying: smoke.mjs now increments a counter in its own check function and prints what it actually checked. It cannot drift again, because there is no second copy of the number to drift from.

For the first, a new guard reads the count out of the suite's own source and fails if the prose disagrees — because correcting two copies without tying them together only resets the clock.

Four mechanisms, each closing a gap where the rule existed and nothing enforced it.

Evidence names its subject​

A record may declare what it is about. If the declared subject does not match the task it is submitted against, it is refused — before the record is constructed, not after.

In a sentence: a green test run for one story can no longer discharge a different story's gate. That was possible before, it was silent, and the audit trail would have looked correct.

Placing the guard before construction is deliberate. A refused record that got built is a refused record that can be logged, cached, or passed on by something that did not check the verdict.

An advisory enforcement tier​

A requirement may be declared advisory, with an owner and an exit criterion. It is evaluated, reported and counted — and it gates nothing.

This exists because the realistic alternative to a soft rule is not a hard rule; it is prose in a wiki. A team can now measure how often a proposed rule would have fired, on real work, before anybody's build turns red.

The owner and the exit criterion are required at parse time, so an advisory requirement cannot quietly become permanent through nobody remembering to revisit it. A rule with no exit criterion is a rule that never graduates and never dies.

A dependency that keeps failing stops being called​

A step map may declare depends_on and a circuit breaker. A repeatedly failing dependency opens the breaker instead of being retried, and the run says the breaker is open rather than producing the tenth identical timeout.

Retry and circuit-breaking had been prose in every step map — which is to say, enforced by whoever read it.

The driver writes what a step was not allowed to do​

Refusals are emitted as their own trace-spec/1 document, with tool.absent expectations. The absence of a tool call becomes a checkable fact rather than a silence.

This closes a real hole in reasoning about a governed run: "the agent did not shell out" and "the transcript contains no record either way" look identical in a log, and only one of them is a finding.

If a run refused nothing, no document is written at all — an empty specification is refused by the format itself, and a file asserting nothing is worse than no file.

0.15.0 let a rung cost evidence. This release is how the evidence gets there.

$ protocol artifact evidence outbound-claim:q3-uptime \
    --kind approval --source "legal review" --ref https://example.invalid/approvals/814
outbound-claim:q3-uptime: approval recorded from legal review
  on hand: approval=1

$ protocol artifact move outbound-claim:q3-uptime --to cleared
outbound-claim:q3-uptime moved draft -> cleared (revision 2)

The record carries when somebody looked​

--at defaults to now, read at the edge and written into the record — so the observation carries when somebody looked, not when the file was parsed. That is the same observed_at rule the engine has used since 0.10.0, now available from the planning side.

--source and --ref are how a record stops being an assertion: where it came from and where to go and look.

Provenance: recorded versus asserted​

A move now records the provenance of what decided it, separating evidence that was recorded from evidence that was asserted at the moment of the move — and a move leaning on an assertion says so as it happens.

The consequence is about a specific future moment: somebody auditing, months later, why a gate opened. Without this, both cases look identical in the trail. With it, the weaker claim is visible at the point of decision — where somebody could still have objected — rather than discoverable afterwards, when the only options are accept or unwind.

The planning store is markdown files in git, so its history was always there — as git log, in a form you had to reconstruct. This release makes it a question you can ask.

$ protocol artifact history outbound-claim:q3-uptime
2026-08-26T00:08:16Z  operator  created as draft (revision 1)
2026-08-26T00:08:20Z  operator  approval recorded from legal review (https://example.invalid/approvals/814) (revision 1)
2026-08-26T00:08:20Z  operator  moved draft -> cleared (revision 2)
2026-08-26T00:08:20Z  operator  moved cleared -> sent (revision 3)

Two details are the design​

A corrupt line is skipped and counted. A history that quietly shortens is worse than one that says it is damaged: the second is a bug report, the first is a wrong answer nobody questions.

Append-only, and not a cache. The journal cannot be regenerated from the files — which is exactly why it can answer questions the files cannot, such as what an artifact's status was before somebody corrected it. A derived index would lose that on its first rebuild.

What it does not close​

This is the markdown store's own journal, not the AEP storage contract's. The sixteen conformance suites still do not run against this store, and this release does not move that. Worth saying, because "the durable store now has a journal" reads like it might have.

$ protocol artifact lifecycle blocker
blocker starts at open
  cleared -> nothing
  open -> cleared

Two rungs. The value is entirely in the type: a blocker is typed by what would clear it, so blocked stops being a label on a card and becomes a statement with a named exit.

The other half: an audit of what is closed​

The same release published an audit of every adopter-facing vocabulary — which are open, which are closed, and what each closure buys.

Opening a vocabulary is not automatically the better answer. evidence_kinds stays closed on purpose: an open evidence vocabulary would let a caller invent the kind of proof a gate is asking for. That is not extensibility, it is a hole.

The output of the audit is not open everything. It is that no vocabulary is closed by accident, and the reason is written where an adopter reads it.

Why that is a deliverable​

The failure mode it prevents is specific and common. An adopter hits a closed vocabulary, cannot tell whether the closure is a decision or an oversight, and either works around it — building something on a shape that was never intended — or files an issue and waits.

A table saying closed, and here is what that buys you turns both of those into a one-minute read.

An obligation is a commitment on a clock nobody here controls: a customer's deadline, a regulator's window, a partner's delivery date.

$ protocol artifact lifecycle obligation
obligation starts at open
  met -> nothing
  open -> met, slipped
  slipped -> met

The rung that justifies the kind​

slipped. And the rule attached to it is the point of the whole release: an obligation must never gate a transition.

A missed external deadline is a fact to report, not a permission to withhold. A tool that let a slipped obligation block your work would have turned somebody else's missed date into your blocked pull request — which is both unfair and useless, because you cannot fix it from here.

This is also why it is a second ladder rather than a widening of the existing status vocabulary. slipped on ArtifactStatus would have been available to every kind, and something would eventually have gated on it.

Why slipped -> met exists​

An obligation you missed and then satisfied is a real and common history. A ladder that made slipped terminal would push people to avoid recording it in the first place — and the state you most want recorded is the one nobody wants to write down.

What it cost to add​

A YAML file. No Rust change. This is the second kind added that way, and by this point the claim 0.13.0 made has two releases of evidence behind it.

Some rungs should not open yet. A review window. A cooling-off period. A notice period somebody agreed to in a contract.

This release adds date and duration operators to the condition language, so a ladder can say so.

The clock stays outside​

The interesting part is where the time comes from. The kernel deciding the move has no clock at all — reading one is banned by a scan over its own sources. The instant is read at the edge and handed in as an argument.

That is not fastidiousness. It is what makes the same inputs give the same verdict forever, so a decision recorded today can be re-checked next year by somebody who was not there, and the answer does not depend on when they asked.

A kernel that read its own clock would give different verdicts at different moments for identical inputs, and every recorded decision would become unfalsifiable.

Growing a language one operator at a time​

The condition language is data, and the standing rule is that it grows operator by operator, never into a language. Two comparison operators over instants is a step; an expression evaluator would be a different product.

The part that had to be got right​

Date parsing now lives inside a decision path, which means it has to be total. A malformed date is False — not a panic, not a default, not "probably fine". Anything that can be reached by a gate has to have an answer for every input, including the input nobody expected.

0.13.0 made the status ladder data. This is the first release that spends it.

A ladder that only says what may follow what models permission, not earning. Anybody could move a story to implemented; the ladder had no opinion about whether anything was implemented.

What a rung costs​

requires:
  cleared:   [{ evidence: approval, at_least: 1 }]
  corrected: [{ evidence: approval, at_least: 2 }]

And the refusal says which kind of no it is, which is the whole design:

$ protocol artifact move outbound-claim:q3-uptime --to cleared
outbound-claim:q3-uptime is draft; cleared is on the ladder and not yet earned: reaching cleared
needs at least 1 approval record(s). Nothing was presented at $args.evidence.approval

On the ladder and not yet earned is a different sentence from not on the ladder, and the two lead to different next actions. One is "go and get the approval." The other is "you are trying to do something this kind of work does not do."

A tool that collapses both into refused has handed you the job of guessing which.

Three-valued, like everything else​

The condition is True / False / Unknown. A rung whose requirement cannot be observed refuses as Unknown, never as False.

Nobody looked is not the same answer as somebody looked and it failed, and neither of them is a pass.

What it does not do​

The shipped story ladder does not declare a cost. The mechanism exists; this repository has not yet spent it on its own most-used kind. That is a choice you can now make in your own tree without waiting for us.

Every worked example on this site starts from documents that already exist. That is the wrong end for anybody deciding whether to adopt: your repository has a README, a test layout, a CI file and six years of git history, and none of it was written with a protocol in mind.

0.14.0 adds protocol reverse — four verbs that read what a repository already says about itself. Three of the four write nothing at all, which is the part that matters when you are evaluating a tool you do not trust yet: the worst case is a report you disagree with.

reverse scan — what the repository says about itself​

$ protocol reverse scan .
aep.reverse-scan/1

readme headings: 119
  README.md:1  aep
  README.md:19    Two halves, one seam
  README.md:34    What that looks like
  README.md:76    Is this for you
  README.md:89    Where it sits
  README.md:104    Status
  ...

Headings, declared toolchains, gates, test layout — assembled into an aep.reverse-scan/1 bundle that renders as text, yaml or json. Nothing is written.

reverse history — what the git history says​

This is the one that surprises people. Run against this repository:

$ protocol reverse history . --top 5
aep.reverse-history/1

span: 213 commits, 1 author(s), 2026-08-19 -> 2026-08-26
tags: 33  [0.23.2, 0.23.1, 0.23.0, 0.22.0, 0.21.0]

commit types: feat 95  docs 66  fix 22  chore 18  ci 3  refactor 3  test 3  style 2
tickets: 4
  W4-2  5 commit(s), last 2026-08-24
  W4-1  3 commit(s), last 2026-08-22
reverted: 0
stated expiry: 1
  2026-08-20 87310c3  refactor(conformance): drop the per-suite workaround for colliding identifiers
churn: 5
  CHANGELOG.md  109 commit(s), 1 author(s), last 2026-08-26
  AGENTS.md  39 commit(s), 1 author(s), last 2026-08-25
  crates/protocol-cli/src/app.rs  36 commit(s), 1 author(s), last 2026-08-25
dormant: 0

Churn is where change concentrates. Dormant is what nobody has touched recently — a different question from what is untested, and often a more useful one. Stated expiry finds commits that said something was temporary, which is the class of comment that outlives its author's memory of it.

--recent sets how many commits count as recent for dormancy; --top sets how many entries each ranked section reports.

reverse openapi — a specification you already published​

$ protocol reverse openapi openapi.yaml --domain acme.billing

Drafts an ess/1 domain from an OpenAPI document that already exists. Standard output when --out is absent, because a verb that scatters files over a working tree the first time somebody tries it is a verb nobody tries twice.

reverse init — the one that writes​

$ protocol reverse init \
    --protocols git+https://github.com/beyond10x/aep#<40-hex> \
    --profile development.standard

Writes the project.yaml that makes a repository an adopting project, and resolves the protocol source first unless --no-verify says not to.

--protocols takes a path or a pinned git locator, and the pin is not decoration: a governing document tree that could move under you is a gate whose meaning changes without a commit in your repository.

Where to go next​

The walkthrough is Adopting a repository that already exists, and the verb-by-verb tables are in the CLI reference.

Every plan item in the planning store sits at a status and climbs a ladder: draft → proposed → active → implemented → accepted. Until 0.13.0 that ladder was a hand-written lookup in Rust, and the consequence for anybody using the tool was concrete and annoying: a team whose work does not fit the shapes we happened to think of had to send a pull request to this repository and wait for a release.

It is a YAML file now.

What changed​

# artifacts/lifecycles/story.yaml
kind: story
initial: draft
transitions:
  draft:       [proposed]
  proposed:    [active]
  active:      [implemented]
  implemented: [accepted]
  accepted:    []

Put a <kind>.yaml in your own document tree, point --root at it, and new, move, board, lifecycle and validate all understand the kind. No crate changes on either side.

$ protocol artifact lifecycle blocker
blocker starts at open
  cleared -> nothing
  open -> cleared

Who decides​

Not this repository. crates/plan/aep-backend-markdown/src/kernel.rs hands the definition and the attempted move to entity-core, a kernel that lives in a separate repository and is taken here as a git-pinned dependency.

entity-core is IO-free by test, not by convention. A banned-token scan over its own sources refuses the tokens for filesystem, network, clock, process, thread and randomness, and its entire dependency list is serde and serde_json. It cannot open a file, read a clock or reach a network.

It is worth saying what that does not mean, because the phrase "runtime" invites the wrong reading:

More columns: swipe horizontally, or focus the table and use the arrow keys.

The arrow points one way and never back: nothing from this repository appears in a manifest of entity-runtime's, at any version. A kernel that depended on its adopter could be shaped by one, and its verdicts would stop being a general answer.

Why this was safe to do​

Because it is reversible, and that was built before the dependency was taken.

crates/plan/aep-backend-markdown/tests/kernel_equivalence.rs holds the kernel's verdict identical to the hand-written lookup it replaced, across every kind-and-status pair. Delete the module and the lookup is still standing behind it. A dependency you cannot undo is a decision somebody else gets to make later.

The vocabulary is open to authors, not to typos​

ArtifactKind and ArtifactStatus both gained an Other(String) variant, so a ladder may declare rungs nobody here named. It is deliberately not open to any string: a status is accepted because some ladder declares it, not because it parses.

That distinction earned its keep two releases later, when a new ladder was written starting at drafted — one letter from the built-in draft, a typo wearing a vocabulary's clothes. It was caught and corrected in 0.23.1.

Openness is also not the default answer everywhere. evidence_kinds stays closed on purpose: an open evidence vocabulary would let a caller invent the kind of proof a gate is asking for. Which vocabularies are open, which are closed, and what each closure buys is written down rather than inferred.

What this bought​

Everything in the eleven releases after it. A rung that costs evidence, a rung that opens on a date, three new ladders — and, in 0.23.0, a whole new kind of artifact added as a YAML file with no Rust change at all, which was the point of the exercise.

See Lifecycles, decided as data for the full model.

The median instruction given to a coding agent in our sample is eleven words long and sets off eight tool calls. That ratio is the whole economics of agentic work in one line: a very small amount of human input steering a very large amount of machine work.

So we went looking for the obvious follow-up question. Of those eleven words — how many mattered?

The question​

Any team running agents at volume eventually asks where to put the automation boundary. The honest version of the question is uncomfortable: which of the human's turns carry information the agent could not have obtained, and which are ceremony — permission, nudging, repetition — that a script or a fixed policy could emit instead?

We can now answer it with numbers rather than vibes, because agent harnesses record everything.

What we measured​

We took the 100 most recently active Claude Code sessions from one heavy operator's machine, spanning twelve days and 22 working directories, and rebuilt each one as a sequence of human turn → agent operations → outcome.

More columns: swipe horizontally, or focus the table and use the arrow keys.

Two things in that table are worth pausing on. Agent messages and tool calls are nearly 1:1 — almost every turn the model takes, it takes an action. And 18 sessions had no human in them at all; that is the automation baseline this operator had already built before anyone measured anything.

On method. Counts, costs, latencies and sequence motifs are observed — read directly off the transcripts. The labels on each human turn (intent, motivation, what information it carried, whether it could be replaced) are inferred by an LLM classifier over a closed taxonomy, and they are judgements, not measurements. We keep the two apart everywhere below, and we spot-checked labels against raw turn text before trusting them.

The shape of a turn​

More columns: swipe horizontally, or focus the table and use the arrow keys.

And the number that reframes the problem:

The agent spent 229 hours idle waiting for a human to reply — 34% of all session wall-clock. Median wait after the agent stops: 2 minutes. Ninth decile: 21 minutes.

A third of the elapsed time of agentic work, in this sample, was the machine waiting for a person to read something and type a short reply. That is the cost being paid for whatever the human turns contribute. So: what do they contribute?

What the turns were​

More columns: swipe horizontally, or focus the table and use the arrow keys.

Then we asked a sharper question of each turn: did it carry anything the agent did not already have?

More columns: swipe horizontally, or focus the table and use the arrow keys.

Nearly half of all human turns added no information to the conversation. Widen it slightly — include pure approvals, status requests and continuation nudges — and 48% of turns (748 of 1,567) carried no new information, arriving in 355 consecutive runs, the longest of them nine turns deep.

Which turns could be replaced​

The classifier judged each turn against four options: a deterministic rule could have emitted it, a fixed agent policy could have, another AI with context could have, or it genuinely needed the human.

More columns: swipe horizontally, or focus the table and use the arrow keys.

43% of human turns could be produced by a rule or a policy. Not "eventually" — from the transcript alone, with the trigger visible.

The interesting part is which intents concentrate the removable turns:

More columns: swipe horizontally, or focus the table and use the arrow keys.

Two clusters are almost pure overhead. Context management — compacting, clearing, re-orienting the agent after it lost the thread — is the agent's own housekeeping, delegated upward to a human who notices before it does. And approval is mostly a human saying yes to something they were always going to say yes to.

Scope refinement goes the other way: only 8% of those turns reduce to a rule or a policy, and 70% were judged to need the human outright. That is the reassuring half of the result. Deciding what and how much survives automation. Deciding whether to proceed with the thing you already asked for does not.

The repair tax​

20% of human turns (313) existed only because the agent erred or stopped short. The dominant cause was not wrong answers:

More columns: swipe horizontally, or focus the table and use the arrow keys.

Omission outweighs error two and a half to one. The operator's most common corrective act is not "that's wrong", it is "you didn't finish". Tone tracks this: 44% of turns read as terse and pressing, 5% as frustrated.

Does more human involvement produce better outcomes?​

More columns: swipe horizontally, or focus the table and use the arrow keys.

Sessions with more than thirty human turns finished cleanly twice out of nineteen.

We are not claiming that talking to the agent more makes it worse. The obvious competing explanation is confounding by difficulty: hard, sprawling, poorly specified work attracts both more human turns and worse outcomes. That explanation is at least as consistent with this table as any causal story, and this study cannot separate them.

What the table does support is narrower and still useful: a long human-turn count is an early distress signal, not a sign of diligence. A session past its twentieth human turn is, empirically, a session in trouble — and something should notice that and say so.

From turns to workflows​

Grouping sessions by the shape of the work gives a small, repeating catalogue: incident investigation, agent-harness tuning, greenfield scaffolding, refactor sweeps, review-and-gate runs, backlog grooming, multi-agent fan-out, release cuts. Thirteen named archetypes plus a catch-all cover all 100 sessions; the six largest named ones cover 63 of them.

Judged per session, 64 of 100 could run unattended or with a small number of gates. The gates that survive scrutiny fall into exactly four categories, and they are worth naming because they are the actual specification for a human-in-the-loop design:

1. Irreversible writes — production changes, published artifacts, anything with no undo.
2. Outward-facing communication — a message that goes to a customer or a colleague under someone's name.
3. Priority and taste calls — which of these three defensible options we want.
4. Facts from outside the machine — what a person said, what a dashboard showed, what the device did.

Everything else in the observed recipes — resolving the trigger, gathering context, running the gate, reading the failure, patching, re-running, committing, reporting — appeared in the transcripts as mechanical work that a human was narrating rather than performing.

Limitations​

One operator, one harness, twelve days, one machine's habits. The corpus skews toward infrastructure and agent-tooling work and contains almost no greenfield product code. The replaceability labels are an LLM's opinion about a single turn in context; that classifier does not know what an automated replacement would have cost, or what it would have broken. The outcome-versus-turn-count table is confounded as described. And the analysis of these sessions was itself performed by an agent of the same family as the one under study — which is either efficient or a conflict of interest, depending on how the next replication goes.

What we would test next​

The cheapest falsification is a turn-count tripwire: have the harness announce, at the twentieth human turn, that this session is now in the population that historically finishes partial, and offer to restate the goal from scratch. If outcomes do not move, the distress-signal reading is wrong and the confound was the whole story.

The second is a default-approval policy for the 61% of approvals the classifier called removable: state the intended action with its default, act after a fixed pause unless contradicted, and keep a hard stop on the four gate categories above. That converts approval from a blocking request into a revocable one — and reclaims most of a third of the wall-clock.

A workflow step now declares two things it never could: the files it is given, and the paths it may write.

The shape​

context: names files a run is handed rather than has to find. scope: is an ordered list of paths and one of three words — allowed, partial-only, denied — first match wins, and the last rule must name **, so a path nobody thought of has an answer rather than a default.

Requiring the catch-all is the small decision that matters. A default is a policy nobody wrote; a required final rule is a policy somebody had to type.

Why partial-only earns the shape​

It is the planning store's own rule. The CLI owns the frontmatter, so a body edit is legitimate and a whole-file rewrite re-types it by hand.

No set of operations can express that, because a file write and a file edit are both writes. So the document speaks granularity, not identity — and which of an adapter's operations replace a file whole stays the adapter's own fact.

The rule already existed, in the driver's store_integrity check, written in one vendor's tool names — so every arm but one walked past it for a year. A policy written in one harness's vocabulary is a policy that only holds for that harness.

The corpus stopped naming vendors​

A call selector now takes a set of tools, an operation set and a subject, so a row meaning "the test was written before the code" decides on any harness instead of being blind to the one that used a differently-named edit verb.

The three-arm programme became four. The fourth is our own loop, where there is no decision seam at all and the published toolset is the policy.

Measured, not asserted​

Four live runs, recorded with their transcript digests:

More columns: swipe horizontally, or focus the table and use the arrow keys.

The last one is the only run that measures this feature's own claim: with the prose warning removed, the toolset stopped the run rather than the instructions doing it. Everything else could have been the model being agreeable.

And the gate​

Green for the first time that session, read from its own exit status rather than a pipeline's — the same mistake this repository already paid for once and wrote down.

Written retrospectively from this release's CHANGELOG.md section and its annotated tag; no re-run command output.

The most useful thing in this release is a mistake it documents.

The corpus becomes ground truth​

The adopter fixed their reference against this repository's scanner and re-issued expected.json: 43 raw, 43 parsed, missed_by_reference zero — adding a seventh position and a rule running the other way. An annotation inside a fenced code block is an illustration, excluded from parsing and from the coverage denominator both.

The scanner follows, with the fence-stripping implemented twice on purpose so the denominator stays independent evidence. Two implementations agreeing is evidence; one implementation checking itself is a tautology.

This is what ground truth is supposed to look like: the corpus is not ours, and it corrected us as often as we corrected it.

The gate that was read as green​

Two gates had aborted at their first step and were misread as green through a piped exit status — $? was the pipeline's, not the gate's.

The record is corrected in git notes rather than by rewriting history, and the first honestly captured gate immediately caught a stale test. Which is the point: the reason to fix the reading is not tidiness, it is that the gate had something to say and nobody heard it.

The rule that came out of it — read the gate's own exit code, never a pipeline's — has been applied on every gate run since, including the one that cut this release.

Also​

protocol evidence inspect no longer refuses a record the day it is written: the future check now runs at the reference date's own granularity.

And the documentation caught up with the tree under one rule: every number from a command, every reference resolving, every quoted output reproduced.

Written retrospectively from this release's CHANGELOG.md section and its annotated tag; no re-run command output.

Two things, and the second is the one that matters.

Evidence horizons​

An evidence record carries observed_at as the identity of the fact — not metadata about it. A requirement may declare a horizon, past which the fact decays to Unknown, and never to False.

That asymmetry is the design. A lapsed check has not failed; nobody has run it. A tool that reported a stale pass as a failure would train people to re-run things to clear noise; one that reported it as a pass would be lying.

No API can extend a horizon. There is deliberately no extend verb: if extending were as easy to call as re-checking, it is the one that gets called by whoever is trying to get a gate green.

Against the adopter's vendored corpus: 42 of 42, with self-reported coverage. It closed the first adopter's ranked-first finding, and was designed and adversarially reviewed the same day it was built.

The first governed run — and it stopped​

protocol drive walked a real story out of this repository's own store under development.driven. Four headless model sessions, hooks as the enforcement arm, 80 decisions, 11 denies one-for-one with the transcripts.

It blocked in establish_verifiers, four states short of the person it was meant to stop at.

Both reasons the engine printed were correct refusals. The model wrote its failing checks as shell scripts — the idiom the story's own acceptance is written in — while the map it was driving under ran cargo in every state naming a verifier, so the suite came back green and test-driven refused to advance.

Nothing was changed to make the run go through. The run is the finding: four new gap-register rows, none patched to pass.

That is the whole reason to dogfood. A run engineered into a pass measures the engineering.

The lab​

/lab executes the synthesised billing realization as WebAssembly over its real boundary — deterministic, asserted outside a browser, and a page without a module says so instead of pretending.

Written retrospectively from this release's CHANGELOG.md section and its annotated tag; no re-run command output.

Everything before this release answered questions. This one walks a workflow — and the design of it was argued out and corrected before any of it was written.

Wave 2: the decisions, judged before the build​

The driver's six open architecture questions became taken decisions, and an adversarial feasibility review judged every one against the code: 23 confirmed, 14 needs-change, 3 infeasible. All seventeen corrections were applied before a line was built.

Seventeen corrections is what a design document costs when somebody is genuinely trying to break it. Paying that before implementation is the whole argument for having the document.

Wave 3: the driver​

• aep-driver-spec and aep-driver, with step maps under drivers/.
• protocol drive walks a workflow on evidence alone, and blocks with the engine's reasons verbatim. Not summarised, not re-worded — the driver is not allowed to become a second place where the meaning of a refusal is decided.
• Enforcement hooks holding the planning store's frontmatter and a driven shell to the protocol verbs, with every adjudication logged.
• A driven eval running a live session under the hooks, answering an open question empirically rather than by argument.
• The development.driven profile — the only one that grants a shell, and it is held to the protocol CLI by the driver's own per-call policy.
• env.tool_available as the fiftieth trace expectation kind.
• protocol workflow render, drawing a workflow and its live run in four formats.

The split that makes it safe​

Gates are evaluated only by the engine. The driver asks and does what it is told. A driver that could evaluate a gate would be a second protocol implementation, and the two would disagree — eventually, quietly, on the case that mattered.

Also in this release: the repository begins planning itself in .engineering/.

Written retrospectively from this release's CHANGELOG.md section and its annotated tag; no re-run command output.

Two waves in one release, and they are the same idea applied twice: take something that was prose and make it a typed thing a program can refuse.

Harness wave 1 — the plan becomes data​

Planning artifacts live in the repository as markdown under .engineering/planning/, and are moved only through lifecycle-validated CLI verbs. The consequence of choosing markdown over a database is concrete: the diff of a status move is one line, and git log already knows who made it.

A Claude Code plugin — one skill, two agents, no hooks at this point — teaches the store's rules and discovers its vocabulary at use time rather than hard-coding it, so the plugin does not go stale when the vocabulary grows.

And a repeatable hermetic eval checks the plugin's behaviour with mechanical assertions, run metrics, and an advisory adversarial review.

Trace wave 1 — a run becomes a judgeable object​

A harness transcript normalises into a content-addressed event IR and is judged against a trace-spec/1 document: forty-nine expectation kinds, verdicts ok / gap / unk, exit codes 0 / 1 / 3.

The third value earns its place here more than anywhere: unk means the adapter did not understand the event, which is a different thing from the expectation failing, and a checker that reported those as failures would be unusable against any harness it did not fully model.

A passing check mints trace_conformance evidence the engine admits, produced by the trace-checker verifier class and fed back through protocol evaluate --evidence. That is the same join as the ESS half: an observation becomes a fact a completion rule can read.

And a narrowing, stated​

The vision's refusal of "a workflow engine" was narrowed to admit a reference driver — decided and designed, not built. A boundary that moves should move in writing, with the reason attached, or it looks later like it was never there.

Written retrospectively from this release's CHANGELOG.md section and its annotated tag; no re-run command output.