RA-E-2026-002 — Cross-Audit Example Using A1–A7: The Risk Dashboard

The case receives the code RA-E-2026-002. E shows that it is a synthetic example. Its status is LS8 after completed demonstration. The publication level is PL3 because the presentation is public, but without actual persons, actual system providers, or actual source material.

The example is placed after the introductory example because it takes more complex material through all seven audit types. The goal is to show how the audit tracks remain distinct even when they bear on the same case.

The mandate is to examine a bounded status report in a fictional training programme. The report states: “The dashboard shows that participant M is red risk and should not receive tool responsibility this week.”

The audit does not decide whether the participant is safe or unsafe as a person. It tests what the dashboard actually shows, what the score is based on, who made the decision, how the person was represented, and what correction is required.

The example uses “participant M” as a synthetic person marker. M is not an actual person. The roles are kept distinct because report author, system owner, instructor, and decision-maker do not have the same knowledge basis or authority.

Contradiction is given to the participant, instructor, and system owner. The participant does not merely respond to a personal characterisation; they respond to concrete registrations, absence codes, module status, and actual completed exercise.

The sources are constructed, but recorded as a real source register. One decisive point is that the dashboard is not a primary event. It is a visual representation of data sources, score rule, and threshold.

Several sources depend on the same registration. Module status, dashboard, and status report are therefore not three independent confirmations of risk; they are several links in the same material chain.

The report sentence is divided into parts. “The dashboard shows,” “red risk,” “M should not receive responsibility,” and “this week” are different claims with different requirements for support.

The matrix shows that some parts are supported: the dashboard did display a red label. But the report goes beyond this when it turns the label into an individual safety decision without showing model limit, counter-material, and human assessment.

All seven audit types are used, but with different functions. The table shows what each track examines, what it may support, and what it must not decide by itself.

This is the core of cross-audit: the tracks meet in the same case, but they keep their own criteria. A linguistic overstatement is not automatically a model error; a model limitation is not automatically authority abuse; a practice error is not automatically identity capture.

Provisional findings are formulated per track. They are not gathered into one total finding about the person, system, or institution. This keeps the case corrigible.

Capture risk is provisionally recorded because category, colour, report, and decision log point in the same direction. But full capture is not identified until it is shown that relevant correction was rejected and had concrete governing consequence.

Contradiction is directed at concrete links: data basis, model wording, decision ground, actual exercise, and consequence. No one is asked to defend their identity or morality.

The response material changes the case. The instructor documents practical exercise. The system owner confirms that “red risk” was poor wording for missing registration. The decision-maker confirms that override was possible, but that the log did not require reasons.

Final findings are formulated narrowly. The example does not say that the system “took over,” that M was captured, or that the decision-maker acted in bad faith. It says what can be documented: linguistic transfer from signal to safety claim, insufficient model grounds, misleading visualisation, weak human control, and capture risk.

Correction must reach several links. Changing one text is insufficient if score, dashboard, decision log, and practice continue unchanged.

The case is synthetically closed when correction is recorded at every affected link: report wording, model use, dashboard, decision log, practice, and review. Participant M does not merely have the label removed; assignment is reassessed with updated training log and instructor note.

The method revision from the example is that cross-audit needs an explicit transfer field. Whenever a finding in one track is used in another, the record must state whether it is only background, support, a new question, or an independent finding.