Explicit Routes Need Explicit Contracts

artifact validation fail-closed behavior lifecycle state route contracts workflow governance Jun 21, 2026

Shortcut routes can make governed workflows easier to operate, but they are risky when the route name hides which stages, audits, and artifacts actually exist. A reduced path still needs a complete contract.

Opening

Shortcut paths are useful until they become ambiguous.

In a governed workflow, a route name is not just a label. It can decide where work starts, which gates remain, which artifacts are produced, and what validation expects later. If that route means different things in different parts of the system, the workflow can look flexible while quietly becoming contradictory.

Problem

The surface issue was a vague route name. It sounded like a naming problem.

The real issue was deeper: the same route was carrying multiple lifecycle meanings. One part of the system treated it as a shorter path through planning. Another treated it as a different audit sequence. Another still expected artifacts that the shortened path might never create.

That is the danger with ambiguous shortcuts. They do not just confuse readers. They can let dispatch, validation, documentation, fixtures, and tests drift apart.

Story / example

The better pattern was not to rehabilitate the vague name. It was to replace it with explicit routes.

Instead of one generic shortcut, the workflow needed names that described the actual lifecycle:

Route Lifecycle
full path Spec -> Spec Audit -> Plan -> Plan Audit -> Build -> Build Audit -> Verify
spec path Spec -> Spec Audit -> Build -> Build Audit -> Verify
plan path Plan -> Plan Audit -> Build -> Build Audit -> Verify
direct path Build -> Verify

Now each route has one meaning.

The important shift is not the wording. It is the contract behind the wording. Each route needs to define:

  • the first dispatch point
  • the stages that run
  • the audits that remain
  • the artifacts that must exist
  • the validators that apply
  • the next legal transition
  • the behavior for retired or invalid route values

Gate posture is part of the route contract

The most important route details are often the ones a shortcut makes easy to misread.

A path that skips planning does not automatically skip design approval. If the route still produces a design-bearing artifact, then the workflow still needs a clear design acceptance rule before build work can proceed. "No Plan" is not the same thing as "no design gate."

That distinction matters because durable stage position and dispatch authorization are different claims. A workflow can be positioned at Build as the next stage while Build dispatch remains blocked until the required gate has been accepted or explicitly overridden. In that model, Build is a guarded waypoint, not permission to start building.

So the route contract should say more than which stages appear in the happy path. It should also define:

  • which artifacts create approval obligations
  • which gates apply even when an adjacent stage is omitted
  • which source files are required before dispatch
  • whether the current stage is a position marker or an execution authorization
  • how stale states fail when the gate posture changes

This is where shortcut routes become product architecture. A route that skips a stage may still carry the risk that stage used to control.

Lesson

A reduced path still needs a full contract.

If a route skips a stage, downstream validation must know that. If a route keeps an audit, the transition graph must not bypass it. If a route still creates a design artifact, the design gate must remain explicit. If an old route name is retired, it should fail closed with a clear migration message instead of silently mapping to a surviving path.

The lifecycle contract and the artifact contract have to change together. Otherwise the system can send work down a path that cannot later prove what validators require.

Broader implication

This applies beyond software delivery workflows.

Any operating system with named paths, fast tracks, approval modes, service tiers, escalation routes, or exception handling can develop the same failure mode. A friendly shortcut becomes dangerous when it hides what was omitted.

The fix is to make reductions explicit:

  • name the path by what it actually does
  • write the lifecycle matrix
  • write the artifact or evidence matrix
  • write the gate posture matrix
  • separate stage position from dispatch authorization
  • test both valid and retired states
  • make silent aliases fail

This is not bureaucracy. It is how shortcuts stay safe.

Closing

Make the path shorter if you need to. But make the contract sharper.