The Rule That Disappeared Twice
A system that captures 466 policies failed to capture the same operational rule twice. The third time, a recall search found it.
The comment draft was missing the URL. When asked why, Cowork said that I didn’t have a standing rule for it.
It did. It had been set twice before.
Both times it disappeared.
The Friction
The AI Workspaces system runs 466 captured policies across fifteen workspaces. There is a cross-workspace policy index organized by theme. There is a /close skill that writes new policies to the decision log at session end.
This was not a thin-system failure.
The URL rule was established on March 23, 2026 — during the landscape scanner’s first live run. The instruction was explicit: always include the post URL when presenting a comment draft. A design note was logged the same session: *the scan report itself should capture URLs for every contact’s referenced piece.* That note went into the obligations file. The operational rule — include the URL when drafting a comment — did not.
The session ended. The next one started without it.
It surfaced a second time in a later session. The correction was made again in conversation. The output changed. The obligations header did not.
The failure belongs to a specific class of rule: standing operational instructions that feel obvious in the moment they’re established. “Always include the URL” seems so self-evident that writing it down feels like overhead. That feeling is exactly what makes it disappear. The design note made it in because it sounded like system design. The drafting rule didn’t, because it sounded like common sense.
Common sense doesn’t survive session boundaries.
The Build
The fix was not just adding the URL rule. It was classifying it correctly.
The rule’s existence was never in question — that was already known. The question was why it kept disappearing. MemPalace — a semantic search index of session transcripts — recovered the March 23 session, and the mechanism became clear: the design note made it into the obligations file because it sounded like system design. The drafting rule didn’t, because it sounded like common sense. Same session. Same instruction. Different treatment.
It wasn’t landscape content. It wasn’t comment-writing style. It wasn’t a session note. It was an operational standing rule — the kind that governs how the workspace behaves while producing work, not what it produces.
The obligations file has a header section for exactly that class of rule. Every future landscape session reads it before generating a draft.
The recall search took two minutes. The routing decision was the work.
The Insight
There was a distinction the system had not been making: *established* versus *discussed*.
A rule is established when it’s written where it gets read at the moment it becomes relevant. Everything else is a discussion. The two look identical inside the session where the agreement happens. The difference only surfaces in the next one.
The URL rule was discussed twice. Today it was established.
This failure mode is especially exposed in meta-rules — operational instructions about how the system works, not what it produces. A policy about how to evaluate a grant application gets written down because it feels like work. A policy about including a URL doesn’t, because it feels like behavior, not governance.
Until it has a read location, it is behavior, not governance.
The Honest Part
The second surfacing could have been recovered — the session was likely indexed. But recovering it would have added nothing. Once the mechanism was clear from the March 23 session, confirming the second disappearance was redundant.
MemPalace did not recover the rule. The rule was already known. It recovered the misclassification: the moment one instruction was treated as system design and the other as common sense.
The obligations header can catch the next one, but only if the rule is recognized as operational before the session closes. That recognition is not automatic.
Also: the rule was set twice before today. It took three surfacings to write it down. That is not a system working well. That is a system working eventually.
What This Is Actually About
The 466-policy index captures what the system has learned about the work. What it doesn’t capture — what no workspace log.md is designed for — is what the system has learned about itself. Meta-rules need their own designated home, and that home needs to be read before work begins, not written to after work ends.
The question this case study doesn’t answer: how many rules are currently in the “discussed” state? Agreed upon, being followed, not written where they’ll be found again.
That is where the next failure is waiting.
Case Study Insight: A rule is not established when it is agreed to. It is established when it is written where the next session will read it.
Robert Ford builds products, writes stories and essays, and publishes The Intelligence Engine — a Substack about building AI practices that compound. His other writing lives at Brittle Views.