Generated Data Exports¶
Stage 28 publishes deterministic JSON exports from the canonical repository records during validation and GitHub Pages deployment.
Export location¶
assets/data/v1/
├── manifest.json
├── missions.json
├── vehicles.json
├── infrastructure.json
├── training.json
├── search-index.json
├── faq.json
└── openapi.json
The files are generated by scripts/generate_exports.py; they are not maintained manually.
Current publication¶
The v1.0.1 publication retains the v1.0.0 canonical record set and API structure while strengthening browser, link and release validation.
Determinism¶
Exports are sorted by stable record ID and name. They use the release metadata in data/version.json rather than embedding a volatile build timestamp, so the same repository state produces the same data payload.
Collection envelope¶
Each collection contains:
{
"schema_version": "1",
"data_version": "1.0.1",
"released_at": "2026-07-22",
"collection": "missions",
"count": 0,
"records": []
}
The actual count and records are populated at build time.
Search index¶
The search index contains lightweight collection, ID, name, service and normalized search-text fields. It supports browser-side tools without forcing every page to download all full collections immediately.
Validation pipeline¶
Both validation and Pages delivery execute:
validate_data.py
↓
generate_exports.py + generate_faq.py
↓
release_readiness.py
↓
audit_links.py
↓
mkdocs build --strict
↓
built-site and browser acceptance
A deployment therefore cannot publish exports from data that failed repository validation, internal-link checks or the browser acceptance gates.
Compatibility¶
Breaking envelope or field changes require a new API directory such as v2. Additive records, optional fields and compatible quality releases may continue within v1 when existing consumers remain valid.