DOCS

Every value block in a Markdown file of [docs] files equals its source – a graph value, a parts entry field, the simulation result or the text of a need or requirement of [project] requirements (req:) – and every source quoted in a block or in a placeholder of the schematic notes exists; a need or requirement quoted is not dropped.

• documents quote the design data: every value block of [docs] files equals its source – a requirement's text too (req:, 3.6) –, every source of a block or a schematic-note placeholder exists, a quoted need or requirement is not dropped – run by edakit docs and the gate's stage G, not by edakit check (6.6) – finds e.g.: a description still on an old graph version, a current that changed with R1, a README with last month's R-4

Why

Numbers in descriptions, decisions and schematic notes are typed once and then lag behind the circuit: a resistor swapped, a margin changed, a part removed. Reviewers and the next session read the stale number as a fact. A requirement copied into a README lags behind the requirements file the same way, and a dropped one still reads as if it held.

What to do

edakit docs --write fills in the current values. A source that no longer exists: quote the part or net that replaced it, or drop the block. A dropped need or requirement: quote the entry that holds now, or drop the block; req: needs [project] requirements. Documents are in no hash, so this voids no sign-off.

Sources

1. edakit handbook 6.6 and 3.6
2. Concept docs/concepts/done/requirements.md, 'Scope': the documents quote a requirement by its ID in a value block (step 3.5)

Replaces G-19

edakit.toml names the project's requirements file in [project] requirements. Without it the point is open, as a required sign-off is: edakit check reports it and passes – a project being set up can still commit –, edakit check --release and the gate do not release.

• requirements file named: [project] requirements in edakit.toml names a file (3.6, 10.4) – open, like a required sign-off: edakit check passes, --release and the gate do not – finds e.g.: a project that never wrote down what its circuit must do

Why

The requirements are the pipeline's input: what the boards must do, in the words of those who want it. Without them the gate can say that the circuit is consistent, but not that it does what it is for, and the reviews M-1, M-5 and M-6 judge the design against nothing written. Since the bell and the tree have their files, every project has one before it orders, as it has its sign-offs.

What to do

Write the file with the skill requirements (/edakit:requirements) and name it: [project] requirements = "hardware/requirements.toml"; a variant names the main project's file and its own.

Sources

1. edakit handbook 3.6 and 10.4
2. Concept docs/concepts/done/requirements.md, decision 5: optional until the bell and pytree have a file; then required, as M-1, M-5 and M-6 are
3. Implementation plan docs/concepts/done/implementation-plan.md, step 4.5; the owner's word of 2026-11-01: build it now, the bell has its file

In the requirements file of [project] requirements, every reference of a requirement that is not dropped resolves: a need or requirement in from (N-…, R-…) stands in the files, a manual check in from or in verify signoff (M-…) is one of the sign-off file or one the gate requires, a rows pattern that starts with a code names a code of the catalog (one that starts with a check ID of before is a finding naming the codes that replace it), and verify script names an entry [scripts.<name>] of kind check or the id of a [[release.stages]]. A from that names a dropped need or requirement is a warning. About a draft – status draft, or no status – every finding is a warning in edakit check and information in the gate: a draft never blocks; it is an error once the user accepts the requirement.

• requirement references resolve – DOCS.ref to DOCS.draft only with [project] requirements (3.6), on every entry that is not dropped: a need or requirement in from (N-…, R-…) is in the files, a manual check in from or in verify signoff (M-…) is one of the sign-off file or a required one (8.2), a rows pattern that starts with a code names a code of the catalog – a check ID of before is a finding with the codes that replace it –, a script is an entry [scripts.<name>] of kind check or the id of a [[release.stages]]; a from that names a dropped need or requirement is a warning. Decisions, standards and words in from are not resolved. About a draft every finding is a warning – an error once the user accepts the requirement (3.6) – finds e.g.: from = ["N-12"] for N-2, rows = "LIM.vv *", rows = "E-3 *", signoff = "M-7", a requirement that still comes from a dropped need

Why

A requirement is traced through its references: where it comes from and what tests it. A typo in an ID – N-12 for N-2, LIM.vv for LIM.v, M-7 for M-6 – breaks the chain without anybody noticing: the gate finds no protocol row for the pattern and the requirement fails for the wrong reason, or it points to an origin that does not exist. A requirement that comes from a dropped need may no longer be wanted at all.

What to do

Correct the ID, or add what it names: the need or requirement to the requirements file, the manual check to the sign-off file, the check to [scripts]. A from that names a dropped entry: drop the requirement too, or name what it comes from now. Decisions (D-…), standards and documents in from are words to edakit, it does not resolve them.

Sources

1. edakit handbook 3.6, 8.7 and 10.4
2. Concept docs/concepts/done/requirements.md, 'Traceability and the gate' and its decisions of 2026-10-28
3. The user's decision of 2026-10-28, after step 1.6: a draft never blocks – errors and blocking start with status = "accepted"

Replaces G-20

Every accepted need of the requirements file is named in from of at least one requirement that is not dropped.

• accepted need has a requirement: every accepted need is in from of a requirement that is not dropped – finds e.g.: a need the user accepted that no requirement made testable

Why

A need says what someone wants, in their words; only a requirement makes it testable – a quantity, a limit, a condition – and points to its evidence. An accepted need that no requirement takes up is a wish the circuit is never measured against: the chain from the need to the evidence ends before it starts.

What to do

Write the requirement that follows from the need (from = ["N-…"], with binding and verify), or name the need in the from of an existing requirement. A need that is no longer wanted gets status = "dropped" with its reason.

Sources

1. edakit handbook 3.6 and 10.4
2. Concept docs/concepts/done/requirements.md, 'Traceability and the gate': every need leads to requirements

Replaces G-21

Every requirement of the requirements file that is not dropped has evidence: at least one entry in verify – rows of the gate protocol, a manual check, a project script or a step of the acceptance test. For a draft – status draft, or no status – it is a warning in edakit check and information in the gate; an error once the user accepts the requirement.

• requirement has evidence: every requirement that is not dropped has verify – for a draft a warning, an error once accepted – finds e.g.: a requirement the gate has nothing to evaluate for

Why

A requirement without evidence is a promise nobody checks: the gate cannot tell whether the circuit meets it, and its binding decides nothing. The evidence often exists already – a simulation scenario, a check, a review – and only the pointer to it is missing. While a requirement is a draft, the file is being written and its evidence may still be missing: the pre-commit hook lets it pass; once the user accepts it, the gate must be able to evaluate it.

What to do

Add verify: rows of the gate protocol ({ rows = "SIM.state * J1 current from the supply" }), a manual check whose note names the requirement ({ signoff = "M-1" }), a project script ({ script = "…" }) or a step of the acceptance test ({ accept = "…" }) – what only a delivered board can show is an acceptance step.

Sources

1. edakit handbook 3.6, 8.7 and 10.4
2. Concept docs/concepts/done/requirements.md, 'Traceability and the gate': every requirement ends in evidence
3. The user's decision of 2026-10-28, after step 1.6: a draft never blocks – errors and blocking start with status = "accepted"

Replaces G-22

A need or requirement of the requirements file that is a draft – status draft, or no status – is a warning in edakit check until the user accepts it or drops it with a reason. In the gate it is information: a draft binds nothing yet – it never blocks the release and needs no acceptance; section 11 of the protocol lists a draft requirement with its evidence as evaluated.

• draft not approved: a need or requirement with status = "draft", or without status, is a warning until the user accepts or drops it; in the gate information – a draft never blocks the release and needs no acceptance (8.7) – finds e.g.: a requirement Claude wrote and nobody approved, which the release is not held to

Why

Claude drafts requirements, only the user approves them: like accepting a warning, it is one of the user's decisions. Until then the requirement binds nothing – the gate evaluates and lists it, but does not hold the circuit to it: a draft left standing is a requirement the release was never held to.

What to do

The user decides: status = "accepted", the text changed and then accepted, or status = "dropped" with a reason. Nothing to accept in the sign-off file: a draft does not hold up the release.

Sources

1. edakit handbook 3.6, 8.7 and 11.4 (working agreement 4: only real decisions go to the user)
2. Concept docs/concepts/done/requirements.md, 'Proposal: the requirements file': the agent drafts, the user approves
3. The user's decision of 2026-10-28, after step 1.6: a draft never blocks – errors and blocking start with status = "accepted"

Replaces G-23

Every requirement of the requirements file that is not dropped names someone who stated it. A source that is given is judged by itself: it names a decision (D-…) or a need (N-…), a file of the project's repository that is not design data, or a date (YYYY-MM-DD: the user with a date). Only a requirement without source is judged by its from: a need or decision, or an entry that is not an ID – a standard the maker chose. Design data is what an edakit.toml of the repository names – graph, parts entries, simulation config, schematic and board files, sign-off file, requirements files, reports and artifacts; a requirement R-…, a manual check M-…, a datasheet, a commit or words count as nothing stated. A warning, for a draft as for an accepted requirement, in edakit check and in the gate.

• requirement names who stated it: a source that is given is judged by itself – a D-… or N-…, a file of the repository that is not design data (git ls-files, without it the files below edakit.toml), a date; without source the from – a N-… or D-…, or an entry that is not an ID. Design data: the files and folders every edakit.toml of the repository names. A warning for a draft too – finds e.g.: source = "sim.json supplies; limits.vin_min_v of U1", source = "locks.pins of every graph; the M-1 notes"; telling a requirement derived but tied to a decision apart is the agent requirements-engineer's

Why

Requirements are the pipeline's input: they say what the boards must do, and the design follows from them. A requirement whose only source is the design's own data says what edakit computes or checks already – a supply above the regulator's minimum input is LIM.range, an error on every board without any requirement. Such entries crowd out the maker's real inputs, each of them voids M-1 and M-6 when it changes, and the reviews must name them in their notes.

What to do

Name who stated it, in their words – the need, the document, the decision, the user and the date – and keep the derived values as the requirement's evidence (verify rows); or drop the requirement when it only restates what edakit checks on every board (status = "dropped", reason = "derived – edakit's catalog checks it").

Sources

1. edakit handbook 3.6 (need and requirement, source and from) and 10.4 (the file's keys)
2. Rule proposal #98 from tgd1975/automatic_christmas_bell: D-32, D-38 and D-39 in docs/decisions.md and docs/requirements-review.md (proposal E), read at 2aec3c5 – 4 of 20 requirements name only design data
3. The owner's decision of 2026-11-01 on #98: a given source is judged by itself, a missing one by from; stated is recognized, not design data guessed; a warning for a draft too