Border-security analysis training for an armed-police academy

The situation

An armed-police academy trains officers for border-security work. The skill being trained is not recall. It is reaching a defensible judgement from incomplete information, under time pressure, and being able to explain how the judgement was reached. The academy wanted a system to support live exercise: a console for the directing staff, a way to organise the analytical elements of a scenario, a method for working through qualitative analysis, and a record of assessment.

The usual answer to “training system” is a courseware platform: lessons, question banks, scores. That would have measured whether a trainee remembered something. It would not have measured the thing the academy is actually selecting for.

The call we made

Make the reasoning process a first-class object, and assess the process rather than the answer.

A border-security judgement is not right or wrong in the way a quiz answer is. Two trainees may reach the same conclusion, one having reasoned well and the other having guessed. The academy needed to see the path: which factors were identified, how they were related, and where the conclusion came from. So the core of the system is a flow graph of qualitative analysis — elements of the scenario linked by reasoning steps — which the trainee builds during the exercise and which the system stores, replays and scores against the assessment criteria.

Four pieces followed:

A training console for the directing staff. The exercise is run, not read: the console starts it, controls progress and injects events while trainees work. That means the system has a notion of exercise time and state, not just content and a submit button.
Analysis construction driven by the scenario. Elements are organised per scenario so that one engine serves many exercises. The builder had to be operable by instructors, not developers; a scenario authoring tool that requires a programmer means the system contains one scenario for ever.
Qualitative analysis as flow-graph reasoning. Expressing the analysis as a graph makes it inspectable and comparable, and turns “show me how you got there” into something the system can answer instead of an interview after the fact.
Assessment management. Scores and evaluations attach to the recorded process, so a result can be justified and re-examined after the exercise rather than during it.

We also designed for replay from the start. If an exercise cannot be replayed, the assessment becomes a memory contest between the trainee and the assessor. The console keeps the timeline, so a session can be walked through afterwards with the trainee present, and the training data accumulates across cohorts instead of ending when the room is cleared.

What we built

Training console with exercise direction and progress control for the directing staff.
Scenario-based analysis construction, where the elements of an exercise are organised and reused.
Qualitative analysis as a reasoning flow graph, stored and replayable.
Assessment management with scores and evaluations recorded against each exercise.
Process capture and replay, so that a session can be reviewed step by step.
Reusable scenario and training data, built up over successive cohorts.

Result

The academy can now assess how a trainee reasoned, not only what they concluded, and can walk a session back with the trainee present. Assessment is more defensible because it points at a recorded process rather than an impression of one; the trainee is not being asked to reconstruct their own reasoning from memory.

The visible part of the system is the console and the flow-graph editor. The part that makes it a training system is that the process is data — which is what allows it to be scored, replayed and compared across cohorts.

There is a general lesson here that applies well beyond training. When the skill being taught is judgement, the design question is not what content to load into the system. It is what process to capture, and whether the people running the exercise can capture it without help.

Screens from this system are not published. It runs on client infrastructure with client data, so we show it live instead: a short screen-share walkthrough under NDA, on a system we demonstrate rather than a screenshot we sanitised. Ask for it in the first call.

Technology

Stack	Vue 3 · Spring Boot · MySQL
Delivery model	On-premise delivery
Client	An armed-police academy (name withheld)
Status	Delivered

What we cannot show

Scenarios, unit designations, trainee identities and assessment records are withheld. Exercise content and personal data are not published, and interface screens from the delivered system are not shown.