The words, in plain English.

Acceptance criteria

The conditions that show a requirement was built correctly, written so anyone can check them. For example: when an order would take a customer past their credit limit, the order is held and the credit manager is notified.

Assumption

Something the specification takes as true without anyone having confirmed it. It stays marked as an assumption until a person confirms it, rejects it, or asks the experts about it.

Build package

The version of the specification written for software to read: a structured file with a trace ID on every piece, the published schema it follows, the same content as readable Markdown, the full specification, and optional instructions for AI coding tools.

Build Ready

The point where a specification can be handed to a builder: no open conflicts, requirements that can be tested, someone named to own the application after it's built, and sign-off. A readiness check names anything still in the way.

Build Specification

An approved document that says what one software application must do, written before anyone builds it, plus a build package for AI coding tools. It covers the goal, the people, the rules, the data, the connected systems and how everyone will know it works.

Business rule

A rule the business follows that the software has to apply: an approval limit, a deadline, a calculation, a discount, or an exception that experienced staff handle from memory.

Change request

A proposed change to a signed-off specification. It's confirmed by the people who decide, and the sponsor when it touches the approved scope. Each confirmed change makes a new version, and after handoff each version comes with a report of what changed.

Conflict

Two answers, or two parts of a specification, that can't both be true, such as two different approval limits for the same purchase. A person who can decide settles it and records why.

Decision maker

A person who can settle disagreements in an area of the work, such as purchasing or scheduling. Conflicts in that area go to them. The Project Owner can decide any of them.

Discovery

Gathering what the people who know the work know, before anything is built: how the work flows, the rules, the exceptions, the data, and what should change.

Exception

An open item the Project Owner accepts for this release instead of settling it now. The Project Owner gives a written reason, and the exception is recorded with their name, title and date and printed with the specification.

Expert

Someone invited to answer questions about their part of the work. An expert can also be an AI agent you operate that knows your systems. Experts answer; only people decide, approve or sign off.

Open question

Something the specification needs that nobody has answered yet. It stays visible until someone answers it.

Readiness checks

Before sign-off, Mochlion checks the specification for gaps, contradictions and anything a builder would have to guess. Each one goes back to the right person to answer, settle, or set aside with a reason. The checks also name anything that still keeps the project from being Build Ready.

Requirement

One thing the software must do, written as a single statement that can be tested, with its own trace ID.

Sign-off

The recorded approval of the whole specification by the project's sponsor (or the Project Owner when there's no sponsor), with their typed name. Any item not yet approved needs a written reason, which is printed with the specification.

Test condition

A specific case a tester checks for a requirement, such as an order exactly at the credit limit, or a delivery requested outside the delivery window.

Trace ID

A short identifier on every item in a specification, so anyone, or any AI tool, can refer to it, see where it came from, and trace it through to its tests.

More in questions about specifying software, or see the terms in use in the sample specification.