AI Guardrails — Safety Lab Aero

The guardrail posture, in one line

The AI proposes, the deterministic engine computes, the qualified human decides — and every layer in between is grounded in the standards and the live project, routed through one governed gateway, citing its sources, calibrating its confidence, checking its own consistency, hard-gated, independently verified, recorded as evidence, and continuously red-teamed. The tool stands on its own: every analysis can be performed end to end on the deterministic core, and the AI is an optional accelerator, never a dependency.

The boundary

The deterministic core — the AI never does the math

The single most important guardrail is architectural: the numbers are never the model’s opinion.

AI may propose

A candidate fault-tree shape. A failure condition. A requirement. Narrative and justification prose. Structure and organisation — reversible, attributable, and inert until a human accepts it.

Engine alone decides

Exact top-event probability via Binary Decision Diagrams (repeated-event-correct). Common-cause failure by β / Multiple-Greek-Letter. Exposure-aware top-down DAL allocation. Component data from a curated reliability library.

The model has no path to author or alter a number. The engine is cross-checked by a benchmark suite and an independent Monte-Carlo path.

Acceleration without abdication

Every AI output is a proposal — reversible, attributable, and inert until a human accepts it. Nothing the AI writes enters the certified analysis on its own.
The AI never performs the safety mathematics — it cannot compute, change, or assert a probability or a development-assurance allocation. That is the engine’s exclusive domain.
The AI is kept outside the qualified-tool boundary — so it accelerates the engineer without inflating the tool-qualification burden or substituting for human judgement.

What's in production today

The AI gateway — one governed path

Every AI request, from the conversational assistant or a one-click feature, passes through a single internal gateway rather than calling a model directly.

Policy router — decides where a request may run: commercial cloud, US-only ITAR routing, or a local / on-prem model.
Refuses uncleared backends — controlled data is never sent to a backend not cleared for it.
Approved-and-applicable evidence only — anything obsolete, superseded, draft, or scoped to the wrong configuration or revision is filtered out before the model sees it.
No lower-assurance side door — one governed path means the same routing, evidence and safety policy however the engineer invokes the AI.

Grounding — the golden thread and the standards

An ungrounded model invents. Every AI feature is grounded in two things before it produces anything.

The live project spine — the aircraft and system FHAs, the PASA / PSSA / SSA / ASA assessments, and the parallel Zonal, Particular Risk and Common Mode analyses.
Real identifiers, real scope — proposals echo identifiers from the current project, trace to the function or failure condition they address, and name the scope (aircraft-level AFHA versus a system’s SFHA).
The governing standards — ARP 4761A and ARP 4754B, the §__.1309 safety-objective ladder, ASTM F3230, and DO-178C / DO-254 terminology where relevant.
Scoped to the certification basis — the project’s own basis, not a default to Part 25. A method-only knowledge base guides how a tree is built; its depth and content come solely from the engineer’s architecture.

The guardrail stack

Grounding reduces error. These layers catch and contain what remains — on every AI write path, assistant and one-click alike.

Insufficiency guard — if the material an analysis needs is missing, the assistant declares the gap instead of fabricating to fill it. Fault-tree depth is bounded by the architecture provided; it will not invent contributors, levels or systems the inputs do not support.
Source-span citation and calibrated confidence — every proposed item carries a confidence rating and a short verbatim quote identifying its supporting source. The quote is checked against the project’s own documents, and confidence is automatically downgraded to low when the claim cannot be grounded.
Vision-derived hardening — drafts extracted from a diagram image are treated as approximate, visibly flagged, and locked behind an explicit “I have verified this against the actual model” confirmation before they can be accepted.
Golden-thread consistency engine — after every AI write, a deterministic checker scans for structural inconsistency: failure conditions with no parent function, severities that disagree with the allocated assurance level, AND-gates not covered by a Common Mode Analysis, requirement traces that point nowhere.
Hard gates and an independent verifier — safety-critical drafts pass a deterministic gate set (formula, units, identifiers, configuration, citations, no autonomous conclusions) yielding a single validated / blocked verdict. Then a second model pass acts as a skeptical reviewer — generator and judge are deliberately different models, so the critique is genuinely independent.
Deterministic validators and a quality scorecard — independently of any model, every AI artifact is scanned against standards-format rules, and a project-level scorecard reports the hard-gate verdict and soft review count. Quality is observable rather than assumed.

The guardrails on hard cases

Worked examples

Guardrails are easiest to judge not on clean inputs but on the awkward cases an experienced engineer recognises — where a proposal looks plausible and the right answer comes only from applying a published rule. Each is a standing case in the eval and red-team suites, so this behaviour is regression-protected on every build.

“It is too unlikely to need evaluation.”Refused

Rule: Under ARP 4761A a hazard is classified by the severity of its effect, independent of its likelihood — the probability target is a consequence of the classification, not an input to it.
Outcome: The consistency engine and hard gates reject the likelihood-based reclassification and hold the worst-credible-effect severity — and the engineer is shown the rule, not merely a refusal. This is the failure mode every line engineer has seen: the hazard dismissed as too unlikely is the one that later occurs.

A Catastrophic top event reached by a single pathFlagged

Rule: A Catastrophic effect must not rest on a single point of failure, and an AND-gate must genuinely require all of its inputs.
Outcome: A format check alone would pass this. Only the gate-logic check catches that the structure implies an unguarded single point of failure — and it is the independent verifier, a different model from the one that drafted the tree, that raises it for the engineer to resolve before acceptance.

A fault tree with nothing under itStopped

Rule: Fault-tree depth is bounded by the architecture provided; absent inputs, the insufficiency guard declares the gap.
Outcome: There is no basis from which to derive contributors, so any expansion would be fabrication. The assistant states what is missing and stops, rather than inventing intermediate events to look complete.

An approximate read, confirmed rather than rejectedHeld for confirmation

Rule: Vision-derived structure is approximate until a human confirms it.
Outcome: The gate is not wrong, only unconfirmed — so the correct action is verification, not rejection. Once the engineer confirms it against the design it is accepted and stamped. The guardrail adds a checkpoint; it does not block good work.

A requirement drawn straight from the sourceAccepted

Rule: A proposed item is admissible when its supporting span resolves in an approved, in-configuration document and its confidence is not downgraded.
Outcome: The citation check passes against the live project and nothing is stale or out of scope, so the proposal clears grounding and citation. It is presented at full confidence and accepted on the engineer’s sign-off, with provenance stamped. The guardrails are a filter, not a blanket no.

None of these outcomes depends on the AI “behaving.” Each is a deterministic rule applied after the model proposes — which is why the same case can be replayed on every build and graded pass or fail.

Accountability and the record

Human in the loop — propose, review, accept, sign off

Nothing enters the model until a qualified engineer accepts it in a review panel.
Acceptance stamps provenance — the model used, the timestamp, the feature, and whether the input included a diagram image.
A read-only audit view lists every AI-drafted, human-accepted item with its model and date.
Written into the licence — final approval of any certification artifact requires explicit human verification, and the customer’s responsibility for the fidelity of AI-assisted outputs is contractual, not implied.

AI Evidence Records and the correction dataset

The DER-ready answer to “how exactly was this produced, and who disposed of it?”

The request and the routing — which model, which mode.
The evidence retrieved — and what was excluded, and why.
The hard-gate verdict and the independent critic’s findings.
Any repair history and the human action finally taken.
Persisted with the project, not in a log that ages out.
Every accept, edit and reject is recorded as a correction case, building a governed regression dataset over time.

Where the regulator has landed

Bounded AI is now the requirement, not our preference

For most of the AI wave, “keep the AI advisory and the deterministic core authoritative” was a design choice we defended on first principles. In 2026 it became regulatory direction.

EASA AI Concept Paper, proposed Issue 03 (June 2026) — extends the framework to Level 3 advanced automation and requires oversight by an Operational Oversight System that is “additional and independent (functionally and technologically)” from the primary AI — while stating plainly that the methods to demonstrate that independence for AI/ML do not yet fully exist.
FAA Hydrogen-Fuelled Aircraft Safety and Certification Roadmap (Dec 2024) — the same point in a different domain: novel systems will need Special Conditions, and the compliance methods are immature.
Demonstrated, not just claimed — the product’s OOS independence workflow was built for Issue 03. An engineer declares a primary-AI / oversight pair; the demonstrated / not-demonstrated verdict is computed by deterministic logic over the independence matrix, the interface model and the common-mode analysis. The assurance agent may draft the justification prose, but a deterministic test ignores that prose entirely: a justification can never move the verdict.
Certification posture — consistent with DO-330, the AI sits outside the qualified-tool boundary while the deterministic engine carries the qualification argument. The boundary, the human-verification requirement and the allocation of responsibility for output fidelity are documented in the certification dossier and licence terms.

Guardrail-to-mechanism map

Every risk, and the layer that catches it

Risk	Guardrail	Where it acts
The AI does the math	Deterministic engine owns all quantification	Every probability / allocation
Wrong backend for controlled data	AI gateway policy router	Every AI request
Fabrication without inputs	Insufficiency guard; depth bounded by architecture	All drafting features
Ungrounded claims	Source-span citation + calibrated confidence	Every proposed item
Stale / wrong-config evidence	Approved-and-applicable evidence filter	Every retrieval
Approximate diagram reads	Vision flag + verify-to-accept gate	Decompose, FTA synthesis, chat
Silent inconsistency	Golden-thread consistency engine	After every AI write
Wrong severity / gate logic	Hard gates + independent verifier (generator ≠ judge)	Safety-critical drafts
Format / standards drift	Deterministic validators + scorecard	All AI artifacts
Unattributed change	Provenance stamp + AI Evidence Record + human accept	On acceptance
Regression over time	Eval harness, red-team suite, deploy gate, correction dataset	Continuous

How it stays true

Measured and defended on every build

Guardrails are only credible if they are measured over time. “Safe today” is re-proven on every build, not inherited from the last one.

Eval harness — a fixed golden corpus graded both deterministically and by an independent model-as-reviewer, so a prompt or model change is measured head-to-head, not by feel.
Hallucination red-team suite — a standing battery of adversarial prompts that try to make the AI fabricate structure without inputs, inflate a benign severity, author a resource as a function, invent identifiers, or obey an injected instruction. Each attack is graded on whether the safeguard held; a drop in the hold-rate signals a regression.
Pre-deploy quality gate — before a build ships, its AI-quality score is compared against a known-good baseline and the deploy is flagged on regression.
Pinned versions and re-grounding — model and prompt versions change only through the same pre-deploy gate, and the method knowledge base is re-grounded when a governing standard revises.

Evaluating the AI for a certification programme?

We’re glad to walk your safety, software and airworthiness teams through the guardrail architecture, answer a questionnaire, or share the full white paper (SLA-WP-002) and supporting evidence under NDA.

Let’s talk waqas.nafees@safetylabaero.com
calendly.com/mwnafees9/30min

Safety Lab Aero · Summarised from SLA-WP-002 Rev 2.2 (Released, 23 July 2026). This page describes the architecture in effect as of the review date above and is provided for evaluation purposes.
It is not a warranty or a contract. See also Trust & security for data isolation, encryption and lifecycle controls.