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.
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.
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. Carries a correction, left visible: an earlier internal claim about which rules the invariant set covers was false and had propagated to nine places.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
TYPE-NNN. They are stable
and are never reused, even when an artifact is superseded or deleted. They do not
correspond to any identifier in the source system.
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.
| Part | Contents | Status |
|---|---|---|
| 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.
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.
It goes to Patrick directly, and he will call. If you would rather move first, the contact page reaches the same inbox.