For the assessor

For the assessor

This page is for the person asked to look at LionDriver independently: a confirmation reviewer, a functional safety auditor or assessor, a SOTIF or AI-safety reviewer, a cybersecurity assessor, or someone deciding whether to take that role on. It says what state to expect, where the plans are, what you would be asked to do, what to assess against, how independence is recorded, and how to send findings. Every line points at the record that owns it; this page decides nothing and claims nothing.

Note

No confirmation measure has been performed, and no assessor has been engaged. The project has one maintainer, so every review at independence level I2 or I3 is planned as external. The project lead decided on 2026-10-14 not to engage an assessor for now; the decision is recorded as revisitable. See where things stand.

Where things stand

Fact	Where it is recorded
No confirmation review, audit or assessment has taken place	Confirmation records folder, WP-M-06 §1
No gate review has been held	Gate records folder
The assessor role is open; the lead chose "no assessor for now"	WP-M-01 §8, decision D-06; decision register entry DQ-009 in register.yaml
Every role in the safety plan resolves to the maintainer; roles needing independence are marked TBD	WP-M-02 §3.1
Much of the record is AI-assisted drafting, which counts at I0 and gives no review credit	WP-M-02 §3.3
Clause citations are marked "check against the licensed copy"; the standards are to be bought when an assessor is engaged	Decision register entry DQ-014 in register.yaml; WP-M-06 OI-1
No work product is approved or baselined; the status of each is in the register	WP-M-00 §3 and its generated status figure

Figure 9 of the traceability record, generated from the WP-M-00 register and the test specifications by trace_figures.py. Green is kept for approved or baselined work products and passed verification.

The dashboard on the Home page shows the same picture in figures. Reading the Living Safety Case explains why zero accepted evidence is the honest number at this stage.

Read in this order

Step	Work product	What to take from it
1	WP-M-01 assurance strategy	The one configuration claims apply to (§3.1), the safety-envelope argument the whole case rests on (§4), the tailoring decisions T-01 to T-13 (§5), the strategic decisions and their status (§8), the top risks (§9)
2	WP-M-02 functional safety plan	Roles and who holds them (§3), the lifecycle phases and gates (§4), the early-implementation rule for at-risk work (§4.1), how the plan tailors the standard (§6)
3	WP-M-06 confirmation measures plan	What you would be asked to do (below), the independence scheme (§3), the assessor qualification and independence requirements (§6.1), the records and their location (§10)
4	WP-M-00 work product register	The gates and their exit criteria (§2), every work product with its clause, gate and status (§3)
5	WP-K-01 safety case	The argument structure, the assumptions (§5), the evidence status (§6), the defeaters (§7). The GSN diagrams are under gsn/ and the machine-readable records under assurance/case-records/
6	WP-K-04 functional safety assessment	The assessment plan and the report template you would fill in, including the independence declaration (§2)
7	Baseline gap assessment	What the project itself found wanting in the inherited code and process, finding by finding

Standards at a glance lists which standard each work product answers to. How the repository is organized maps the folders.

What you would be asked to do

WP-M-06 plans every measure by gate. The summary table is WP-M-06 §9; the detail is in the sections it points to.

• Confirmation reviews CR-01 to CR-12, each naming the work products, the planned independence level and the gate (§4.1). The procedure for one review is §4.2.
• Functional safety audits AUD-1 and AUD-2, checking that the plans are carried out as written (§5).
• Functional safety assessments FSA-I1 and FSA-I2 at the concept and system-design gates, and the final FSA-F before any release record (§6).
• SOTIF and AI reviews SR-01 to SR-04, planned at an independence equivalent to I3 because the standard sets none (§7).
• Cybersecurity assessment per WP-M-09, with the report in WP-K-05 (§8).

Who may do each is in §6.1: no authorship of or contribution to the assessed work, no reporting line to the maintainer, no financial interest beyond the fee, no involvement in upstream development of the assessed code, competence at the level WP-M-04 §4.2 sets, declared in writing in each report.

What to assess against

A review is against a named state of the record, never against the moving branch.

Thing	Where
Engineering baselines, and whether each is frozen by a tag or still under development	assurance/case-records/baselines/, rules in WP-P-01
The reference configuration the claims apply to	cfg-001 and the reference vehicle page
A snapshot of the safety case as a PDF at a named baseline, with a manifest of hashes and a build attestation	Snapshot releases
A numbered controlled copy issued to you by name	Controlled copy workflow, recorded in distribution.yaml under WP-P-04
The digest that identifies the exact state of every record	The dashboard headline in the README
Which files count as safety-relevant, and in which class	Safety-relevant paths, owned by WP-P-01

Everything is public. Read access is a clone of the repository at the baseline commit; the WP-K-04 access row adds vehicle and installation records and interviews with the role holders.

How independence is recorded

• The levels I0 to I3 and who can reach each one today are in WP-M-06 §3.
• A confirmation record is written by the named reviewer at the required level, states that independence in writing, and is stored under 10-safety-case/confirmation/ using the WP-P-05 §7.2 template.
• Only a review record in case/reviews/ can move a claim or evidence item to accepted. The validator rejects an accepted object whose review reference does not point to an accepted review that lists it.
• What does not count. A passing CI run. An AI-generated pre-review such as the RR-2026-nnn records or the ISO 26262 documentary audit package: these are I0 inputs to a confirmation measure, and say so in their own headers. The ASPICE capability baseline is a self-assessment.

Where the known problems are listed

The project publishes its own counter-evidence. Start with these rather than hunting for it.

List	Where
Findings against the inherited code and process, GAP-nn	Gap assessment
Defeaters attached to claims, DF-nn	WP-K-01 §7 and case/defeaters/
Assumptions the argument rests on, AOU-nn	WP-K-01 §5
Open items of each work product	The last section of every work product, counted per gate in the gate skeletons
Project risks, R-nn	WP-M-07 risk register
Questions the lead has decided, and the ones still open	Decision register; see How decisions are made
The lead's recorded deviations where a measure was deferred	Decision register entries DQ-013 (gate G0 with its reviews as open conditions) and DQ-010 (independent reviewer) in register.yaml

How to send findings

• A finding from a confirmation measure becomes a GitHub issue labelled confirmation-finding, handled under WP-P-03, and is listed with its ID in your record (WP-M-06 §10).
• A comment on a work product short of a formal review goes to the pull request that changes it, or to an issue naming the work product and section.
• A vulnerability goes through SECURITY.md, never a public issue. See Reporting a safety concern.
• A question goes to Discussions.

Taking the role on

Engaging an assessor is a decision of the project lead, recorded in the decision register (DQ-009 for functional safety, DQ-024 for cybersecurity). If you are considering it, the shortest route is an issue or a discussion thread saying so, with the competence evidence WP-M-04 §4.4 asks for. Whether a legal entity is needed for the contract is itself a recorded decision (WP-M-04 OI-5).

Assurance status represents recorded engineering evidence and review state. It does not constitute certification or approval for unsupervised operation.