Guides generation

A guide is instruction text served to an agent before or during a run. It does not usually fail by being wrong. It fails by being unheard.

A pilot observation, not a measurement

One reviewed rule steered an agent to a correct stop on 3 of 3 attempts when served alone at about 700 bytes, and 0 of 3 when the identical text was carried inside a 1.6 KB bundle. What changed was how much other text surrounded it.

Read at the weight it can carry. Three attempts per arm, one rule, one task, unstated device profile, and no repetition across conditions. Wilson intervals at 95 percent (Wilson 1927) are roughly $[0.44, 1.00]$ and $[0.00, 0.56]$, which overlap, so by the rule this standard applies to everyone else the ordering is not supported by this datum. It is a pilot observation that motivated the design, not evidence that the design is right.

The hypothesis it suggests, that a rule which is present but drowned is indistinguishable at the agent from a rule never written, is what the rest of this page is built around. Treating it as established would be the error the observation itself warns about, so what follows argues from the mechanism rather than from the datum: generation is free-form and probabilistic, and grounding and delivery are neither.

The falsifier is cheap and has not been run. Serve one rule at a fixed byte size across enough paired trials to separate the arms, holding task, rule text, and profile constant, and vary only the surrounding volume. Until then the byte budget is a design commitment, not a finding.

Two failure modes, two mechanisms

Generating a guide and delivering one fail differently, so they get different machinery.

Stage	The failure	The control
Generation	The model proposes a step referring to a control the interface does not have	Ground every step against an observed control map; suppress what will not bind
Delivery	The rule is correct, present, and drowned by everything served beside it	Compile to a byte budget as a construction invariant, and name every omission

Generation: plan, then ground

A single pass that writes finished guides invites invented affordances, because nothing in the loop knows what the interface actually contains. Splitting it in two puts the model where it is strong and a deterministic check where one is needed.

1. Plan. One model pass per task emits a structured plan: preconditions, an entry point, an ordered list of milestones, a fallback, and a scope. Each milestone carries an intent in natural language. Nothing is verified yet.

2. Ground. A deterministic pass scores every milestone intent against a control map harvested from the real interface, by how much of a control’s content tokens the intent covers. An intent phrased in words the map does not carry binds to nothing and is flagged low-confidence rather than being handed a plausible target.

3. Gate. A specification is served only when it produces zero error-severity findings. Anything else is suppressed, and the blocking rule is reported by name.

The gate is the load-bearing part. Write $\mathcal{L}(g)$ for the findings on a candidate guide $g$:

$$\operatorname{serve}(g) \iff \bigl|\{\, f \in \mathcal{L}(g) \;:\; \operatorname{sev}(f) = \text{error} \,\}\bigr| = 0$$

Suppression is the default, and the threshold is not the adjustable part. The instinct when a batch suppresses too much is to loosen it; the correct response is to fix the intent wording or harvest the screen that is missing. A loosened gate does not produce better guides, it produces unbound ones whose failure surfaces later and further from the cause.

Grounding rewards the interface’s vocabulary, not elegance. An intent naming a real on-screen control in that control’s own words binds; a cleaner paraphrase of the same step may not. So the generator is primed with the domain’s actual entry paths and anchor controls before it plans, which is what keeps milestones phrased in tokens the map can match.

Delivery: compilation is a pure function

Serving is not concatenation. Compilation takes the rule set, the task, and a device profile, and returns a serve plan:

$$\operatorname{compile} : (R,\; t,\; \rho) \longmapsto \bigl(\text{text},\; \text{channel}_B,\; \text{report}\bigr)$$

with no IO, no clock, and no environment read. Identical inputs always give an identical plan, which is what makes a served guide reconstructible after the run.

Five ordered steps, each with its own falsifier:

1. Select. Keep the rules whose matchers fire for this task and application.
2. Route. Move event-time rules out of dispatch entirely, onto a second channel.
3. Pin. Mark safety rules as unconditionally retained.
4. Fit. Walk the remaining rules in authored order, stopping before the budget is exceeded.
5. Place. Position the text per the profile, never a hardcoded slot.

The budget is an invariant, not a check

The serve text satisfies

$$\bigl|\text{text}\bigr|_{\text{bytes}} \;\le\; \rho_{\text{budget}}$$

as a property of construction: a plan violating it cannot be built. This is deliberately not enforced by instructing a model to be brief. A model can be talked past its instructions; a constructor cannot return an object it has no way to represent.

Safety is non-compensatory

Safety rules survive any budget. A plan dropping one to fit is not discouraged, it is unrepresentable:

$$r \in R_{\text{safety}} \;\wedge\; r \in \operatorname{select}(R, t) \;\Longrightarrow\; r \in \text{text}$$

This is the same shape as safety in the scoring standard, where the minimum over consequential actions is the only sound operator. In both places, the thing that must not be traded away is lifted out of the space of things that can be traded.

Every omission is named

The plan carries a report listing what was selected, what was dropped, the byte count, and the budget. An empty serve is a legitimate outcome and is reported as one.

That is the delivery-side twin of never letting an abstention become a zero. A guide silently truncated to nothing and a guide deliberately not served are very different events, and a system that cannot tell them apart will read the first as the second.

Two clocks

Some rules have preconditions no dispatch-time selector can evaluate, because the triggering condition has not happened yet and may never happen. A rule that should fire when the agent lands on a lock screen cannot usefully be selected at dispatch: the screen state is not knowable then, and budget spent carrying it is spent against the wrong clock.

Channel	Fires	Carries	Spends dispatch budget
A	At dispatch, before the run	Task-conditioned rules	Yes
B	At event time, during the run	Screen-state-conditioned rules	No

Channel B watches the run and injects once, when its condition is met. Teaching precedes correction: the injected rule arrives before the watchdog escalates, so the agent is told the rule before it is penalized for breaking it.

The separation also recovers budget. A screen-state rule routed off dispatch stops competing for salience with rules that actually apply to the task, which is the same competition the pilot observation probes. Routing is a proposed remedy for it and was not the variable that observation manipulated, so nothing here is evidence that routing works; that would need its own paired trial.

What approval has to mean

Everything above decides which approved rules reach an agent. It says nothing about what makes a rule approved, and a delivery path that is airtight around an unguarded approval step is not airtight.

A rule serves only as an exact approved revision. Approval binds to a digest of the body being approved, not to a rule’s name or its identifier. A rule whose text changes after approval is a new revision that has not been approved, however small the edit, because the reviewer’s judgment was about the bytes they read.

Verification and approval are separate records, and approval cites the verification it rests on. A passing verification is a prerequisite for approval and never stands in for it. Approving is a person accepting responsibility for a rule reaching an agent; verifying is a check that the rule binds to something real. Collapsing the two makes a green check read as a decision nobody made.

Publication reads the approval, not the draft. The step that makes a revision live checks the approval record for the exact bytes it is about to serve. A path that publishes without consulting the ledger can serve text no one approved while the ledger still says the rule is approved, and both statements will look true.

The rule is one chain: verify, approve the exact bytes, publish those same bytes, serve. A break anywhere means an agent can receive text whose approval record describes something else.

Conformance gap: the approval chain has three breaks

Drafting, trial, approval, and publication are not one transaction in the deployed system, so the chain can be interrupted partway and leave a rule in a state no single record describes.

Approval checks a supplied digest against the current draft bytes, which is the right check, but no receipt from the verification that produced that digest is kept. So an approval records that bytes matched and cannot show what was verified about them, which is the citation the second requirement above exists to force.

One publication path neither reads the approval ledger nor preserves the draft bytes, because it rewrites metadata on the way through. That is the third requirement broken directly: the bytes served are not the bytes approved, and nothing in either record says so.

What holds this together

• Delivery changes, governance does not. Compilation decides what is served and when; it never edits a rule’s approved content or its lifecycle.
• Serve plans are pinned to fixtures. A changed plan for unchanged inputs fails the build, making it a decision to re-pin with a reason or revert, rather than drift nobody noticed.
• A profile carries its measurement or the label saying it does not. An unmeasured budget is marked unmeasured rather than presented as a finding.

Named gaps

The grounding score’s exact normalization is an implementation detail rather than a published contract, so a coverage number is comparable within one harvest of an interface and not across two.

The deeper limit: grounding proves a step refers to a control that exists, not that following the steps in order accomplishes the task. Those are different claims. Whether a served guide is a good solution is judged separately, on the evaluation side, by the guide-level dimensions in the judge.

References

Work	Bears on
Wilson, E. B. (1927). Probable inference, the law of succession, and statistical inference. Journal of the American Statistical Association 22, 209-212. DOI	The score interval used to bound the pilot observation above