The full Ask SCL question library, in plain text. These are the same answers the assistant on Ask SCL draws from. Last updated 2026-08-29.
Safety Critical Labs is an independent certification authority for artificial intelligence in safety-critical systems. It holds AI and machine learning to the same rigor as traditional safety-critical software, anchored in human-spaceflight-grade standards. The product is the certification mark, not consulting. The closest analogies are bodies like UL, DNV, and ISO registrars.
The AI Requirements Framework is SCL's core standard for assuring AI in safety-critical systems. It defines ten core requirement areas, AI-1 through AI-10, that apply to every AI system, plus three conditional areas: AI-11 for multi-model systems, AI-12 for neural networks, and AI-13 for continuous learning. It is domain-agnostic and supplements established standards like DO-178C, ISO 26262, and NPR 7150.2D with AI-specific requirements and co-located verification. Its founding principle is that requirements are defined by the failures they prevent, not the capabilities they enable.
Certification starts with a conversation about your system and its safety context. SCL assesses the AI against the applicable requirement areas of the framework and reviews the verification evidence you assemble for each one. Systems that meet the requirements receive the SCL certification mark and a verifiable certificate. Reach out through the contact page to scope an engagement.
The process moves from scoping, to evidence review against the framework, to a certification decision. SCL determines which requirement areas apply to your system, then evaluates the verification evidence for each applicable area against a grading rubric. The result is a pass or fail decision with a defined applicability statement. The process page walks through each stage.
Timeline depends on the scope of the system and how ready your verification evidence is when the engagement begins. A system with mature, well-documented evidence moves faster than one still assembling it. SCL scopes an estimated timeline with you at the start of an engagement. Contact SCL to discuss your specific case.
Cost is scoped per engagement, because it depends on the size and complexity of the AI system and the assessment effort involved. SCL does not publish a fixed price list at this stage. Reach out through the contact page and SCL will provide a scoped estimate for your system.
SCL is pre-accreditation. Intake with ANAB is on file and a fee estimate has been received, but formal engagement is deferred until certification volume supports it. The long-term path is accreditation under ISO/IEC 17065 through a recognized body such as ANAB or A2LA. The accreditation page tracks current status.
The framework is domain-agnostic and layers on top of established safety-critical software standards rather than replacing them. It supplements DO-178C for airborne software, ISO 26262 for automotive, and NASA's NPR 7150.2D for spaceflight software, adding AI-specific requirements and verification. This lets teams keep their existing standard and add the AI assurance layer on top.
The core areas AI-1 through AI-10 apply to any AI system. Three conditional areas cover specific paradigms: AI-11 for systems that combine multiple models, AI-12 for neural networks, and AI-13 for systems that keep learning after deployment. Because the requirements are defined by failure modes rather than by a particular technology, the framework spans classical machine learning through modern neural and multi-model systems. The boundary is behavioral, not technological: a system whose correctness can be fully verified against an explicitly written specification, with no reliance on an artifact learned from data, is not AI for the framework's purposes, and standard software assurance applies to it.
They are the three conditional areas that apply only when a system uses a given paradigm. AI-11 covers systems that combine multiple models, AI-12 covers neural networks, and AI-13 covers systems that keep learning after deployment. A system is assessed against these only where they apply, on top of the always-applicable core areas AI-1 through AI-10.
Capabilities change constantly, but the ways a safety-critical system can fail are more stable and more testable. By defining each requirement around a specific failure it prevents, the framework stays relevant as models evolve and produces verification that maps directly to safety outcomes. This mirrors long-standing safety engineering practice like FMEA and fault tree analysis.
No. The framework supplements the safety-critical software standard you already follow, such as DO-178C, ISO 26262, or NPR 7150.2D. It adds the AI-specific requirements those standards do not yet cover, so you keep your existing process and layer AI assurance on top.
Co-located verification means each requirement in the framework ships with the verification method that proves it, in the same place. Instead of a separate test plan, the way you demonstrate compliance sits next to the requirement itself. This keeps the evidence traceable and makes assessment consistent across systems.
The AI Requirements Framework is published openly on Zenodo, with a concept DOI that always resolves to the latest version at 10.5281/zenodo.19024420. A companion white paper is posted on SSRN as a citable preprint. The framework page links the current release and its DOI.
Yes. The framework is open and freely available. You can read the current version through the documents page, which links the Zenodo record and the white paper. The Standard itself is open on purpose; the proprietary part is SCL's assessment and audit methodology.
The current published version is v3.6. The concept DOI at 10.5281/zenodo.19024420 always resolves to the latest version, so citing it keeps a reference current across updates. The framework page links the exact current release.
A consultancy helps you build a system. SCL certifies whether a finished system meets an independent standard, and does not consult on the systems it assesses, so the mark stays independent. The product is the certification mark itself. The model is closer to UL or DNV than to an advisory firm.
The SCL mark is the certification a system earns by meeting the framework's applicable requirements. It comes with a verifiable certificate that anyone can check on the verify page. SCL Certified is filed as a trademark, so the mark signals a specific, defensible standard rather than a generic claim.
Every certificate SCL issues has an entry in the public register. Use the verify page to look up a certificate and confirm its status, the system it covers, and the framework version it was assessed against. The register is the authoritative source of truth for any SCL certification.
SCL is in early operation and has not issued a production certification yet. The register currently holds a specimen record that demonstrates what an issued certificate looks like. The verify page shows that specimen so you can see the format before real certifications are listed.
SCL focuses on domains where an AI failure can hurt people or cause serious loss, such as aerospace, spaceflight, automotive, medical, and other safety-critical fields. Because the framework layers onto the safety standard already used in each domain, it adapts across industries. The markets page describes the sectors in scope.
SCL is grounded in real safety-critical software experience, including work integrating AI into NASA's Software Engineering Handbook. That background shapes the framework's spaceflight-grade posture and its emphasis on verifiable evidence. The expertise page covers the relevant experience.
The contact page is the way to reach SCL to scope a certification, ask a question the library does not cover, or discuss your system. SCL is in its first phase of operational conversations and welcomes early inquiries.
The news page tracks developments in AI assurance and regulation, and the updates page logs changes to SCL and the framework. You can subscribe to receive briefings. Start with the subscribe page to follow along.
Ask SCL is built with Llama. Answers are generated by an open-weight Llama 3.1 model that SCL fine-tuned and runs on hardware SCL controls; no cloud AI provider generates answers. Answers are grounded in the published FAQ and verbatim text from the AI Requirements Framework. Before answering, a small ranking model hosted by Cloudflare scores your question against SCL's own framework text to choose which passages to use. Cloudflare also runs the request handling for the assistant and stores retained questions. Questions are not retained unless you turn on question retention on the Ask page, which is off by default. It is an informational assistant only and plays no part in certification decisions.
A certificate records that a system met the framework's applicable requirements at the time of assessment. It does not say the system is safe, that it will not fail, or that it is approved for any regulatory purpose. It is not a regulator's clearance and does not move operator responsibility to SCL.
SCL does not score a nondeterministic system against a single correct output. The certification claim is bounded by the Operational Design Domain the system declares up front (AI-1.0). Inside that envelope the framework asks for evidence that behavior stays within defined bounds: testing across representative operational inputs against pass/fail criteria (AI-3.3), calibrated confidence on probabilistic outputs (AI-8.3), and drift monitoring with performance threshold maintenance in operation (AI-4.1, AI-4.2). The result is a determination against the applicable requirements at the time of assessment; it is not a score.
In traditional software the intent goes into the code: a developer who decides a word means spam writes a rule that says so, and a reviewer can read the rule and trace it to a requirement. In an AI system the intent goes into the loss function. The developer labels examples and defines one number that says how wrong the last guess was, and training adjusts the parameters until it gets smaller: warmer or colder, played by a machine. The decision logic is left to training, so behavior is learned from data rather than written down, and the traceability from requirements to code breaks (AI-1).
Training produces a set of weights, coordinates in a space nobody drew. In code the word the developer had in mind is still a string a reviewer can search for. After training it has dissolved into numbers, so you cannot grep for intent. The weights hold the same knowledge the rule would have, in a form that cannot be read back. The framework agrees: there is no code to cover in a neural network's weights (AI-3), and decisions come from learned patterns in weights that are not directly interpretable (AI-8). Whether a system has crossed that line is a behavioral test (Section 1.2.1).
You verify the envelope around it. First, the conditions it was trained under: data provenance (AI-1.3), a characterized training distribution (AI-6.1), and testing across operational inputs (AI-3.3). Second, the conditions it operates under: a declared Operational Design Domain (AI-1.0), drift and performance monitoring (AI-4), and out of distribution detection (AI-6). Third, the mechanisms that catch it when it fails: hallucination response (AI-5) and human oversight with final decision authority (AI-9). The model stays opaque and probabilistic, or nondeterministic. The envelope does not.
A test result is a moment in time: how the model did on the inputs you chose, the day you ran it. Because its behavior was learned from data, the model holds patterns nobody designed or thought to test, and it can change in operation without any code change as the data around it drifts. The framework pairs every requirement with a verification method, of which test is one of four (Section 4.1), and requires some verification to continue in operation, including drift monitoring and performance threshold maintenance (Section 4.4). SCL surveillance then checks that this monitoring is working.
A spam filter retrained weekly learns new spam terms; detection goes up. Then the finance team mails a crypto policy update, the model learns that too, and starts blocking internal finance mail. The loss function improved, detection is up, and the system blocks legitimate business. A regression test misses it: aggregate accuracy went up. That is drift under an improving loss. The framework monitors behavior: drift from the training baseline (AI-4.1) and performance thresholds with a defined response on breach (AI-4.2). AI-13.1 sets permission criteria for learning that continues in the field.
Every assessment produces a determination document regardless of outcome. It records the system assessed, framework version, classification level, requirement sets, findings, quantified risk score, and the formal determination: Certified or Not Certified. A certificate, issued only when the applicable requirements are met, records that the system met them at the time of assessment. It does not claim the system is safe, that it will not fail, or that it has regulatory approval, and the operator stays responsible. The determination itself is a finding against requirements, not a score.
DO-178C does not run the safety assessment that sets its rigor. The aircraft level assessment does, through the methods of ARP4761/A and the assurance level assignment of ARP4754A/B, and the resulting software level reaches the software life cycle as an input. That level then selects which Annex A objectives apply. SCL's gate answers a narrower question, whether behavior rests on a learned artifact, so criticality still comes from your own domain's process.
The count follows from failure modes, not from a target number. Each area exists because a class of AI failure has already happened in the field, and the set grows as new classes are recognized. Ten core areas cover failures any AI system can exhibit. Three more apply only to systems that use multiple models, neural networks, or post-deployment learning.
A readiness assessment tells you where you stand against the framework before committing to a full certification cycle. It identifies gaps without producing a formal determination, so it is not a certification and does not grant the mark. The version on the site is an indicator, not a formal risk score.
Certification is not a one time event. Safety Critical systems carry an annual surveillance audit and Mission Critical systems a biennial one. Reassessment is triggered by a model version change, a significant environment change, a drift threshold breach, or an incident involving an AI assisted decision. The validity period is scoped per engagement.
Confidentiality terms are set in the written engagement agreement that governs each assessment, so they are agreed before any evidence changes hands. SCL retains assessment documentation for at least ten years or the life of the certified system, available for regulatory review. Contact SCL for the terms that would apply.
Yes. SCL applied the framework's verification methods to NASA's public C-MAPSS turbofan dataset and published the measured results, including the methods that failed their own subject. Every number is reproducible from an open repository. The evidence page shows what was measured.
Yes, under its licence. The framework is published under Creative Commons Attribution ShareAlike 4.0 and may be read, cited, and reproduced under those terms. ShareAlike means an adaptation you distribute has to carry the same licence. The SCL name, certification mark, and logo are separate from the framework licence and may be used only as expressly authorised in writing.