The Trust and Harness Framework

Part I established what the policy requires the organization is obligated to accept. Part II tells the organization what to do, and the bond between the two is where a policy either becomes operational or stays on the shelf. The Accountability Principle named who answers for AI-assisted work: the operator who used the tool, the custodian accountable for the affected domain, and the organization that deployed it. What it did not provide is an instrument the operator can apply in the moment, in front of a specific tool and a specific task, to decide how far that tool can be trusted with the work. This chapter provides the instrument.

The Trust and Harness Framework sorts every AI deployment into one of four tiers according to how much constraint surrounds the tool’s output and, as a direct consequence, where responsibility for checking that output falls. The tiers are not a ranking by model capability, and a higher tier is not necessarily better in all use cases. The tiers are a way of confidently assigning trust in AI output to the structure(s) that creates and earns that trust level. Before the tiers themselves, the chapter has to be precise about the thing that affects our trust in AI output the most: the harness.

What a Harness Is

A harness is the set of instructions, contracts, constraints, data sources, reviews, and decision boundaries that surround an AI model’s inference and governs its output. The model generates; the harness decides what the generation can touch, what it must be checked against, and who is answerable for the result. A useful way to view the distinction is that the AI model is the engine and the harness is everything else that makes the engine safe to operate: the chassis it sits in, the brakes that stop it, the steering that aims it, and the instruments that tell someone what it is doing.

The harness lives silently in the space between the AI model and the world its output reaches. On one side is the model, producing responses to provided inputs. On the other side is a system of record, a customer, a production environment, or a decision with consequences. Whatever stands in that space between, inspecting, constraining, grounding, logging, or approving what passes from the model toward the consequence, is the harness. When nothing programmatic occupies that space and there’s only a person reading the responses, the person is the harness. This is the first thing an operator has to understand about the AI tools they use every day. In an AI open-chat window, the operator is the harness, and the only one.

A programmatic harness can be created through a series of deliberate, often business-oriented choices, and each choice can tighten or loosen the trust the AI output can carry. What data may the model access? A simple chat interface typically can see only what the operator types into it (assuming no additional tool capability built into the chat system). A grounded system is given access to an approved body of source material and nothing else. What may the model touch? A drafting assistant touches nothing, and its output sits inert until a person uses it in another system (e.g., internal email, corporate website, official communication). An operational AI agent may be permitted to write to specific fields in an internal financial ledger and forbidden everything else. What must be checked, and against what? An AI assistant may be required to cite a source for every claim, to run its output through a test before that output ships, or to pause for a person’s approval before it does anything that cannot be easily undone. Who is answerable when the output is wrong? Every harness, however simple or elaborate, resolves to a person who owns the outcome. These are some of the questions that help build a harness, and the answers an organization gives to them are what determine how much trust its people can place in what the AI produces.

At the simple end, the harness is a single person in a conversation, deciding sentence by sentence what to keep and what to discard. At the elaborate end, the harness is a multi-layered, complex system, and it is worth exploring those layers plainly, because highly trustworthy harnesses in use today are assembled from them. The first layer is the execution environment, the bounded place where an AI agent actually runs. Intentionally isolated so that its activity cannot spill into systems it was never meant to reach. There is an identity and permissions layer, the layer that assigns an identity to the AI system, configures rules about what the agent is allowed to access, and enforces that boundary the way the organization enforces it for any employee. There is a verification layer, the checks built into the system that test the output before the output is allowed to be used as input for any other system or process. And there is an observability layer, the audit trail of an agent’s actions, sequence of operations, costs, and changes, enabling human operators to review or reconstruct its behavior for debugging and auditing. These layers describe what a modern, multi-dimensional harness can look like. They are not a checklist that every governed deployment must satisfy. The point of naming them is that the model is one component sitting inside this assembly, not the assembly itself, and the trust the assembly earns comes from the maturity of the harness around the model far more than from the model itself.

This is the idea the rest of the chapter is built on, and it is worth stating before we name the tiers that give it structure. The trust an operator may place in AI output is set by the harness attached to the model and by how well that harness fits the work, not by the brand of the model or the size of the model. A frontier model reached through a bare chat window is still an open conversation with no harness but the person reading it. Whatever honesty tendencies have been trained into the model helps modestly, but it is not a harness, and it is not what makes the output safe to rely on. It follows that a smaller model wrapped in a rigorous, purpose-built harness can be trusted with work the frontier model’s chat cannot. The capability of the model is real, and it matters, but it is not what determines how far the output can be trusted in any given use case. The harness determines that.

None of this changes who is accountable, and the distinction needs to be restated. Two questions sit behind every use of AI output. The first is how far the output can be trusted, meaning how much of the checking has the system already performed before a person acts on or accepts it. The second is who answers when the output is wrong. Tightening the harness raises how much an operator can trust the output for its purpose. It does not move responsibility for that output away from the people the Accountability Principle named. A tool that checks its own work more thoroughly is still a tool, and accountability for what it produces still goes to the operator who used it, the custodian accountable for the domain it flowed through, and the organization that deployed it. The harness influences how much verification a result has already received before a person or another system relies on it. It does not change who answers when the result is wrong, and there’s a meaningful consequence. The tiers that follow organize the first question. They leave the second exactly where the Accountability Principle placed it.

The Four Tiers

With our understanding now of a harness’s role in shaping AI output, the four tiers of AI deployments can be revealed. Each tier is a band on the same spectrum: how much constraint surrounds the output, and therefore how much of the trust has been built into the system rather than left to a person. In policy and organizational management, there is a constant tension between precision and practicality. Four tiers are defined because this number strikes a good balance. It captures the critical distinctions that change what an operator may safely do with AI output, without creating an overly complicated rulebook that employees would find confusing or cause difficulty in judgement.

Tier 1 is open-ended chat: a general-purpose assistant reached through a conversational interface and used for the operator to have questions answered quickly. The model can produce any response that completes the prompt, and nothing inspects, grounds, or checks that response before it reaches the operator. The operator is the entire harness, and every factual claim the tool makes is unverified until the operator verifies it. Tier 1 is where most enterprise AI use sits today, and its openness is exactly what makes it useful for drafting, brainstorming, summarizing material, or explaining an unfamiliar subject. The same openness is what makes it the wrong place for work whose output will travel onward, relied upon as accurate or factual, without a person performing verification of its claims.

Tier 2 is a retrieval-augmented system (RAG): a tool that answers from a body of source material it retrieves at the time of the operator’s request rather than from the model’s general training, and that can refer to where an answer came from. The harness here adds grounding and boundaries. The model’s answers are tied to sources the operator can open and check. Verification narrows accordingly, from confirming everything to confirming that the cited source genuinely supports the claim.

The strength of a Tier 2 deployment depends on how governed its source material is, and two cases sit inside the tier. In the stronger case, the system is restricted to a designated, approved corpus that someone in the organization or trusted by the organization owns and keeps current, like a data warehouse. The data boundary is fixed and known, the sources are vetted, and a named owner is accountable for the accuracy and currency of what the tool can draw on. This is a tier suited to regulated and high-stakes fields such as legal, healthcare, and customer support, where an unsupported or hallucinated answer is unacceptable and the organization needs to pre-determine exactly what the tool was allowed to consult. In the weaker case, retrieval runs against the open Internet. The answers are still grounded in retrievable sources the operator can check, which is what keeps this in Tier 2 rather than Tier 1, but no one owns the corpus, the boundary is whatever the open web returns, and the burden on the operator to confirm each source is correspondingly heavier. Both are Tier 2. They are not equally trustworthy, and an organization should know which one it has deployed.

Tier 3 is a constrained operational agent: an AI system permitted to take a bounded set of actions against other systems, inside a defined workflow, with scoped permissions. Crucially, these actions are initiated by a human operator, or they are strictly gated by human sign-off before any external state changes are applied. An internal support-request triage agent, triggered by an operator, that classifies incoming requests and routes them to the right queue, without resolving them, is a Tier 3 deployment: its actions are real, but they are gated, bounded, and easily reversible. Tier 3 is also commonly found in AI-assisted software development, where discrete skills are created and used in moving application changes through the CI pipeline. A software developer may call a skill that pushes code to the software repo and creates a pull request, deploy changes to a staging environment for QA testing, or kick off a GitHub Action to deploy to production and perform a health check of the updated site. Each example affects other systems, with the skills supplying the bounded set of allowable actions, and initiated by a human operator.

Tier 4 is the purpose-built skill: a specialized system of instructions engineered to execute a high-value business process end-to-end, running at machine speed, triggered on events, not human action. It is the most heavily constrained tier and yet paradoxically, the most powerful for the job it was built to do since its harness is custom-fit to the exact risks and requirements of the task. The guardrails and potential use of execution layers, are what enable the autonomy. The defining shift from Tier 3 is where the human stands. A Tier 3 deployment has a person in the loop on the initiating action, may serve as a gate during execution, and frequently inspects the outcomes before allowing changes to travel. A Tier 4 deployment removes these gates by default and moves the human up a level: the role-holder sets the policy the AI system’s skill operates within, oversees the monitoring, handles the exceptions it escalates, and owns the operational outcome. The human no longer approves each transaction because the judgment that used to require a human has been built into the harness as validation logic.

A deployment qualifies as Tier 4 when it satisfies three conditions. It is built entirely around one specific, complex workflow and no other, whether that is automated vendor reconciliation in finance, software development from spec to deployment in engineering, or dynamic inventory re-routing in logistics. Its harness grants it the permissions and tool access to act directly on critical systems, bounded by validation logic strict enough to make that access safe. And it has an explicitly named human role-holder who is accountable for its actions and its outcomes. What clears a Tier 4 assignment is that validation logic, not a person. If an organization decides that a particular action must still be authorized by a human every time or even on occasion, that action is running at Tier 3, even when it sits inside an otherwise autonomous Tier 4 process.

Tier 4 is easiest to see in the work where organizations are reaching for it hardest, which is software development and the deployment of software changes. Consider a purpose-built engineering harness that runs whenever a product requirements document (PRD) is presented: it takes that document, converts it into a technical specification, implements the features it specifies, tests, creates documentation, and carries changes through to production. The harness is built for that job and no other. It runs inside an isolated environment where its code can execute without reaching systems outside its remit. It can touch only the repositories and resources its permissions allow. It runs everything it produces through an automated test suite and a set of policy checks before that work counts as completed. It records each step and decisions it takes along the way. An engineering role-holder owns the harness, sets the policy it runs under, builds in monitoring, and answers for what it ships. That is a Tier 4 deployment, and it is Tier 4 not because it has a sandbox and scoped permissions and logging, but because it was built for one job, harnessed to fit that job, runs on its own trigger rather than a person’s prompt, and has an owner. The layers it happens to contain are how this particular harness is built. They are not the reason it qualifies.

The same example shows where the line between Tier 3 and Tier 4 actually gets drawn, because the decision that separates them is whether to keep a human gate in front of the action. A human approval before a production release is the slowest part of the loop, and it comes under immense pressure exactly when a team has automated everything around it. An organization that has successfully automated a complex process can see plainly how much faster it would move if it also removed the final gate before deployment, and for many the calculation is that the speed gained outweighs the residual risk. This paper does not judge that trade-off. What it insists on is clarity about what the trade-off is. Using human gates throughout a familiar workflow makes the deployment Tier 3, with a person in the loop on the action. Removing it makes the deployment Tier 4, autonomous through to production in the software development example, with far more harness and trust. The gate is not merely friction to be optimized away; it is the specific mechanism by which a person accountable for the outcome authorizes the action. A skill operating at machine speed without it can execute a great deal before anyone with authority reviews what it did, and an organization should make that change deliberately, knowing it has moved the deployment from one tier to the next, rather than discovering after the fact that it did.

One final claim runs through all four tiers and deserves to be stated on its own. The tier is a property of the deployment, not of the AI model. The same underlying model can occupy any of the four tiers depending on the harness built around it. A capable frontier model offered through a chat window is a Tier 1 deployment, because nothing constrains or checks its output but the person reading it. A modest model inside an autonomous, purpose-built skill is a Tier 4 deployment, because the harness, not the model, is doing the work of making the output trustworthy for its task. An organization that classifies its AI use into tiers by the reputation or capability of the models involved will classify it wrong. The question is never how good the model is. The question is how much do we trust the harness that surrounds it.

The four tiers, with where each one places the harness and the verification, are summarized below.

Tier and Task Alignment

The four tiers are only useful if the organization matches them to work correctly, and the rule for matching is simpler than it might appear. The tier a piece of work requires is set by the consequence of the work product, not by the convenience of whatever tool is closest at hand. Work whose output will enter a system of record, reach a customer, or drive a decision that is hard to reverse needs a harness equal to that consequence. Work that produces a rough first draft for a person to complete needs almost no harness at all. The mistake the framework exists to prevent is reaching for the most available tool, which is usually the open chat, and using it for work that needed far more around it.

A short illustration makes the alignment concrete. It is not a real deployment. It is a composite of how this work is done well, offered so the contrast with failure is clear.

A research team needs to find supporting material for an important document, the kind of material that has to be real, has to say what it is claimed to say, and will be relied on by people downstream who will not re-check it themselves. Rather than ask an open chat assistant to produce the material, the team works through a tool built for the job. The tool is restricted to a trusted, licensed library of genuine source material and draws its answers only from that library. Every answer it returns links back to the specific source it came from. A researcher opens each cited source, confirms that it exists and that it says what the tool claims it says, and only then relies on it. Someone in the organization owns that library and keeps it current, so the body of material the tool draws from stays trustworthy. The task is the same one that, done carelessly with an open chat, produces invented material presented with full confidence. Done at the right tier, with grounding, traceable sources, a person confirming each one, and an owner for the corpus, the same task is far more reliable. The difference is not the intelligence of the model. The difference is the harness the work was given.

From this the chapter’s central requirement follows, and the policy states it directly. Every AI deployment in the organization must be classified into a Trust and Harness tier before it is approved for use, and the tier it receives governs the work it may and may not perform. A deployment classified at Tier 1 may not be used for work that requires the grounding of Tier 2, the operational boundaries of Tier 3, or the separation of execution layers, verification, and ownership of Tier 4. An operator who needs Tier 4 work done may not substitute a Tier 1 tool and personally stand in for the harness the work required. The classification is a decision made before the deployment is approved, and it binds what the deployment is allowed to do.

The Verification Burden Shifts With the Tier

As work moves up the tiers, the responsibility for verifying AI output does not disappear. It moves, and it changes hands. Verification is not a replacement for accountability, and the two must not be confused. Accountability is fixed by the Accountability Principle, and it does not shift with the tier. For every AI deployment at every tier, responsibility for the output flows to the operator who used it, the custodian accountable for the affected domain, and the organization that deployed it. That is settled, and the tiers have no influence over it. What the tiers settle is a different and narrower question: who performs the work of checking the output, against what, and also under consideration, how often.

At Tier 1, and through much of Tier 2, that work belongs to the operator, personally and primarily. The operator chose to produce the work with AI, and the operator owns the checking of what the AI produced. This holds even when the work crosses into domains the operator does not own. Here a distinction matters that is easy to get wrong. When an operator’s AI-assisted work will draw from another domain, the Accountability Principle requires the operator to route the consequential work product to that domain’s custodian for review prior to execution, so the custodian can exercise the authority they hold over their own domain. It does not require the custodian to become the verifier of the operator’s AI output. The operator does not discharge their own responsibility for checking the output by handing it to a custodian. The custodian’s review is the custodian’s authority over their domain. The verification is still the operator’s.

This is a deliberate choice, and the reason for it is practical as well as based on principle. If verification shifted onto the domain custodian every time an AI-assisted workflow touched their domain, the sheer volume of open-ended AI use across an organization today would bury custodians under other people’s AI usage. The custodian who owns a domain would spend their days verifying output that operators throughout the organization produced with open chat tools. The operators would quietly stop feeling responsible for output they could just route elsewhere for verification. Both outcomes are exactly what the policy is built to prevent. The operator who uses AI for work must take, and must feel, primary responsibility for what that AI produces.

At Tier 3 and Tier 4, verification ownership consolidates, and it moves from the individual operator into the harness and the role-holder who owns it. A constrained operational agent is verified at two points: by the human who triggers or signs off each consequential action before it touches another system, and by the role-holder who owns the autonomous workflow and monitors the agent’s behavior over time. The operator interacting with a well-built Tier 4 deployment is not personally re-verifying each output, because the verification has been built into the system and assigned to its owner. The speeds at which these AI deployments can operate, and the workloads they can handle, are the payoffs of the higher tiers.

This is where the chapter’s requirement earns its wages, because the act of classifying AI deployments creates the control structure. When a deployment is classified into a tier, the organization has, in that same act, established who holds the responsibility for verifying its output. A Tier 1 classification says the operator is the verifier. A Tier 4 classification says the harness verifies and a named role-holder owns it. A deployment that cannot be placed in a tier, or that sits in a tier with no identifiable owner of its verification, is for that reason at fault with the policy, no matter its technical sophistication. The control this chapter contributes is the requirement that no deployment is approved until it has a tier, because a deployment with a tier is a deployment whose verification has an owner, and a deployment without one is a deployment whose output no one has been made responsible for checking. How that verification is then carried out in practice, and how approval and data handling attach to each tier, are specified elsewhere in the operating framework. This chapter settles the prior question on which those depend: what tier the deployment is, and therefore where its verification lives.

The Most Expensive Mistake

One mistake is more common and more costly than any other in enterprise AI use, and the whole framework is arranged to prevent it. It is the use of a Tier 1 tool for Tier 3 or Tier 4 work. An operator opens a chat window, gives it a task whose output will travel onward into a record, a decision, or a customer’s hands, and in doing so becomes the entire harness for work that needed a real one. The conversation is fluent and confident, the output looks finished, and the single point of verification, the operator, is the same person who is moving quickly and trusting the tool. Nothing in the deployment catches what the operator misses, because in a Tier 1 deployment there is nothing in it but the operator.

The clearest illustration of this failure is one already examined in this policy. A professional preparing a formal document used a general chat assistant to find supporting prior decisions to cite. The AI assistant returned references that looked authoritative but did not exist. When the references were questioned, the professional asked the same assistant whether they were real, and the assistant confirmed that they were. The work reached its destination carrying invented material. Read through this chapter’s framework, the failure is precise. The work required Tier 2 classification at the least, research that had to be grounded in real sources and checked against them. It was done with a Tier 1 tool and the attempt to verify by asking the same tool to confirm itself was not a verification at all, because a Tier 1 deployment contains no verification other than the person, and that person had handed the checking back to the tool that produced the claims. The harness the work required was never built, and the operator stood in for it without realizing that standing in for it was the job they had taken on.

That is the mistake that assigning deployments to tiers is meant to avoid. The tier is the first decision the organization makes about any AI deployment, before the deployment is approved and before an operator places weight on its output. It tells the operator how much of the trust has been built into the system and how much remains theirs to supply. It tells the organization where verification lives and who owns it. And it keeps the Accountability Principle operational in daily work, because naming the tier makes visible where the checking sits, and visible checking is what lets the role-holder accountable for an outcome exercise their accountability authority. Large swathes of work across organizations route through AI now. Classifying the deployment is how the organization keeps work in view of the people who answer for it.