# AEGIS — Microkernel Component Architecture

- **Document ID:** ARCH-07
- **Phase:** B.1 — Structural Foundations
- **Status:** Draft for review (post independent architecture review)
- **Version:** 0.1
- **Date:** 2026-07-10
- **Owner:** Chief Security Architect
- **Depends on:** ARCH-01 through ARCH-06, CLAUDE.md
- **Consumed by:** ARCH-08 through ARCH-16

---

## 1. Purpose

Define the engines that compose AEGIS. Each engine is an independently replaceable subsystem communicating with the Security Kernel and, indirectly through the Kernel, with other engines. The Security Brain is **the composition of these engines mediated by the Kernel** — not a single reasoning monolith.

Constitutional constraints in force:
- **Microkernel Philosophy** — engines are replaceable.
- **Security Brain is orchestrator, not monolith** — reasoning distributed.
- **Recovery-First Design** — every engine answers five recovery questions.
- **No peer-to-peer privileged calls** — every cross-engine invocation is Kernel-mediated.

## 2. Engine Roster

The user-mandated engines, plus two AEGIS-added engines the v0 scope requires as first-class members:

| # | Engine | v0 status | Purpose (one line) |
|---|---|---|---|
| E-01 | **Connector Engine** | v0 | I/O with external systems: log sources, IdP, threat-intel feeds, cloud APIs, notification targets |
| E-02 | **Normalization Engine** *(AEGIS-added)* | v0 | Deterministic mapping of raw events to canonical OCSF schema, additive-only |
| E-03 | **Storage Engine** | v0 | Read/write facade over PostgreSQL (control) and ClickHouse (event); enforces classification and tenant scoping |
| E-04 | **Detection Engine** | v0 | Sigma-based correlation, statistical baselines (later), findings production |
| E-05 | **AI Engine** | v0 | Three-tier AI router (L1/L2/L3), prompt lifecycle, provider adapters |
| E-06 | **Policy Engine** | v0 | Rule-based decisioning: what is allowed, when, for whom, under what classification |
| E-07 | **Identity Engine** | v0 | Human, service, and agent identity lifecycle; IdP integration; RBAC + capability delegation to Kernel |
| E-08 | **Audit Engine** | v0 | Layer-A ring receiver + Layer-B signed archival + independent verification tools |
| E-09 | **Case Engine** *(AEGIS-added)* | v0 | Cases, findings-to-case assembly, incident timelines, evidence bundles |
| E-10 | **Telemetry Engine** | v0 | AEGIS's own metrics, logs, traces; scrubber pipeline; opt-in external export |
| E-11 | **Recovery Engine** | v0 (backup/restore); expanded post-v0 | Backup, restore, DR runbooks, degraded-mode orchestration, chaos drills |
| E-12 | **Plugin Engine** | interface only in v0; full in v0.2+ | Manifest, sandbox launch, capability grants, plugin lifecycle |
| E-13 | **Response Engine** | interface only in v0; full in Phase 3 | Automated response actions (quarantine, disable-key, etc.); no v0 execution |
| E-14 | **Runtime Risk Engine** *(added post-B.1 elevation)* | v0 | Dynamic risk score, context awareness, threat escalation, asset criticality, business impact, AI confidence adjustment, adaptive response level. Specifications in ARCH-11 (Multi-Stage Decision Pipeline). |
| E-15 | **Evidence Engine** *(added post-B.1 elevation)* | v0 | Evidence provenance, integrity metadata, confidence scoring, transformation history, trust scoring, explainability contract implementation. Specifications in ARCH-12 (Evidence Chain Architecture). |

## 3. Engine Contract

Every engine MUST comply with the following contract; deviation requires an Owner-approved architectural exception (recorded in `docs/exceptions/`).

### 3.1 Structural

- **C-1.** Runs as its own process (or process group). No engine shares a process with another engine.
- **C-2.** Presents its own cryptographic identity (ARCH-09); mTLS to Kernel and to data plane.
- **C-3.** Speaks to other engines only via Kernel-mediated calls. Peer-to-peer control-plane calls are prohibited.
- **C-4.** Publishes and consumes events on NATS or Kafka topics whose publish/consume capabilities are Kernel-issued.
- **C-5.** Exposes: `/health`, `/ready`, `/live`, `/version`, `/capabilities` (introspection of held capabilities).
- **C-6.** Emits structured logs, metrics, and traces (Telemetry Engine consumes).

### 3.2 Behavioral

- **C-7.** Idempotent request handling with a per-request `trace_id`.
- **C-8.** Fail-secure: any failed authorization, expired capability, or missing classification → deny + audit.
- **C-9.** Retries on transient failures with backoff; never hides persistent failures.
- **C-10.** Emits a Layer-A audit event via Kernel for every sensitive operation initiated *by* the engine (in addition to Kernel-side audit).
- **C-11.** Honors classification: any propagation of a classified message preserves or upgrades classification; downgrade requires an explicit policy decision.

### 3.3 Replaceability

- **C-12.** The engine implements a *stable interface* (protobuf-defined API + versioned event schema). A drop-in reimplementation is possible without changes to peers.
- **C-13.** No hidden implicit dependency on another engine's implementation choice; only its interface. (Example: Detection Engine can be re-implemented in another language provided it consumes the same OCSF-normalized events and emits the same finding schema.)
- **C-14.** Configuration is via a versioned, schema-validated document; hot-reload MUST be optional; safe-restart is always supported.

### 3.4 Recovery-First (five questions)

Every engine's architecture section MUST answer:

1. **How does it fail?** — enumerated failure modes.
2. **How is failure detected?** — health/probe/anomaly.
3. **How is recovery initiated?** — automatic vs. runbook-driven.
4. **Can recovery be automated?** — yes/partial/no with rationale.
5. **Can recovery be rolled back?** — yes/no with mechanism.

## 4. Engine Specifications

Format: **Purpose** → **Inputs / Outputs** → **Kernel interactions** → **Storage** → **Failure modes** → **Recovery answers** → **v0 scope**.

### 4.1 E-01 Connector Engine

- **Purpose.** All I/O with external systems: ingest connectors (syslog, HTTPS push, cloud audit pull, forwarder receiver), IdP callbacks, outbound webhooks, notification channels.
- **Inputs.** External protocol traffic; connector configuration; connector credentials (via Kernel-mediated secret retrieval).
- **Outputs.** Raw events published to Kafka; IdP tokens; delivered notifications.
- **Kernel interactions.** Requests `Read-Secret` for connector credentials; requests `Publish-Ingest` capability per source; produces Layer-A audit events on connect/disconnect and on notification send.
- **Storage.** Connector configuration in Postgres via Storage Engine; no direct DB access.
- **Failure modes.** Source unreachable; source auth expired; malformed events; rate spike; deserialization crash.
- **Recovery.**
  1. *How does it fail?* Per-connector isolation prevents fleet-wide crash; individual connector goroutines fail independently.
  2. *Detection.* Health probe + per-connector last-success timestamp + dead-letter counters.
  3. *Initiation.* Automatic reconnect with backoff; runbook for persistent-auth failure.
  4. *Automated?* Yes, for transient failures; runbook for credential rotation.
  5. *Rollback?* Yes, via configuration rollback and DLQ replay.
- **v0 scope.** Syslog (TCP/UDP/TLS), HTTPS push, one cloud connector (choice per ARCH-18), one reference forwarder receiver.

### 4.2 E-02 Normalization Engine (AEGIS-added)

- **Purpose.** Map raw events to canonical OCSF schema; produce a normalized-view derived object linked to raw by `raw_ref + integrity_hash`.
- **Inputs.** Raw events from Kafka.
- **Outputs.** Normalized events on a downstream Kafka topic + persisted in event plane.
- **Kernel interactions.** `Publish-Normalized` capability; `Read-Raw` on inputs; audit events for redaction actions.
- **Storage.** ClickHouse via Storage Engine.
- **Failure modes.** Unmapped source variants; schema drift; redaction miss; PII leaked into normalized copy.
- **Recovery.**
  1. Unmapped events go to a "quarantine" partition, not dropped.
  2. Health probe + quarantine size metric + normalization-error rate.
  3. Automatic replay on rule-set update; runbook for high quarantine.
  4. Automated for schema updates via versioned mapping catalog.
  5. Rollback via `normalization_version` — old view remains queryable; re-normalization is possible without touching raw.
- **v0 scope.** Full pipeline; OCSF v1.x baseline; quarantine partition.

### 4.3 E-03 Storage Engine

- **Purpose.** Read/write facade over PostgreSQL (control plane) and ClickHouse (event plane). Enforces tenant scoping, classification, immutable-event-sourcing rules, and query budgets.
- **Inputs.** CRUD requests from other engines (via Kernel).
- **Outputs.** Query results; write receipts.
- **Kernel interactions.** Every access requires a Kernel-issued capability (Read-Logs, Write-Findings, Export-Cases, etc.) with tenant + resource scope.
- **Storage.** Owns PostgreSQL and ClickHouse connections; owns tenant-scoping middleware; owns row-level policies where the underlying store supports them.
- **Failure modes.** DB down; connection exhaustion; slow query; index bloat; write amplification; disk pressure; ClickHouse merge lag.
- **Recovery.**
  1. Per-store health probes + circuit breaker; graceful degradation (read-only mode).
  2. Prometheus metrics on slow queries, connection pool, replication lag.
  3. Automatic reconnect; runbook for restore.
  4. Automated for transient; runbook for restore-from-backup coordinated with Recovery Engine.
  5. Rollback via Recovery Engine backup restoration.
- **v0 scope.** Full facade for six-capability data; export API for tenant data extract.

### 4.4 E-04 Detection Engine

- **Purpose.** Correlate normalized events using Sigma rules and (later) statistical detectors; produce findings.
- **Inputs.** Normalized events + rule set.
- **Outputs.** Findings (with citations) published to a NATS topic; persisted via Storage Engine.
- **Kernel interactions.** `Read-Normalized`, `Publish-Findings`, `Read-Rules`, `Write-Findings`.
- **Storage.** Rules in Postgres via Storage Engine; findings in Postgres (metadata) + event plane (evidence links).
- **Failure modes.** Runaway rule; pathological event; rule compilation error; false-positive spike; missed detection.
- **Recovery.**
  1. Time-boxed rule evaluation; resource caps per rule; per-rule circuit-breaker.
  2. Rule-eval latency histograms; false-positive rate per rule; findings volume alerts.
  3. Automatic rule disable on eval-timeout streak; runbook for rule triage.
  4. Automated for known-bad rules; human for suspected miss.
  5. Rollback via rule-set version pin.
- **v0 scope.** Sigma; test-harness for rules; extension contract for statistical detectors (implementation deferred).

### 4.5 E-05 AI Engine

- **Purpose.** Route AI requests through the three-tier model (L1/L2/L3); manage provider adapters; own prompt lifecycle. **Does not perform correlation, storage, or action.**
- **Inputs.** AI request from Case Engine or Detection Engine (via Kernel).
- **Outputs.** Recommendation object (with citations) delivered to the AI Safety Layer for validation.
- **Kernel interactions.** `Invoke-AI` capability per tier + classification; `Read-Evidence` scoped to the requesting case; `Publish-Recommendation`.
- **Storage.** Prompt/completion pairs and redaction manifests in ClickHouse via Storage Engine; provider adapters read secrets via Kernel-mediated secret retrieval.
- **Failure modes.** Provider outage; rate-limit; hallucination; prompt injection; adapter bug; runaway cost.
- **Recovery.**
  1. Circuit breaker per provider; tier fallback (L3 down → L2 up); cost budget per tenant.
  2. Provider health metrics + citation-validation failure rate + Safety Layer rejection rate.
  3. Automatic fallback; runbook for extended provider outage.
  4. Automated for transient; runbook for adapter update.
  5. Rollback via adapter version pin + prompt template version pin.
- **v0 scope.** L1 rules; L2 local (Qwen primary, Llama fallback); L3 hosted (Claude, GPT, Gemini) tenant-configurable; **Safety Layer is a separate engine (referenced but detailed in ARCH-14, Phase B.3)**.

### 4.6 E-06 Policy Engine

- **Purpose.** Evaluate policy rules the Kernel consults during mediation. Owns the policy corpus. Explains decisions.
- **Inputs.** Policy consultation requests from Kernel (identity, capability, resource, classification, boundary, context).
- **Outputs.** Decision (allow / deny / require-consent / require-4-eyes / require-break-glass) + rationale + policy-rule references.
- **Kernel interactions.** Kernel calls Policy for decisions; Policy has read access to policy corpus in Postgres via Storage Engine.
- **Storage.** Policy corpus in Postgres (versioned, signed); hot cache in memory.
- **Failure modes.** Slow evaluation; policy compilation error; conflicting rules; missing rule; over-permissive default.
- **Recovery.**
  1. Timeout on evaluation (Kernel-side); safe default is **deny**.
  2. Latency SLO; evaluation-error rate; decision-cache hit rate.
  3. Automatic reload on rule update; runbook for conflicting-rule detection.
  4. Automated for known-good; human for rule-conflict resolution.
  5. Rollback via policy corpus version pin.
- **v0 scope.** Rule DSL (Rego-like or a scoped OPA embedding — TBD in ARCH-12); ships with a base policy set covering all six capabilities; policy authoring UI is v0-lite.

### 4.7 E-07 Identity Engine

- **Purpose.** Own the lifecycle of human, service, and agent identities. Integrate with IdP (OIDC). Manage RBAC. Serve as the source of truth Kernel consults for capability delegation.
- **Inputs.** IdP callbacks; identity CRUD requests; RBAC changes; agent-identity registration.
- **Outputs.** Verified subject + role + attributes; RBAC → capability translation for the Kernel.
- **Kernel interactions.** Kernel calls Identity Engine on session establishment and on capability delegation checks; Identity emits identity-change events on NATS; Kernel consumes.
- **Storage.** Identities, roles, sessions in Postgres (via Storage Engine).
- **Failure modes.** IdP unreachable; token replay attempt; session hijack; RBAC misconfiguration; sync drift with IdP.
- **Recovery.**
  1. Session cache with short TTL; IdP outage triggers break-glass path for existing valid sessions; new logins fail closed.
  2. IdP health; session anomaly detection; RBAC change audit.
  3. Automatic session refresh; runbook for IdP outage.
  4. Automated for transient; runbook for sync repair.
  5. Rollback via RBAC snapshot restore.
- **v0 scope.** OIDC; 6 roles + capability delegation surface; break-glass workflow entry point.

### 4.8 E-08 Audit Engine

- **Purpose.** Receive Layer-A hash-chained audit records from the Kernel; verify local ring copies; produce Layer-B signed archival batches to durable storage; expose independent-verification tools.
- **Inputs.** Layer-A records from Kernel over NATS; Layer-A ring snapshots.
- **Outputs.** Signed Layer-B batches to object store; verification API; export bundles.
- **Kernel interactions.** Audit Engine has its own signing key hierarchy (AS-K-03); operations on that hierarchy pass through Kernel; Kernel writes to Audit are subject to the same BC contract.
- **Storage.** Layer-B batches to object store (Recovery Engine coordinates); index of batches in Postgres.
- **Failure modes.** Archival storage unreachable; signing key issue; chain-gap detection; batch integrity failure.
- **Recovery.**
  1. Local buffer while archival is unreachable; chain-gap alerts immediately.
  2. Watermark of latest archived batch; gap detector; signing key freshness monitor.
  3. Automatic retry to archival; runbook for chain-gap incident.
  4. Automated for transient; **chain-gap is a critical incident**, human-driven.
  5. Rollback is not applicable to audit; forward-only.
- **v0 scope.** Full Layer-A receipt + Layer-B batching + signing + published verification tool.

### 4.9 E-09 Case Engine (AEGIS-added)

- **Purpose.** Group findings into cases; build incident timelines; own case state, annotations, evidence bundles.
- **Inputs.** Findings from Detection Engine; analyst actions from UI (via Kernel); AI recommendations from AI Engine (post Safety Layer).
- **Outputs.** Cases, timelines, exported evidence bundles.
- **Kernel interactions.** `Read-Findings`, `Write-Case`, `Append-Timeline`, `Export-Case`.
- **Storage.** Cases in Postgres (metadata); timelines composed at query time from findings + annotations + AI recs.
- **Failure modes.** Race between two analysts; malformed AI rec; corrupted export.
- **Recovery.**
  1. Optimistic concurrency; append-only annotations; per-export signature verified before delivery.
  2. Conflict-rate metric; export failure rate.
  3. Automatic for optimistic-lock retries; runbook for corrupted export.
  4. Automated for common cases.
  5. Annotations are additive; rollback = new annotation, never destructive edit.
- **v0 scope.** Full case + timeline + export; UI is v0-lite.

### 4.10 E-10 Telemetry Engine

- **Purpose.** Own AEGIS's own operational telemetry: metrics, logs, traces of the platform (not tenant events). Run the scrubber pipeline. Provide opt-in external export.
- **Inputs.** OpenTelemetry from every engine + Kernel.
- **Outputs.** Prometheus/OpenMetrics scrape; internal log store; trace store; opt-in external export.
- **Kernel interactions.** `Publish-Telemetry`, `Export-Telemetry`; egress calls (opt-in) require capability + boundary crossing.
- **Storage.** Short-retention telemetry store; separated from audit and tenant data.
- **Failure modes.** Cardinality explosion; PII leak into logs; scrubber bypass.
- **Recovery.**
  1. Cardinality limits per label; sampling under load; scrubber has property tests.
  2. Cardinality metrics; scrubber pass rate; sampled-log review.
  3. Automatic sampling; runbook for scrubber-miss forensic.
  4. Automated for sampling; human for scrubber-miss incident.
  5. Configuration rollback + retention purge on scrubber-miss.
- **v0 scope.** Full internal telemetry; opt-in external export off by default.

### 4.11 E-11 Recovery Engine

- **Purpose.** Own backup, restore, DR runbooks, degraded-mode orchestration, chaos-drill scheduling, and rollback tooling for the whole platform.
- **Inputs.** Schedule; snapshot triggers; restore requests; runbook invocations from operators or automated triggers.
- **Outputs.** Backups, restores, degraded-mode transitions, health verifications.
- **Kernel interactions.** `Execute-Recovery` is a highly-privileged capability requiring 4-eyes for destructive operations; `Read-Snapshot`, `Write-Snapshot`.
- **Storage.** Backup metadata in Postgres; backup payloads to object store; keys from separate KEK hierarchy (AS-K-08).
- **Failure modes.** Backup miss; restore corruption; slow restore; ransomware on backup target; misapplied runbook.
- **Recovery.**
  1. Backup-of-the-backup (immutable copy); scheduled restore drills; per-runbook property tests.
  2. Backup success metric; restore drill pass rate; drift from RTO/RPO SLOs.
  3. Automatic backup; automatic restore drill; human for real restore.
  4. Automated for backup + drill; runbook-driven for real recovery.
  5. Every restore leaves the source intact; rollback = point in time selection.
- **v0 scope.** Backup + restore + DR runbook + drill scheduling; automated response actions are Phase 3.

### 4.12 E-12 Plugin Engine (interface only in v0)

- **Purpose.** Manifest validation, sandbox launch, capability grant, plugin lifecycle.
- **v0 scope.** Interface + manifest schema defined; runtime implementation is v0.2+; detailed in ARCH-14 (B.3).

### 4.13 E-13 Response Engine (interface only in v0)

- **Purpose.** Automated response actions (quarantine, credential-revoke, rule-push, etc.).
- **v0 scope.** Interface defined so that Case Engine and AI Engine can emit "proposed action" objects; **no execution in v0** (F-4.5). Full Response Engine is Phase 3, with its own threat model.

## 5. Cross-Engine Data Contracts

Interfaces are defined by *event schemas* and *API schemas*, not by shared code. Every schema is:
- **Versioned** (major.minor).
- **Signed** by the publishing engine's identity where the schema is a durable artifact (raw events, findings, cases, exports).
- **Documented** with backward-compatibility rules.

Key durable schemas (detailed in ARCH-08):

| Schema | Producer | Consumers | Version |
|---|---|---|---|
| Raw Event | Connector | Normalization, Detection (advanced), Case (evidence) | v1 |
| Normalized Event (OCSF) | Normalization | Detection, Case (evidence), AI (evidence) | v1 |
| Finding | Detection | Case, AI, Policy (for rule triage) | v1 |
| Case | Case | UI, AI, Audit, Export | v1 |
| Recommendation | AI (post Safety Layer) | Case | v1 |
| Audit Record (Layer A) | Kernel | Audit Engine | v1 |
| Audit Batch (Layer B) | Audit Engine | Archival | v1 |
| Policy Rule | Policy | Kernel, UI | v1 |
| Capability Token | Kernel | Engines | v1 |
| Identity | Identity | Kernel | v1 |

Contracts are published under `docs/schemas/` starting Phase B.2.

## 6. Independent Architecture Review

### 6.1 Hidden Assumptions

| Assumption | Handling |
|---|---|
| The Kernel-mediated hop is affordable for every cross-engine call. | Kernel round-trip budget documented; caching (D-05-2) absorbs most calls; data-plane per-record ops are broker-ACL, not Kernel. |
| Sigma is sufficient for v0 detection. | Backed by extension contract for statistical detectors; not fully sufficient beyond v0 but is a defensible baseline. |
| The reference forwarder receiver adequately covers Windows / macOS / Linux hosts. | True for v0; endpoint agent (post-v0) will replace the forwarder for AEGIS-owned deployments. |
| OpenTelemetry as the telemetry substrate is stable through 2036. | Standards-based; if OTel becomes deprecated, the Telemetry Engine is replaceable per C-12. |

### 6.2 SPOFs

| Finding | Response |
|---|---|
| **F-1.** *Storage Engine is a facade over PG + ClickHouse — its outage halts everything.* | Storage Engine is stateless; horizontally scaled; per-store circuit breakers; degraded-mode allowlist. |
| **F-2.** *Audit Engine SPOF for Layer-B archival.* | Kernel-side local ring buffer + short-window replication; multiple Audit Engine replicas; extended outage triggers alert but not platform halt (per ARCH-05 F-3 revision). |
| **F-3.** *Policy Engine outage stalls all mediation.* | Kernel-side timeout with default-deny; short-cache of policy decisions; Policy Engine replicated. |
| **F-4.** *IdP outage locks tenants out.* | Session cache; break-glass local admin; multi-IdP support is v1. |

### 6.3 Privilege Escalation

| Finding | Response |
|---|---|
| **F-5.** *Storage Engine trusted to enforce classification — bug allows a caller to bypass.* | Property tests for classification propagation; row-level policies where DB supports; audit-side detection of classification-violating queries. |
| **F-6.** *Case Engine allows edits that overwrite history.* | Append-only annotations; hard delete requires break-glass. |
| **F-7.** *AI Engine directly writes to Case Engine without Safety Layer.* | Architecturally impossible: AI Engine's `Publish-Recommendation` topic is consumed by the Safety Layer, which is the only publisher on `Validated-Recommendation`; Case Engine consumes only the validated topic. |

### 6.4 Trust-Boundary Violations

| Finding | Response |
|---|---|
| **F-8.** *Normalization Engine leaks PII into normalized store.* | Scrubber pipeline in normalization stage; property tests; PII detection in Detection Engine; tenant redaction policy consulted. |
| **F-9.** *Telemetry Engine ships tenant identifiers externally.* | Scrubber pipeline; egress capability; opt-in default off. |

### 6.5 Bottlenecks

| Finding | Response |
|---|---|
| **F-10.** *Detection Engine single-instance can't keep up.* | Horizontally scalable by tenant partition; per-rule budget; rule-cost profiler. |
| **F-11.** *Case Engine timeline rendering slow for large cases.* | Server-side pagination + streaming; timeline is view-model computed from persisted parts. |
| **F-12.** *AI Engine's Safety Layer becomes bottleneck.* | Safety Layer scaled horizontally with AI Engine; parallelizable per request; specific latency budgets in ARCH-14. |

### 6.6 Supply Chain

| Finding | Response |
|---|---|
| **F-13.** *Compromised Sigma rule repo.* | Rule ingestion is signed-source-only; unsigned rules are quarantined; ARCH-12 covers governance. |
| **F-14.** *Model registry poisoning affects L2.* | Model provenance verification on load; canary evals per model; consensus for HR; ARCH-14. |
| **F-15.** *OTel SDK vulnerability.* | Hash-pinned dependencies; scrubber sits between SDK and export; kill-switch on external export. |

### 6.7 AI-Specific Risks

| Finding | Response |
|---|---|
| **F-16.** *AI Engine tries to fetch external context (RAG) and pulls attacker-controlled content.* | External RAG is out of v0. If added later, source-signed content and cache-side redaction (ARCH-09/14). |
| **F-17.** *AI Engine holds L3 API keys — key theft = tenant exfil.* | Keys held in Kernel-mediated vault; AI Engine calls Kernel to *use* a key, not to receive it; providers with zero-data-retention modes preferred; per-call audit. |

### 6.8 Operational Risks

| Finding | Response |
|---|---|
| **F-18.** *Thirteen engines to run is heavy for a small deployment.* | Reference single-node deployment collocates engines under a supervisor; separate processes remain but on one host; footprint sized in ARCH-16. |
| **F-19.** *Engine drift — someone builds a peer-to-peer call for speed.* | Enforced by SAST rule (no direct client calls between engines except via Kernel-mediated topics); code-review checklist; runtime detection at the mesh layer. |

## 7. Decisions

### D-07-1. Thirteen distinct engines (11 user-mandated + Normalization + Case)

- **Advantages.** Clear boundaries; independent lifecycle; replaceability; small blast radius per engine; recovery contracts practical per unit.
- **Disadvantages.** Higher deployment count; more inter-engine schemas to maintain.
- **Security Impact.** *Positive.* Compromise is contained.
- **Performance Impact.** *Neutral.* Data plane bypasses Kernel; control plane cost is small.
- **Operational Complexity.** *Higher* than a monolith; managed by the reference single-node collocation.
- **Maintainability.** *Positive* — ownership is clear.
- **Scalability.** *Positive.*
- **Alternative Designs.** *Fewer, coarser engines (e.g., merge Normalization into Detection).* Reduces surface but couples data-format concerns to correlation. Rejected. *More, finer engines (split AI into Router + Prompter + Adapters).* Overfragmentation. Rejected for v0.
- **Reason.** The 11 you specified plus Normalization and Case is the smallest set that respects the microkernel principle for v0 scope.

### D-07-2. Normalization is its own engine, not a Detection sub-module

- **Advantages.** Independent replaceability (schema evolution); dedicated quarantine + versioning; property tests focused on schema fidelity.
- **Disadvantages.** One more engine.
- **Security Impact.** *Positive.* Redaction lives in the right place.
- **Performance Impact.** Neutral (bus-decoupled).
- **Operational Complexity.** Marginal.
- **Maintainability.** *Positive.*
- **Scalability.** *Positive.*
- **Alternatives.** *Merge into Detection.* Couples schema to rules; rejected. *Merge into Connector.* Couples I/O to normalization; rejected.
- **Reason.** Immutable-event-sourcing principle demands a clear boundary between raw and derived.

### D-07-3. Case is its own engine, not a UI concern

- **Advantages.** Cases + timelines + evidence bundles are durable, first-class artifacts; consistent contract for exports; policy-governed.
- **Disadvantages.** One more engine.
- **Security Impact.** *Positive.* Export contract enforced structurally.
- **Performance Impact.** Neutral.
- **Operational Complexity.** Marginal.
- **Maintainability.** *Positive.*
- **Scalability.** *Positive.*
- **Alternatives.** *Cases live in UI code.* Weaker export contract; rejected. *Cases in Detection Engine.* Couples detection to case lifecycle; rejected.
- **Reason.** Cases are durable evidence artifacts; they deserve engine-level ownership.

### D-07-4. Response Engine defined but not implemented in v0

- **Advantages.** Interface defined so Case + AI can already produce action proposals; keeps design honest without shipping unsafe automation.
- **Disadvantages.** Some customers want automation; deferred.
- **Security Impact.** *Positive.* No unsafe autonomous action in v0.
- **Performance Impact.** N/A.
- **Operational Complexity.** Neutral.
- **Maintainability.** *Positive.*
- **Scalability.** N/A.
- **Alternatives.** *Skip entirely.* Then retrofitting later is harder; rejected. *Ship a limited executor.* "Limited" degrades under adversarial input; rejected for v0.
- **Reason.** Defining without executing satisfies F-4.5 while preserving forward compatibility.

## 8. Open Questions

- Q-07-1. Language per engine — the Kernel is TS (default); Normalization and Detection may benefit from a faster runtime (Rust or Go) at v1. Resolved in ARCH-12.
- Q-07-2. Reference single-node collocation supervisor (systemd unit set vs. docker-compose vs. single-binary supervisor). Resolved in ARCH-16.
- Q-07-3. Sigma engine implementation — vendor an existing library vs. write a scoped subset. Resolved in ARCH-12 / ARCH-18.
- Q-07-4. Precise cloud connector priority for v0. Resolved in ARCH-18.

## 9. Change Log

- **0.1 (2026-07-10)** — Initial draft after independent architecture review.