Version Eleven

"Never Active products don't indicate risk."

The sentence entered one of many system prompts on an afternoon. An LLM response had triggered an alert that made no operational sense, the kind of technically correct signal that collapses under the smallest amount of scrutiny mixed with institutional knowledge. The model had identified language that correlated with risk and applied that pattern faithfully, even though the customer had never adopted the specific product in the first place. I pulled up the underlying record, scrolled through a transcript and other data, looking for the moment that had confused the system, and the conclusion arrived quickly: the model wasn't exactly wrong about the language, but the framing of the problem was off. A customer who never started using something cannot meaningfully be described as about to stop. The model was missing context I took for granted.^[1]

So I wrote the rule and committed it to the prompt.

That prompt lives in a system I named TARS, after the Interstellar robot, because I could. Every fifteen minutes a cron job wakes up, analyzes five accounts, and goes back to sleep. It pulls from everything: CRM data, call transcripts, chat logs, meeting notes, issue trackers, a PM tool. Quietly, continuously, across the full portfolio.^[2]

Everything surrounding that rule has already begun to fade. The particular transcript or record that triggered the problem, the order in which the logic became clear, all of it dissolves into the background noise of dozens of similar afternoons. Only the rule remains intact. Every transcript the system analyzes now encounters that sentence, quietly adjusting the model's interpretation before the rest of the analysis unfolds.

That persistence produces a strange inversion of how organizations usually forget things. A teammate leaves, a document gets archived, a wiki page falls out of date, and the reasoning that once guided a decision slowly dissolves into rumor. Months later the same question surfaces again and someone reconstructs the answer from scratch, unaware that the organization solved the problem once already.

Here the opposite occurs. Reasoning evaporates slowly, in time, but the rule survives. And rules like this don't only accumulate in the prompt or memory file. They hide inside the system's architecture, in decisions that looked like engineering but were actually beliefs.

As an example: the Slack sync originally processed account-related channels in alphabetical order.

I realize that doesn't sound like the beginning of a disaster. But with hundreds of channels and API rate limits, the sync would reliably run out of time somewhere around the letter M. Every single run. Accounts whose Slack channels happened to start with N through Z were structurally underserved, not occasionally or randomly, but systematically, as a feature of the alphabet. I only caught this after noticing that some accounts consistently had rich Slack context in their analyses while others had none, and the dividing line was, absurdly, the first letter of the channel name.

The fix was simply a rotation cursor, a few lines of code that picks up where the previous run left off. But the broader lesson stayed with me: any system with bounded execution time and ordered processing will create invisible hierarchies. Alphabetical ordering feels neutral but isn't. And the hierarchy it created was perfectly silent, distinguishable from normal operation only if you already suspected something was wrong.^[3]

The most surprising version of this pattern involved the system prompt's persona instruction. The prompt tells the model "you are the world's best [x], and your job is to [y]" where [x] is a particular role in a company, and [y] is a judgment call. For months I assumed this was a tone instruction, a way to make the output sound less like a help desk and more like a colleague. Then I actually compared the outputs side by side, and the difference was larger than I expected.

Without the "world's best [x]" framing, the model hedges. Assessments arrive padded with qualifiers: potential risk factors, possible concerns, indicators that may suggest elevated attention. These are the kinds of sentences that are technically defensible and practically meaningless. Someone reading "there may be potential risk factors" across forty accounts learns exactly nothing about which ones need attention this week.

With the persona framing, the model became more likely to commit. It names the evidence, identifies the source, and makes a call about what matters and what doesn't. My best explanation is that the persona creates pressure toward specificity. Someone who hedges everything isn't actually performing the role the prompt describes, and the model seems to resolve that tension by grounding itself in concrete evidence rather than retreating to vague or abstract qualifications.

The instruction that most shaped how the system reasons turns out to be a sentence about who the model is. Telling the model it occupies a role appears to do more work than telling it how to weigh information, because the role implies a stance toward the information that no list of rules can specify directly. A skilled practitioner doesn't hedge across forty accounts, and the model, reading itself as one, stops hedging too.

I find myself unsure what to call this. It isn't quite prompt engineering in the way that phrase usually gets used. The lever is identity, expressed as a few words at the top of a file that the model takes as constitutive of how it should think rather than how it should sound. Which means the most consequential governance choice in the system, the one that determines whether anyone trusts the output enough to act on it, was a sentence I wrote without realizing I was making a governance choice at all.

Inside the prompt file, lines accumulate gradually. The filename or a random comment gives the game away:

2026-02-21-v11

Over time the prompt begins to resemble sediment more than design.^[4] Buried inside it are fragments of conversations the organization has already forgotten: an account misread as at-risk, a transcript mentioning a competitor that turned out to be harmless, a product adoption metric missing from a regional account that once triggered a cascade of false alarms. Each line compresses the outcome of a discussion that once occupied a room full of people.

Rules behave differently from principles in that respect.

Principles carry a type of lineage with them. Someone can usually reconstruct the argument that produced them. Principles have parents.

In contrast, rules accumulate through unexpected encounters. An edge case appears, the system reacts poorly, and a constraint enters the prompt to prevent the mistake from repeating itself. The only evidence that the lesson ever mattered is a lingering discomfort when I consider deleting that rule.

Scar tissue might be closer to the right term than memory. Each rule marks a place where the organization's assumptions turned out to be incomplete. Scar tissue protects the system from reopening the same wound twice.^[5] It also conceals the original injury.

And the scar tissue isn't confined to the prompt. The rotation cursor, the persona instruction, the cooldown windows: each of these is a rule embedded in architecture rather than language, harder to find and harder to question because it presents as engineering, not a rule.

TARS wasn't designed as the system of record for how the organization thinks. These things rarely are. Someone builds a tool to solve a specific problem, and then the tool accumulates context, and the context layer grows, and at some point the system crosses a line nobody quite notices. It holds institutional knowledge that exists nowhere else, not in the CRM, not in anyone's head, not in documentation. It becomes the company's context brain without anyone formally deciding it should be.

By the time the prompt reaches version eleven, most of the scenes that produced its instructions have already disappeared. The model still behaves correctly because the rules execute every time the system runs, but the reasoning that gave those rules their meaning has begun to dissolve. What remains is a system that remembers certain operational lessons more faithfully than the organization itself does, applying them hundreds of times a week without hesitation or explanation.

I've thought about deleting some of the older rules. There are lines in the prompt I no longer fully recognize, instructions that feel right in the way that all caution feels right, without my being able to fully reconstruct the scene that made them necessary.^[6] Now those sentences run without me, in contexts I didn't anticipate, shaping conclusions I won't always see.

The honest version is that I keep meaning to audit the prompt and don't. I open the file, read down through it, and somewhere around the lines I can't immediately place I find a reason to close the tab. The reasons are always plausible. Something else needs attention. The rule probably exists for a good reason. A quiet system is doing its job, and the cost of disturbing one that runs without complaint is hard to justify against work that visibly needs doing.

What I'm describing is probably avoidance, not really an active decision. The rule survives because removing it would require me to know something I no longer know, and acquiring that knowledge would mean reconstructing an afternoon that has already dissolved into all the other afternoons. So the rule stays, and the next person to read the prompt encounters it as part of the system's apparent design, indistinguishable from instructions written yesterday with full context and conviction.

The model underneath those rules has changed too. Every constraint was calibrated against a specific version's tendencies, and the version that made the original mistake may no longer exist. Which means some of these rules might be correcting for failure modes the current model doesn't have, while remaining silent about new ones it does. The scar tissue protects against an injury the body can no longer sustain.

What stops me from deleting them, finally, is the discomfort of not knowing. The rule might be protecting the system from something the organization has forgotten how to name.

Or it might be a ghost.