Cybersecurity Operations Centre scaffolding QC — rationale gaps and structural fixes

System

{{entity:Cybersecurity Operations Centre}} QC review on a freshly scaffolded project. Prior session established 8 STK and 12 SYS requirements with 9 subsystems classified in the SE:cybersec-ops-centre namespace, 2 populated diagrams, and 13 trace links. Status was scaffolded; no subsystem, interface, or verification requirements existed.

Findings

Every requirement in the project — all 20 — was missing rationale, violating the mandatory --rationale rule. All 20 were also unassigned to document sections, which would prevent trace linksets from resolving correctly once subsystem decomposition begins.

Lint identified 4 findings: 2 medium-severity warnings about abstract temporal metrics (“day”, “year”) in {{stk:STK-STK-NEEDS-004}} lacking statistical context, and 2 low-severity ontological ambiguity notes where {{entity:Cybersecurity Operations Centre}} (abstract, {{hex:40A57AD9}}) and the platform variant (physical, {{hex:50B571D9}}) were classified inconsistently at 72% Jaccard similarity. The lint also surfaced a notable 100% Jaccard match between {{entity:Endpoint Detection and Response Subsystem}} ({{hex:51F77B19}}) and {{entity:SIEM Engine}} ({{hex:51F77B19}}) — identical hex codes reflecting their shared trait profile as powered, active, signal-processing software subsystems.

The decomposition diagram showed 9 internal data flows but was missing several critical interfaces: {{entity:Vulnerability Management System}} to {{entity:SOAR Platform}} (automated remediation), {{entity:Identity and Access Monitoring Subsystem}} to {{entity:SOAR Platform}} (account lockout), and {{entity:SIEM Engine}} to {{entity:Communications and Reporting Subsystem}} (direct executive dashboard feed). No architecture decisions were documented. No interface requirements existed despite 9 subsystem interconnections being modelled in the diagram.

Corrections

Rationale added to all 20 requirements. Each rationale explains the engineering derivation of specific numeric thresholds and what failure mode drives the requirement. For example, {{sys:SYS-SYS-DETECT-001}}‘s 120-second correlation window is justified by its position within the 15-minute MTTD budget from {{stk:STK-STK-NEEDS-001}}, leaving time for triage and notification downstream.

Sections created and requirements assigned. STK document: 1 section (Stakeholder Needs). SYS document: 5 sections (Detection and Correlation, Response and Containment, Threat Intelligence and Vulnerability, Data Management and Reporting, Infrastructure and Availability). SUB document: 9 sections pre-created for each subsystem to support incoming decomposition. IFC document: 2 sections (Internal Data Flows, External Interfaces). ARC and VER documents: 1 section each.

5 interface requirements created ({{ifc:IFC-IFC-INTERNAL-001}} through {{ifc:IFC-IFC-INTERNAL-005}}) covering the SIEM-SOAR alert handoff, EDR-SIEM telemetry feed, TIP-SIEM IOC push, SOAR-EDR containment command API, and NSM-SIEM network metadata forwarding.

1 architecture decision recorded ({{sys:ARC-ARC-RAT-001}}) documenting the SIEM-centric hub-and-spoke architecture rationale — O(n) integration complexity, centralised correlation, and downstream SOAR placement to prevent false-positive-driven containment.

12 CONNECTS facts added to the Substrate graph, covering all diagram edges plus 3 missing interfaces (VMS→SOAR, IAM→SOAR, SIEM→Comms). 8 new trace links created: 3 additional STK→SYS derivations (filling coverage gaps for scalability, compliance, and detection) and 5 SYS→IFC derivations. Total trace links: 21.

Baseline QC-2026-03-18 captured at 26 requirements, 21 trace links.

flowchart TB
  SOC["Cybersecurity Operations Centre"]
  SIEM["SIEM Engine"]
  NSM["Network Security Monitoring"]
  EDR["Endpoint Detection and Response"]
  TIP["Threat Intelligence Platform"]
  VMS["Vulnerability Management"]
  SOAR["SOAR Platform"]
  IAM["Identity and Access Monitoring"]
  INFRA["SOC Facility Infrastructure"]
  COMMS["Communications and Reporting"]
  SIEM -->|Correlated alerts| SOAR
  NSM -->|Network alerts, metadata| SIEM
  EDR -->|Endpoint telemetry, alerts| SIEM
  TIP -->|IOC enrichment data| SIEM
  SOAR -->|Containment commands| EDR
  VMS -->|Vulnerability context| SIEM
  IAM -->|Identity alerts| SIEM
  SOAR -->|Notifications, reports| COMMS
  TIP -->|Threat context for playbooks| SOAR

Residual

The 2 medium-severity lint findings (abstract temporal metrics in STK-004) are informational — the requirement itself specifies “24 hours per day, 7 days per week” which is unambiguous despite the lint’s concern about missing statistical parameters. No fix needed. The ontological ambiguity between the abstract “Centre” and physical “platform” reflects a genuine distinction (organisational function vs. deployed infrastructure) and does not require reconciliation. The identical hex codes for EDR and SIEM subsystems are expected — at the 32-trait resolution they share the same functional profile; differentiation emerges at the component level during decomposition.

External interfaces (to CTI feeds, regulators, ITSM) shown in the context diagram have no corresponding IFC requirements yet. These should be created during the next decomposition session.

Next

With status at qc-reviewed, the next session should begin first-pass decomposition of the highest-risk subsystem. The {{entity:SIEM Engine}} is the clear priority — it has the most interfaces (6 inbound data flows), the tightest performance constraints (150K EPS steady-state, 500K burst, 120-second correlation), and is the architectural linchpin of the hub-and-spoke design. Decompose SIEM into its internal components (log collector, normalisation pipeline, correlation engine, rule management, storage backend) and generate SUB requirements in the prepared SUB-SIEM section.

← all entries