SYSTEM-STANDARD

SYSTEM-STANDARD.md — System Component Type (as-built spec + how to build/operate it)

Type-layer standard, sibling of TEMPLATE-STANDARD.md (report) and PROFILE-STANDARD.md (profile). Governs the (system) component type ONLY. A system is a PRESCRIPTIVE product: its value is a delivered technical capability — what to build, how to deploy/configure/harden it, and how to operate it — NOT knowledge about a subject. It does NOT carry the report anatomy (BLUF / Key Judgments / ACH / PIR) or the profile spine; it has its own spine, below.

Living standard. Reconciled 2026-07-04 to the requirements-traceable spine that all 19 system cells actually use (SYS-001..010, AGT-001/002/004/005/007/008, OSINT-041/054/062). The prior revision prescribed a build/operations skeleton (Document Control / verbatim caveat / Annexes A-B) that no cell implemented; the reconciled spine below is the NEED → REQ → verification → acceptance-test chain the cells were built on, which is the stronger fit for the project’s requirements doctrine (atomic, verifiable requirements each carrying a verification method at definition time).

1. What a system is

Value = a built/configured technical capability handed to the client or team — a platform, feed, dashboard, pipeline, kit, or loadout — documented so it can be reproduced, accepted, and operated. Imperative/prescriptive voice about the build and its operation, never an estimate about a subject. The reader builds, accepts, and runs from it; they do not read it to know a fact.

2. Required anatomy (every system deliverable carries this 8-section spine)

1. # <SYSTEM NAME> + a one-line as-built descriptor that states the design-basis / acceptance- criterion discipline.
2. ## 1. Purpose and Design Basis — the requirements core:
   • 1.1 Scope and Objective — what the system is and does; the in / out-of-scope boundary.
   • 1.2 Design Basis — the design principle(s) the build rests on (what it replaces, why this shape).
   • 1.3 Needs — each NEED-<DID>-NN in stakeholder language, with a Source (named stakeholder, by initials) and a Context. A need is unverifiable as stated.
   • 1.4 Requirements — each REQ-<DID>-NN atomic, verifiable, solution-bounded, traced to a NEED, carrying a verification reference [VR-<DID>-NN] and a Verification Method (Inspection / Analysis / Demonstration / Test) at definition time. One requirement, one shall.
3. ## 2. Architecture As Built — the logical / physical architecture as an ASCII block diagram.
4. ## 3. Components and Bill of Materials — table: Component | Spec | Vendor/Link | Price | Tier | Status | Traceability (→ REQ). Real, grounded components (named OSS/stack, priced; internal work at $0.00); no fictional or speculative tools.
5. ## 4. Build and Deployment — phased, reproducible provision → configure → start.
6. ## 5. Hardening Baseline — host / network / process / data-at-rest controls; each control traces to a REQ or a stated threat / design principle.
7. ## 6. Integration Points — table: Interface | Type | Direction (Consumed / Produced) | Contract. Every seam the system consumes or produces, with its contract; cross-domain seams reflect the manifest’s ART-<slug> wiring.
8. ## 7. Acceptance Tests — table: Criterion (REQ) | Method | Expected Result | Reference (VR). Every requirement has a matching acceptance test; no claim of “built” without a test that proves it.
9. ## 8. Run and Maintenance Handover — console start, maintenance schedule / cadence, ownership (named element / initials). Every operational duty names a cadence and a responsible element.
10. END OF SYSTEM.

A system MAY add domain annexes after §8 where the build warrants (e.g., a severity-matrix mapping or a delivery-schema contract, as in SYS-008) — additive, never a substitute for the spine.

3. The load-bearing rule (system-specific discipline)

Every architectural component (§2-§3) and every hardening control (§5) traces to a stated design basis — a NEED/REQ, a threat, or a design principle — AND to a corresponding acceptance criterion in §7. No component without a reason; no “built” without a test that proves it. Every requirement in §1.4 is atomic (one shall), verifiable, and carries its verification method; every integration point names its direction and contract; every operational duty in §8 names a cadence and an owner.

4. Lawful-collection caveat (mandatory where the system collects or monitors)

Where the system performs collection or monitoring, state that collection is restricted to publicly available information — no authentication bypass, no intrusion, no acquisition of non-public data — and that scraping / monitoring at scale carries ToS, CFAA-analogue, and data-protection (GDPR/CCPA) exposure to be scoped with counsel per engagement; document authorization basis, lawful purpose, jurisdiction, and retention before operation begins. Systems that do not collect (comms loadouts, C2/TOC, sandboxes) state that the collection caveat does not apply and omit it — do not pad. This is not legal advice.

5. Sourcing & confidence discipline

Admiralty grading (A-F x 1-6) and the L x I 1-25 risk key apply ONLY where the system’s output or this spec actually cites graded intelligence or scores risk (e.g., a tipping / threat-feed acceptance criterion). A pure build/operations spec cites no subject-intelligence — in that case state that the analytic scales do not apply and omit them; do not pad.

6. Format

Pure heading hierarchy; markdown tables for every matrix; an ASCII architecture diagram in §2. Real stack / components only, no live commercial tool names invented for effect. No emojis anywhere (verify-enforced); ASCII-clean; personnel by initials; operational language renders to lawful effects per DOCTRINE.md. END OF SYSTEM closes the file.