Building your Judgment Stack

How to get AI to actually work in your business

White collar work is the act of taking responsibility for your judgment. The value is created by good judgment and captured by the act of taking legal accountability for the results. Most work consists of two types of judgment:

1. Orchestration – ordering tasks in a complex process to solve a problem

2. Criterial – framing a problem, or determining quality on a solution

I’ve written extensively about how this affects the future of work, and about why AI tools can excel at certain tasks and fail at others. This piece assumes that AI will play a significant role in task orchestration, but that it won’t fully replace humans and human criterial judgment. This is about pivoting that framing into action.

Your judgment is what separates the output of your business using AI from the outcome that your clients could get by using AI on their own. The specific way you constrain and direct your AI tools encodes your judgment into AI action and it differentiates your output from what would otherwise be a commodity. That encoding is your firm’s judgment made explicit for AI. It is the bridge between the processes that your business runs on and the AI agents that can orchestrate them.

This is your judgment stack, the logic, knowledge, and interface points that define your work processes. Your judgment stack enables AI to orchestrate your workflows in support of human criterial judgment applied to the inputs and outputs of those workflows.

Building a judgment stack takes time, and it can feel overwhelming. This article is about where to start and how to organize the effort so that you see immediate benefit to your current workflows while building the infrastructure that your future ones will require. It’s not a step-by-step guide about how to build AI agents; there are a million of those on the internet and that’s not really what I write. This is the article you should read before you read that so that you understand what you need to build.

Do you even Reason bro?

AI models “reason” by selecting and sequencing patterns against whatever constraints and context they’re given. That sounds complicated, but it’s a fairly useful way to think about what these tools are doing. You give the model a problem. The model looks for relevant patterns in its training and applies them against the constraints of the problem as it understands them. The quality of the output depends on the quality of those constraints and the patterns in its training.

Give an AI model your firm’s specific decision logic, your standards, your accumulated knowledge about how you approach a class of problem, and it can apply all of that. It will reason over the constraints and context that you’ve provided. Give it nothing firm-specific, and it does what it’s designed to do: find the closest corollary to your problem in its training data and predict the most probable answer. General purpose models produce generally correct answers. Think about the most politically savvy person you know and think about how they speak in a way that sounds intelligent but avoids taking a concrete stance on anything. Just enough substance to imply an opinion, but not so much as to draw out a disagreement. This is what foundational models do when asked specific questions about your business. It’s like asking your state senator to comment on your business plan; the response will sound exactly like a good answer.

What models lack is a specific roadmap to connect what is generally true about the world to what is specifically true about your business.

This knowledge is encoded in the culture at most businesses, and it is therefore inaccessible to AI tools: how decisions get made in review, what gets corrected and why, what “good” actually means in practice versus what the documentation says. It’s implied through artifacts that reflect the judgment but don’t contain it. Your deliverables are outputs of reasoning, not maps of it. And it’s delivered ephemerally: in client conversations, in the explanations that accompany the documents, in the exchange where the reasoning behind the work gets communicated and then disappears. Even if you had a transcript of every meeting, you wouldn’t capture the intention with which the words were delivered. The reasoning isn’t in the artifact. It was never meant to be.

Your firm has a reasoning system. It runs on experience, apprenticeship, and institutional culture. It works. It has worked for a long time. But it is invisible to every AI tool you are trying to deploy, because none of it has been made explicit in a form that any tool can access. That doesn’t mean that you’ve been doing it wrong; it just means that you will have to do it differently if you want to use AI tools effectively at scale in your work.

You can’t really recover the recipe from the meal. Even if you could reverse-engineer the reasoning from finished deliverables, it would be harder and less reliable than writing the reasoning down on purpose. And the reasoning you’d recover would be specific to that one deliverable rather than generalizable across the class of problem.

There are emerging platforms that address a related but different problem. Mistral recently launched Forge (mistral.ai/news/forge), a platform that lets enterprises train custom AI models on their proprietary data. That’s a genuinely promising capability: once you’ve given it the recipe, Forge can orchestrate the production of the meal at scale. But it doesn’t infer the recipe. It still needs your judgment articulated explicitly enough to train against: the evaluation criteria, the alignment objectives, the policies. The judgment stack is the upstream work that makes any of these approaches functional, whether you’re directing a general-purpose model at runtime or training a custom one from scratch.

The judgment stack is the result of doing the work to understand, define, and document your business processes in a format that is easily understood by AI tools.

What the Judgment Stack Consists Of

A tech stack is the organized set of software tools your people use to run your business. Your judgment stack is the organized set of encoded judgments that your AI systems will use to orchestrate tasks within that software stack. It has three components, each serving a different function in the system. Depending on your particular approach to software, size of your company, etc. the actual implementation of this varies - but the general approach to the types of files you need to create is consistent.

Logic

Logic encodes how your firm approaches a specific type of problem into a specific file for each type of problem. The decision rules, the sequencing, the priorities, the boundary conditions, the exception handling. Logic tells AI: for this type of problem, here is how we think about it, here is what matters, here are the steps, here is where work can proceed automatically and where to stop and surface the decision to a human.

This is not instructions for humans written loosely enough that a smart person can figure it out – nor is it step by step instructions for automating a set of tasks. It is judgment encoded into criteria that a system with the ability to recognize patterns and call tools (but with only basic ability to tell good from bad) can reliably determine the next action to take.

Human-oriented process documentation leaves gaps that experienced people fill with judgment. That’s fine when the audience is human. Coding-level automation scripts actions when the course is predetermined; this is just called automation. But, when the audience is an AI model, every gap is an opportunity for the model to improvise, and improvisation from a model without an understanding of your firm’s judgment means reverting to the generic answer. The relentless pursuit of adequacy.

Knowledge

Knowledge is curated background information that is relevant to a specific type of problem. This is usually a bunch of individual files all stored together in a single place to be referenced (or indexed as important to be referenced for a certain type of problem). It is most often stuff like your standard acceptable contract language, your design standards, your library of building codes, a curated set of articles that represent your particular view of a certain framing of a certain problem, your past project data. The accumulated understanding of what works and what doesn’t in your specific practice.

Logic without knowledge is the earnest intern, doing the right motions but the results lack wisdom. You can encode perfect decision rules, but if the model doesn’t have access to the primary standards that those rules reference, then every bit of context exerts equal pull; as if you just “liked” every available movie on Netflix. On the other hand, Knowledge without logic is a library nobody uses – like your company knowledge base that your service desk keeps reminding you to look at. Knowledge is curated content to bias the model towards a given answer. It is worth noting that the “curated” part of that statement matters A LOT. Knowledge evolves over time and requires a librarian to maintain relevance. This is real work. There is a benefit to doing it well, but it’s not free.

Interface

Interface is what the human needs to see to make a decision about the quality of an output, or to give instructions about the nature of a task. These are example documents of what the output needs to look like in order for the human to review it, or structured forms that you want to use to gather inputs or information from a human before you start work on a project. Remember the last time you worked with a junior employee - this is normalizing that experience so that you can focus on the problem at hand rather than wondering if you remembered to tell them everything important before they got started.

The interface encodes what information needs to be present, in what form, and in what order, for the person who needs to decide. The human receiving AI output or directing the AI input should be making the decision, not hunting for the information required to make it. On the output side, this means structuring results so the criterial judgment is efficient: the flagged issues, the relevant comparisons, the context that matters, with everything else stripped away. On the input side, this means giving the human a clear way to provide the criterial context that shapes how AI executes: the specific priorities for this engagement, the risk tolerance, the strategic considerations that the logic needs to know about.

Together, logic, knowledge, and interface encode the boundary between orchestrational and criterial work for a given domain. Logic and knowledge direct AI on the orchestrational side. Interface structures both the input and output for the criterial side. Your judgment stack is the growing collection of these components across your firm’s domains.

What This Looks Like for a Real Domain

So, cool. It’s all abstract though until you apply it in a real domain. Contract review is as good a case study as any, the work crosses multiple types of judgment, and the boundary between orchestrational and criterial is instructive. I walked through this example in a previous piece from the perspective of work classification. Here I want to walk through it from the perspective of the judgment stack.

A contract arrives at your firm. Some of the work that follows is orchestrational. The contract gets uploaded and scanned. Clauses are classified against a taxonomy: indemnification, limitation of liability, termination conditions, insurance requirements. Each clause gets compared against your firm’s standard acceptable language. Deviations are identified. The path through this work is known. The output at each step is checkable. A clause either is or isn’t an indemnification clause. The comparison to standard language either shows a deviation or it doesn’t.

Some of the work is criterial. A clause deviates from your standard language. Does it matter? The clause might accomplish the same thing in different words. It might shift risk in a subtle way that’s acceptable for this client but wouldn’t be for another. It might be technically nonstandard but strategically unimportant given the size of the engagement. Whether the deviation matters is a judgment call that depends on context, priorities, and risk tolerance that is a poor fit for agents to handle. That’s where the human stays.

The judgment stack for this domain makes the boundary explicit.

Logic

The logic encodes the classification rules, the deviation thresholds, the escalation conditions. Building it forces a precision that your firm probably hasn’t had to exercise before. You’ll probably argue about what an acceptable deviation from standard indemnification language means. You find that the threshold for escalation has never been defined, because it lived in the experience of whoever happened to be reviewing the contract that day. So, after that argument you will end up with some useful statements about which type of indemnification language is acceptable and which type isn’t. It’s not verbatim language that is written out here - it’s intent; AI is actually pretty decent at determining the intent of specific legal language. These disagreements aren’t problems with the encoding process. They’re the encoding process revealing judgment that was always there but never articulated. Resolving them is valuable entirely apart from what happens with AI. This is also where you put things like “if you aren’t sure about a particular clause, it’s better to surface it for review than accept it with hesitation”; or “this language can vary wildly and most of it is acceptable, it’s the presence of any clause here that we are looking for.” You set the tone, not script the decision.

Knowledge

The knowledge is your standard acceptable language for each clause type, your documented risk tolerances, your record of prior negotiation outcomes with specific counterparties. This material exists in your firm. It’s scattered across templates, emails, and the institutional memory of whoever has been doing this work the longest. Curating the signal from the noise reveals which standards are documented and which are folklore, which reference materials are current, and which are outdated, and how fragile the arrangement of institutional knowledge actually is. It exposes the work that separates knowledge from content. The work of curating the clauses that represent your standard is probably done - what makes this robust is to pile in thoughtful versions of negotiated alternatives that demonstrate a range of acceptable options. What makes it crap is including all of the contracts that you’ve ever approved, even though some of them were edge cases or mistakes that you got away with. It happens.

Interface

The interface works both directions. On the input side, the reviewing lawyer needs to provide context about this specific contract: the counterparty history, the risk tolerance for this project, the negotiation strategy, whether there are relationship considerations that change what’s acceptable. The interface documents are example templates of that information and how it should be collected, think of input forms or checklists that you used to fill out. On the output side, the lawyer sees flagged deviations ranked by risk, each shown alongside the standard language it deviates from, with relevant context from prior negotiations and in a template that feels familiar to everyone on the team. This is an example of how you want the results returned; do you want a contract with highlighted text output to Word, or a narrative of the issues with the original contract text followed by the corrected text? These examples give the model a structure to interface with you and a way in which to normalize the interaction across your team.

Even before AI executes any of this, the decomposition has clarified the process. The boundary between orchestrational and criterial work is visible (logic defines orchestration, knowledge and interface surface the important issues for criterial evaluation by a human). Disagreements about standards are resolved in the process of curating all of the knowledge. What the reviewer actually needs to see to make a decision is defined in the interface examples. The judgment stack improves the current workflow while building infrastructure for the next one. The work is not just an investment made for future AI use. It pays off now.

This sounds like too much work

Yeah, it kind of is - but the alternative is just turning your business over to AI and hoping that your firm has cooler people than your competitors, because your work will be generic. That might work in your case, but I’ve never been able to rely on being cooler than anyone.

The good news is that what you’ll find once you get started is that a lot of your work uses similar logic, knowledge, and interfaces. Each domain you build makes the next one easier, because the decomposition process is itself a learnable discipline. The people doing the encoding get better at identifying boundaries, writing logic, assembling knowledge, designing interfaces. Your firm develops an organizational competence in making its own judgment explicit, and that competence applies to every subsequent domain.

Domains start to reference each other. The risk tolerances encoded in your contract review knowledge become available when your project scoping logic needs to assess contractual constraints on a new engagement. The design standards assembled for one building system provide context when another system’s logic needs to coordinate with it. Each new domain added to the judgment stack increases the value of every domain already there.

You can start building this today. The tools exist to do this at a small scale in a way that creates usable content for the larger scale. As on March 2026, I suggest using a product like Claude to start with. Set up a project, use the skills function to build out your logic, and use the files to upload knowledge and interface examples. New products are coming out all the time, so that recommendation might not last long; but the point is that you can start small and start in a commercially available platform. This gets cumbersome at scale, but it’s a great place to start. Once you outgrow that, you’ll need to build out enterprise quality agents (or move to a platform company) that work across your data at scale. This is a bigger step, but if you have a solid judgment stack organized at a small scale then it’ll be much easier to migrate to the enterprise scale. The work is reusable.

The firms that build their judgment stack operate on a different production model than the firms that don’t. What that separation means competitively is a longer conversation. But the work of making your judgment explicit is valuable regardless of what AI does next, because the discipline of knowing how your firm actually reasons is worth having whether or not a machine ever acts on it.