Written guide

Requirements Altitude

People taking discovery usually cannot tell what altitude a piece of information is at. They chase configuration-level detail with no filter, collect goals and process notes that never become anything scopeable, or force premature confirmations. The missing piece is almost always the mid-level: a specific, technology-agnostic statement of what the system must do.

This is the written guide. Eighteen modules, three appendices. Same altitude as theFour Laws — a standing reference, not a brochure. A paid course can sit on top of this later. The writing is the product until then.

The four altitudes

LevelNameWhat it capturesTest
L0Business OutcomeGoal, pain, success criteria — no system named.True regardless of system used.
L1Process / CapabilityWorkflow, actors, sequence — still system-agnostic.Diagrammable with no system named.
L2Functional RequirementSpecific, scopeable capability. The missing middle.Two engineers would agree on scope.
L3Detail / ConfigurationFields, APIs, exact rules, edge cases.Resolvable without further client input.

The core discipline: no L3 question on a topic thread until an L2 bridge statement exists for it. L2 is authored by the practitioner. It is not transcribed from the client.

Every statement also has a source. Tagging altitude without tagging who said it averages together people who do not actually agree. Start atthe model, keepthe field card visible on calls, or read the problem statement that opens the guide.

The public essays The Missing Middle andThe Reset Is the Project are the short versions of modules 1 and 12. This section is the full argument.

The guide

The model

In the field

After the call

Reference