Kernel capabilities implemented. End-to-end platform integration and qualification are progressing.Interactive demonstrationPlatform status

Decision and control

Immune Engine

Pressure and quarantine state at the admission boundary.

Pressure/quarantine state and an admission veto within defined policies, plus a containment request shape. Not an autonomous detector.

Implemented2 lifecycle positionsNon-production evidence

Responsibility

What Immune Engine is responsible for

The Immune Engine maintains pressure and quarantine state and can veto admission when that state requires it. The reviewed implementation contains no detector and no autonomous containment actuator: containment is a request shape, and containment actions remain partial.

Containment is a governance decision under time pressure. The intended capability is to make that decision explicit: signals are evaluated against policy, and the outcome is a defined constraint on what may execute, with an audit trail.

What is implemented today is the state and veto half of that picture: pressure and quarantine state participate in admission, and an unobserved policy context blocks rather than permits. Detection, autonomous containment and automated recovery are not implemented.

Lifecycle position

Where it sits in the governance lifecycle

Stage numbering is canonical across the site. Open the interactive lifecycle to see every component with responsibilities at each stage.

  1. Decision

    Coordinate policy, constraints and uncertainty.

  2. Execution

    Apply the effect through a controlled adapter.

Verified capabilities

What is verified today

Capabilities are drawn from the product register. Each one is bounded by the limitations stated further down this page.

  • Pressure and quarantine state used by admission
  • Admission veto when immune policy state requires it
  • Fail-closed behaviour when policy context cannot be observed
  • Containment request shape (actions partial; no autonomous actuator)

Inputs

  • Pressure/quarantine signals
  • Immune policy state
  • Admission context

Outputs

  • Admission veto
  • Immune state records
  • Containment request

Evidence and maturity

What the evidence supports

Maturity describes verified engineering evidence in a bounded environment. It is not a production-readiness statement.

Implemented

Maturity note

Pressure/quarantine state and an admission veto are implemented, and live admission can be blocked when policy context is unobserved. There is no detector or autonomous actuator, and containment actions are partial (R-08).

Not production-qualified

This label describes verified engineering evidence only. No production deployment, certification, benchmark or customer outcome is claimed.

Evidence recorded

  • Recorded Control Plane chain hop 6: immune pressure/quarantine state and admission veto.
  • Release-candidate platform conformance record: containment actions PARTIAL (R-08).
  • Live admission blocked with POLICY_CONTEXT_UNOBSERVED in the 2026-11-03 audit.

Dependencies

  • Control Plane
  • MZiNG Network
  • audit ledger

Dependencies are stated as the product register records them. A dependency is not automatically production-qualified; see its own product or component page for its maturity and limitations.

Limitations

What this product does not do (yet).

Limitations are stated before the evaluation questions so they cannot be missed, downplayed or treated as future-work footnotes.

Limitations — read before evaluating
  • No detector and no autonomous containment actuator are implemented.
  • Containment actions are partial (R-08); autonomous recovery was not demonstrated.
  • Live D8 admission is blocked while immune policy context is unobserved.
  • Packet-level or device-level containment enforcement is not implemented, and no detection-rate claim is made.

No capability on this page should be read as production qualification. If a limitation is material to your use case, it belongs in the evaluation scope — not after it.

Relationship to the platform

How it fits

The Immune Engine constrains the same admission and execution boundary that Gatekeeper and NARG enforce. It does not execute effects; it removes permitted activity when the policy state requires it.

Evaluation questions

  1. Which signals would trigger containment in your environment?
  2. What is contained — a tenant, an actor, a target or a class of action?
  3. What has to happen before containment is lifted?

Next step

Evaluate Immune Engine against a real control problem.

Bring a system boundary, an action class and a failure mode. The first step is to agree what should be governed and what evidence would count.