# Module Count Reconciliation — SHIELD/ATLAS **Status:** Authoritative. Last reconciled 2026-04-28. **Owner:** Platform docs. **Canonical number going forward:** **66 modules — shipping today.** ## TL;DR If you are writing a new public-facing document, brief, or template after 2026-04-28, use **66 modules** and frame it as "shipping today" / "in production today". Do not advertise a higher number unless it is explicitly labelled as a **roadmap pathway** count and the wording makes the roadmap framing unambiguous. ## Why three numbers exist Different surfaces of the platform have, at various points, advertised three different module counts. All three were correct *in their own definitional context* at the time they were written; the drift is a result of three things being counted, not three measurements of the same thing. | Number | What it actually counted | Where it appears | | --- | --- | --- | | **66** | The canonical runtime modules that are wired into `MODULE_MANIFEST`, registered with the platform event bus, and exposed by the live server today. This is the number every operator and every evaluator can verify by hitting the running platform. | `server/platform.ts` registry/health surfaces, `server/dual-use.ts`, `server/evaluator-ai.ts`, `server/intel-synthesis.ts`, `server/ai-audit-engine.ts`, `server/routes.ts`, `server/esms-faq.ts`, `server/sbir-proposal-engine.ts`, `server/tactical-onboarding.ts` | | **86** | A historical MAP/GAP audit roll-up that included 66 runtime modules **plus** ~20 sub-module / capability-bundle entries that the audits treated as separately auditable units (e.g. POSEIDON's five maritime sub-modules, the four CYBER ecosystem layers, ESMS sub-capabilities). The 86 number is correct *as an audit decomposition*, not as a runtime module count. | `docs/MAP_GAP_Audit_audit-*.md` (timestamped, historical), `docs/MAP_GAP_Audit_Round5_Final.md`, `docs/Army_ITDX26_*` (snapshot at submission time), `docs/jsoc_readahead/Capabilities_and_Boundaries.md` | | **94 / 95** | A "with roadmap pathways" count that bundled the 66 shipping modules with planned-but-not-shipped work (PQC tactical messenger, expanded mobile parity screens, additional dual-use sub-modules, evidentiary export packaging, etc.). This was written into the master capability statement and several outside-audience marketing surfaces while the work was in flight. The 29 planned-but-not-shipped pathways now have a single canonical home — see the **Roadmap section** at the bottom of `docs/Capability_Statement_SHIELD_ATLAS.md` and the matching `roadmap-29` anchors in `server/templates/capability-statement.html`, `server/templates/capability-statement-combined.html`, and `server/templates/capability-statement-general.html` (each as a `
` block) plus `server/templates/whitepaper.html` (sub-section `

` under the existing `
`). | `docs/Capability_Statement_SHIELD_ATLAS.md` (master), `docs/Capability_Brief_SHIELD_ATLAS_World_Cup_2026.md`, `docs/SHIELD_ATLAS_Differentiator_Briefing.md`, `docs/Compound_Effects_Multi_Problem_Architecture.md`, `docs/APEX_CAPABILITY_PACKAGE.md`, `docs/SUBMISSION_HISTORY_AND_PIPELINE.md`, `server/templates/*.html` (capability-statement, whitepaper, ops-hub, documents) | ## What changed on 2026-04-28 After the Wed 29 Apr 2026 funk_capes brief was finalized (which does not surface audit history in front of the audience), we reconciled every **live, forward-facing** surface to **66**: - All HTML templates served by the Express backend (`server/templates/*.html`). - The runtime banners and evaluator endpoints in `server/platform.ts`. - Server-side AI/RAG context strings (`server/rag-researcher.ts`, `server/procurement.ts`). - The master capability statement (`docs/Capability_Statement_SHIELD_ATLAS.md`) and the public-facing capability briefs / differentiator briefings. - Internal trackers (`docs/Opportunity_Tracker.md`, `docs/SUBMISSION_HISTORY_AND_PIPELINE.md`). - Forward-going proposal / read-ahead documents that are still in the active-pipeline (`docs/Army_ITDX26_*`, `docs/jsoc_readahead/*`, `docs/JSOC_Capes_Brief_2026-04-27.md`, `docs/MAP_GAP_Audit_Round5_Final.md`, `docs/Compound_Effects_Multi_Problem_Architecture.md`, `docs/APEX_CAPABILITY_PACKAGE.md`). ## What was deliberately NOT changed These surfaces are **point-in-time historical records** and rewriting them would be revisionist. They are preserved as-shipped: - `docs/MAP_GAP_Audit_audit-.md` — timestamped audit snapshots generated by the AI audit engine at the moment of audit. These document what each model believed at that timestamp. - `docs/submissions/_*.md` and `docs/submissions/print/*.html` — formal submissions actually transmitted to government evaluators (DIU, FEMA, DoW, AFRL, JIATF-401, MAPS, Golden Dome, APFIT, etc.). These reflect the capability narrative ISS LLC sent on the date in the filename. If the recipient asks how today's count reconciles with a 95-module submission, refer them to this document. - `docs/outreach/_*.md` — dated outreach messages to partners. - `docs/HONEST_CAPABILITY_AUDIT_2026-04-16.md` — dated honest-audit snapshot that itself flags the 86 vs 95 inconsistency. - `docs/briefings/2026-04-29_funk_capes_brief/` — finalized brief deck. The one residual reference ("not walking 95 modules") is positioning copy describing what the brief is *not* meant to do, and the audience never sees it. ## Rules for new content 1. New public-facing surfaces must say **66 modules** and frame it as "shipping today" / "in production today" / "live and operational today". 2. If you need to talk about planned-but-not-yet-shipped work, you must say "66 modules today plus N roadmap pathways" or equivalent, and call out the roadmap items by name. Never fold roadmap items into the headline number. 3. The audit decomposition (86) is an internal MAP/GAP artifact only. Do not surface it on outside-audience marketing material. 4. Authoritative source of truth at runtime is `MODULE_MANIFEST` in `dual-use/app-orchestrator-sop.js` plus the `getModuleRegistry()` / `getRegistrySummary()` outputs surfaced under `/api/modules/registry` and `/api/evaluator/capabilities`. If those ever drift from 66, update this reconciliation note (and every public surface) before the next outside audience sees it. ## 2026-04-28 update — single source of truth for displayed counts Headline counts that appear on the public surfaces `/`, `/capabilities`, `/cap`, `/whitepaper`, `/documents`, and `/ops-hub` (as well as the `/api/health`, `/api/status`, `/api/evaluator/quick-start`, and `/api/evaluator/capabilities` endpoints) are no longer hard-coded. They are derived at request time from the constant `MODULE_COUNT`, which is `MODULE_MANIFEST.length` in **`server/module-manifest.ts`**. That file is now the canonical, narrowly-scoped server-side manifest of the 66 shipping modules — name, id, and category for each one — and it is what every displayed headline reads from. How it is wired: - HTML templates use the literal placeholder `__MODULE_COUNT__` wherever the shipping-module headline number is shown. - `server/platform.ts` exposes a tiny helper, `injectModuleCount(template)`, which substitutes `__MODULE_COUNT__` with `String(MODULE_COUNT)` whenever a template is served. Every `/`, `/capabilities` (and aliases), `/cap` (and aliases), `/whitepaper`, `/documents`, and `/ops-hub` (and aliases) route goes through this helper. - The `/api/health`, `/api/status`, and evaluator endpoints reference `MODULE_COUNT` directly instead of a numeric literal. - `/api/evaluator/capabilities` additionally returns the full `manifest` array so external consumers can verify the per-module breakdown without scraping HTML. If the shipping module count ever changes, edit `server/module-manifest.ts` (add or remove an entry), and every headline, health endpoint, status endpoint, and evaluator banner will follow on the next request. No template edits, no string-search-and-replace across pages, no risk of drift between the API and the marketing copy. The historical `MODULE_MANIFEST` in `dual-use/app-orchestrator-sop.js` and the broader `getRegistrySummary()` (which counts all `safeRegister` calls, including sub-services) remain untouched — they continue to serve their original audit/runtime-registry purposes. `server/module-manifest.ts` is the narrower, intentionally-curated list used **only** for the public shipping-module headline number.