Deployment as the Primary Artifact

Imagine two proposals arriving on the same desk. Both carry the same price, both name the same team, and both use confident language about delivering value for a customer's AI work. Read quickly, they seem interchangeable. Yet one may leave the customer with something real, while the other leaves a stack of slides. Before deciding which engagement deserves trust, you need a way to look past the proposal's wording and see what the work actually produces. The diagnostic used for exactly that purpose is called the document-versus-code test.

The word primary does most of the work in that question. Most engagements produce several outputs along the way, such as notes, meeting summaries, and drafts. The test does not ask about those side products. It looks at the thing the engagement was fundamentally built to deliver. Find that one artifact, then classify it as either a document or a deployment. Everything else in the engagement is supporting material for that main output.

Because the test focuses on the primary artifact rather than on the sales pitch, it cuts through presentation. A proposal can describe a deployment in impressive detail while the work it actually delivers is a set of planning documents. The artifact is what the customer is left holding at the end, so it is the right thing to inspect.

The test works because every engagement has a primary artifact, and that artifact falls into one of two categories. The engagement is the container, the primary artifact is what it delivers, and the artifact is either a document or a deployment. The test does not ask how large the engagement was, how senior its staff were, or how expensive it was. Those features can be identical for both outcomes, which is exactly why the test looks elsewhere.

Read the flowchart from top to bottom. You first locate the engagement's primary artifact and ignore the side outputs. You then ask the one question: is this artifact a document or a deployment? A deployment leads to the substantial label. A document leads to the imitative label, and the test then looks at how the document has been used rather than how well it was written.

Once you have identified the primary artifact, the classification depends on which of the two categories it belongs to. The source describes each category through its characteristics, so the sections below take each in turn.

The test becomes clearer when you trace an engagement forward through time. The source describes two firms hired to help a logistics company use AI to route its delivery requests, and asks you to watch what each firm leaves behind once the consulting period ends. The source does not spell out what either firm delivered, so the walkthrough below uses a hypothetical version to show how the test is applied.

Notice that the example never needed to judge either firm's skill or intentions. The test asked only what was delivered and whether it could still be run. The price, the team size, and the proposal's tone were set aside, since those features can match across both kinds of engagement.

Putting the two outputs next to each other makes the contrast easier to see. The comparison below lists the features the test is really looking at: whether the output can run, whether its results can be measured, and whether it remains in use after the engagement ends. Read the diagram row by row. The left column holds the forms a document commonly takes, all of which describe something without executing it. The right column lists the conditions that a deployment satisfies.

The diagram is a summary of the source's categories, so use it as a quick reference rather than a full substitute for the reasoning above. The key contrast is the last row. A document can be well written and still leave the customer with nothing operable, while a deployment keeps working after the people who built it have gone.