155 engineering requirements

The 2027 rulebook is written to be judged, not to be designed from. This page turns it into 155 shall-statements, each traced to a rule clause or a Q&A ruling, each given a mission, a type and a primary check. Half of them are gates: a rover can be legal, score well, and still fail on mass, size, power cut-off or a document deadline. The full table is filterable by domain, mission and type, and it is the yardstick every subsystem chapter in this book is measured against.

What a traced requirement is

Each row pairs a shall-statement with its trace, its missions, a type, a primary check, the affected subsystems and a note. The identifier is stable and is never renumbered when a row is inserted, so a cross-reference from a subsystem chapter stays valid. The trace names the rule clause, the Q&A question, or both, and says derived when the requirement follows from a rule without reproducing its wording. The mission field names the events the row applies to. The type says whether the row is a gate or a target. The check names the primary method. The affected subsystems field is the first pass at an interface list. The notes carry the derivation, the penalty, the 2026 contrast or the missing value.

A derived row is not optional. It is the difference between a rule and an activity: the rule says the sample comes from at least 10 cm below the surface, and the derived rows say what the sampling mechanism, the depth record and the operator interface have to do about it.

The rulebook traces are written as clause references, so the table can be read against Rules, limits and the field clause by clause S-URC27-RULES. A Q&A trace resolves on Q&A rulings, and every derived row is a statement about this rover rather than a quotation S-URC27-QA.

The eleven domains

Two domains carry the gate risk: SYS, where 13 of 14 rows are mandatory, and OPS, where 11 of 12 are. Two carry the performance risk: ARM and SFT, where 31 of 40 rows are scoring-driven and the task weights are not published S-URC27-RULES.

The full table

The table below is the complete set. Each column sorts; domain, mission and type filter; the search box matches the requirement text and the notes. Use the identifier links to reach a single row, and the download link under the table for a spreadsheet.

Three types, two failure modes

The distinction decides where the margin goes. A mandatory row with no margin is a risk of losing an event; a scoring-driven row with no margin is a risk of losing points inside an event S-URC27-RULES. The two are budgeted differently.

What each check method means

The count is by the first method named, so a row that reads test and inspection is counted as a test. Many mandatory rows are inspections at a weigh-in or a document review, which is why a team can pass every functional test and still fail the table S-URC27-RULES.

Where the coverage is thin

Three limits are worth stating before the table is used as a checklist.

• 102 rows trace to a clause and not to a Q&A ruling. They are only as good as the clause reading, and the 2027 rulebook has clauses whose wording changed in the rewrite, so a requirement inherited from an earlier year has to be re-read rather than carried over.
• The Q&A can move. The 2027 page was revised twice after publication, and 51 rows depend on it S-URC27-QA. A ruling that changes rewrites the trace of every row that cites it.
• The scoring rows carry an unpriced gap. The 2027 task weights for three missions are not published, so a scoring-driven row says what capability is needed and cannot say what it is worth S-URC27-RULES.

Rows a first build is most likely to miss

What the rules do not publish

Every row below is a value a design or a test would use, that no 2027 document gives. The right-hand column is the action that produces a usable number S-URC27-RULES S-URC27-QA.

The check plan in twelve steps

1. Run the weigh-in as a test. Build a 1.2 m gauge, weigh every mission configuration and the 70 kg aggregate, and time the procedure inside a 15-minute setup.
2. Time the clock. Fifteen minutes of setup, ten of teardown, ten of retrieval and the ten-minute transition between Autonomy and Equipment, with the real command post and the real cable.
3. Test the stop as one action. With compute and radios running, confirm that no subsystem keeps power from any battery.
4. Test the link at 1 km and inside a radio shadow, in each of the three 900 MHz sub-bands, and confirm that the rover keeps driving and signals arrival by LED.
5. Measure the stop distances. Run the 1 m route stops and the 3 m astronaut stops on natural terrain and report the distribution, not the best pass.
6. Build judge-like mock-ups for every servicing task and record the forces and travels the rules omit.
7. Test depth and mass. Take at least 5 g from below 10 cm in soil that ranges from easy to very hard, and verify the cache seal when inverted.
8. Run the life detection on blind samples and controls. A bench result is not a field capability.
9. Test typing with 3, 4, 5 and 6 letter keys, with backspace corrections, no key repeat and a judge reset.
10. Test the suit for heat, camera and microphone link, two-way audio and helmet removal, with the electronics that count in the mass and cost budgets.
11. Keep every field test away from MDRS. Use a permitted off-road site and plan the campaign before travel.
12. Collect the evidence as the tests run. The review is a mission worth 100 points and a gate on the other 400.

Further reading

• Rules, limits and the field holds the clauses these rows trace to.
• Q&A rulings holds the answers behind 51 rows.
• Missions and scoring explains what each mission rewards.
• 110 engineering problems turns the largest subset of these rows into build tasks with acceptance criteria.
• Deadlines carries the document rows in the operations domain.