The acceptance and approval chains

OTB Works has two separate “who signs off on this, in what order” mechanisms. They’re built on the same underlying idea and configured the same way by an administrator, but they answer different questions and you’ll meet them in different places. It’s worth being clear which one you’re looking at.

The acceptance chain answers: is this deliverable actually done? You meet it in Prove → Acceptance.
The change-approval chain answers: does this proposed change to the plan need to be reviewed, and by whom? You meet it in Deliver → Changes, every time you save a sitting.

Both are configurable per instance, an administrator decides how many stages there are, their order, and who may sign each one, but neither is optional in outline: every instance ships with at least one stage in each, and some rules underneath both are fixed no matter how they’re configured (see below).

The acceptance chain

Every deliverable has its own definition of done, free text, agreed up front, that the person accepting it is actually signing against. Nothing can be signed off until this is written.

A deliverable then walks an ordered chain of sign-off stages. The version shipped by default on a new instance has three:

Definition agreed: the customer signs that they agree what “done” means, before the work starts. Required.
Internal QA: an optional internal tick, typically by the workstream lead. Not required by default.
Customer acceptance: the customer’s final sign-off once the work is actually delivered. Required.

An administrator can change how many stages there are, their order, who signs each (a named role, scoped programme-wide or to reach, or a specific named list of people), and whether each is required, see the administrator guide.

What you’ll see on the deliverable’s own acceptance page

A visual track of every stage: done stages show who signed and when, the current stage shows who’s eligible to sign it right now, and anything not yet reached shows as not-yet-reached. If a stage has nobody currently eligible to sign it, nobody holds the required role yet, say, the product tells you that plainly rather than leaving the stage looking stuck for no visible reason.

Segregation of duties: you can’t sign off your own work

Whoever did the work on a deliverable does not, by default, get to sign off that same deliverable’s stages. If you were an assignee on it and you try to sign, the page tells you directly: “You did the work on this deliverable, so you cannot sign this stage.” An administrator can turn this off for a specific stage (allow_self_sign), but the default everywhere is off.

Delegated signing does not get round this. If someone signs “on behalf of” someone else, the segregation check looks at both names, the person actually signing, and whoever they’re signing for. You’ll always see both names on a delegated signature, worded plainly (for example, “Grace signed on behalf of James”), never just one name standing in as if they’d signed it personally.

If the definition of done changes after a stage was signed

Each signed stage keeps a snapshot of the exact definition-of-done text as it stood the moment it was signed. If that text changes afterwards, any stage signed against the old wording is marked stale, including everything chained after it, so a sign-off can never silently keep applying to a definition of done nobody actually agreed to.

What “fully accepted” unlocks

Once every required stage is signed and current, the deliverable reads as accepted. This matters beyond the Prove screen itself: a benefit’s realised status is capped below “fully realised” until every deliverable it depends on has reached this point.

The change-approval chain

Every time you save a sitting, it’s checked against your instance’s change-approval chain to work out which stages of approval it actually needs. The base case, the one every instance ships with, is a single, unconditional stage: a Reviewer approves it. Nothing more elaborate is required unless your instance has configured extra, conditional stages.

Conditional stages

An administrator can add stages that only join a given sitting’s requirements when a specific, measurable thing is true about it, never a vague or freeform condition. The fixed list a stage can be conditioned on:

a date slipping by more than a set number of days,
effort changing by more than a set percentage or number of days,
the equivalent cost impact exceeding a percentage or amount,
any scope change,
touching something that’s already part of the active baseline,
touching a deliverable that’s already been accepted, or that feeds a benefit,
any deletion,
spanning more than one workstream.

If a sitting bundles several changes, each threshold-based condition is checked against the worst single figure across everything in the sitting, never an average, and never a sum. If any one item in the sitting matches a boolean condition (a scope change, a deletion), that’s enough to trigger it.

You’re told why, before and after you save

Before you save, the Save bar shows you the real named signers your change will need once you’ve entered enough to compute it, something like “Grace Lin (workstream owner), Daniel Osei (delivery lead)”, not just a count. After you save, the same reasoning is recorded permanently against the sitting: a plain sentence like “two approvals because this slips 12 days and changes scope”, so the author and every approver read the identical explanation, and it doesn’t change retroactively if the chain’s thresholds are retuned later.

A workstream can have its own path

An instance’s change-approval chain has one default path, but a specific workstream can be given its own path that replaces the default for anything touching it , useful, for example, for a supplier-run workstream that genuinely needs a different approval route. A sitting touching more than one workstream has to satisfy the union of whatever those workstreams’ own paths (or the shared default, for any that don’t have their own) require.

What’s fixed, no matter how either chain is configured

Segregation of duties always applies, including through a delegated signature, an instance can loosen self-signing per stage, but it can never make the underlying check disappear.
You can never approve or reject your own sitting, and a reviewer can never approve only the part of a sitting they happen to reach.
Every signature and every approval is dated and attributable: who, when, and on whose behalf, if delegated.
A rejection always shows. A deliverable’s acceptance status can never quietly look “complete” if its most recent event was actually a rejection sitting unresolved underneath it.

Where to go next

A sitting and reach, the mechanisms the change-approval chain is built on top of.
The administrator guide for how to actually configure either chain.
The Prove section of this guide for using the acceptance chain day to day.