Version. 0.1 Date. 2026-06-27 Status. Standing note for the Loomworks project. Surfaces whenever a Companion response asserts that an action happened, offers an action, or names a feature — i.e. whenever the Companion's words make a claim about system state or capability. Origin. Three failures found in Operator testing (2026-06-27), all the same shape: the Companion's words claimed something the system did not do or cannot do. Lineage. Same family as correctness-guarantees-in-code-not-prompts, FORAY-emission-belongs-at-the-auditable-event-layer, and database-as-definition-layer-not-decision-layer. All four say: the guarantee must live in the substrate, not depend on a surface (or a script) cooperating. This note applies that family to what the Companion says.
The Companion must only claim an action happened if the system actually performed it. It must only offer an action it can actually perform. It must only name a feature that actually exists.
The Companion's words are a surface. Right now, that surface can say things the substrate never did:
The defect is the same in all three: the Companion's reply is decoupled from what the engine actually did or can do. The response is emitted by a script (a prompt) that assumes success, independent of whether success occurred. The words follow the script, not the system.
The principle closes that gap: the Companion's success-claims, offers, and feature-references must be gated on real system state — emitted because the engine confirmed the action, set up the offer, or has the feature, not because a prompt told the responder to say so.
| # | The Companion said | What the system actually did | The gap |
|---|---|---|---|
| A | "Done — I've stopped using that." (remove flow) | Nothing — the assertion was untouched, still committed, no retraction event written. The confirmation branch needs is_confirmation_turn AND len(matches)==1; the match didn't resolve to one, so retract_assertion never ran — but the responder emitted the scripted success line anyway. | A success claim with no action behind it. |
| B | "Want me to save that?" (remember-about-me Stage 1) | The note was mis-classified as general_conversation; the responder free-formed an offer with no held-write set up behind it. | An offer with no action behind it. |
| C | "If you want it permanently erased, that option will be available in your settings." (every retraction) | No such setting, no assertion-erase endpoint exists. The sentence is hardcoded in the prompt (forget_about_me.md:7); "in your settings" is the generic _LOCATION_FALLBACK filler. | A feature promise with no feature behind it — and a feature that, if built as worded, would violate corrections-preserved (permanent erasure destroys the record the seed keeps as a correction). |
A and B are success/offer decoupling. C is a feature-reference decoupling. All three are the same principle violated.
Success claims gate on the action. "Done" is sayable only when the engine confirms the action ran. If the retraction didn't persist, the Companion must not say it did — it should say what actually happened (e.g. "I couldn't find a single matching note to remove — did you mean one of these?") rather than a scripted success line. The success language is emitted from the engine's confirmed result, not scripted into the prompt as an assumption.
Offers gate on capability. The Companion offers to save/remove/produce only when the path to actually do it is set up. An offer the system can't fulfill is the start of a loop (instance B became the remember-about-me stall).
Feature-references gate on existence. The Companion names a setting, a button, or a capability only if it exists. No prompt should script a promise of an unbuilt feature. (And no prompt should promise a feature the seed forbids — instance C's "permanent erasure" is both unbuilt and seed-violating.)
The structural form: wherever possible, success language should be driven by the engine's result, not authored in the responder prompt as a fixed string that assumes the result. A prompt that says "on a confirmed retraction, say 'Done'" is the trap — it fires the success line on the intent to retract, not the fact of retraction. The fact must gate the words.
It does not require the Companion to be terse or robotic — natural, warm phrasing is fine, as long as the claim is true. It does not forbid the Companion from describing things it will do as part of a confirmed flow. It governs claims about completed actions, offers of actions, and references to features — the places where words assert system state. Conversational text that makes no such claim (explanation, discussion, acknowledgement) is unaffected.
Three confirmed instances — strong enough to name now, not wait for a fourth. The immediate fixes (gate instance A's "Done" on the real retraction; remove instance C's invented promise; instance B is the remember-about-me loop, separately scoped) close the known cases. The systematic follow-on is to audit the responder's scripted success-claims, offers, and feature-references for other places a prompt assumes a result the engine hasn't confirmed — because three instances means there are likely more untripped.
If the systematic audit lands, this note is a candidate for promotion into the methodology document proper alongside the other substrate-trust principles.
DUNIN7 — Done In Seven LLC — Miami, Florida Loomworks Standing Note — The Companion Must Not Claim What the System Did Not Do — v0.1 — 2026-06-27 Three instances: a success claim, an offer, and a feature promise, each decoupled from system reality. The Companion's words must be gated on what the engine actually did, can do, and has. One confirmed pattern; immediate fixes + a systematic audit follow.