Safety Critical Labs / Certification Process

A formal determination.
And a quantified
risk score.

Every SCL assessment produces both. A four-phase, documented process for AI systems operating in safety-critical environments. Aerospace, aviation, medical, automotive. Not a general impression. Not a vendor attestation.

Four phases
01
Applicability determination
Scope · Classification · Tailoring

Phase 1 produces an applicability determination for the specific system being assessed. It begins with a kickoff meeting and a structured questionnaire, because the Lead Assessor cannot define scope from the outside. Boundary, classification, and tailoring decisions all depend on specific information about how the system is built, how it is operated, and the consequence its outputs carry. The four items below are the components of that determination. Each is recorded in writing, and the client signs off before any evidence is reviewed.

System boundary definition: What components of the AI system are within scope? What interfaces with out-of-scope systems require explicit boundary documentation?
Classification assignment: Is this system Safety-Critical AI, Mission-Critical AI, or Operational Support AI? Classification drives which requirement sets (AI-1 through AI-10) are applicable and at what depth.
Tailoring rationale: Where do operational constraints require tailoring of standard requirements? Every tailoring decision is documented with an explicit rationale that becomes part of the certification record.
Applicability Determination Record (ADR): Signed formal output of Phase 1. System-level information used for applicability and classification is captured in the ADR, which establishes the assessment scope in writing before any evidence is submitted. Client signs off before Phase 2 begins.
Engagement scope. The assessment fee covers all four phases through certificate issuance. Scope and engagement timeline are established here, before Phase 2 begins.
02
Evidence package review
Documentation · Test reports · Verification matrices

The client submits their evidence package against the applicable requirement set. Our team reviews each submission against specific framework requirements with documented findings, not general observations. Every finding is traceable to a requirement number, a specific criterion, and a pass/fail disposition. The items below are the categories of evidence we review and the formal output that closes the phase.

Documentation review: Architecture documentation, model cards, training data records, validation reports. Reviewed against each applicable AI-1 through AI-10 requirement.
Operational procedures review: Post deployment performance data, drift monitoring logs, continuous validation records, human override procedures, authority limit documentation, OOD escalation protocols, and human AI interaction logs.
Test report analysis: ML test coverage results, bias evaluation reports, OOD detection test results, and adversarial robustness test outcomes. Dated and reproducible. Assessed against framework criteria, not general best practices.
Verification matrix review: Requirements traceability from each applicable requirement to a corresponding verification method and documented test result. No placeholders.
Evidence package review report: Formal output. Documents open items, requests for additional evidence, and preliminary findings. Client has opportunity to address open items before Phase 3.
Not ready to certify yet? Organizations can request a readiness assessment before committing to a full certification cycle. A readiness assessment identifies specific gaps against the framework without producing a formal determination.
03
Technical assessment
Structured audit · Findings · Risk score

The structured audit of your AI system against the framework requirements. Where evidence review examined documentation, technical assessment examines the system itself: its architecture, its test infrastructure, and the operational validity of its verification claims. This is also the phase where the risk score is calculated. The items below are the activities that make up the audit, the grading they produce, and the remediation path for any conditional findings.

System walkthrough: Technical review of architecture decisions against framework requirements. Focus on AI-specific failure mode coverage, not general software quality.
Test infrastructure review: Assessment of the test environment used to generate evidence. Test infrastructure that cannot reproduce results does not support a determination.
Finding grading: Each finding is graded Pass, Conditional Pass (with defined remediation), or Fail. Grading rationale is documented against specific requirement criteria, not assessor judgment.
Risk score calculation: Using a structured consequence-based scoring methodology, the technical assessment produces a quantified risk score for your system. The score reflects assessed failure modes, operational consequences, and the effectiveness of human oversight controls. It is reproducible, documented, and issued with your certificate. A number your leadership, your regulators, and your procurement officers can read.
Remediation paths: For Conditional Pass findings, a defined remediation path with specific acceptance criteria is provided. Remediation is verified before certificate issuance.
04
Certificate issuance
Formal determination · Risk score · Surveillance schedule

A formal determination document stating what was assessed, what was found, and what is required to maintain certificate validity. Every assessment produces a Determination Document regardless of outcome. A certificate is issued only when applicable requirements are met. Both documents include the risk score. The items below are the formal outputs of this phase, the records retained, and the surveillance schedule that keeps the certificate valid.

Certification Determination Document: Issued regardless of outcome. States the system assessed, framework version, classification level, requirement sets, findings summary, quantified risk score, and the formal determination: Certified, Conditionally Certified, or Not Certified.
Certificate (if certified): States system name and version, client organization, SCL framework version, classification level, requirement sets assessed, risk score, issue date, validity period, and surveillance due date. The certificate does not state the system is safe. It states the system was assessed against a defined standard, met the applicable requirements, and carries a documented risk level at the time of assessment.
Assessment record retained: All documentation from all four phases is retained by SCL for a minimum of 10 years or the life of the certified system. Available for regulatory review.
Surveillance schedule established: Certification is not a one-time event. AI systems change behavior over time. Every certificate includes a structured surveillance schedule.
Surveillance and recertification

Certificate issuance is not the end of the relationship. AI systems change behavior over time, so every certificate carries a defined surveillance cadence and the conditions that trigger recertification. The schedule below is calibrated to classification level and is set at issuance.

Safety-Critical Annual surveillance audit. Full reassessment of drift metrics, OOD detection logs, and operational performance data since certification.
Mission-Critical Biennial surveillance audit. Focused reassessment of continuous validation records and any model updates made since the original certification.
Triggered reassessment Required for any of: model version change, significant operational environment change, defined drift threshold breach, or incident involving an AI-assisted decision with safety consequences.
Certificate of conformance