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 ]

From kickoff to certificate.

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-13) 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-13 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 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 Major finding.

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 Major or Observation. A Major finding means a requirement is not met for the Operational Design Domain in force at determination. An Observation means the requirement is met and the assessor has recorded a recommendation that does not affect the determination. There is no intermediate grade: a requirement is met or it is not. Grading rationale is documented against specific requirement criteria, not assessor judgment.
Technical Assessment Report: Formal output, signed by the Lead Assessor. States the findings against each applicable requirement, the evidence each rests on, and the quantified risk score. It is the last word on findings; the determination itself is made in Phase 4, not at the closing meeting.
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: Every Major finding carries a defined remediation path with specific acceptance criteria, stating what would need to be true for the finding to be resolved. Any Major finding means Not Certified, and remediation is verified through re-assessment before a certificate can be issued. Where assessment evidence shows the declared Operational Design Domain was broader than the system can support, the ODD may instead be reconciled during the assessment so the certificate reflects the envelope the evidence supports.
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 areas, findings summary, quantified risk score, and the formal determination: Certified or Not Certified.
Certificate (if certified): States the certificate number, the Certification Determination Document number, system name and version, client organization, the operational claim, SCL framework version and its version DOI, classification level, requirement areas assessed, notable exclusions, risk score, issue date, validity period, surveillance due date, the Lead Assessor and the Principal's signature. The full field list is at /deliverables. 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.
Operational Support Triennial surveillance audit. Confirmation that the system remains in its declared advisory role, with continuous validation records and any model updates reviewed 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 ]

See where your system stands before engaging.

Take the readiness assessment