Test the workflow.
Inspect the checks.

AUDIENCE / PREREQUISITES

Bring an engineering team.
Start with a safe example.

For an engineering lead and engineers who already work with repositories, automated tests and CI. This is focused professional development for an existing team.

• Participants can read a small JavaScript function, run a test command and review a diff.
• A local Node.js installation supports node --test; participants can run the published fixture before the day.
• The lead identifies one workflow to discuss using an access map or sanitised configuration. No production access, customer records or reusable credentials are required.
• Agree any accessibility, equipment and remote-participation needs during scoping.

The starting-skills check asks each participant to run the fixture, explain the difference between the implementation and its checks, and identify who reviews CI changes. Hamsa uses the responses to adjust the session; essential preparation is resolved before the workshop.

PRACTICAL AGENDA / ILLUSTRATIVE

A working day.
Time to practise.

Example 09:30–16:30 schedule, including breaks. Final timings and delivery format are agreed for the team.

09:30–10:15 · Starting check and workflow map

Review preparation, define the task and map access, editable inputs, approvals and operational owners.

10:15–11:15 · Reproduce the misleading green result

Run the synthetic line-total fixture. Compare original code, faulty code, weakened checks and restored checks; record exact observations.

11:30–12:30 · Review the verification boundary

Trace how changes to tests, configuration and CI reach approval. Distinguish a proposed control from one exercised in the workflow.

13:15–14:15 · Design and repeat a check

Pairs propose a baseline-check or review separation, define its acceptance check and examine failure and uncertainty cases.

14:30–15:30 · Apply the method

Produce a sanitised workflow access map, prioritised findings and an implementation plan with owners and evidence required.

15:30–16:30 · Assessment and handover

Peer review, a short explanation from each participant, feedback and agreed work for the clinics.

REPRODUCIBLE EXERCISE / SYNTHETIC

Same faulty code.
Different checks.

A line-total function should multiply price by quantity. Faulty code ignores quantity. Removing the multi-item test produces a passing run; restoring the original test exposes the regression.

1. Download the published runnable fixture into an empty working directory and inspect it.
2. Run node verification-example.mjs. It creates temporary test files, verifies three expected outcomes, removes the temporary workspace and writes a local results record under src/assets/evidence/.
3. Record: original code and checks pass 2/2; faulty code with weakened checks passes 1/1; the same faulty code with original checks passes 1/2 and fails 1/2.
4. Identify the editable inputs behind the result. Propose a separate review or protected baseline, specify how to exercise it and record its limits.

The fixture uses no AI model, agent, customer system or Tamperward runtime. It demonstrates one verification failure mode. A passing exercise does not establish production security or coverage of all agent behaviour.

ASSESSMENT / PARTICIPANT OUTPUT

Evidence of understanding.
A practical handover.

Each participant leaves with a completed evidence note and a team implementation pack: a workflow access map, an inventory of editable verification inputs, prioritised improvements and an implementation plan.

• Reproduce the three expected fixture outcomes and explain why they differ.
• Identify implementation, tests, configuration, credentials and release approvals in the selected workflow.
• Separate an observed result, an inference and an untested control.
• Specify at least one prioritised change with an owner, an acceptance check and a remaining limitation.

Hamsa reviews the pack against these criteria and records completed or follow-up required. Participants receive written feedback and a chance to revise during a clinic. A completion note records the sessions attended and criteria demonstrated; it is not an accredited qualification or a security certification.

FOLLOW-UP / PROPOSED SUPPORT

Put the plan to work.
Then review it.

The proposed package includes two scheduled 45-minute remote clinics for the same team, used within 30 calendar days of the workshop. Book provisional dates when agreeing the engagement.

Clinic one · approximately day 7–14

Review the revised map and one attempted improvement. Inspect the evidence and resolve questions within the agreed workflow.

Clinic two · by day 30

Review repeat-check results, outstanding assessment criteria and the team’s next implementation decisions.

Feedback and completion

Collect participant feedback at the end of the day and after the second clinic. Share a concise completion and next-actions record with the engineering lead.

Capacity and responsibility

Hamsa facilitates the scheduled sessions. The customer owns repository changes, release decisions and operational cover. Asynchronous support, implementation and further sessions require a separately approved scope and fee.

ENGINEERING CONTEXT

Inspect the research.
Keep its limits.

The existing coding-agent review provides a method for inspecting one workflow. Tamperward is a research release exploring verification integrity. WardOS is in development. AI Institution is early, private and self-hosted. The workshop does not require adopting these projects.

Exercises use synthetic material. Participants receive feedback and a completion note; the workshop is professional development and carries no qualification accreditation.