The First Artifact Has No Readiness Gate

Count the gates

Anthropic published a playbook for the AI-native software lifecycle. Six stages. Plan, design, build, test, deploy, maintain. The first stage opens with a file: intent.md, drafted with Claude from the originator's idea, corrected by the originator, and accepted by a product owner before design begins.

Now count the controls after it. Plan mode reads the codebase without editing until an engineer approves a plan. Hooks allow, ask, or block. Tests run and screenshots get taken before an engineer sees the diff. Branch protection records code-owner approval. Production deploys require named release authorization. Some controls are automated and some still require judgment, but each declares a condition and records whether it was met.

Go back to the first artifact. The playbook gives it human review, but no readiness floor beneath the reviewer's judgment. Human approval is a gate. It is not a repeatable check on whether the file names an actor, an observable outcome, a hard boundary, a failure mode, and a way to verify the result. It is a person, on a Thursday, with a dozen tabs open, reading a paragraph that sounds fine.

That is not an oversight. The playbook is honest about what the file is: "a proto-spec in the originator's own terms." Which is exactly right, and exactly the problem.

Every control downstream can then work exactly as designed against whatever that paragraph said.

I built the check, and it rejected everything

I had the same idea earlier this summer and got it wrong first.

The plan was to answer one question without a model: is this intent ready to hand to an agent? Six rules. A specific objective. A focused title. Observable outcomes. At least one hard constraint. An edge case with defined behavior. One verification step. Pure functions over the spec, fast enough to run on every keystroke.

Then I tested the objective rule. Against 14 real specs it accepted 4. On the labeled benchmark: 0 of 13 valid examples accepted, 11 of 11 deliberately vague ones rejected. That second number looks like success until you notice that a function that always returns false scores identically. The rule had no discriminating power. It was measuring nothing.

The cause was my own narrow taste dressed up as logic. The rule wanted an actor from a short list and a word that described failure. So this passed:

Users can't complete checkout when the payment step times out.

And this failed:

Let curators reorder a collection and publish it without re-uploading any assets.

Curators weren't on the list. Let wasn't a failure. The sentence names a person, a capability, and a boundary, and my gate couldn't see any of it. I had encoded my own writing style and called it meaning.

Fixing that took the 14 real specs, a 98-item labeled corpus, and a rewrite of the semantic rules to accept more ways intent gets expressed. An objective can name a failure or a capability. An actor can be a role, a name, or implied by the sentence. An outcome can carry a number, a relative change, an observable capability, or a concrete state. A number stuck to a feeling is still not measurable, so "100% delighted" still fails, and should.

The gate got useful when I stopped trusting its preferred phrasing over the meaning it was supposed to recognize.

A verdict nobody can see is not a gate either

Having a working check turned out to be half the problem.

A deterministic verdict is worth something only if the next reader gets it without doing any work. Mine lived in the app. You opened Pathmode, you saw the ledger. Which means the agent reading intent.md in your repo saw nothing, and neither did the reviewer skimming the file in a pull request. The check existed and the file stayed silent about it.

So the verdict now travels inside the file. Every save through Pathmode's MCP server recomputes it and stamps it into the frontmatter:

---
id: "intent_abc123"
version: 3
status: "approved"
readiness: "passed 6/6"
source: "https://pathmode.io/intent/intent_abc123"
evidence: 4
---

Three lines matter there. readiness is the verdict, recomputed on every MCP write, and it names the failing checks when it fails: failed 4/6 — blocking: edge-cases, verification. source says this file is a working copy of a record that outlives it. evidence counts what backs the spec, where zero is a legitimate answer and a visible one.

You can check this yourself, which is the point. The Claude Code plugin bundles @pathmode/mcp-server, runs the preflight with no API key, and keeps the spec on your machine:

/plugin marketplace add pathmodeio/claude-plugin
/plugin install pathmode@pathmode

Then ask Claude Code to run a preflight. You can also inspect the gate in the live example at preflight.pathmode.io. The browser and Pathmode app use the canonical implementation; the MCP server carries a port, and a parity test fails our build if the two ever disagree. Run the check twice on an unchanged file and you get the same answer. That reproducibility is what makes the verdict useful evidence rather than another opinion.

What has to be in the file

intent.md is likely to become a common filename now. Anthropic named it, other tools may adopt it, and the name will end up meaning whatever the first thousand files that carry it happen to contain.

So we wrote down what we think has to be in one, as a conformance profile with three levels.

Level 0 parses. Frontmatter with id, version, status. A machine can read it, identify it, and tell whether it changed. Says nothing about quality.

Level 1 is buildable. Passes the six checks and carries the verdict. An agent reading it is not left to invent a missing objective, outcome, constraint, edge case, or verification step. This is the level that matters for handoff, and a hand-authored file with no tooling behind it can reach it.

Level 2 is accountable. Adds source and evidence. A Level 1 file tells you it is clear. A Level 2 file lets you ask why anyone believed it, and find the answer somewhere other than the author's memory.

One rule sits under all of it: a failing verdict never blocks the save. Write the file, commit it, even ship it if you choose, with failed 3/6 sitting in the frontmatter where everyone can see the risk. A check that stops people from saving their own draft gets deleted inside a week, and then there is no floor at all. The preflight reports. The person decides.

Name one source of truth

The playbook is ahead of me here. It already says to name one system as the authoritative record for each artifact and have everything else hold a copy or a link to it, and it describes the markdown files as "working copies" when the record lives elsewhere.

Then it lists the candidates. The repo, if engineering leads. Jira, ServiceNow, or whichever requirements tool already owns the process.

Read that list with product intent in mind. A repo scopes the record to one codebase and ends it when the branch is deleted. A ticket scopes it to one delivery unit and buries the reasoning in comment threads nobody opens twice. Both are reasonable homes for a plan. Neither was built to hold the decision itself, the evidence under it, and the alternatives it ruled out.

The mechanic is right, and the source line above is me following it. What the list is missing is a system whose job is holding the judgment.

What the check cannot do

The rules look for document-level signals: a recognizable actor, an observable outcome, a concrete constraint, an edge case with defined behavior, a verification step. Those are properties of the text, so a function can check for them consistently.

It cannot tell you that you named the right actor. It can recognize an observable outcome, but not decide whether that outcome is worth pursuing. It can count evidence links, but not establish that the evidence supports the objective, represents the users who matter, or outweighs the evidence pointing somewhere else. Presence is not grounding.

Which means a file can pass 6/6 and still be a bad idea, precisely specified. If the objective came from an executive hunch while the support queue points elsewhere, thresholds and edge cases only make the hunch easier for an agent to execute at speed.

Anthropic's security team draws the same line from the other side. Writing about an SDLC where AI authors most of the merged code, their deputy CISO divides the work three ways: deterministic checks for what a machine can prove, narrowly scoped AI reviewers for reasoning that crosses components, and humans for "directing, setting intent, and owning final approval."

Setting intent sits on the human side of that line. A machine can check that a spec has its parts. It cannot own what the spec commits you to.

That boundary is what makes the check useful. It answers the narrow question a deterministic rule can answer: does this spec have enough shape to build against? Whether the work deserves to exist remains a judgment. It belongs to a person, and no amount of frontmatter transfers it.

The cheapest gate you will add

Anthropic's playbook is right about the shape of all of this. Code stopped being the bottleneck, so the constraint moved upstream into planning and review, and the artifacts have to be machine-readable for any of it to work. The audit trail they describe, intent to spec to plan to diff to review findings, is the correct thing to want.

An audit trail is only as good as its first entry.

The preflight itself costs nothing to run and takes about a minute to act on. It is the earliest control in the chain, and it determines what every later control inherits.

Count the gates in your own pipeline. Then look at what is guarding the file they all inherit from.