Policy Runtime & Evaluation

Audience: Policy Engine operators, platform engineers, and tooling authors integrating with the runtime. Scope: How SPL policies are compiled, cached, and executed, how results surface via API/CLI/UI, and the runtime’s determinism, observability, and offline guarantees.

Imposed rule: Runtime evaluations must use frozen inputs (SBOM, advisories, VEX, reachability, signals) and emit explain traces plus DSSE/attestation metadata; no live feed calls during evaluation.

This guide describes how stella-dsl@1 policies are compiled, cached, and executed, and how results are surfaced via APIs, the CLI, the Console UI, and observability. For the full authoring-to-archival flow, see the Policy Lifecycle & Approvals guide; for batch and scheduled execution, see Policy Runs & Orchestration.

1. Components

2. Execution flow

  1. Resolve active policy version for tenant (or specified version for simulate).
  2. Load IR from cache; verify hash matches attested value if provided.
  3. Fetch frozen inputs via cursors: SBOM digest, advisory snapshot id, VEX set, reachability graph hash, signals bundle.
  4. Evaluate rules in priority order; record explain entries (rule, because, inputs, signals).
  5. Persist findings, explain traces, and run metadata (runId, policyVersion, hashes) to storage.
  6. Emit events: policy.run.started, policy.run.completed, policy.run.failed; optionally policy.run.shadow when settings.shadow=true.

3. Caching & determinism

4. APIs & CLI

5. Observability & SLOs

6. Failure modes & handling

7. Offline / air-gap

8. Data model (high level)

9. References