Specification as Procurement Contract

The Problem

You are outsourcing development. The vendor needs to know what to build. You write a requirements document — pages of natural language, use case diagrams, acceptance criteria in spreadsheets. The vendor interprets it. You review their interpretation. Misunderstandings surface late, during user acceptance testing or after delivery.

Disputes about scope and correctness are expensive. "That is not what we specified" meets "that is not what the document says." Both sides are right, because the document is ambiguous enough to support either reading.

This pattern repeats in government IT procurement, outsourced enterprise development, and system integrator engagements — anywhere the people who define the system and the people who build it are in different organizations.

The Approach

Write the specification in Spine. Include it in the procurement contract. The compiled Spine executable is the reference implementation. Acceptance testing is automated comparison: the vendor's deliverable against the reference.

The specification is not ambiguous because it compiles. There is no room for interpretation disputes. If a scenario is unspecified, the specification does not compile for that case — it is an explicit gap, not an implicit assumption.

The vendor does not need to learn Spine. They need to produce a system whose behavior matches the reference. They choose their own stack, tools, and architecture. The specification constrains what the system does, not how it is built.

The Outcome

• Objective acceptance — the vendor's delivery is tested against the reference executable. Pass or fail. No subjective interpretation of requirements.
• Scope clarity — the specification defines exactly what is in scope. Gaps are visible as uncompiled cases. Change requests become specification amendments — versioned, verified, and traceable.
• Reduced dispute risk — "what was specified" is answered by the specification, not by competing interpretations of a natural language document.
• Vendor independence — the specification belongs to the procuring organization. If the vendor relationship ends, the specification and reference implementation remain.

The Workflow

Requirements → Specification in Spine → Compile → Reference Executable → Include in Procurement Contract

During vendor delivery:

Vendor Delivers System → A/B Test Against Reference → Accept or Reject

When scope changes:

Change Request → Amend Specification → Re-verify → Update Reference → Formal Change Order

Why This Works

Procurement contracts fail when the definition of "done" is subjective. The reference executable makes it objective. The vendor knows what to build. The procurer knows what to test against. Both parties work from the same artifact.

The specification is also a risk management tool. Because it is verified, the procuring organization knows the requirements are internally consistent before the contract is signed. Contradictory requirements — a common source of costly change orders — are caught by the compiler, not by the vendor.

And because the specification is version-controlled and formally verified, it creates an audit trail. Every change to the requirements is a diff in the specification. Every acceptance decision is a comparison against a deterministic reference. This is the level of traceability that high-stakes procurement demands but rarely achieves.