Skip to content

Commit a2d549a

Browse files
committed
docs: add all-bootstraps full-scope gap analysis
1 parent 8525835 commit a2d549a

5 files changed

Lines changed: 1636 additions & 0 deletions
Lines changed: 353 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,353 @@
1+
# All Bootstraps Full-Scope Gap Analysis
2+
3+
**Date:** 2026-03-12
4+
**Author:** Codex (GPT-5)
5+
**Status:** Full-scope semantics-first gap analysis
6+
**Scope:** current `OSHConnect-Python` public-data publisher fleet, legacy `csapi-explorer` bootstrap corpus, helper-layer and artifact-state analysis, and official-source review.
7+
8+
---
9+
10+
## 1. Executive Summary
11+
12+
The bootstrap program is directionally strong, but it is not yet canonically complete.
13+
14+
The current `OSHConnect-Python` fleet is no longer a loose collection of scripts. It already expresses three distinct bootstrap families:
15+
16+
- station-per-system publishers for fixed monitoring locations;
17+
- Pattern A companion-datastream publishers for additional modalities attached to existing systems;
18+
- Pattern C feed-adapter publishers for high-churn external entities and event feeds.
19+
20+
That is real architectural progress. It means the project is already operating with a recognizable public-data modeling language.
21+
22+
At the same time, the fleet still has four major full-scope gaps:
23+
24+
1. **Canonical completeness is broken.** `publishers/iss/iss_publisher.py` exists, but `publishers/iss/bootstrap_iss.py` does not. `publishers/README.md` still tells users to run the missing bootstrap. The current public-data fleet therefore has a real bootstrap hole.
25+
2. **Artifact maturity is uneven.** NWS, NDBC, OpenSky, USGS NIMS, and USGS EQ have meaningful enrichment or total-package support. CO-OPS and Aviation WX do not. USGS water has a research note claiming a total package path that is not present in the current tree.
26+
3. **Semantic maturity is uneven.** OpenSky, USGS NIMS, and USGS EQ now read like deliberate semantic models. NWS, NDBC, CO-OPS, Aviation WX, and USGS water are functionally solid, but they still carry varying degrees of metadata, vocabulary, and packaging debt.
27+
4. **Operational hygiene lags the bootstrap layer.** The shared bootstrap helper now uses hostname verification and required certificates, but active publisher runtimes broadly still disable TLS verification on observation POSTs.
28+
29+
The strongest current fleet members are:
30+
31+
- `publishers/opensky/bootstrap_opensky.py`
32+
- `publishers/usgs_nims/bootstrap_usgs_nims.py`
33+
- `publishers/usgs_eq/bootstrap_usgs_eq.py`
34+
35+
The strongest legacy architectural reference is still:
36+
37+
- `scripts/bootstrap_iss.py`
38+
39+
The most important universal recommendation is not to add yet another publisher first. It is to consolidate the semantic and operational gains already achieved:
40+
41+
- fix runtime TLS verification;
42+
- close the ISS canonical-home gap;
43+
- codify the bootstrap families as first-class shared patterns;
44+
- make artifact state explicit and trustworthy;
45+
- add round-trip conformance probes so rich metadata is verified, not merely posted.
46+
47+
---
48+
49+
## 2. Corpus and Method
50+
51+
This report is based on five evidence classes:
52+
53+
1. direct reading of every active bootstrap in `OSHConnect-Python`;
54+
2. direct reading of every legacy bootstrap in `csapi-explorer/scripts`;
55+
3. direct reading of paired runtimes, sidecars, helper code, current packs, total packs, and prior research notes where they materially affected bootstrap judgment;
56+
4. official standards review for CSAPI-connected design intent, SensorML, SOSA/SSN, SWE Common, and OM concepts;
57+
5. official upstream source review for NWS, NDBC, CO-OPS, AviationWeather, OpenSky, CelesTrak, USGS Water, USGS NIMS, and USGS Earthquake resources.
58+
59+
The report is intentionally `semantics first`.
60+
61+
That means a bootstrap was not scored highly simply because it creates resources successfully. It had to communicate the right meaning, provenance, field semantics, and artifact maturity for that success to be durable.
62+
63+
The full scoring rubric, inventory, and source corpus are documented in:
64+
65+
- `All_Bootstraps_Full_Scope_Gap_Analysis_Appendix_A_Inventory_and_Rubric_2026-03-12.md`
66+
- `All_Bootstraps_Full_Scope_Gap_Analysis_Appendix_D_Source_Corpus_and_Roadmap_2026-03-12.md`
67+
68+
---
69+
70+
## 3. Bootstrap Family Map
71+
72+
| Family | Current members | Legacy / adjacent members | Why It Matters |
73+
|---|---|---|---|
74+
| Station-per-system | NWS, NDBC, CO-OPS, Aviation WX, USGS Water | None directly, though ISS helper extraction influenced the shared mechanics | Dominant current public-data pattern; also the main source of duplicated bootstrap structure. |
75+
| Pattern A companion datastream | USGS NIMS | None direct | First explicit cross-publisher dependency pattern in the active fleet. |
76+
| Pattern C feed adapter | OpenSky, USGS EQ, intended ISS target | Legacy ISS is the strongest precedent | Best fit for feeds where the upstream source is not a stable set of fixed monitoring platforms. |
77+
| Scenario / migration / enrichment | None as primary current publishers | ISS legacy bootstrap, UAS, localizer, v2.5, v3.1, v4, phase2 | Shows what the current helper layer still does not cover and what should not be confused with the public-data fleet. |
78+
79+
Two conclusions follow from this map:
80+
81+
1. The project should stop behaving as if "bootstrap" is one undifferentiated class of script.
82+
2. The current helper layer is strong for public-data publishers, but it is not yet a general connected-systems bootstrap framework.
83+
84+
---
85+
86+
## 4. Fleet-Wide Heatmap Summary
87+
88+
### 4.1 Current fleet
89+
90+
| Bootstrap slot | Topology / model | Metadata | Provenance | Ops hygiene | Artifact maturity | Net read |
91+
|---|---|---|---|---|---|---|
92+
| NWS | Strong | Adequate | Strong | Weak | Strong | Functionally solid station bootstrap with real enrichment history, but still not a final canonical package. |
93+
| NDBC | Strong | Adequate | Strong | Weak | Strong | Strongest current station-family variant, especially because it spans buoy and imagery semantics. |
94+
| CO-OPS | Strong | Adequate | Strong | Weak | Partial | Good bootstrap with relatively thin artifact support compared to its code quality. |
95+
| Aviation WX | Strong | Partial | Adequate | Weak | Minimal | Clear bootstrap shape, but semantically and artifact-wise thinner than the rest of the station family. |
96+
| OpenSky | Strong | Strong | Strong | Weak | Strong | Best current feed-adapter reference in the fleet. |
97+
| ISS current slot | Minimal | Missing | Partial | Adequate | Missing | Runtime exists, canonical bootstrap does not. |
98+
| USGS Water | Strong | Adequate | Strong | Weak | Minimal | Semantically stronger than its artifact maturity suggests; package-state mismatch is the main blocker. |
99+
| USGS NIMS | Strong | Strong | Strong | Weak | Exemplary | Best current Pattern A example, though still coupled to water-bootstrap assumptions. |
100+
| USGS EQ | Strong | Strong | Exemplary | Weak | Exemplary | Best current source-traceability story in the active fleet. |
101+
102+
### 4.2 Legacy fleet
103+
104+
| Script | Architecture value | Metadata value | Security / portability | Current role |
105+
|---|---|---|---|---|
106+
| `bootstrap_iss.py` | Very high | Very high | Weak | Migration candidate and active precedent |
107+
| `bootstrap_uas.py` | Medium | High | Weak | Historical artifact with reusable enrichment ideas |
108+
| `bootstrap_localizer.py` | Medium | Low | Weak | Scenario-only focused bootstrap |
109+
| `bootstrap_v25.py` | High | Medium | Weak | Historical migration bridge |
110+
| `bootstrap_v3.1.py` | Medium | Low | Weak | Historical artifact |
111+
| `bootstrap_v4.py` | Very high | Low | Weak | Scenario-only authoritative bootstrap |
112+
113+
The heatmap has one dominant pattern:
114+
115+
- `Semantics and provenance are improving faster than artifact trust and runtime hygiene.`
116+
117+
That is a good sign for architecture, but it is also a risk. The repo can appear more mature than it is if a reader confuses strong research notes or pack prose with actually present, canonical, on-disk artifacts.
118+
119+
---
120+
121+
## 5. Current-Fleet Findings
122+
123+
### 5.1 The station family is mature enough to standardize
124+
125+
NWS, NDBC, CO-OPS, Aviation WX, and USGS water all repeat the same operational skeleton:
126+
127+
- load a sidecar station list;
128+
- build one procedure;
129+
- build one system per station;
130+
- build one or more datastreams per station;
131+
- build a root deployment, a grouping deployment, and one leaf per station;
132+
- support `--clean`, `--clean-only`, and `--dry-run`;
133+
- rely on `publishers/bootstrap_helpers.py`.
134+
135+
This repetition is no longer accidental. It is a stable family. The project should treat it as such and extract a family-level builder instead of continuing copy-edit maintenance across five scripts.
136+
137+
### 5.2 The best current semantic designs are not the oldest ones
138+
139+
The most semantically deliberate current bootstraps are not the oldest public-data scripts. They are the ones backed by stronger recent artifact work:
140+
141+
- OpenSky for Pattern C feed adaptation;
142+
- USGS NIMS for Pattern A companion-datastream modeling;
143+
- USGS EQ for source-verified event-feed modeling.
144+
145+
These are important because they show that the repo is now capable of more than "one station, one datastream, one leaf deployment" thinking.
146+
147+
### 5.3 Artifact coverage is now a maturity discriminator
148+
149+
Two bootstraps with similar code quality can now differ materially in overall maturity depending on their adjacent artifacts.
150+
151+
Examples:
152+
153+
- CO-OPS has better inline provenance than its artifact state implies, but no pack.
154+
- Aviation WX is structurally clear, but thin in both metadata and artifact depth.
155+
- USGS water has good sidecar semantics, but its claimed total package is not actually present on disk.
156+
- USGS NIMS and USGS EQ both benefit materially from total-package support that already exists and is inspectable.
157+
158+
Artifact maturity is now part of the implementation, not just documentation.
159+
160+
### 5.4 ISS remains the active fleet's largest contradiction
161+
162+
The current repo clearly intends ISS to be part of the publisher fleet:
163+
164+
- `publishers/iss/iss_publisher.py` exists;
165+
- `publishers/iss/Dockerfile` exists;
166+
- `publishers/docker-compose.yml` includes an ISS service;
167+
- `publishers/README.md` still includes `python -m publishers.iss.bootstrap_iss`.
168+
169+
But the bootstrap itself is still missing.
170+
171+
This means the fleet cannot honestly claim full bootstrap coverage until ISS is migrated into `OSHConnect-Python`.
172+
173+
### 5.5 Runtime security posture is weaker than bootstrap security posture
174+
175+
This is the most operationally important current-fleet finding.
176+
177+
The helper layer uses certificate verification and hostname checks. The runtimes do not consistently inherit that discipline. Across the active runtime publishers, TLS verification is commonly disabled for outbound CSAPI POST operations.
178+
179+
This creates an avoidable architecture split:
180+
181+
- bootstrapping is relatively disciplined;
182+
- continuous publishing is comparatively permissive.
183+
184+
That split should not survive into a canonical fleet.
185+
186+
---
187+
188+
## 6. Legacy-Fleet Findings
189+
190+
### 6.1 Legacy does not mean obsolete
191+
192+
Several legacy scripts still matter because they solve problems the current fleet either inherited from them or has not yet re-solved in a better way.
193+
194+
The best example is `scripts/bootstrap_iss.py`:
195+
196+
- it is still the strongest rich-SensorML publisher bootstrap precedent in the corpus;
197+
- it is explicitly the source pattern for `publishers/bootstrap_helpers.py`;
198+
- it models a dual-product publisher with a meaningful deployment tree;
199+
- it already solves the missing current-fleet ISS bootstrap problem in concept.
200+
201+
### 6.2 The scenario scripts reveal the helper layer's boundary
202+
203+
`bootstrap_v4.py`, `bootstrap_v25.py`, and `bootstrap_phase2.py` show that the current helper layer is not yet a general bootstrap framework. It does not directly cover:
204+
205+
- subsystems;
206+
- control streams;
207+
- scenario graph import;
208+
- complex deployment repair or migration logic;
209+
- schema rewrites during migration.
210+
211+
This is not a criticism of the current helper layer. It is a boundary condition. The project should decide whether to keep that boundary or expand beyond it intentionally.
212+
213+
### 6.3 Legacy security and portability are still poor
214+
215+
The legacy scripts continue to expose patterns that should not be propagated:
216+
217+
- hardcoded production endpoints;
218+
- embedded credentials;
219+
- TLS verification disabled;
220+
- server- and ID-specific assumptions inline in the script body.
221+
222+
These scripts are historically informative, but they should not be treated as drop-in current templates.
223+
224+
### 6.4 The scenario bootstraps are valuable mainly as references, not destinations
225+
226+
The right move for most of the legacy scenario corpus is not migration into the publisher repo. It is clearer separation:
227+
228+
- keep the useful ideas;
229+
- keep the backup truth sources where they still matter;
230+
- stop treating these scripts as peers of the public-data fleet in day-to-day contributor workflows.
231+
232+
---
233+
234+
## 7. Cross-Cutting Gap Taxonomy
235+
236+
### 7.1 Semantic-model gaps
237+
238+
- several station-family datastreams still flatten multiple observed-property concepts into one broad record without an explicit semantic contract for null reasons, QC, or per-field provenance;
239+
- fixed-station publishers rarely model feature-of-interest semantics beyond the station system itself;
240+
- Pattern A and Pattern C are present in code but not yet normalized as canonical vocabulary inside the project.
241+
242+
### 7.2 Metadata and SensorML gaps
243+
244+
- metadata richness is uneven across the active fleet;
245+
- NWS/NDBC history shows that writing SensorML is not the same as preserving rich SensorML through server round-trips;
246+
- some packs are mature enough to be relied on, but others are absent or only claimed by research notes.
247+
248+
### 7.3 Provenance and traceability gaps
249+
250+
- provenance quality varies widely by publisher;
251+
- some bootstraps now embed substantial official-source references;
252+
- others remain dependent on minimal inline URL sets or planning-note context;
253+
- repo/documentation drift can now make provenance look stronger than the artifact state actually is.
254+
255+
### 7.4 Operational and security gaps
256+
257+
- active runtime TLS verification remains the biggest fleet-wide hygiene issue;
258+
- station-family duplication makes operational improvements expensive to roll out uniformly;
259+
- conformance verification is still too manual.
260+
261+
### 7.5 Repo-boundary and canonical-home gaps
262+
263+
- ISS bootstrap split across repos;
264+
- scenario and public-data artifacts still share mental and physical neighborhoods that blur contributor expectations;
265+
- research-note claims are not always synchronized with on-disk artifact reality.
266+
267+
---
268+
269+
## 8. Prioritized Recommendations By Tier
270+
271+
### 8.1 Tier 1: universal high-priority gaps
272+
273+
1. Restore TLS verification across active runtimes.
274+
Type: `runtime-follow-on`
275+
276+
2. Codify the bootstrap families as first-class shared patterns.
277+
Type: `bootstrap-only`
278+
279+
3. Publish and enforce an artifact-state taxonomy for packs, total packs, historical source bases, and research notes.
280+
Type: `archive/clarify`
281+
282+
4. Standardize provenance manifests and semantic-contract sidecars for every active publisher.
283+
Type: `metadata-only`
284+
285+
5. Add automated round-trip conformance probes for SensorML and result-schema retrieval.
286+
Type: `runtime-follow-on`
287+
288+
6. Close the ISS canonical-home gap.
289+
Type: `migration`
290+
291+
### 8.2 Tier 2: publisher-family gaps
292+
293+
1. Extract the station-per-system family builder.
294+
Type: `bootstrap-only`
295+
296+
2. Define a canonical Pattern C feed-adapter contract.
297+
Type: `metadata-only`
298+
299+
3. Define a canonical Pattern A dependency contract for companion datastreams.
300+
Type: `bootstrap-only`
301+
302+
4. Separate scenario-only bootstraps from public-data publisher workflows.
303+
Type: `archive/clarify`
304+
305+
### 8.3 Tier 3: per-bootstrap target-state work
306+
307+
1. NWS and NDBC: integrate the mature parts of their enrichment work into a verified, canonical runtime-plus-bootstrap state.
308+
Type: `runtime-follow-on`
309+
310+
2. CO-OPS and Aviation WX: bring them to pack parity with the better-supported publishers.
311+
Type: `metadata-only`
312+
313+
3. OpenSky: keep the current model but harden runtime behavior and quality semantics.
314+
Type: `runtime-follow-on`
315+
316+
4. USGS water: reconcile the missing total-pack directory and elevate the statistic-specific semantic contract into a canonical package.
317+
Type: `total-pack`
318+
319+
5. USGS NIMS and USGS EQ: extend the already-strong packages into clearer next-stage runtime and semantic guidance.
320+
Type: `runtime-follow-on`
321+
322+
### 8.4 Tier 4: legacy migration or archival cleanup
323+
324+
1. Migrate legacy ISS bootstrap into the current publisher repo.
325+
Type: `migration`
326+
327+
2. Archive or clearly label UAS, localizer, v2.5, v3.1, v4, and phase2 as scenario-specific or historical.
328+
Type: `archive/clarify`
329+
330+
3. Preserve reusable ideas from the legacy scenario family without preserving insecure transport and credential patterns.
331+
Type: `archive/clarify`
332+
333+
---
334+
335+
## 9. Decision Log and Assumptions
336+
337+
1. The report scores the current repository state, not the intended state described in older planning notes.
338+
2. A claimed artifact that is absent from the current filesystem was treated as missing.
339+
3. Runtime behavior was included only where it materially affected bootstrap confidence, especially for security and bootstrap/runtime alignment.
340+
4. Legacy scenario scripts were treated as architecturally relevant even when they are not current publisher targets.
341+
5. Standards-conformance scores are design-intent maturity judgments, not formal certification claims.
342+
6. The report assumes the project goal is to maximize semantic clarity and reproducible richness, not merely to achieve minimal demo functionality.
343+
344+
---
345+
346+
## 10. Appendix Map
347+
348+
- `All_Bootstraps_Full_Scope_Gap_Analysis_Appendix_A_Inventory_and_Rubric_2026-03-12.md`
349+
- `All_Bootstraps_Full_Scope_Gap_Analysis_Appendix_B_Current_Fleet_Dossiers_2026-03-12.md`
350+
- `All_Bootstraps_Full_Scope_Gap_Analysis_Appendix_C_Legacy_Fleet_Dossiers_2026-03-12.md`
351+
- `All_Bootstraps_Full_Scope_Gap_Analysis_Appendix_D_Source_Corpus_and_Roadmap_2026-03-12.md`
352+
353+
The appendices contain the per-bootstrap evidence tables, category scores, score justifications, and source corpus details that support the summary conclusions above.

0 commit comments

Comments
 (0)