The closure gate,
not the checkbox.

See the highlighted block above the contents list. The rest of this article walks through what an enforced closure gate is, the chain it forms, and why it is the difference between a record that looks closed and a record that is defensible in an audit.

In most legacy safety tools, closure is a status field. A user opens the record, decides the matter is handled, and sets the status to closed. The status is free text or a dropdown. Nothing checks that the underlying risk was actually dealt with. A user can hand-type a green “closed” status that no one verified.

This feels efficient and is the single most expensive habit in aviation safety record-keeping. The problem is not that people are careless. The problem is that the tool records the click, not the work. A checkbox tells you someone marked it done. It does not tell you the barrier that failed was restored, or the corrective action was effective, or anyone with authority looked at the evidence.

The cost lands later. Three years on, an auditor pulls the record and asks a simple question: show me why this was safe to close. A hand-typed green status is not an answer. There is no enforced link from the event to the barrier that degraded, to the action that fixed it, to the check that confirmed the fix. The trail was never required, so the trail does not exist. A checkbox is not a closure, and a hand-typed green status is not defensible.

• The status says closed; nothing proves the risk was closed.
• No required link from the failed barrier to a corrective action.
• No check that the corrective action actually worked.
• No record of who decided, or what evidence they read.

eAviora replaces the closure checkbox with a chain of gates. A gate is a condition the workflow checks before it will let the record move on. The record cannot reach a closed state while any gate in the chain is unmet. Closure stops being something a user asserts and becomes something the system permits only when the conditions are true.

The chain runs in order:

• A degraded barrier requires a corrective action. When a barrier on the record is rated degraded, the workflow opens a requirement: there must be a linked corrective action (a CAPA) attached to that barrier. The record cannot proceed toward closure with a degraded barrier and no action against it. The link is structural, not a note in a comment box.
• The corrective action cannot be marked done until it passes an effectiveness check. Marking a corrective action complete is itself gated. The action sits open until an effectiveness check confirms the fix achieved its intended outcome. Until then it cannot be marked done, and the record it belongs to cannot close.
• Accepting the risk instead requires a co-signed waiver.If the operator decides not to fix the risk but to accept it, that path does not bypass the gate — it routes through a different one. Residual-risk acceptance requires a two-person, co-signed waiver written into the record (covered in section 05).

And the chain sits inside a workflow that cannot skip a step. The occurrence record runs a ten-stage workflow, and the stages run in order — the workflow will not jump a stage to reach the end. So even before the barrier-and-action gates apply, the record cannot leap past intake, classification, investigation and review to land on closed. The two mechanisms compound: an ordered workflow that holds the sequence, and closure gates that hold the substance.

Effectiveness verification is the gate that separates a corrective action from a to-do item. Closing a corrective action without it is the checkbox problem in miniature: someone did something, marked it done, and no one confirmed the something worked.

What it requires.The corrective action cannot be marked done on assertion alone. An effectiveness check must confirm the action achieved its intended outcome — that the barrier it was meant to restore is actually restored, judged against operational evidence rather than against the fact that the work was attempted.

Why it is a hard gate, not a reminder.A reminder can be dismissed; a gate cannot. The corrective action stays open until the effectiveness check passes. The record that depends on it stays open too. This is the mechanism that stops the most common failure mode — a corrective action closed in good faith that did not fix the underlying problem, leaving the barrier degraded behind a green status.

What it produces. Because the check happens on the record, it leaves a trace: the action, the evidence the verifier read, the outcome, and the time it happened. That trace is what makes the eventual closure readable in an audit. The effectiveness check is not paperwork bolted on after the fact; it is the step that earns the closed status the record will later carry.

Not every risk gets fixed. Sometimes the operationally correct decision is to accept a residual risk — the fix is disproportionate, the exposure is tolerable, or a permanent control is scheduled and an interim acceptance bridges the gap. A safety system has to allow this. What it must not allow is acceptance by a single click in a free-text field.

In eAviora, accepting residual risk does not bypass the closure gate — it is a gate of its own. Acceptance requires a two-person, co-signed waiver: two named people put their names to the decision, and the waiver is written into the record. One person cannot quietly accept a risk and move on. The decision is a deliberate, attributed act by two parties, not a status set in passing.

And the waiver is built to survive an audit. It is co-signed and recorded on the record, time-stamped and audit-logged at the moment it is made. When an auditor later asks why a risk was carried rather than closed, the answer is on the record: who accepted it, that a second person co-signed, and when. The difference between this and a free-text “risk accepted” note is the difference between a defensible decision and an unsupported one.

• Two named signatories, not one click.
• The waiver is written into the record, not a side note.
• Co-signed, time-stamped and audit-logged when it happens.
• Readable years later as a deliberate, attributed decision.

Enforcement is only worth as much as the proof that it holds. The occurrence loop — event, to the barrier that degraded, to the corrective action against it, to the effectiveness check, to closure — was tested end to end against a live environment. The scenario suite returned thirteen of thirteen green. The gates either hold and the scenario passes, or a gate leaks and the scenario fails. The suite passes.

This is what “defensible by construction” means in practice. The defensibility is not a report someone writes after the event to make the file look complete. It is a property of how the record is built. A regulator can read the traceable path — event to barrier to corrective action to effectiveness — and every step is time-stamped and audit-logged in the same step it happens. There is nothing to reconstruct, because the trail was recorded as the work was done.

Put the two pictures side by side. In a legacy tool, an auditor pulls a record closed three years ago and finds a green status someone typed; there is no enforced link from the event to the barrier to the action to the check, so the status proves only that a box was ticked. In eAviora the same record carries the chain — the degraded barrier, the corrective action that addressed it, the effectiveness check that confirmed it, or the co-signed waiver that consciously accepted the residual — every step attributed and stamped. A checkbox is not a closure. A hand-typed green status is not defensible. An enforced gate chain is both.

The relevant surfaces: SMS module, Actions (CAPA). See how the wider loop connects in occurrence, CAPA, SPI and SRP, or contact us to discuss your operation.