For the assessor

For the assessor

This page is for the person asked to look at the fork independently: a confirmation reviewer, a functional safety auditor or assessor, a cybersecurity or ML reviewer, a notified body's examiner, 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 lead decided not to engage an assessor for now and to revisit it at G1 (decision register DQ-009).

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 until G1	WP-M-02 §3.1; decision register entry DQ-009 in register.yaml
Every role in the safety plan resolves to the maintainer; roles needing independence are 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"; no standard is held	WP-M-06 OI-1; decision register DQ-011
The concept-phase package (safety case, DFMEA, requirements, test plan) is an input the author wrote; nobody has reviewed it	Gap assessment §1
No work product is approved or baselined; the rest are drafts and skeletons	WP-M-00 §3
Nothing has been tested: the fork has powered no arm	WP-V-07, test sites

Rendered from the register at every wiki sync.

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 three-layer argument the whole case rests on (§6), how each standard is used (§4), the tailoring decisions (§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 activities per phase (§4), the early-implementation rule for the bench safety hardware (§4.1), gate reviews (§10)
3	WP-M-06 confirmation measures plan	What you would be asked to do (below), the independence scheme and its mapping onto IEC 61508-1 §8 (§3), the assessor qualification (§6.1), the schedule (§9), the records (§10)
4	WP-M-13 regulatory conformity strategy	The Machinery Regulation route, the Annex I Part A threshold, the technical documentation mapping, the non-commercial licence
5	WP-M-00 work product register	The gates and their exit criteria (§2), every work product with its clauses, gate and status (§3)
6	Process model and maps	How the disciplines' work fits together per phase, the cross-domain interfaces, the confirmation measures each gate needs and whether they have been performed, the readiness of each gate
7	Baseline gap assessment	What the project itself found wanting in the inherited arm, the package and the process, finding by finding, with the standard each bears on
8	WP-K-04 functional safety assessment	The report template you would fill in, including the independence declaration

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.

• Confirmation reviews CR-01 to CR-12, each naming the work products, the planned independence level and the gate (§4.1). The risk assessment (CR-02), the safety functions and their required PL (CR-04), the PL calculation (CR-07) and the safety case (CR-12) are the ones that carry the argument.
• 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), in the sense of IEC 61508-1 §8 and the validation of the achieved PL against the required PL.
• Cybersecurity review and assessment CS-I1 and CS-A1 under IEC 62443 (§7).
• ML reviews ML-R1 to ML-R3 of the position that no learned policy carries a safety function (§7).
• Conformity assessment NB-1 by a notified body, if the route the lead chooses needs one (§8, DQ-012).

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 reBot-DevArm development at Seeed Studio, competence in machinery functional safety with evidence, 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
The commit of this record and of the software forks, once they exist	The Baseline field of every work product; the gap assessment header
The reference configuration the claims apply to	WP-M-01 §3.1 and the reference arm page
Which files count as safety-relevant, and in which class	Safety-relevant paths, owned by WP-P-01
Baselines, snapshots and controlled copies	Baselines in case/baselines/ (BL-001); snapshots and controlled copies to come with WP-P-04

Everything is public. Read access is a clone of the repository at the baseline commit.

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 record template.
• What does not count. A passing CI run. An AI-generated pre-review. A self-assessment such as the ASPICE capability baseline. The trace memo of the concept-phase package, which the author wrote about their own workbooks.

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 arm, the package and the process, GAP-nn	Gap assessment
Open items of each work product	The last section of every work product, counted per gate in the gate skeletons
Open cross-domain interfaces	The readiness section of each process map
Project risks	WP-M-07 (skeleton; the top risks are in WP-M-01 §9)
Questions the lead has decided, and the ones still open	Decision register; see How decisions are made

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.
• 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.

Taking the role on

Engaging an assessor is a decision of the project lead, recorded in the decision register (DQ-009 for functional safety; the cybersecurity assessor and the notified body are open items of WP-M-06 and WP-M-13). If you are considering it, the shortest route is an issue saying so, with the competence evidence WP-M-04 asks for.

Assurance status represents recorded engineering evidence and review state. It does not constitute certification or approval for operation with a person in reach.