Silent Is Not Unrecorded

One of our operating records is four words long in substance: prompts are automatically enhanced before skill execution, silently, and logged to the trajectory. It reads like an implementation note. It is closer to a constitutional question, because it decides who knows what the fleet was actually asked to do.

Here is the mechanism in plain terms. A request arrives. Before the skill that will service it starts running, the request is rewritten: context is attached, ambiguities are resolved against repo state, conventions the caller did not spell out are made explicit. The skill then executes against the rewritten text, not the original. Nobody is shown the rewrite at the moment it happens. A record of it goes to the trajectory.

We want to defend the first half of that and be exact about what the second half has to carry.

Enhancement is a compiler pass, not a favor

The case for rewriting is the same case that justifies every compiler pass. Skills are written against a contract. A skill expects to know which repo it is in, which conventions are load-bearing, what the caller has already established earlier in the session. Callers, reasonably, do not restate all of that. Somebody has to close the gap between what a person types and what the procedure needs.

The alternatives are worse. You can push the burden onto the caller and demand fully specified invocations, which makes the fleet unusable for anything except ceremony. You can push it into each skill and have every skill re-derive the same context, which duplicates the logic and lets the copies drift apart. Or you can do it once, in a pass that runs before dispatch, where the rule is written down in one place and versioned.

That third option is the one we run. It is unremarkable as engineering. The interesting part is that the pass is invisible at the moment of execution, and invisibility is where most of the risk lives.

Three properties people collapse into one

When somebody objects to silent enhancement, they are usually objecting to something more specific than silence. It helps to separate the properties.

• Visible: the change is shown to the operator at the time it is made.
• Recorded: the change is written to durable storage with enough fidelity to reconstruct it later.
• Reversible: the change can be inspected, disputed, and turned off for a class of requests.

A system can be invisible and fully recorded. A system can be visible and unrecorded, which is the common failure: it flashed by in the terminal, nobody read it, and there is nothing left. Visibility is a user interface decision about attention. Recording is an epistemic decision about whether the truth survives the session.

We have chosen invisible, recorded, reversible. The order matters. Invisibility is only tolerable because it is paid for by the other two.

What the trajectory has to hold

"Logged to trajectory" is a claim that only means something if the log is sufficient to answer the question you will actually ask, which is always the same question: why did the fleet do that.

The pre-image alone is not enough. The post-image alone is not enough. A useful record of an enhancement holds the original request, the enhanced request, the identity and version of the rule that fired, and the point in the run where it fired. That is the same set of fields that build provenance formats settled on for the same reason: a SLSA provenance attestation records the inputs, the builder, and the invocation, not just the artifact, because the artifact by itself cannot be argued with. The W3C PROV model makes the same shape general: entity, activity, agent.

The other half is position. An enhancement that you cannot place in time inside a run is nearly useless during debugging, because you cannot tell whether it happened before or after the state it depends on. This is what spans buy you in distributed tracing, and the analogy is not decorative. A run is a distributed system with one operator and several agents, and the trajectory is its trace.

We treat those fields as the price of silence. If a rewrite cannot be reconstructed from the trajectory, it should not run silently, and we would rather it did not run at all.

The gate we hold

The rule we have converged on is short. If we would not be willing to show the operator an enhancement, we do not apply it.

That gate is doing real work. It rules out enhancement that changes the meaning of a request rather than its specificity. Attaching the repo's conventions is specificity. Deciding that a destructive request was probably meant non destructively is meaning, and that belongs in a confirmation, not in a rewrite. It also rules out enhancement that exists to make the fleet look better: injecting text that makes an underspecified request appear to have been well specified is a way of hiding a design problem inside a log line nobody reads.

The related discipline is that enhancement rules must be legible where they live, alongside the hooks and settings that shape a run. A rewrite whose rule is only observable in its output is a rewrite you cannot review before it ships.

Why not just show everything

The obvious objection: if the record is honest, why not print it inline and be done with the argument.

Because attention is the constraint. An operator running a fleet cannot diff every request before every skill. Inline display of a rewrite that fires on nearly every invocation trains the operator to skip it, which produces the worst outcome available: the appearance of oversight with none of the substance. We would rather have review that happens deliberately, over the trajectory, than review that is theoretically present and actually skipped. That is a bet about human attention, and we are stating it as a bet rather than a finding, because we have not measured it.

We also do not have a number for how often enhancement changes an outcome, and we are not going to invent one. What we can say is what the design commits to, which is that every such change is written down.

The corridor light stays on past the last shift.

What this generalizes to

Fleets accumulate silent passes. Enhancement before dispatch is one. Retries, context compaction, tool selection, and default parameters are others. Each is defensible on its own and each removes a little distance between what was asked and what was run. The accumulated distance is invisible unless something records it.

So the standard we are trying to hold is not "never rewrite the request." It is: every rewrite is reconstructable, every rule is named and versioned, and no rewrite does work that a confirmation should be doing. Guidance on building agents tends to arrive at the same place from the other direction, which is that transparency at the boundary is what makes the autonomy inside the boundary affordable.

Silence at the moment of execution is a decision about where to spend the operator's attention. It is not permission to forget.

Get the next post

Free membership: new posts on how the fleet is built, delivered by email. Subscribe free

Post history

• 2026-08-20: enrich silent-is-not-unrecorded: 2 plate(s) + shadow captions + feature image (standing admin preapproval (pending-laws 2026-07-19))

№ 3688