How the repository is organized

How the repository is organized

This repository holds three things: upstream's hardware record, merged and never edited here; the concept-phase engineering package the fork published first; and the assurance record the fork adds around them. The software that moves the arm lives in upstream repositories until the fork the lead approved (DQ-007) is made.

Generated by make_assets.py. Left: what the fork inherits, classed by the safety-relevant file list. Middle: the record. Right: what is generated from it and never edited by hand.

What the fork inherits

Source	What it is	How it is handled
hardware/	Upstream's hardware record: the v1.1 STEP assembly, the printed, machined and purchased-parts BOM, the thermal performance test	Updated only by merging from Seeed-Projects/reBot-DevArm, with an impact analysis; class SR-Q
motorbridge SDK, ROS 2 driver, LeRobot and Pinocchio integrations, the web UI	The software, in upstream repositories and on the Seeed wiki	Described in the record, not changed, until the fork the lead approved (DQ-007) is made; afterwards forked, pinned and classed SR-Q, with the controller safety layer SR-A
reBot_DevArm_*.xlsx, .docx, .pdf at the root	The concept-phase engineering package of 2026-05-04: safety case, DFMEA, requirements, architecture, test plan, trace memo	An input to the record, never edited; its identifiers are kept, its gaps re-stated in the gap assessment

The assessed baseline is named in the gap assessment header. Upstream's README stays at the top of the fork's README; the fork is not affiliated with or endorsed by Seeed Studio.

This repository

Path	What it is
assurance/	Every work product, analysis, decision and review
assurance/process/	The integrated process model: activities, lanes, interfaces and gates as data; generated process maps
assurance/01-management/decisions/	The decision register and the inbox page builder
assurance/tools/	The folder index generator, the link and table checkers
docs/	The architecture overview and the generated README figures
tools/wiki/	The wiki build tool and infographics
wiki/	These pages
.github/workflows/	The assurance checks and the wiki sync

Changed by pull request to main and checked by the workflows below.

The assurance tree, folder by folder

Folders are numbered in lifecycle order. Each work product is named WP, a letter for its area, and a number; the glossary decodes the letters. The authoritative table, with the standard clauses each folder answers to, is in assurance/README.md, and each folder's README is generated from the register.

Folder	Prefix	What it holds
00-assessment/		Gap assessment of the inherited hardware record and the package, GAP-01…GAP-36
01-management/	WP-M	Assurance strategy, safety plan, confirmation measures, regulatory strategy, cybersecurity and ML plans, upstream and supplier management, impact analysis, the decision register
02-concept/	WP-C	Machine definition, operating envelopes, risk assessment, safety functions and required PL, risk reduction concept, interaction and misuse, cybersecurity and ML concepts, insufficiency analysis
03-system/	WP-S	Safety requirements specification, SRP/CS architecture, stopping and separation budget, safety-chain I/O, cybersecurity architecture, system verification
04-hardware/	WP-H	Safety-chain hardware, electrical safety, failure analysis, PL calculation, component qualification, mechanical analysis
05-software/	WP-W	The controller safety layer and the hardened host software: requirements, architecture, safety analysis, units, verification, safety parameters, ML engineering
06-validation/	WP-V	Safety validation, stopping and holding tests, collaborative validation, E-stop validation, fault injection, cybersecurity validation, the test operations hold point, field trials
07-supporting/	WP-P	Configuration, change, problem resolution, documentation, review, traceability, tool and component qualification, release
08-analyses/	WP-A	FMEA, FTA, common cause failure, STPA, independence of the safety chain
09-production-operation/	WP-O	Assembly and commissioning, operation, information for use, field monitoring, incident response
10-safety-case/	WP-K	The safety case, the technical documentation index, the cybersecurity case, assessment reports, release record; gate and confirmation records
process/, trace/, case/	WP-P-11, WP-T-01	The process model with its maps and swimlane figures, the trace items (hazards, safety functions, assumptions of use) and the Living Safety Case records with their validator and dashboard
sim/	WP-P-12	The hazard scenes: upstream's CAD posed by a joint rig, one Blender scene and review dashboard per hazard that a picture helps; pictures only, no evidence credit (Hazard scenes)

What checks a change

Every workflow lives in .github/workflows/.

Workflow	Runs when	What it checks
assurance	Every pull request and push to main	The Living Safety Case records, their validator tests and the dashboard; the decision register's lifecycle rules and its figure; the folder indexes against the register; the process model with its maps, gate skeletons and swimlane figures; the README figures against their generator; relative links; Markdown tables
wiki	Every pull request, and every push to main	Builds these pages and checks that every link target still exists; on a push, syncs them and the rendered infographics to the GitHub wiki

The link and table checks skip hardware/ and the upstream README translations: they are upstream's content. A passing workflow accepts nothing on its own. It can be evidence that a reviewer accepts; see contributing.

What is generated

Generated	From	By
Folder READMEs under assurance/	WP-M-00 §3	assurance/tools/folder_index.py
Process maps and gate skeletons	assurance/process/model/, WP-M-00, WP-M-02, WP-M-06	assurance/process/tools/process_model.py
Process swimlanes, lifecycle grid and interface figures	The same model	assurance/process/tools/process_figures.py
Living Safety Case dashboard, status, badge and README blocks	assurance/case/ records	assurance/case/tools/generate_dashboard.py
README and wiki figures (hero, standards, architecture, roadmap, lifecycle, status card, standards map, repository map)	The data in the generator and the records	docs/assets/rebot/make_assets.py
Decision lifecycle figure	The decisions README	assurance/01-management/decisions/fig_lifecycle.py
The decision inbox page	register.yaml	assurance/01-management/decisions/build_inbox.py
Wiki infographics	register.yaml, WP-M-00, the safety-relevant file list, the workflows	tools/wiki/infographics.py at sync

None of them is edited by hand; CI fails when one is stale.