Repository navigation
How decisions are made
The project lead is the safety authority and often reviews from a phone. The process keeps the questions put to them few, and each one quick to answer. The rules are in the decision register README; this page is the short version.
Rendered from register.yaml by infographics.py at every wiki sync; no number on it is typed by hand.
- Risk acceptance
- Required Performance Level and hazard scope
- Arm behaviour defaults and operating-envelope limits
- Money, hardware, the assessor
- Roles and independence
- Gate go or no-go
A reversible technical choice is made by the engineering side, recorded as assumed with the recommended option, and the lead can change it later. A task is not a decision: it stays in the work product that owns it.
Every entry in register.yaml stands on its own. No bare
IDs. A question carries:
- the question in plain words;
- two or three lines on what is at stake;
- two to four options, the recommendation first, each with what it does and costs;
- how hard it is to undo (
easy,revisit,hard), what it blocks, and which gate it belongs to; - the sources: every document that raised it;
- one picture when it shows the difference between the options.
Generated by fig_lifecycle.py from the lifecycle table of the register README; CI fails if stale.
| Status | Meaning |
|---|---|
queued |
Recorded but not asked yet. May name questions to settle first. |
open |
Asked; in the current batch of about ten. |
answered |
The lead picked an option, on the inbox page or in chat. |
assumed |
No answer by the proceed-after date; the recommended option was taken. Allowed only when easy to undo. The lead can still change it. |
applied |
The change is made. The entry names the commit and where the decision is recorded. |
withdrawn |
The question no longer applies; a note says why. |
A hard question is never assumed and never applied without an answer from the lead. A revisit question waits
for an answer too, but can be reopened at the gate it names. Once applied, the decision is recorded where the
project keeps that kind of decision: the decision log of WP-M-07
for strategic decisions, otherwise the work product that owns the item. The register entry points there.
The questions open today are the ones that shape everything below the first gate: which arm to assess first (the B601-DM that has a BOM, or wait for the RS variant), which regulatory frame (EU machinery, US, or both), which operating envelope the first safety case covers (the supervised bench alone, or the classroom too), what Performance Level the stop functions must reach, whether any collaborative claim is made (contact permitted, or separation only), what emergency-stop hardware to fit before any powered test, whether to fork the software that moves the arm, whether the learned policies are inside the item, when to engage an assessor, and who may approve while the project has one person. Ten more wait in the queue: the standards purchase, the conformity route, the security level target, the camera default, gripper holding, the bench speed ceilings, the RS variant, the supply disconnect, the supplier data request and where the safety layer runs. Each open question is a card on the inbox page with its options and recommendation.
- Sort before asking. Only what the lead alone can decide reaches the register as a question.
- Batches of ten. About ten questions are open at a time, those that unblock the most. The rest wait as queued, written ahead so the next batch is ready.
-
Answer on the inbox page or in chat. The inbox page is generated from the register by
build_inbox.py; its answers are copied back into the register at the start of the next session. - Explanations first. Requests to explain a question are answered before anything new is asked.
- Apply and record. The change is made, the entry points to the commit, and the next ten open.
check_decisions.py checks the register against these
rules in the assurance workflow on every pull request.