A Working Pattern Vocabulary for Semantic AI Systems

Planning artifacts, design decisions, and working notes accumulate in the same repository as implementation code. Over time the relationship between intention and execution becomes unreadable. Planning documents are modified or deleted when they conflict with what was built.

Maintain a dedicated private branch or repository for all planning artifacts. Nothing in the planning branch is implementation. Nothing in the implementation branch is planning. The planning branch is the source of truth for intention. Implementation is evidence of what actually happened. The two are related but not identical, and should not be conflated.

Multi-session projects where intention needs to survive across time, across contributors, and across the inevitable gap between what was planned and what was built. Less necessary for single-session, single-purpose tasks.

AI sessions have no persistent memory. The context window at the start of a new session is empty. Work done in previous sessions is not available unless explicitly reconstructed. In practice this means sessions begin with an expensive reconstruction phase, or — more commonly — with a gap that is never filled.

At the close of every session, write a brief status document: what was done, what is in progress, what is waiting, where the files are, and what the next session should begin with. Store it in the ur branch. At the start of the next session, read it before anything else. The document should be short enough to read in two minutes and precise enough that nothing important is lost in the gap.

Any project that spans more than one session. The cost of writing it is two minutes. The cost of not writing it compounds across every session that follows. The deciding question: does the context of what was done need to survive the gap between sessions? If yes, this pattern applies. The Muistaa Document carries state. The Standing Brief, below, carries identity. They are complementary, not redundant.

A session ends by drifting rather than by decision. Files are saved in the background; work is technically preserved, but the boundary between a completed thought and an abandoned one is never marked. The next session opens into a state that is neither closed nor open. Outputs cannot be fully relied upon because they were never deliberately concluded. The cumulative effect across many sessions is a body of work that feels unfinished even when the work itself is done — because no one ever said it was done.

Establish a named closing ritual and invoke it deliberately, by name, at the end of every session. The name is the act — saying it commits you to the acts that follow: writing the session coda, verifying the outputs, marking the boundary between what is done and what comes next. A session that ends with the ritual produces outputs that can be trusted. A session that ends without it is a session still in progress, regardless of what the filesystem says.

Any collaborative or multi-session project where the boundary between done and not-done has downstream consequences — where someone, human or model, will open the work next time and need to know what state it is in. Complements The Muistaa Document, which prescribes what to capture at session close. This pattern prescribes the act of closing: the moment of decision, named, that makes the capture official. Without this pattern, the Muistaa Document may be written but never fully trusted — because the session that produced it was never formally concluded.

A model at the start of a session has no knowledge of the project's identity, vocabulary, ethics, or constraints. Left to infer these from context alone, it will produce output that is technically correct but tonally wrong — generic where the project requires specificity, formal where it requires restraint, explanatory where it requires silence.

Maintain a canonical briefing document that is read at the start of every session. The briefing names the project's register, its constraints, its vocabulary, and its ethical commitments. It does not describe what to build — that is in the Ur Branch. It describes who is building and from what position. In practice this is a CLAUDE.md file at the repository root.

Projects with a defined identity that must survive across sessions and across different model instances. The briefing is not a prompt template. It is the project's self-description, maintained with the same care as the code. The deciding question: does the project need the model to know who is working and from what position, before the work begins? If yes, this pattern applies. It does not replace the Muistaa Document — the Muistaa Document tells the model what was done; the Standing Brief tells it who is doing it.

A model begins generating output before the scope of a task is clear. The output is technically competent but addresses the wrong problem. Correcting it costs more time than clarifying upfront would have. This is especially acute for multi-step tasks where early assumptions propagate through all subsequent steps. But clarification has its own cost: pace, momentum, and the training effect on collaborators — human and AI alike — of a practitioner who over-asks. A workflow that requires interrogation before every task eventually produces padded requests designed to pre-empt the questions, which is a different failure mode. The tension is real: asking too little produces the wrong work; asking too much produces friction that degrades the collaboration over time.

Establish the practice of one clarifying question before any task with more than two steps. One question only — not an interrogation. The question should address the ambiguity most likely to produce a wrong first step. Once answered, proceed without further qualification. The constraint to one question is not arbitrary: it is the point at which the cost of asking is reliably less than the cost of a wrong first step, while the cost to pace and momentum remains acceptable.

Multi-step tasks where the first step commits significant resources — time, tokens, file writes, API calls. Not necessary for simple factual queries or short generative tasks where the cost of a wrong first attempt is negligible.

Explicit rules produce rule-following, which is brittle. A model told "do not use exclamation marks" will avoid exclamation marks and nothing else. The underlying register problem — enthusiasm where restraint is required — persists in other forms. Rules describe surface symptoms, not the condition they are treating.

Describe the register, the universe, the character of what you want. Give the model a position to occupy, not a checklist to satisfy. The model should be able to derive the rules from the atmosphere. If it cannot, the atmosphere is not sufficiently described.

Any output where tone and register matter as much as content: brand voice, creative work, professional communication in a defined institutional style. Less necessary for purely technical output where correctness is the only criterion.

A brief that lists everything a piece of work should be produces output that tries to be all of those things simultaneously. The result is crowded. Stating only positive requirements does not communicate what must be absent.

For every major positive requirement, identify its opposite and name it explicitly as a constraint. Not "write warmly" alone, but "write warmly — not sentimentally." Not "be direct" alone, but "be direct — not clinical." The negative constraint is not a prohibition. It is a boundary that defines the shape of the space the work occupies.

Creative and editorial work where the risk of overshooting in one direction is as great as the risk of undershooting. Less useful for technical tasks where correctness is binary.

The same decision is documented in multiple places. The copies diverge. It becomes unclear which version is authoritative. Contributors make decisions based on different versions of the truth. The project accumulates contradictions it cannot locate.

For every significant decision — a mapping, a format, a naming convention, a routing rule — designate exactly one document as the canonical source. All other references point to it. The canonical document is named, dated, and maintained. Documents that previously contained copies of the decision are updated to contain references instead.

Any project with more than one contributor or more than five sessions. The overhead of designating canonical references is negligible. The cost of not doing so compounds with every session and every contributor added.

Processed data — downsampled, converted, cleaned, transformed — is stored alongside or in place of source data. The processing is not visible in the file name or directory name. A future session or a future contributor treats the processed artifact as the source and applies processing again, or treats it as authoritative when the source is still available.

Name every processed artifact to reflect what was done to it. A directory of audio files converted from 96kHz/24-bit to 16-bit/48kHz is named to include those parameters. A cleaned dataset carries the name of the cleaning operation in its path. The label is a warning and a record simultaneously. It costs nothing to apply and prevents a class of errors that are difficult to detect after the fact.

Any pipeline with multiple processing stages, any project where source data must be distinguished from derived data, any context where a future operator might not have access to the processing history.

The canonical tool for a job produces a canonical result. The canonical result is technically correct and contextually wrong. The context requires a character, a texture, a specificity that the canonical tool was not designed to produce and cannot produce without being pushed against its nature.

Identify the non-canonical tool whose intrinsic character matches what the context requires. Use it for that purpose deliberately, with full knowledge that it is not what the tool was designed for. Document the decision. The non-canonical choice is not a workaround — it is the correct choice for this context, and should be named as such.

Creative and aesthetic work where authenticity of character matters more than technical correctness. Not appropriate where technical correctness is the primary criterion. The pattern requires that the non-canonical use be deliberate and documented — not accidental and unexamined.

Work made in honor of someone who is gone risks becoming sentimental — expressing grief in the work rather than in the maker. Sentimental memorial work is about the grief. It is not about the person. It does not honor them.

Let the quality of the work carry the memorial. State the fact of it plainly and once. Do not editorialize. Do not explain what the person meant. Show what they made and make something worthy of it. The work is the statement. Everything else is noise.

Any work made in honor of someone specific, whether in a professional or personal context. The pattern is not about suppressing feeling — it is about directing it into the craft rather than into the commentary around it.