The Specification Becomes the Control Plane

Describe the trigger, the people or systems involved, the decision being made and the outcome the business needs. That creates a stable center even when implementation choices change.

Make assumptions visible. A coding agent will confidently fill silence; an accountable team identifies silence as a decision still to be made.

Inputs, validation rules, permissions, failure states, idempotency, performance and recovery belong in the specification when they determine whether the system is safe to operate.

Use concrete examples and Given–When–Then scenarios where they make the intended behavior testable while leaving room for sound design choices.

Connect every important behavior to a way of proving it: an automated check, an observable signal, a human review or a controlled business acceptance step.

The specification should let a reviewer distinguish a complete feature from a plausible-looking implementation.