SCP approach / Synthetic worked example
Customer Promise Protection: from problem to acceptance evidence
A fictional example connecting analysis, requirements, Gherkin acceptance criteria and UAT planning.
One operating question
Which customer orders need attention, what response is feasible, and who may authorise it? Fictional Northbridge uses twelve selected orders to examine shared stock, inbound supply, quality holds and delivery events.
Apply the SCP approach
- Define: agree the order population, frozen delivery promise, owners and acceptance criteria. Output: scoped problem and initial requirements. Decision: is the boundary measurable?
- Understand: map the order-to-delivery process and validate stock, receipts and timestamps. Output: baseline and data gaps. Decision: is the information usable?
- Diagnose: examine shortages with allocation analysis, Pareto analysis and fishbone hypotheses. Output: evidence-supported causes and risks. Decision: which causes merit action?
- Design: compare recovery options; describe user stories, use cases and Gherkin criteria. Output: proposed workflow and test plan. Decision: is a controlled trial justified?
- Test, prove and embed: run reference checks, then plan integration tests and business-user UAT. Output: test evidence, defects and remaining risks. Decision: do authorised owners accept the change?
- Sustain and improve: monitor data freshness, event misses, service and full costs. Output: owned control plan. Decision: continue, refine or stop?
What the synthetic analysis reveals
The initial queue contains six orders: SO003, SO002, SO005, SO007, SO009 and SO012. Four physical recoveries are illustrated. SO005 has no qualified alternative; SO012 needs a timestamp correction, which earns no physical-recovery benefit. A later carrier event puts SO008 at risk, demonstrating why a snapshot alone is insufficient.
User stories and acceptance criteria in Gherkin
Open each Feature below. Eight stories contain 24 Given/When/Then acceptance scenarios, including exceptions and permission boundaries.
US-01: Recognise order risk
# SYNTHETIC DATA AND FICTIONAL CLIENT. No client UAT sign-off.
Feature: US-01 Recognise order risk
As a planner
I want to see order risk with its supporting evidence
So that I can act on the right shortages
Scenario: AC-01 Allocate shared stock once
Given SO001 needs 50 units of A and SO002 needs 40 on 7 October
And usable A stock is 60 and the inbound receipt is 9 October
When the planning snapshot is assessed
Then SO001 is covered and SO002 is 30 units short
And the same stock is not allocated twice
Scenario: AC-02 Include a receipt on the material need date
Given SO004 needs 60 units of C on 7 October
And usable stock is 10 and 50 inbound units are confirmed for 7 October
When the planning snapshot is assessed
Then SO004 is covered
Scenario: AC-03 Exclude quality-held stock
Given SO009 needs 50 units of H on 12 October
And usable H stock is 10 and blocked H stock is 40
And the inbound receipt is 13 October
When the planning snapshot is assessed
Then SO009 is 40 units short
And the blocked stock remains unavailableUS-02: Prioritise the exception queue
# SYNTHETIC DATA AND FICTIONAL CLIENT. No client UAT sign-off.
Feature: US-02 Prioritise the exception queue
As a operations lead
I want to review exceptions using an agreed allocation policy
So that I can protect earlier commitments without arbitrary scores
Scenario: AC-04 Use a stable priority sequence
Given the twelve-order synthetic snapshot has been assessed
When the review queue is sorted by material need date then customer tier then order ID
Then the order sequence is SO003, SO002, SO005, SO007, SO009, SO012US-03: Validate supply information
# SYNTHETIC DATA AND FICTIONAL CLIENT. No client UAT sign-off.
Feature: US-03 Validate supply information
As a planner
I want to identify missing or stale confirmations
So that I can avoid acting on unreliable coverage
Scenario: AC-05 Show missing information explicitly
Given item B has 80 inbound units but no receipt date
When SO003 is assessed
Then its state is "Missing input"
And its shortage quantity is unknown rather than zero
Scenario: AC-06 Accept the freshness boundary
Given a supply confirmation was updated exactly 24 hours before the assessment
When freshness is assessed using the agreed 24-hour threshold
Then the confirmation is current
Scenario: AC-07 Flag information beyond the freshness boundary
Given a supply confirmation was updated 24 hours and 1 second before the assessment
When freshness is assessed using the agreed 24-hour threshold
Then the confirmation is stale
Scenario: AC-08 Correct a stale confirmation without claiming a recovery
Given SO012 initially appears 60 units short
And its item K confirmation is stale
When the planner verifies and records receipt on 13 October with a current timestamp
Then SO012 is covered
And the correction earns no physical recovery or financial saving creditUS-04: Approve proportionate recovery actions
# SYNTHETIC DATA AND FICTIONAL CLIENT. No client UAT sign-off.
Feature: US-04 Approve proportionate recovery actions
As a operations manager
I want to review feasible recovery proposals within my delegated authority
So that I can protect service while controlling spend
Scenario: AC-09 Prevent a planner from authorising spend
Given a planner proposes a GBP 300 recovery
When the planner requests execution
Then the result is "Approval required"
And no execution is recorded
Scenario: AC-10 Require recorded approval
Given an operations manager has authority for a GBP 300 recovery
When execution is requested without recorded approval
Then the result is "Approval required"
Scenario: AC-11 Respect the delegated spending boundary
Given an operations manager may approve a recovery costing up to GBP 500
When a GBP 500.01 recovery is requested with that manager approval
Then the result is "Approval required"
And Finance approval is needed under the synthetic policy
Scenario: AC-12 Record an approved action only once
Given a current GBP 300 action is approved by an operations manager
And its action key is REC-SO002
When the same approved action is submitted twice
Then one simulation action and one audit entry exist
And the second result is "Already recorded"US-05: Protect quality and the original promise
# SYNTHETIC DATA AND FICTIONAL CLIENT. No client UAT sign-off.
Feature: US-05 Protect quality and the original promise
As a customer service lead
I want to preserve quality controls and original customer commitments
So that I can report service honestly
Scenario: AC-13 Reject an action involving a held lot
Given a recovery has spend approval but the proposed lot remains on quality hold
When execution is requested
Then the result is "Quality hold"
And no execution is recorded
Scenario: AC-14 Allow a separately qualified alternative
Given a separate alternative lot has completed quality approval
And a current GBP 320 recovery has recorded spending approval
When an authorised operations manager requests execution
Then the result is "Recorded in simulation"
And the original blocked stock remains held
Scenario: AC-15 Keep the frozen promise for performance measurement
Given SO005 has a frozen promise of 10 October and actual receipt of 14 October
When customer service communicates a revised date of 14 October
Then SO005 remains late against the frozen promiseUS-06: Respond to new transport information
# SYNTHETIC DATA AND FICTIONAL CLIENT. No client UAT sign-off.
Feature: US-06 Respond to new transport information
As a planner
I want to refresh risk when new shipment events arrive
So that I can act on threats that were not known at the first snapshot
Scenario: AC-16 Detect a later carrier delay
Given SO008 was covered by an inbound receipt on 9 October
And a carrier event received on 7 October changes that receipt to 14 October
When the new event is accepted and risk is reassessed
Then SO008 becomes 30 units short
And its frozen customer promise remains 11 October
Scenario: AC-17 Ignore a repeated event identifier
Given carrier event EVT-G-01 has already been accepted
When EVT-G-01 is received again
Then the result is "Duplicate ignored"
And the planning version does not increase againUS-07: Retain an evidence trail
# SYNTHETIC DATA AND FICTIONAL CLIENT. No client UAT sign-off.
Feature: US-07 Retain an evidence trail
As a pilot sponsor
I want to trace decisions to data, approvals and outcomes
So that I can review the change before authorising rollout
Scenario: AC-18 Record a decision audit trail
Given a current recovery with recorded approval is accepted in the simulation
When the action record is inspected
Then it includes actor, time, action, reason, cost, approval, evidence and planning version
Scenario: AC-19 Block action on unvalidated information
Given a recovery has spending approval but its supporting data is not current
When execution is requested
Then the result is "Data validation required"
And no execution is recorded
Scenario: AC-24 Revalidate after a planning version change
Given a recovery was assessed against planning version 1
And a new event has changed the current version to 2
When the version 1 recovery is submitted
Then the result is "Revalidation required"
And no execution is recordedUS-08: Measure outcomes and full costs
# SYNTHETIC DATA AND FICTIONAL CLIENT. No client UAT sign-off.
Feature: US-08 Measure outcomes and full costs
As a finance reviewer
I want to reconcile service and financial results without double counting
So that I can make an evidence-based investment decision
Scenario: AC-20 Require delivery in full as well as on time
Given an order for 50 units arrives by its frozen promise but only 49 units are received
When OTIF is calculated
Then the order does not count as OTIF
Scenario: AC-21 Keep the complete eligible cohort
Given the synthetic live pilot contains 120 eligible orders of which 108 are OTIF
When the pilot service result is calculated
Then the denominator is 120 and OTIF is 90 percent
And the denominator is not restricted to alerts or successful recoveries
Scenario: AC-22 Reconcile freight and programme costs once
Given the synthetic comparison-adjusted gross freight benefit is GBP 720
And additional inspection costs GBP 80
And economic programme costs are GBP 9400 and cash programme costs are GBP 7600
When the pilot business case is calculated
Then operating benefit before programme costs is GBP 640
And net economic result is minus GBP 8760
And net cash result is minus GBP 6960
And the GBP 820 detailed recovery freight is not deducted a second time
Scenario: AC-23 Avoid a saving claim for an uncommitted proposal
Given an unqualified GBP 1800 proposal is rejected
And no approved baseline expenditure exists for that proposal
When benefits are assessed
Then the rejected proposal contributes zero savingReference checks and UAT are separate
24 Python reference assertions pass. They exercise selected rules in an in-memory illustration. The Gherkin files have not been executed through Cucumber. Live integration, security, performance and business-user acceptance remain unproven.
All 24 client UAT cases: Not run. The execution template leaves actual results, evidence, defects and sign-off blank. Users must run the agreed scenarios in the client environment and record their outcomes before an acceptance decision.
Example trace: CPP-01 → US-03 → AC-06 (exactly 24 hours remains current) → UAT-06 → reference check → boundary defect demonstration → corrected reference check. Client acceptance is still absent.
Benefits must include the full costs
The synthetic cohort illustration shows GBP 720 gross benefit, less GBP 80 inspection cost: GBP 640 operating benefit. Including GBP 9,400 economic programme costs gives a GBP 8,760 net loss; the cash result is a GBP 6,960 loss. These are illustrative short-period results, not a forecast or client return.
Do not count a timestamp correction as a recovered order, an uncommitted rejected proposal as a saving, or order value as protected profit. Agree the assumptions, comparison cohorts and double-counting controls with each client.
Business analysis / Requirements structure
Connect the business outcome to the detail
Grouping requirements helps a team see why a change matters, manage its scope and retain the links from a business need through to acceptance. We would agree a proportionate structure with the client, using stable IDs and clear ownership.
- Business outcome: the measurable improvement sought, with its baseline, scope and sponsor.
- Epic: a substantial body of related work supporting that outcome. Agree its boundary and success measures.
- Feature: a coherent capability within the epic, small enough to assess and plan. Define what it enables and its dependencies.
- Detailed requirements: specify the needed behaviour, rules, data and quality constraints. User stories can express a user's goal and reason; use cases describe interactions, alternative paths and exceptions.
- Acceptance criteria: define the specific, testable conditions each requirement must satisfy, expressed as Gherkin Given/When/Then scenarios where appropriate.
Linked underneath: testing and UAT evidence
Acceptance criteria → linked test cases → recorded results and defects → authorised acceptance decision. Retain the criterion version, test environment, tester and evidence so the team can see what was proved and what remains unresolved. The criteria define what must be met; testing and UAT evidence record whether it was met.
User stories and use cases are complementary ways to describe requirements. A use case may support several stories; it does not have to be a child work item. Security, accessibility, data freshness and performance requirements may apply across several features and should be linked wherever they need verification. Tasks describe the work to deliver the change.
A Customer Promise Protection example
Synthetic example — proposed SCP grouping, not a client implementation.
- Outcome CPP-01: improve fulfilment against the frozen customer promise, assessed alongside full operating costs. Targets would be agreed with each client.
- Epic EP-CPP-01: Customer Promise Protection.
- Feature FE-CPP-01: recognise and prioritise order risk. Groups US-01, US-02 and US-03 in the worked example.
- Story US-03: enable a planner to validate supply information before acting. Linked use case UC-CPP-01 describes reviewing an exception, checking freshness and requesting a correction when needed.
- Criterion AC-06: Given supply information is exactly 24 hours old, When freshness is assessed, Then it remains current under the synthetic rule.
Linked evidence for AC-06
AC-06 → UAT-06 → actual result, supporting evidence and any defect → authorised acceptance decision. UAT-06 remains Not run. The separate Python reference check passes; it does not constitute client UAT or acceptance.
The other proposed features group controlled recovery (US-04, US-05), event handling and audit (US-06, US-07), and benefits measurement (US-08). Keep the tested version of each criterion and the evidence together when a requirement changes.
Manage the structure without losing the links
- Record an ID, parent or related item, owner, source, priority, status and version. Link dependencies and cross-cutting requirements explicitly.
- Prioritise features by value, risk and dependencies, then refine the detailed requirements with users. Assess changes against scope, tests and expected benefits.
- Use Define to establish the outcome and initial groups; refine them through Understand and Design; verify them in Test, prove and embed; monitor the outcome in Sustain and improve.
- Apply this to Control Tower workflows, automation readiness and other services where process or system changes require clear requirements and acceptance.
Tool mapping: Azure Boards provides Epic and Feature levels above requirement-level items; the item name depends on the chosen process. Jira commonly groups stories under epics, so a separate Feature level needs an agreed mapping or suitable configuration. Confluence can hold linked use cases, process descriptions and decision records. Agree the structure around the client's tools rather than assuming the same hierarchy everywhere.
References: Microsoft: organise features and epics; Microsoft: work item types; Atlassian: epics and stories. Source guidance reviewed 17 October 2026; the grouping and example above are SCP proposals.
Keep the evidence connected
Tools to manage requirements, testing and decisions
Jira and Confluence, or Azure DevOps, can support a linked record of the problem, user stories, Gherkin acceptance criteria, tests, defects and approvals. We would agree the workflow, owners, permissions and version controls around your existing systems.
- Jira and Confluence: link delivery work items with process descriptions, requirements and decision records. Agree how test cases, execution evidence and defects will be managed, including any test-management extension.
- Azure DevOps: use Boards for delivery work and Test Plans for test cases and execution records, with links back to requirements. Documentation can sit in a wiki or your agreed knowledge repository.
- Across either option: retain stable IDs, named owners, the version tested, evidence and an authorised acceptance decision. Tool configuration and appropriate access are part of the design.
These are alternative ways to organise delivery. The tools preserve links; business users still need to perform UAT and an authorised owner must decide acceptance.
Atlassian: using Jira and Confluence together · Microsoft: Azure DevOps and Test Plans
Use the example in a discovery discussion
The example connects synthetic records, requirements, acceptance criteria and UAT planning on this page. Agree client-specific rules, permissions, evidence and costs before a pilot.
Gherkin reference: Cucumber. Acceptance-testing reference: ISTQB Acceptance Testing syllabus (2019).