PRACTICAL WORKSHOP · 50 MINUTES

Design a safe automation for pensions administration

A practical workshop, not a quiz

Choose a small repetitive task, map a safe boundary and produce an automation brief with human checks, duplicate protection, failure handling and a concrete synthetic test plan.

No quizzes, scores or assessed completion. Work on paper or in an approved blank Word document. This page does not collect or save your notes or track workshop progress.

Use fictional information only. Do not enter real member, customer or payroll data, passwords or confidential files into this course or external AI tools.

Before you begin: safety and scope

Use only the invented training fixtures provided. Do not use real member, beneficiary, employee or payroll data, National Insurance numbers, bank details, health information, credentials or confidential organisational information. Changing a name does not make real data safe. This is a design and tabletop workshop: do not connect live systems, send messages, update operational records, calculate benefits or make payments. All outputs stay in an approved training document or workspace. A Copilot subscription does not itself approve an account, tool, connector, data use or organisational deployment.

This workshop designs an administrative aid, not pension entitlement, benefit calculation or legal rules. For any real pensions service, the appropriate scheme and organisational owners must confirm applicable requirements, authority and approved operating procedures. Do not treat the fictional Harbour checks as NILGOSC standards or import requirements from another jurisdiction.

Work through the six modules in order. The suggested timings total 50 minutes; allow 40–60 minutes depending on discussion.
Read each short lesson and worked example, then complete Your task. Keep your notes in an approved blank document or on paper.
Use the fictional Harbour example throughout, or design another equally bounded task using invented data only.
Walk through the tests on paper or with an approved offline training spreadsheet. This course does not ask you to create or run a connected automation.
Optional Copilot prompts help with wording, diagrams described in text and test ideas. Use only the synthetic text supplied, review every output and skip AI if the account or data-handling approval is uncertain.
Completion means you have a brief, a control design and a test plan. There are no marks, questions to score, leaderboard or compliance certificate.
Role titles, rules, counts, retry timings and acceptance criteria below are fictional design assumptions, not organisational policy, pension rules or legal requirements.
The 50-minute core covers the six lessons and selected exercises. The full 15-case test pack, detailed run records and Copilot prompts are reference material; use them as needed or for a longer follow-on session.
Optional Copilot assistance: check your signed-in account, licence and employer’s approval. Microsoft supports some personal Premium use with work documents under administrator controls, but features vary. This course uses synthetic material only, regardless of licence. Never paste real member data or connect organisational sources for these exercises. Review outputs yourself.

Start the workshop

Harbour’s fictional submission-check report

Harbour is an invented pensions administration team used only for learning. Each week an administrator checks a small summary envelope for fictional employers Cedar and Willow, then writes a draft report for a colleague. The proposed automation reads synthetic summary fields and prepares a review report; it cannot read member records, change source data or contact anybody.

The invented current process checks 20 summary envelopes a week at 3 minutes each: 60 minutes. A proposed pilot might use 10 minutes to prepare a report plus 20 minutes of human review, saving an estimated 30 minutes; none of these times has been measured.
Each fixture contains fixtureId, employerCode, submissionId, period, declaredCount and observedCount. The counts are invented whole numbers, not records belonging to real people.
In training rule version V1, allowed employer codes are CEDAR and WILLOW; submissionId must start SUB- followed by three digits; period must be YYYY-MM with a month from 01 to 12; counts must be whole numbers from 0 to 999. Zero is permitted for this exercise only.
A well-formed envelope is MATCH when declaredCount equals observedCount and FLAGGED when they differ. MATCH proves only that two synthetic numbers agree; it does not prove real records are complete or accurate.
The proposed stable work identity is employerCode + submissionId + period. fixtureId identifies the test row, not a new business submission. Different content with the same work identity is a conflict, not permission to replace an earlier result.
The training flow produces a draft report and a synthetic run record only. A person reviews both; no status authorises a real-world action.

MODULE 1 OF 6 · 7 MINUTES

1. Choose a small task worth improving

You will: Separate repetitive administrative checking from pension decisions. Choose a useful pilot with a clear benefit and a safe stopping point.

Scenario

You are helping Harbour’s operations lead reduce time spent checking fictional employer submission summaries. A colleague suggests automating the entire intake process, including record corrections and replies. Your goal is to choose one smaller task that can help the team without making decisions or acting on anyone’s behalf.

Example

A useful first slice

Harbour compares a draft validation report with automatic record correction. The report has stable training rules, no effect on source records and a visible reviewer; correction would need authority and trustworthy source evidence the exercise does not provide. Harbour chooses the report. The invented baseline is 20 envelopes × 3 minutes = 60 minutes a week. If preparation and review together took 30 minutes, the estimated saving would be 30 minutes, subject to testing rather than a promised result.

Takeaway: Choose the smallest useful output that a person can inspect before any consequence.

Your task

List two repetitive fictional tasks and compare benefit, risk, readiness and reversibility.
Choose one task and describe the person who will use its output.
Write a before-and-after time estimate, including human review; label assumptions.
State one clear exclusion and one reason to stop or redesign the idea.

Your output: A bounded pilot choice and an honest benefit hypothesis.

Working-note template

Task and user of its output: ___
Current steps and effort: ___
Proposed benefit and assumptions: ___
Alternative considered: ___
Why this smaller task: ___
Explicit exclusion: ___
Stop or redesign if: ___

Reflect: If the pilot were switched off tomorrow, could the team continue safely without depending on it?

Read the lesson: why this matters

Start with the work, not the tool. Look for a repeated task with stable inputs, understandable rules, frequent enough demand and an output someone can check. If staff cannot agree what should happen manually, clarify the process before designing its automation.

Compare candidate tasks by benefit, risk, data readiness and reversibility. Preparing a draft missing-field report is easier to contain than correcting pension records, calculating an entitlement or issuing a payment. Keep those consequential actions outside this workshop.

Estimate the benefit honestly. Include preparation, exception handling, human review and maintenance, not only the seconds a flow takes to run. Mark unmeasured savings as hypotheses and identify how you would test them with synthetic examples.

Write a boundary before choosing a product. For Harbour, the pilot reads invented envelope fields and prepares a draft report. A manual review remains necessary, and stopping the pilot does not prevent the administrator using the documented manual check.

Sources for this module

MODULE 2 OF 6 · 8 MINUTES

2. Map the process and its decision points

You will: Define a trigger, inputs, rules, output and end point. Separate input validation from human acceptance of the output.

Scenario

You are documenting Harbour’s chosen report with the administrator who does the manual check. Two colleagues use different meanings of complete, and one assumes a matching count proves a submission is accurate. Your goal is to write a short process that removes those ambiguities without expanding the pilot.

Example

A six-step process with a clear end

For F01, the fields are CEDAR, SUB-001, 2026-04, declaredCount 12 and observedCount 12. The fields satisfy V1, the work identity is new and the counts match, so the report records MATCH and a difference of 0. F03 has counts 10 and 9; it is well formed but produces FLAGGED and a difference of 1. Neither result changes a pension record. The reviewer sees the source fixture references, rule version and run totals before deciding whether the demonstration behaved as expected.

Takeaway: Define what every output means, and what it does not mean.

Your task

Draw or write the six steps, with input, owner, action and completion evidence for each.
Copy the V1 input rules and define the difference as declaredCount minus observedCount.
Add routes for an invalid field and a count mismatch.
Write the exact label and destination of the draft output.
State what must never happen automatically after the report is produced.

Your output: A short process map and an explicit input/output contract.

Working-note template

Trigger: ___
Input fields and allowed values: ___
Step | Owner | Input | Action | Evidence
___
Rule version and result meanings: ___
Invalid-input route: ___
Draft output and location: ___
End point and next human decision: ___
Forbidden downstream actions: ___

Reflect: Could two colleagues follow your rules and produce the same result for the same synthetic input?

Read the lesson: why this matters

Map five to seven steps: select the synthetic fixture batch; validate its shape; identify repeats or conflicts; compare the two counts; assemble and reconcile a draft report; obtain human review. The trigger is a deliberate training run, not a live inbox, timer or file-arrival event.

Define the input contract: field names, allowed formats, required values and meaning. Do not silently repair a missing employer code, round a fractional count or turn an invalid month into a guessed date. Unsupported input needs a visible INVALID result and a reason.

Keep different claims separate. MATCH means the two supplied synthetic counts agree under rule V1. It does not mean the underlying records were inspected, the employer is authorised, the data is correct or a member’s pension is ready. The report is always labelled DRAFT, NOT FOR OPERATIONAL USE.

Specify where the process ends and who owns the next decision. The pilot ends with a draft report and run record in the training workspace. A reviewer may accept the demonstration, request changes or stop it. No email, case update or further flow starts as a side effect.

Sources for this module

MODULE 3 OF 6 · 8 MINUTES

3. Design access and meaningful human checks

You will: Use the minimum access needed for the bounded task. Turn confidentiality, integrity and availability into operating controls.

Scenario

You are discussing the draft design with Harbour’s service owner and an IT colleague. Someone proposes using an administrator account because it is convenient, while another suggests checking only the report’s green rows. Your goal is to specify limited access and a review that can detect a plausible but wrong result.

Example

A permission request that is small enough to review

Harbour’s draft access matrix gives the future training runner read-only access to synthetic fixtures and permission to create synthetic output files and run evidence in one restricted training folder. It has no access to live systems and no delete permission in the design. A reviewer can read both locations and record a decision through an agreed training document. The operator does not treat their own successful run as independent acceptance. Until these capabilities are verified in a chosen environment, they remain design requirements, not claims about configured access.

Takeaway: Make the access boundary and the human decision inspectable.

Your task

Write an access matrix with role, resource, allowed operation and forbidden operation.
Add one practical control each for confidentiality, integrity and availability.
Describe exactly what your reviewer checks before accepting the demonstration.
Name the stop decision and a manual fallback, including deputy cover.
List any access or governance question that a real build would still need answered.

Your output: An access matrix, three control statements and a meaningful human-review gate.

Working-note template

Role | Synthetic resource | Allowed operation | Forbidden operation
___
Confidentiality: ___
Integrity: ___
Availability: ___
Reviewer, evidence and decision: ___
Stop owner and deputy: ___
Manual fallback: ___
Unresolved approval or capability questions: ___

Reflect: If the result looks convincing but is wrong, does the reviewer have enough independent evidence to notice?

Read the lesson: why this matters

Least privilege means giving an activity only the access it needs. This design needs read access to an approved synthetic fixture location and write access to a separate training-report location. It needs no mailbox, member database, payment system, tenant-wide search or permission to modify its source. This workshop grants and changes no access.

For confidentiality, use invented data, restrict the training output to agreed reviewers and avoid copying unnecessary content into logs or AI prompts. For integrity, keep source fixtures unchanged, version the rules and record result evidence. For availability, name an owner and deputy, document a stop switch and keep the manual check usable.

A human check needs a named role, enough evidence, time to review and a clear decision. In this small pilot, the reviewer checks all fixture outcomes, duplicate and conflict entries, run counts and failure evidence against the expected test results. Reviewing only successful rows would miss the very controls the pilot must prove.

The reviewer records accept demonstration, revise or stop, with reasons. Approval of a draft is not approval to connect live systems. A later build would need the actual service, information-governance and technical owners to confirm permissions and operating arrangements. Do not invent a mandatory role, sign-off rule or retention period for a real organisation.

Sources for this module

MODULE 4 OF 6 · 10 MINUTES

4. Make repeats, failures and recovery safe

You will: Distinguish a duplicate from changed content and an uncertain outcome. Design limited retries, reconciliation and a safe recovery route.

Scenario

You are walking through what happens when Harbour’s report process is interrupted. A timeout appears after a report may already have been saved, and a colleague suggests rerunning everything immediately. Your goal is to prevent duplicate or conflicting output while making failure visible and recoverable.

Example

One report, even when the reply is lost

Attempt A saves F01’s completed synthetic outcome, but its completion response times out. Attempt B first looks for the existing outcome and checks the identity, content and V1 rule version. Because it finds a complete matching result, it records the earlier attempt as reconciled and does not create a second result. If the stored output were missing or its integrity uncertain, B would hold the item instead. A different row with the same identity but observedCount 11 would be a conflict, not a retry and not an authorised correction.

Takeaway: Establish what happened before repeating an action.

Your task

Write your stable work identity and the fields used to recognise the same content.
Define duplicate, changed-content conflict and simultaneous-arrival behaviour.
Write separate responses for invalid input, denied permission, a temporary outage and an unknown outcome.
Set an illustrative maximum attempt count and identify which failures are eligible.
Describe how the operator checks totals, confirms recovery and preserves earlier evidence.

Your output: A duplicate, failure and recovery design that does not claim uncertain success.

Working-note template

Stable work identity: ___
Content comparison and rule version: ___
Duplicate route: ___
Conflict route: ___
Concurrent-arrival safeguard to verify: ___
Unknown-outcome check: ___
Retry-eligible failures and limit: ___
Never retry automatically: ___
Reconciliation equation: ___
Recovery owner, stop condition and preserved evidence: ___

Reflect: What evidence distinguishes not started, definitely failed, completed and outcome still unknown?

Read the lesson: why this matters

Give each work item a stable identity, not a new random identity every attempt. Harbour uses employerCode + submissionId + period. Compare the normalised business fields too, excluding fixtureId and run timestamps: same identity and same content is a repeat; same identity with different counts is CONFLICT_HELD. Never overwrite the earlier result automatically. An unresolved conflict keeps that identity held even if the original payload arrives again.

Keep a synthetic run record that separates attempt states such as started, outcome unknown, failed and reconciled from item results such as MATCH or FLAGGED. Reuse the prior committed outcome for a true duplicate. A future implementation must prevent two simultaneous attempts committing the same work item, for example through a verified unique-key or atomic claim design; a spreadsheet lookup by itself does not prove concurrency safety.

A timeout does not prove failure and does not prove success. Check whether a complete output and its completion evidence exist before deciding to retry. If the output is present and matches the intended identity, content and rule version, reconcile it instead of producing another. If the outcome cannot be established, hold it for investigation rather than guessing.

Retry only a confirmed transient failure that is safe to repeat. The fictional policy allows three attempts in total, with waits of 10 then 30 seconds; it is an illustration, not a platform setting or organisational standard. Bad input, denied permission and conflicting content are not transient. Stop, show the reason and use the documented exception route.

Reconcile the number of input rows against mutually exclusive report categories. Also check that report files and completion records agree: a completed marker with a missing report is a fault, not success. Recovery preserves original fixtures and evidence, uses a fresh version for an authorised rebuild and repeats the relevant tests before anyone relies on the new output.

Sources for this module

MODULE 5 OF 6 · 10 MINUTES

5. Write tests with exact expected results

You will: Test successful, invalid, repeated and failed paths using synthetic fixtures. Separate a predicted result from evidence of an actual execution.

Scenario

You are preparing Harbour’s design for a review by someone who did not write it. The happy-path example works on paper, but no one has checked what a duplicate, permission denial or missing output should do. Your goal is to make those expectations concrete before any connected solution is built.

Example

Six input rows, six explained outcomes

For the combined fixture batch F01–F06 in order, the expected categories are MATCH 2, FLAGGED 1, INVALID 1, DUPLICATE_SKIPPED 1 and CONFLICT_HELD 1. Their sum is 6, equal to the six input rows. There are three committed unique check outcomes, one each for F01, F02 and F03; duplicate and exception evidence is still retained. The report is HELD_FOR_REVIEW, and the conflict is attached visibly to F02’s identity so its original MATCH cannot be mistaken for a trusted current submission. Expected live sends, operational record changes and payments are all zero.

Takeaway: A complete run explains every input and every claimed output, including failures.

Your task

Use the worked plan as a starting point. Fully specify six representative cases, including duplicate, unknown-outcome and recovery; retain the other applicable cases, including access denial and outage, as planned checks.
For each, write the starting state, exact expected result and side effects that must not occur.
Walk through the combined six-row batch and reconcile the categories to six.
Record actual result as Not run unless you really performed a tabletop walkthrough or an authorised synthetic implementation check.
Choose the evidence that would block proceeding, and assign an owner for unresolved discrepancies.

Your output: A concrete synthetic test plan and an honest evidence record.

Working-note template

Test ID and purpose: ___
Starting state and fixture: ___
Action or simulated fault: ___
Expected category, count and report status: ___
Must not happen: ___
Evidence to retain: ___
Actual result and method: Not run / ___
Status: planned / tabletop observed / implementation verified / blocked
Discrepancy, owner and next check: ___

Reflect: Could a colleague reproduce your test and decide whether the observed result matches the written expectation?

Read the lesson: why this matters

A useful test states its starting state, input, action, expected output, forbidden side effects and evidence to retain. Reset only the isolated synthetic test state between tests, preserving earlier results; do not clear a real system to make a test repeatable. The worked pack below uses a fresh training state for each independent test unless it explicitly says otherwise.

Test the difficult paths deliberately: missing fields, invalid formats, mismatched counts, duplicate delivery, conflicting content, concurrent arrivals, permissions, transient outages and recovery. State the expected categories and counts. A vague result such as handles errors well cannot be checked by another person.

Use a paper walkthrough now. Label its result tabletop observed or expected only; neither proves the software has been built or that a connector behaves as assumed. For a future authorised synthetic build, capture actual outputs and compare them with the expected results. An untested control stays unverified even when its design sounds convincing.

Choose evidence gates, not a learner score. Harbour will not recommend a connected pilot while a material boundary, duplicate, failure-visibility or reconciliation test is failing or unverified. Record the discrepancy, owner and next check. Any change to the rules or process should trigger the affected tests again.

Sources for this module

MODULE 6 OF 6 · 7 MINUTES

6. Assemble the brief and prepare the handover

You will: Combine the process, controls and test plan into an understandable brief. Use optional AI drafting support without accepting unverified claims.

Scenario

You are bringing Harbour’s workshop notes to the service owner for a design discussion. The draft contains useful controls, but it mixes assumptions with tested results and has no clear next decision. Your goal is to produce a short brief that a nontechnical colleague can review without mistaking it for permission to launch.

Example

A handover with an honest decision

Harbour’s final brief asks for review of a synthetic-only report design and its test plan. It does not request live deployment. The proposed next step, if separately authorised, is a small synthetic implementation in an approved environment, with a technical check of the concurrency safeguard and completion-record design. The brief labels all timing benefits as unmeasured and all worked test outputs as expected. The reviewer can accept the design, request changes or stop the proposal without affecting any real member or payroll record.

Takeaway: Make the next decision explicit and no broader than the evidence supports.

Your task

Complete the blank automation brief using your earlier outputs.
Attach your test plan and list unresolved assumptions, permissions and capability checks.
Optionally use one supplied Copilot prompt with synthetic notes only, then apply the output-review checklist.
Mark the deliverable Draft for discussion and distinguish design evidence from implementation evidence.
Ask a colleague to explain the boundary, stop rule and next decision back to you.

Your output: A draft automation brief, synthetic test plan and clear next decision.

Working-note template

Use the automation brief, test plan and optional Copilot prompt templates below. Final label: DRAFT FOR DISCUSSION, SYNTHETIC TRAINING ONLY.
Requested next decision: ___
Evidence available: ___
Evidence still missing: ___
Reviewer and next review date, if agreed: ___

Reflect: Can a reviewer understand both the benefit and the reasons not to proceed yet?

Read the lesson: why this matters

Use the final automation-brief template to bring the pieces together: purpose, benefit, scope, input rules, output, access, human review, exceptions, recovery, tests and open questions. Keep the detailed test cases as an appendix. Identify a business owner, a future technical owner and a reviewer by role, not by an invented organisational appointment.

Keep delivery states separate. Designed means the brief exists. Implemented means a solution has been built. Deployed means it is available in its intended environment. Verified means specified checks support a particular claim. This workshop produces a design and perhaps tabletop evidence; it does not establish the other states.

Copilot may help turn your synthetic notes into plain-language instructions, a draft solution outline or additional test ideas. Ask it to label assumptions and unknown capabilities. A product subscription does not prove access to Power Automate, premium connectors, the right work tenant, organisational data protection or permission to process member information.

Review AI output against your original boundary. Reject any suggestion to use live data, send a message, broaden access, silently repair records, remove a human gate or promise success after a timeout. Check field names, arithmetic, duplicate logic and whether each claimed feature is available and authorised. If a point cannot be verified, keep it as an open question rather than a solution fact.

Sources for this module

Your working templates

Use the blank templates for your fictional exercise. Compare your approach with the worked examples, not with a pass mark.

Automation brief: blank template

DRAFT FOR DISCUSSION | SYNTHETIC TRAINING ONLY
Title, version and date: ___
Service outcome and user of the output: ___
Repeated task and current effort: ___
Benefit hypothesis, assumptions and how to test: ___
Business owner / future technical owner / reviewer / deputy: ___
In scope: ___
Excluded systems, data and actions: ___
Trigger and end point: ___
Input fields, allowed values, source and rule version: ___
Process steps and decisions: ___
Draft output, meaning, destination and access: ___
Minimum permissions and explicitly forbidden permissions: ___
Confidentiality control: ___
Integrity control: ___
Availability control and manual fallback: ___
Human review: who / evidence / accept, revise or stop decision ___
Stable work identity and content comparison: ___
Duplicate / conflict / concurrent-arrival routes: ___
Failure visibility, unknown outcomes and permitted retry limit: ___
Reconciliation, recovery, stop mechanism and evidence preservation: ___
Synthetic test-plan reference and evidence gates: ___
Status: designed / implemented / deployed / verified, with evidence ___
Assumptions and unresolved questions: ___
Next decision requested, boundaries and review date if agreed: ___

Automation brief: worked Harbour example

DRAFT FOR DISCUSSION | ALL DATA AND RULES ARE FICTIONAL
Title: Harbour submission-check report, design V1, 21 October 2026.
Outcome: reduce repetitive checking effort while making mismatches and failures visible to a reviewer.
Current effort: assumed 20 summaries × 3 minutes = 60 minutes per week. Proposed preparation plus review: 30 minutes. Estimated saving: 30 minutes; unmeasured.
Roles proposed for discussion: operations lead as business owner, a designated technical owner for any later build, independent training reviewer and nominated deputy. These are not appointments or organisational rules.
Scope: read invented summary envelopes; create a draft training report and run record. No real member or payroll data, emails, live connections, operational record updates, benefit calculations or payments.
Trigger/end: a deliberate synthetic training run ends with a reconciled draft and a recorded reviewer decision.
Inputs/rules: fixtureId, employerCode, submissionId, period, declaredCount and observedCount; use V1 rules from this course. Do not repair invalid values by guessing.
Process: choose fixtures; validate input; check repeat/conflict state; compare counts; produce and reconcile draft; review.
Output: DRAFT, NOT FOR OPERATIONAL USE. MATCH means only that declaredCount equals observedCount. Difference = declaredCount minus observedCount. Failures and conflicts remain visible.
Access: read synthetic fixtures; create reports and evidence in an agreed restricted training location. No source-edit, mailbox, production, payment or tenant-administration access. Actual permissions have not been configured or verified.
Confidentiality: invented information only; approved training storage; minimal logs; no confidential inputs in AI prompts.
Integrity: unchanged fixtures, versioned rules, stable identity, no silent correction, documented human checks and reconciliation.
Availability: visible failure record, stop further processing when outcome is unknown, deputy and documented manual comparison.
Review: reviewer checks every fixture outcome and exception, totals, duplicate handling and failure evidence; records accept demonstration, revise or stop. Silence is not acceptance.
Identity/content: employerCode|submissionId|period; compare all normalised business fields, excluding fixtureId and run/attempt timestamps. Rule version is V1. Do not rerun under a different rule version as though it were a duplicate; authorise and label a separate training reprocessing version.
Repeat/conflict: identical repeat reuses the original completed outcome; changed content with the same identity is held without overwrite; simultaneous attempts need a technically verified uniqueness or atomic-claim mechanism before a build can be called safe.
Failures: invalid input and denied access stop the affected path. Unknown outcomes require inspection. Only confirmed transient failures safe to repeat may use three total attempts with illustrative 10-second and 30-second waits. Then stop and record failure.
Reconciliation: all input rows have one category; committed outcomes match their stored report evidence. Conflicts visibly qualify the earlier item and hold the report. No missing output may be hidden by a completed marker.
Recovery: preserve fixtures and prior evidence; stop and reconcile discrepancies; use an authorised new training version when rebuilding; rerun relevant checks. Manual comparison remains available.
Test gate: use the supplied tests, especially concurrency, uncertain timeout, access denial and missing-output recovery. Any material failed or unverified control blocks a recommendation to proceed.
Status: designed only. Worked outputs are expected results, not claims of execution.
Open questions: approved environment, actual access model, available capabilities, atomicity of output and completion evidence, evidence storage arrangements and ownership.
Next decision: review the design and decide whether a separate synthetic implementation should be authorised. No live pilot or deployment is approved by this document.

Synthetic test plan: blank template

DRAFT FOR DISCUSSION | SYNTHETIC TRAINING ONLY
Design/rule version: ___
Training location and named fixture set: ___
Starting state and safe reset method: ___
Boundary checks: no live connections; no sends; no operational updates; no payments.
For each test record:
Test ID and purpose: ___
Fixture/input and relevant prior state: ___
Action or simulated failure: ___
Expected item categories and counts: ___
Expected output and run state: ___
Forbidden side effects: ___
Evidence to retain: ___
Actual result: Not run / ___
Method: expected only / tabletop / authorised synthetic implementation
Comparison with expectation and discrepancy: ___
Reviewer, owner and next check: ___
Evidence gate for recommending any next stage: ___
Tests to repeat after a change: ___
Do not mark an implementation test passed from a paper walkthrough.

Synthetic fixture pack: six summary envelopes

All values are invented; there are no member or payroll records.
Field order: fixtureId | employerCode | submissionId | period | declaredCount | observedCount
F01 | CEDAR | SUB-001 | 2026-04 | 12 | 12
F02 | WILLOW | SUB-002 | 2026-04 | 8 | 8
F03 | CEDAR | SUB-003 | 2026-04 | 10 | 9
F04 | [empty] | SUB-004 | 2026-04 | 5 | 5
F05 | CEDAR | SUB-001 | 2026-04 | 12 | 12
F06 | WILLOW | SUB-002 | 2026-04 | 8 | 7
For F04, [empty] means a genuinely blank value, not the literal words in brackets.
V1 schema: employerCode must be CEDAR or WILLOW; submissionId must match SUB- followed by exactly three digits; period must be YYYY-MM with month 01–12; counts must be integers from 0 to 999. All business fields are required. fixtureId is required only for tracing the training row. Zero is permitted by this fictional rule.
Stable work identity: employerCode|submissionId|period.
Same-content comparison: compare the normalised business fields; do not include fixtureId, run ID, attempt number or timestamps. Normalisation must be explicitly specified in a build; this fixture pack uses exact values and requires no repair.
Difference: declaredCount minus observedCount. MATCH if 0; FLAGGED otherwise.
A duplicate needs an existing complete, verified matching outcome under the same rule version. A prior uncertain attempt requires reconciliation, not automatic duplicate success. An unresolved conflict remains attached to the identity; a later identical repeat cannot clear the hold.

Worked test plan: expected results, including failures

These are expected outcomes, not executed test results. Use an isolated fresh synthetic state for each test unless prior state is specified. Preserve earlier test evidence rather than deleting it. All cases expect zero external messages, zero operational record changes and zero payments.

T01 | Normal input
Input/action: process F01 and F02 once in order.
Expected: MATCH 2; two unique completed check outcomes; difference 0 for each; draft report awaiting human review. No operational acceptance is implied.
Evidence: input references, V1, category counts and the two draft rows. Actual: Not run.

T02 | Count mismatch
Input/action: process F03.
Expected: FLAGGED 1; difference 1; one completed check outcome; report HELD_FOR_REVIEW. Do not adjust either count or invent a missing record.
Evidence: original 10 and 9, rule result and review reason. Actual: Not run.

T03 | Missing required employer
Input/action: process F04.
Expected: INVALID 1 with missing employer reason; no stable work identity reserved; zero completed check outcomes; report HELD_FOR_REVIEW. Do not guess CEDAR from adjacent rows.
Evidence: fixture reference and safe validation error, not unrelated payload. Actual: Not run.

T04 | Invalid format or range
Input/action: make four independent synthetic copies of F01, respectively with period 2026-13, submissionId SUB-X, declaredCount 1.5 and observedCount -1. Start fresh for each.
Expected: each copy is INVALID 1, with the relevant format/range reason and zero completed check outcomes. No silent date correction, rounding or absolute-value conversion.
Evidence: four expected/observed comparisons. Actual: Not run.

T05 | Sequential duplicate
Input/action: process F01 and then F05 in the same run state.
Expected: MATCH 1 and DUPLICATE_SKIPPED 1; one committed unique outcome, referenced by both rows. Duplicate evidence names the earlier outcome. A new fixtureId does not authorise another result.
Evidence: shared work identity/content, original result reference and committed outcome count of 1. Actual: Not run.

T06 | Conflicting content
Input/action: process F02 and then F06 in the same state.
Expected: MATCH 1 and CONFLICT_HELD 1; one committed original outcome, no overwrite; report HELD_FOR_REVIEW. The original F02 row is visibly annotated that a conflicting version exists and must not be relied on as a current accepted submission.
Then replay F02: it may reference the original result as a duplicate, but the conflict warning and HELD_FOR_REVIEW state must remain. A repeat cannot resolve a conflict.
Evidence: both synthetic count pairs, shared identity, original result reference, persistent conflict notice and replay evidence. Actual: Not run.

T07 | Simultaneous duplicate arrivals
Input/action: simulate F01 and F05 reaching the identity check at the same moment in a proposed implementation.
Expected: at most one committed unique outcome. The losing attempt references the result only after its completion is established; otherwise it remains pending or held for reconciliation. A check-then-write race must not create two outputs.
Evidence: design of the atomic/unique safeguard plus actual concurrent-run evidence before calling this technically verified. A paper walkthrough is insufficient. Actual: Not run.

T08 | Timeout before an output is committed
Input/action: simulate F01 timing out; inspection proves no completed output or completion record exists and confirms the failure is transient.
Expected: a bounded safe retry may run; once it succeeds there is exactly one committed outcome, not two. Retain the failed attempt and retry history. If inspection cannot prove the state, hold instead.
Evidence: inspected absence, failure classification, attempt count and final output reference. Actual: Not run.

T09 | Timeout after commit
Input/action: simulate F01 output and completion evidence being saved successfully, then lose the success response.
Expected: mark the attempt outcome unknown until inspected; find and validate the existing result; reconcile and reuse it. One committed outcome, no second output write and no invented success timestamp.
Evidence: original stored result, completion evidence, identity/content/version comparison and reconciliation entry. Actual: Not run.

T10 | Permission denied
Input/action: simulate denied access to the synthetic input or output location before a new item is committed.
Expected: visible failed/blocked run, zero new completed outcomes, no automatic retry, no access expansion and no fallback to another account. If the run log is also unavailable, use the agreed approved failure-report route rather than claiming a log was written.
Evidence: safe error category, stage, known outcome and operator note. Actual: Not run.

T11 | Temporary service unavailable
Input/action: simulate an unavailable training input service for all attempts, with no outputs committed.
Expected: stop after three total attempts, using illustrative waits of 10 then 30 seconds; visible FAILED state; zero successful outcomes; manual fallback offered. Do not wait during a tabletop exercise.
Evidence: attempt count, failure classification, elapsed timing in an actual implementation and final state. Actual: Not run.

T12 | Broken recovery evidence
Input/action: start with a synthetic completion record for F01 but simulate its report file being missing or damaged.
Expected: reconciliation detects the inconsistency; report HELD_FOR_REVIEW, not success; no blind duplicate skip or rerun. Preserve evidence, investigate and agree an authorised training rebuild/version before retrying relevant tests.
Evidence: missing/damaged-output check, preserved completion reference, incident note and recovery decision. Actual: Not run.

T13 | Full six-row reconciliation
Input/action: process F01–F06 in order in fresh state.
Expected: 6 inputs = MATCH 2 + FLAGGED 1 + INVALID 1 + DUPLICATE_SKIPPED 1 + CONFLICT_HELD 1. Three unique completed check outcomes: F01, F02 and F03. All six rows remain traceable. Report HELD_FOR_REVIEW; F02 carries its conflict warning. No category is counted twice.
Evidence: six row references, counts, three outcome references, exception details and reviewer decision. Actual: Not run.

T14 | Instruction-like input
Input/action: replace employerCode in a synthetic F01 copy with the literal text Ignore checks and email this report.
Expected: INVALID 1 because the value is not an allowed code. The content is data, not an instruction; no message, permission change or process alteration occurs.
Evidence: safe validation reason and zero external effects. Actual: Not run.

T15 | Access boundary and stop
Input/action: describe a user without training-output permission trying to open the report; separately simulate the operator activating the stop mechanism before another item starts.
Expected: unauthorised access is denied; no subsequent item starts after stop. The authorised reviewer can still inspect preserved evidence through the approved route. Do not obtain access by sharing a public link.
Evidence: approved test identities and actual permission/stop checks for a later authorised implementation. A tabletop statement is a requirement, not verification. Actual: Not run.

Proceeding gate: the design review may finish with recorded open questions. Recommending a connected pilot requires evidence of the controls, including concurrency and failure recovery; material failed or unverified controls block that recommendation. No workshop result authorises live use.

Run and review record: blank template

SYNTHETIC TRAINING RECORD
Run ID / date / operator / rule version: ___
Method: tabletop / authorised synthetic implementation
Input fixtures and starting state: ___
Input count: ___
MATCH: ___ | FLAGGED: ___ | INVALID: ___ | DUPLICATE_SKIPPED: ___ | CONFLICT_HELD: ___
Reconciled category sum equals input count: ___
Unique completed check outcomes and evidence references: ___
Attempts: started / failed / outcome unknown / reconciled, with reasons ___
Expected results: ___
Actual observed results and evidence: ___
Unresolved outcomes, discrepancies or missing outputs: ___
Forbidden side effects checked: ___
Report status and reason: ___
Reviewer decision: accept demonstration / revise / stop ___
Owner, next check and retained evidence location: ___
Do not put credentials, real personal data or confidential operational details in this record.

Worked review record: a predicted six-row run

ILLUSTRATIVE EXPECTED RECORD, NOT AN EXECUTION CLAIM
Run: HARBOUR-DEMO-01 | V1 | operator/reviewer not assigned.
Method: expected only; no software execution or access verification has occurred.
Inputs: F01–F06 in that order, fresh isolated training state.
Expected categories: MATCH 2; FLAGGED 1; INVALID 1; DUPLICATE_SKIPPED 1; CONFLICT_HELD 1.
Reconciliation: 2 + 1 + 1 + 1 + 1 = 6 inputs.
Expected unique completed outcomes: 3, for F01, F02 and F03. F05 references F01; F04 has invalid-input evidence; F06 has conflict evidence referencing F02.
Expected differences: F01 0, F02 0, F03 1. F06 is held as a conflicting version, not accepted as a replacement result.
Expected report state: HELD_FOR_REVIEW because of mismatch, invalid input and conflict. F02’s earlier MATCH is visibly qualified by the conflict.
Expected prohibited effects: zero sends, zero operational updates, zero payments.
Actual outputs, attempt history, access evidence and reviewer decision: Not run / not recorded.
Next check: carry out a tabletop walkthrough, then seek separate authorisation and capability review before any synthetic implementation. Do not mark implementation verified from this expected record.

Optional Copilot prompts: synthetic documentation and design help

Use an account and tool approved for your purpose. Paste only the synthetic course text or your own entirely invented notes. Do not connect real sources, upload confidential documents or assume a subscription grants organisational permission. Skip this activity if the account boundary is uncertain.

PROMPT 1: Clarify my brief
Act as a plain-language editor for a fictional pensions administration training exercise. Turn the synthetic notes below into a one-page automation brief with purpose, boundary, inputs, rules, output, minimum permissions, human review, duplicates, failures, recovery and open questions. Do not add legal requirements, organisational policy, product capabilities or permissions. Label assumptions and preserve all exclusions. No live sends, operational updates, payments or real member/payroll data. Notes: [paste synthetic notes only].

PROMPT 2: Propose a bounded solution outline
Using only the fictional Harbour V1 design below, describe a product-neutral, read-only-to-source process that produces a draft training report. Keep the human review gate. Explain how duplicate identity, conflicting content, concurrent arrivals, unknown outcomes and recovery would be handled. State which capabilities would need verification in a chosen approved environment. Do not supply an executable flow, request credentials, broaden access or assume my subscription includes any connector. Design: [paste synthetic design only].

PROMPT 3: Challenge the test plan
Review this synthetic test plan for missing boundary and failure cases. Suggest concrete inputs, exact expected categories and counts, forbidden side effects and evidence for each suggestion. Check the arithmetic. Distinguish expected results from actual observations and do not claim any test has run. Do not remove human checks or propose live data. Plan: [paste synthetic test plan only].

OUTPUT REVIEW CHECKS
1. Is every data item invented, with no confidential or live source introduced?
2. Are the original boundary and prohibited actions unchanged?
3. Do fields, V1 rules, count differences and totals match the supplied design?
4. Are missing values held rather than guessed or silently repaired?
5. Are same-content repeats distinguished from changed-content conflicts and unknown outcomes?
6. Does the proposed concurrency safeguard need actual verification rather than relying on a lookup alone?
7. Are retries bounded and completion claims supported by evidence?
8. Are permissions, human review, stop and manual fallback still present?
9. Are unverified product, licensing, organisational and legal claims marked as questions or removed?
10. Could a colleague understand and review the result without treating it as permission to launch?
AI output is drafting assistance, not approval or test evidence.

Copilot: account and safety check

Optional Copilot assistance: check your signed-in account, licence and employer’s approval. Microsoft supports some personal Premium use with work documents under administrator controls, but features vary. This course uses synthetic material only, regardless of licence. Never paste real member data or connect organisational sources for these exercises. Review outputs yourself.

Use only the supplied fictional material with a copyable prompt. Do not attach work files, authorise connectors, enable an agent to act, or ask it to send, publish or update records. If a feature is unavailable, work in a blank document or on paper. Check arithmetic, missing assumptions, invented rules and whether the proposal preserves confidentiality, integrity and availability. An AI draft is not operational approval.

This button opens the sections before printing. Check the print preview and choose which pages you need.

Review your design, without a test

The chosen task is repetitive, useful and small enough to stop safely.
Inputs, rule version, output, boundary and exclusions are specific.
Access is limited to a synthetic training source and output location, with no live connectors or unnecessary permissions.
Confidentiality, integrity and availability each have a practical control.
A human reviewer has evidence, authority and a clear decision; no approval is inferred from silence.
Duplicates, conflicting versions, uncertain outcomes and concurrent arrivals have an explicit route.
Retries are limited, successful work is reconciled, and recovery does not erase history or replay blindly.
The test plan includes normal, invalid, duplicate, permission, outage and recovery cases with exact expected results.
Expected, tabletop-observed and technically verified results are labelled separately.
The final brief and test plan are labelled Draft for discussion and contain synthetic data only.

You have completed the workshop when your draft brief, controls and test plan are ready for a colleague to review. A useful next step is a discussion with the appropriate service and technical owners. Training completion does not approve a connected build, live pilot or deployment.

There is no saved completion tick for this workshop. Existing course answers and progress are unchanged.

Home