A Label Is Not a Requirement

Software teams use labels as compression. Say dashboard and people imagine charts, filters, permissions, refresh behavior, and a dozen conventions they have seen before. That compression is useful in conversation because people can notice when their pictures disagree. They ask a question, point at a sketch, or change the subject until somebody makes the decision. The label starts the discussion. It does not finish the specification.

An agent does not share the room's unspoken picture. Give it the label and it will still produce something convincing. That is the dangerous part. The result will contain sensible defaults, tidy behavior, and choices nobody authorized. Because the output looks familiar, those invented decisions arrive disguised as implementation detail. Your factory did not automate the product decision. It silently delegated it to the next model call.

A requirement becomes usable when it names an observable consequence. Who is trying to do what? What must remain true before and after they do it? Which boundary cannot be crossed? What should happen when the happy path breaks? A label can suggest the shape of a solution. Only those decisions tell the factory which solution is yours.

This does not demand a giant document. More prose can create more hiding places for ambiguity. A short decision can be strong: an operator may retry a failed action without creating a second result. That sentence gives the builder a boundary and gives the verifier something to attack. Build a retry-safe flow is weaker, even though it sounds technical, because the word safe has not chosen what failure means.

Make the distinction mechanical. Store the label as context, not acceptance. Require each unit of work to carry an actor, an outcome, the boundaries that matter, and the evidence that will prove the outcome. If one of those is unknown, preserve the unknown. Do not let an agent convert an empty field into a plausible guess just to keep the line moving.

Teams often treat ambiguity as a writing defect. They tell someone to improve the ticket, add detail, or be clearer. That advice fails because not every unknown belongs to the same person. A product tradeoff belongs to whoever owns the customer consequence. A security boundary belongs to whoever owns the risk. A technical choice may belong inside the factory if the surrounding constraints make its consequences interchangeable.

The system needs to route each unknown to its owner. When two outcomes are both plausible and materially different, stop and ask for judgment. When several implementations satisfy the same decided outcome, let the machinery choose and record why. When a policy already settles the question, retrieve it and enforce it instead of asking a person to remember it again. The goal is not to eliminate uncertainty. It is to prevent uncertainty from changing owners without anyone noticing.

That routing rule is also how you keep humans out of repeatable work without pretending judgment disappeared. People decide consequences. Agents explore options, implement the chosen boundary, and produce the evidence. The factory becomes faster precisely because it knows which questions deserve a stop and which ones do not.

A weak verification stage checks whether the result resembles the label. The dashboard has charts. The migration moved records. The checkout accepts payment. That proves category membership, not correctness. A polished imitation can pass every one of those checks while violating the reason the work exists.

Verification must attack the consequences named before implementation. Can a person see only the information they are permitted to see? Does interrupted work resume without duplication? Does a rejected operation leave the prior state intact? The exact checks depend on the product, which is the point: generic labels produce generic tests, and generic tests certify the model's assumptions instead of the business's decisions.

Keep the evidence attached to the requirement it proves. When the requirement changes, the affected proof should become visibly stale. When a check fails, route the failure to the stage that owns the missing decision or broken implementation. A screenshot that looks right is not a substitute for that chain. It is decoration unless the decided outcome was visual.

Take one item your team currently calls ready and delete its familiar nouns. Remove dashboard, integration, refactor, migration, and every other word that arrives with a borrowed mental picture. What remains should still tell you whose world changes, what becomes possible, what must never happen, and what evidence will settle the question. If it does not, the work was never ready. The label was carrying decisions nobody made.

Then encode that test at the entrance to the factory. Reject work that offers a category without a consequence. Route real unknowns to named owners. Let agents choose freely only inside boundaries where the choice does not change the business outcome. Verify the stated meaning under conditions the builder did not select.

Our position is that agent-run delivery will punish teams that confuse shared vocabulary with shared intent. Humans have been patching that confusion with meetings and memory for years. Factories remove the patch and multiply the consequence. The winners will not write the longest requirements. They will build machinery that can tell the difference between a useful shorthand and an undecided product—and refuse to manufacture the difference on its own.