RISKOPILOT follows the Tripod Beta chain of reasoning end to end: an incident narrative becomes a fact base, the fact base becomes a causation tree, the tree exposes failed barriers, and the barriers point to the organisational preconditions that let them fail. Nothing appears in the report that is not tied to a piece of evidence.
An investigation is shaped by what gets written down in the first hours. Intake takes the raw narrative — statements, shift logs, permits, photographs, alarm history — in whatever language it arrives in, and holds it as source material rather than conclusion.
Every uploaded item becomes a citable object with an origin, a timestamp and an owner. Later chapters can only assert something if they can point back to one of these objects.
Statements are split into discrete facts, each one classified as observed, recorded, inferred or disputed. Inference is allowed; disguising inference as observation is not.
Contradictions between sources are kept visible rather than resolved silently, so the analysis can be tested by anyone reading the report afterwards.
The fact base is assembled into the Tripod Beta structure: agent of harm, object, and the event that connects them, then the chain of active failures, preconditions and latent conditions behind each one.
The tree is a reasoning artefact, not a diagram exercise. Each node carries its evidence reference and its classification, and the panel below shows the live analysis surfaces produced from it.
Tripod Beta tree, case R-2847: the agent (gravity, work at height) reaches the object (a worker on a scaffold platform) through two failed barriers — fall-arrest verification and guardrail restoration — producing the event, a fall from height of 8 m. Each failed barrier traces to an immediate cause, a precondition and an underlying organisational cause.
Case R-2847 in standard Tripod Beta grammar: the event occurs when the agent (gravity) reaches the object (the worker) through failed barriers. Each failed barrier traces back to an immediate cause, a precondition and an underlying organisational cause. Click a barrier.
For each event path, the controls that were supposed to prevent or limit the outcome are named and given a state: intact, failed or missing. A control cannot be marked intact because it exists on paper — it has to be demonstrated in the evidence.
The bow-tie below is the same explorer used in the product. Select a barrier to see its state and the evidence citation behind it.
Each failed or missing barrier is traced to the basic risk factors behind it, scored across the eleven General Failure Types: design, hardware, maintenance management, procedures, error-enforcing conditions, housekeeping, incompatible goals, communication, organisation, training and defences.
The profile turns a single incident into a statement about the management system — which is what makes it comparable across cases and useful to a board.
Recommendations are generated per weak barrier and per dominant failure type, then written against the hierarchy of controls: elimination and substitution before engineering, engineering before administration, administration before protective equipment.
Each recommendation carries the barrier it repairs, the failure type it addresses and the evidence that justifies it, so the closure argument is auditable years later.
The output is a full investigation report, a board briefing, and the underlying figures, in English, French, Spanish or Portuguese — generated from a single analysis so the versions cannot drift apart.
Evidence stays in your workspace. Reports are exportable, retention is configurable, and every access is logged for the accountability trail.
Each chapter draws on a published method. These pages set out the source, the steps and the limits of each one.
Start with a free audit: upload a narrative, see the fact base, the tree and the barrier states before you commit to anything.
No card required for the audit. £99 per investigation report.