Why textualism, original public meaning, and AI governance all turn on the same uncomfortable fact: intent does not travel unless it becomes part of the record.

There is an old fight in legal interpretation about where meaning lives.

Intentionalists look for purpose. They ask what Congress meant to do, what the drafters were trying to accomplish, and what problem the law was meant to solve. Legislative history matters in this view because floor speeches, committee reports, drafter notes, and surrounding debate can reveal the intent behind the enacted words.

Textualists are skeptical of that move. They argue that the law is the text that was enacted, not the private intentions of the people who helped write it. The words are the law. The meaning is what the text would have conveyed to a reasonable reader, not what a motivated advocate can later reconstruct from a convenient committee report.

Originalists make a related move in constitutional interpretation. Original public meaning says the Constitution means what its words would have been understood to mean by the public at the time of ratification. Not what a drafter secretly intended. Not what a later judge wishes it said. The meaning is anchored in the text, the historical context, and the interpretive record available at the relevant time.

You do not have to be a textualist or an originalist to see the infrastructure point.

Once a system has to act on language, intent is not enough. Intent has to travel through something. It has to travel through text, context, rules of interpretation, and a record of what was available to the interpreter when the decision was made. Otherwise, “what I meant” becomes an after-the-fact story.

Anyone who has spent time debugging prompts has run into the same problem.

You thought you were telling the model to be careful. You were actually telling it to hedge every answer into uselessness. You thought you were asking it to be concise. You were actually removing the context it needed to be right. You thought you were giving it freedom to reason. You were actually giving it permission to invent.

The words on the page were doing work you did not realize they were doing.

That is the uncomfortable part of working with language models. A prompt is not what you meant. It is not the conversation you wish you had with the model. It is not the background assumptions in your head. It is not the thing you would have clarified if another person had looked confused.

A prompt is the artifact the system received, interpreted, and acted on.

That is why the analogy to textualism matters. In human organizations, we constantly rely on unwritten context. We rely on shared history, institutional memory, tone, relationships, and the ability to stop and ask, “wait, what did you mean by that?” Human communication survives ambiguity because humans have recovery mechanisms.

AI systems do not get those recovery mechanisms for free.

There is no hallway conversation where you explain that when you said X you obviously meant Y. No shared institutional memory unless it is supplied. No unstated assumptions unless they are embedded somewhere in the context. No ability to rely on “what everyone knew” unless what everyone knew made it into the materials the system was given.

The system only has the record.

This does not mean the model is a textualist judge. It is not. The originalist’s reasonable reader is a legal construct. A model is a versioned, probabilistic system operating inside a specific runtime. The same words can produce different behavior under a different model, a different instruction hierarchy, a different retrieval result, a different tool definition, a different policy layer, or a different configuration.

So the lesson is not that the model found the one correct meaning of your prompt. The lesson is that your intent did not travel.

Intent does not become operational just because it existed in your head. Context does not exist just because your team would have understood it. Purpose does not govern the system unless it is encoded in the materials the system actually sees.

This is the prompt engineering lesson people often miss. Prompt engineering is not merely a collection of magic phrases, though some prompt patterns work for model-specific reasons that are not obvious from the surface text. At its core, prompt engineering is drafting. It is the work of turning intention into operative language.

That is why it feels so much like legal drafting. You are not writing what you wish the system understood. You are writing the thing the system will act on.

In production AI systems, that “thing” is larger than the sentence the user typed.

The operative prompt includes the system instruction, the developer instruction, the retrieved documents, the tool definitions, the prior turns, the examples, the policies, the memory, the model version, the ranking logic that decided which facts were included and which were left out, and the configuration that shaped how deterministic or creative the output could be.

That is the effective prompt.

This is where context engineering starts to absorb prompt engineering. The hard problem is no longer merely finding better words to ask the model. The hard problem is constructing the interpretive environment in which the model can behave reliably enough, predictably enough, and accountably enough for the job it is being asked to do.

Legal interpretation has always depended on more than raw text. Textualists still need grammar, usage, canons of construction, dictionaries, historical context, and an account of the reader. Original public meaning still needs evidence of how words were used at the relevant time. Even the most text-centered theories need a record.

AI systems make that dependency operational.

What was the user prompt? What system instruction controlled it? What policy applied? What documents were retrieved? What facts were omitted? Which tool schemas were available? Which model ran? Which version of the surrounding system produced the answer?

These are not merely implementation details. They are the interpretive record of the system.

That is why the prompt is the meaning. Not because the model is a perfect reader. Not because the words have one stable meaning across all systems. Not because intent is irrelevant. But because the system can only act on what made it into the operative prompt. If something was not in that record, it was not available to govern the system’s behavior.

At that point the issue changes. It is no longer just an interpretation problem. It becomes an evidence problem.

For a toy prompt, failure looks like annoyance. The answer was too verbose. The model misunderstood. The prompt needed tuning.

For a production system, failure looks like a governance gap. The system made a decision, but nobody can reconstruct what it was asked, what it knew, what it was allowed to do, what policy constrained it, what model produced it, or which version of the surrounding context shaped the result.

If you cannot reconstruct the effective prompt, you cannot explain the output. If you cannot explain the output, you cannot evaluate whether the system behaved correctly. If you cannot evaluate whether it behaved correctly, you cannot govern it.

This is why prompts need version control. Retrieved documents need provenance. Tool definitions need change history. Policy layers need to be preserved. Model versions need to be tied to outputs. Evaluations need to capture not just the answer, but the context that made the answer plausible.

But preservation is only the first step. A record without evaluation is archaeology. A record without monitoring is trivia. A record without enforcement is a diary. Governance requires the record, but it also requires machinery that acts on it: tests, policy gates, drift detection, human review, incident analysis, and change control.

Otherwise, the organization has outputs but not governance.

A log tells you what happened. A record tells you what the system was asked to do, what it was allowed to know, what constraints it was operating under, and why the resulting behavior was plausible from the materials available to it.

Without that, accountability collapses into storytelling.

The team says the model was supposed to be careful. The prompt says “avoid unsupported claims,” but the retrieved material was stale. The policy says “follow the customer’s procedure,” but the procedure was missing from context. The audit says the system made a decision, but nobody can reconstruct the versioned bundle of instructions, documents, tools, model, policies, and configuration that shaped it.

At that point, you are not governing the system. You are narrating around it.

That is the deeper lesson from textualism, originalism, and prompt debugging.

Text is never just text. It is text plus an interpretive frame, text plus context, text plus a record of what counted as meaning at the time. In law, we fight about that because rights, obligations, and institutional power depend on it. In AI systems, we are turning that fight into software.

The prompt is not your intent.

The output is not self-explaining.

The effective prompt is the record.

You may not fully own the model. You may not own the provider’s policy stack. You may not own the training process, the safety layers, or the hidden machinery that shapes the output.

But you can own your side of the interpretive record. You can preserve what you supplied, what the system saw, what it was allowed to do, what it returned, how it was evaluated, and what changed afterward.

That is the infrastructure of accountable AI.

The prompt is the meaning because the prompt, properly understood, is the record the system acted on.

You either govern that record, or you inherit someone else’s explanation.