Every engagement begins with the same artifact. One page. Written collaboratively over the course of two to four weeks. Signed by the executive sponsor and the operating owner. Re-read at the start of every weekly check-in. It's called the constraint document, and most of the value of the Diagnose phase comes from the act of writing it together.
I've written some version of this document with every client since 2023. The format has changed over time. The function hasn't. The function is to force a leadership team to commit to a single, falsifiable framing of the work before any code is written. That sounds obvious. It is not the standard practice.
Most AI engagements begin without an artifact like this, and most of them spend the first three months discovering, expensively, that the leadership team did not agree on what they were doing.
— What it isOne page. Six fields. Hard to write, easy to refer back to.
The constraint document fits on one page. It has six fields, and each field exists because it answers a question the team will otherwise have to answer at the worst possible moment — usually three months in, when something has gone wrong and there's no shared reference to anchor the conversation.
That's the whole document. One page, six rows, three signatures. The hardness is not in the format. The hardness is that every field has to be true, and the leadership team has to agree. The first version of any constraint document is wrong, and the rewrites are where the engagement actually does its work.
— Why it worksIt exists to make disagreement visible.
The first time a leadership team tries to fill in the Outcome row, three things happen with reliability. The CEO writes one sentence. The COO writes a different sentence. The CTO writes a third sentence that is actually about a technical capability, not a business outcome. The CFO points out that none of these are measurable in the system of record. The room has just discovered that it did not, in fact, share an understanding of what the project was for.
This is the document's first job: surface disagreement at the cheapest possible moment. The disagreement is going to surface eventually. The question is whether it surfaces in week two, during a Diagnose-phase conversation that costs the team only its time — or in month seven, when an engineering team has built three months of the wrong thing and a board update is due in ten days.
The Baseline row does similar work. Most leadership teams discover, when they try to write down a measurable baseline for their stated outcome, that the number doesn't exist in any consistent form. There are three internal dashboards reporting three different versions of it. Or the metric exists, but it's reported quarterly, and the project will need it weekly. Or it exists, but only at company level when the project actually moves it at segment level.
The Constraints row is where the political work happens. Every engagement has constraints the leadership team is willing to discuss in writing and constraints they are not. The constraint document forces these into the light — "we cannot lay off the existing team," "the legal department will not approve any change that touches the EU data residency stack," "the CRO has a personal stake in the Salesforce integration and will not approve replacing it" — and once they're written, the engagement can route around them honestly. Constraints unsaid are the ones that kill projects in month six.
The first version of the document is wrong. The rewrites are where the engagement does its work.
A shared anchor that survives the engagement.
Once signed, the document becomes the anchor for everything that follows. Every weekly check-in begins by re-reading it aloud. Every scope change conversation starts with: "Does this still serve the Outcome row?" Every dispute between sub-teams routes back to the Constraints row. Every conversation about whether to continue past a phase gate routes back to the Go/no-go row.
This sounds bureaucratic. It is the opposite. The document removes most of the meetings that would otherwise be required to maintain alignment, because the alignment is preserved in writing. Weekly check-ins run for thirty minutes, not ninety, because nobody is re-litigating what the project is for. Scope changes are decided in the room rather than escalated upward, because the framework for deciding them is already signed.
The second-order effect matters more. The constraint document survives the engagement. When we leave, the document stays. The next person who tries to extend or replace the work has a one-page artifact that tells them exactly what was being attempted, what was achieved, and what was deliberately left alone. The institutional memory survives the consultant.
— When not to use itThis is not always the right tool.
The constraint document works when the work has a definable business outcome. It does not work, and should not be forced, in a few situations.
If the engagement is genuinely exploratory — the company doesn't yet know what AI could do for them and wants a structured exploration — the constraint document is premature. The right tool there is a research engagement: two to four weeks, broader brief, output is a prioritised list of plausible outcomes, each of which would then get its own constraint document if it advances to a proper engagement.
If the engagement is genuinely greenfield — a new product, a new business line, a new venture — the constraint document is too narrow. New ventures have to evolve their outcome definition through contact with customers. Locking in a target metric before launch is the wrong instinct. A different artifact is right there: a north-star metric, a set of leading indicators, and a quarterly re-write of the strategic thesis.
If the engagement is platform or infrastructure work, where the business outcome is real but indirect — building shared model infrastructure to serve five future use cases, say — the constraint document needs adaptation. The Outcome row becomes a capability statement; the Baseline becomes a current-state architectural assessment; the Target becomes capability checklist. The discipline of the document still applies. The specifics of the format do not.
The frame, not the form.
What ultimately matters is not the document itself. It is the frame the document enforces. The frame is: agree on the outcome before the work, name the owner, name the constraints, name the failure condition. Whether this lives on one page or in a Notion doc or scribbled on a whiteboard in someone's office is irrelevant. What matters is that it lives somewhere, that the leadership team has committed to it together, and that it gets re-read before every decision the engagement is about to make.
Most engagements that fail did not fail at the model. They failed at this frame. The constraint document is the cheapest, most boring, most consequential artifact in any AI advisory engagement — and it is the one thing I have not seen a successful engagement skip.