Back to the essay
Requirements Library · Public Preview

The FirePro Requirements Library

A wildfire detection and initial-attack programme that is designed and unfunded. This is the design — what the system must do, what it must refuse to do, what would prove it working, and what remains unknown.

The accompanying essay argues that a detection system for Oregon sits designed and waiting on a funding decision rather than on an invention. It also made a promise: that when the design work was ready it would be shown rather than described secondhand. This is that showing.

Nothing described here has been built. No hardware exists, no agency has been approached, and no line of production code has been written. A programme that cannot yet be built can still be specified to the point where a reviewer can find its faults, and that is the entire claim being made. A specification is worth reading when it is falsifiable — when it names the observations that would show it wrong, the assumptions it proceeded under, and the places it is silent.

Where this library comes from

Two bodies of practice, deliberately hybridised. The first is the BABOK Guide v3, published by the International Institute of Business Analysis, cited throughout by clause number and clause name. Every characterization of it here is our own wording, so a reader with a copy can check our reading against the clause rather than take it on trust. No text from the guide is reproduced.

The second is an internal specification-driven method developed in-house, referred to as the House Method. Where the two agree, this library says so once. Where they genuinely disagree, it says which one the library follows and why. Those disagreements are the most useful content in the preview, and they are marked rather than blended — a methodology page that smooths its sources into consensus has hidden the only part a practitioner could argue with.

One point of provenance, because this library is strict about it elsewhere. These pages are derived from the programme’s design corpus through a structured inventory of it, rather than reproduced from the source artifacts directly. The structure, the goals, the rules and the gap list are faithful to that corpus; the full-depth material — every artifact at full section depth, with its evidence and traceability blocks intact — is held privately and released after a conversation. So a figure quoted here should be read as reported at one remove, not as a quotation from a signed artifact. The library asks elsewhere that a status claim rest on the primary artifact rather than on a secondary record’s assertion about it; this preview does not yet meet its own standard on that point, and says so rather than letting the omission read as compliance.

What is published, and what is not

The programme

The charter: what it is, and what it stands on

The problem stated narrowly enough to be wrong, the five bounded contexts the design is organised around, and the ten design invariants with the artifact that enforces each.

The programme

What success would look like, and what would prove it wrong

Six goals for the programme itself — distinct from the goals of the practice that produced the specification. Each carries a measure and the observation that would falsify it. None has a baseline, and the reason is on every row.

The programme

What it will not do, and what would stop it

Six permanent non-goals, seven halt conditions, and eleven risks — seven from the source and four created by gaps in it, marked as such. Two of the risks have no engineering answer at all, and they are why the programme is shaped the way it is.

The programme

Who this lands on, and who can stop it

Six role journeys and the authority model underneath them. The property worth more than the rest: the roles that can stop an action are not the roles that can command one — a crew member’s no-drop hold beats the duty officer’s authorisation, and no screen resolves it the other way.

The programme

The mechanism, including the three ways it fails

Six specified sequences, three of them failure paths carried at the same depth as the successes — because failure is where an invariant is either true or decorative. Includes the principle underneath all six: degrade toward noise and toward safety, never toward silence or toward capability.

The programme

Six milestones, ordered by authority rather than ambition

Why the hardest permission is asked last, why the two programme-ending assumptions are tested at opposite ends, and the rejected alternative presented at full strength. States a defect in itself: the last two milestones name no failing observation.

Published in full

The eight screens, and what each refuses to do

Every operator surface the system specifies, each published with what it enforces beside what is deliberately absent from it. The absences are the point: no auto-confirm at high confidence, no override for a failed safety gate, no authorise control at all when the ground is not the agency’s to attack, and a crew member’s no-drop hold that the duty officer cannot override. Three screens are rendered from the specification; all imagery is generated and labelled as such.

Published in full

The method: seven artifact categories

What the library recognises as an artifact, where each category comes from in the BABOK Guide and in the in-house method, what each one contains, and the completeness test you can apply to it yourself. Includes the four places the two source methods genuinely disagree and which one this library follows.

Published in full

Goals and how they are measured

Six goals for the practice, each with a measure, the instrument that captures it, the collector, the frequency, and the observation that would falsify it. Five of the six have no baseline yet, and the page says which and why rather than presenting a figure it does not have.

One artifact, complete

RULE-004 — a detection claim carries its confidence

A single business rule worked end to end through all fourteen sections of the standard template. It is published complete, including an acceptance criterion recorded as currently failing and an evidence section recorded as empty, because a worked example that hides those teaches the wrong thing.

Published in full

What this corpus does not cover

Seven gaps the practice found in its own requirements set, including one — the near-total absence of adversarial security analysis — that is the largest and least defensible. Published because a requirements practice that cannot find its own gaps is not working.

Concept draft

The law this would need in order to exist

The Wildfire Early Detection Partnership Act, drafted in Legislative Counsel form so its gaps sit where a drafter would look for them. Nobody has introduced it, no legislator has seen it, and no sponsor is attached — the bracketed figures are placeholders a drafter would price, not positions anyone has taken. It is here because the programme’s hardest dependencies are statutory rather than technical: who holds the federal airspace authorization, who pays across the years it has prevented nothing measurable, and how insurers and utilities contribute without it becoming a subsidy. Its section 6 is the argument in miniature — the assessment disappears for any owner holding a current defensible space certification, so public money for detection cannot quietly displace private responsibility for fuel.

The rest carries operational specifics — siting, spectrum, platform and vendor selections, tuned numeric thresholds, named counterparties and jurisdictions. Those are withheld as a publication decision, not because the corpus lacks them. Where a number has been removed from a published page, the sentence says so rather than reading as though no number exists.

Conventions used throughout

The library as published

Thirty-nine parts. The status column is the honest answer to what is actually being shown, and it is printed here rather than discovered after a request.

PartContentsStatus
Front matter Purpose, method note, conventions, the standard artifact template Full
I.1 The need the programme addresses; the current state On request
I.2 Practice goals with measures, baselines, instruments and falsifiers Full
I.3 Programme scope: in, out, and the boundary cases On request
I.4 Constraints, assumptions with falsifiers, declared halt conditions On request
II.1 Decision register — identifier, title, authority, status Sample
II.2 The decisions, each with costed alternatives, forgone value and a dissenting view On request
II.3 Superseded decisions, retained with successor pointers On request
III.1 Need register, grouped by the goal each serves Sample
III.2 The needs, each with acceptance signals stated before implementation On request
III.3 Transition needs, held separately because they retire On request
III.4 Needs considered and not taken, with reasons On request
IV.1 Business rules register, each rule declarative with enforcement as metadata Full for one rule
IV.2 Entity definitions with attributes, relationships and governing rules On request
IV.3 Controlled vocabularies On request
IV.4 Glossary — binds every other part Sample
V.1 Value attributes, agreed before any criterion below On request
V.2 Acceptance criteria (pass/fail) Sample
V.3 Evaluation criteria (scaled, for ranking options) On request
V.4 Quantified non-functional standards with populations and denominators On request
V.5 The checks: what runs, in what order, what a failure blocks Sample
V.6 Refusal evidence — each blocking check witnessed refusing Empty, and declared empty
V.7 Bypass procedure and bypass log On request
VI.1 Structure map — how the parts form a coherent whole On request
VI.2 Views, one per audience concern On request
VI.3 Trace matrix across goals, needs, rules, entities, artifacts and checks On request
VI.4 Coverage gaps, each classified correct-by-design or real Sample
VI.5 Generation and freshness — how this part is derived and guarded Full
VII.1 Measure results against baseline and target Not applicable — unbuilt
VII.2 Variance analysis Not applicable — unbuilt
VII.3 Performance reading and value reading, reported separately Not applicable — unbuilt
VII.4 Limitations within the solution, and in the surrounding organisation Sample
VII.5 Evidence appendix — captures, outputs, references, all timestamped Not applicable — unbuilt
VII.6 Lessons carried forward On request
Appendix A Index by identifier, all parts On request
Appendix B Index by goal — every artifact serving each goal Sample
Appendix C Change log, library-wide, append-only On request
Appendix D Clause map — the source clause behind each convention Full
Appendix E Open questions and known gaps Full

Three rows are worth noticing before you read anything else. Part V.6 is empty and says so. The whole of Part VII is not applicable and says so. Appendix E is published in full and is the longest thing here that reflects badly on the corpus. Those three facts are the argument for the rest.

Requesting the rest

The parts marked on request are released after a conversation. That is not a formality and it is not a mailing list: the material carries operational detail about a system intended to operate in public airspace alongside crewed aircraft, and who holds it is a decision worth making one person at a time.

A phone number is required because the conversation happens by phone. If you would rather not provide one, use the contact page instead and say what you are looking for — that route is open and always will be.

What happens to this: it is stored so the conversation can happen, and used for nothing else. It is not added to the newsletter and not shared. You can have the record deleted at any time by asking via the contact page. The privacy page describes it in full.