Mechanics 1 of 8 · 2 min read
Describe What Should Be True
A specification gives people and systems a shared outcome to work toward.
Part of our current product model. These essays explain responsibilities and required checks, not a certification of deployed behavior.
A person should not need to design an agent workflow to ask for a useful result. Start with the outcome: what should be true, which constraints matter, and what evidence would make the result acceptable.
That is the role of a Business Truth in this model. Axioms provides tooling for expressing it in Truth specs or Gherkin. The specification can exist before anyone undertakes to deliver it.
A small example
Consider an illustrative delivery-planning problem. The organization wants every accepted order assigned to a delivery plan within the agreed service window and available capacity.
This leaves room for several approaches. It does not prescribe which agent to call first or which route to choose. It does require clarification: which orders, whose capacity estimate, which service window, and what happens when the available information is incomplete?
Those questions belong in the specification or its supporting evidence requirements. Hiding them in a prompt makes the agreement harder to inspect.
Keep three questions separate
The desired outcome describes what should be true. The evidence requirement describes what must be demonstrated before relying on a result. Authority determines who may bind the organization.
A well-formed specification answers only part of that problem. Parsing it does not establish that the capacity exists. Passing generated tests does not show that every relevant concern was included. A simulation supplies evidence under its assumptions.
The specification and its checks can improve together as omissions become visible. Neither should be described as infallible.
Give the promise a version
A proposed revision may change a constraint or add an evidence requirement. Record that revision explicitly so different attempts can be assessed against the version they actually used.
A commitment binds the organization to a specific version of the Business Truth. Updating the specification for tomorrow does not silently change what another party relied on yesterday.
The engineering work begins with making that distinction representable and testable. It continues through reasoning, assessment, and authorization. The specification is the starting point, not a shortcut around them.