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.

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-<timestamp>.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/<date>_*.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/<date>_*.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.