EVE Shadow Policy

Evaluate a candidate policy against live traffic or historical decisions — without changing the authoritative verdict.

Who this is for

Policy owners who want to change a rule and know, before it goes live, what would have been different — how many decisions flip, which classes regress, and by how much. You need a safe way to test a candidate policy that structurally cannot affect production decisions.

The problem

Changing an enforcement policy blind is risky: a tighter rule might block legitimate actions, a looser rule might let through what you meant to stop. Testing in production is worse. You need to run the candidate policy in parallel, compare it to the authoritative decision, and get a signed report of the divergences — while the authoritative verdict stays untouched.

Supported capabilities

• Authenticated shadow evaluation. Authenticated customers can evaluate candidate policies in shadow — live or by historical replay — and see divergences without changing the authoritative decision (core/agent_monitoring/shadow.py, shadow_service.py, saas/routers/shadow_router.py).
• Replay and signed divergence reports. EVE replays historical decisions against a candidate policy and produces signed divergence reports with modeled-effect estimates (shadow.py replay/build_report; shadow_report_v2.py).

Readiness: shadow evaluation and replay/divergence reporting are PILOT_READY — the shadow subsystem is authenticated pilot-ready.

How it works

1. An authenticated customer supplies a candidate policy.
2. EVE evaluates it in shadow — against live traffic, or by replaying historical decisions.
3. For each decision, EVE compares the candidate's outcome to the authoritative outcome.
4. EVE produces a signed shadow report (jcs-1) with agreement rate, divergence by class, and any critical regressions.
5. The authoritative decision is never altered. Promotion is dry-run only and never activates a production policy.

Technical example (report shape)

{
  "shadow_report": {
    "version": 2,
    "canon": "jcs-1",
    "agreement_permille": 987,
    "divergence_by_class": { "BLOCK->ALLOW": 3, "ALLOW->BLOCK": 10 },
    "critical_regressions": [],
    "signature": "ed25519-…"
  }
}

Rates are carried as integer permille (per-thousand) so they stay within the jcs-1 supported value domain.

Signed evidence example

The shadow report is itself signed evidence. Divergence figures are modeled effects from replay or sample, explicitly labeled as such — not observed production outcomes.

Verifier example

import { verifyEvidence } from "@eve/coreguard";
const report = verifyEvidence(shadowReport, { publicKeyPem });
// { valid: true, signature: "ed25519-valid" }

Deployment options

Shadow Policy runs in hosted mode (for authenticated customers) or embedded inside the EVE service. Evaluation is authenticated; it is not an anonymous public surface.

Readiness

Shadow evaluation and replay/divergence reporting are PILOT_READY — the shadow subsystem is authenticated pilot-ready. Signed reports use jcs-1, which is SUPPORTED. The EVE SDK core overall is a RELEASE CANDIDATE WITH EXCLUSIONS.

Limitations

• Shadow evaluation is structurally non-authoritative: it cannot alter the active verdict. Promotion is dry-run only and never activates a production policy.
• Divergence estimates are modeled effects from replay or sample — explicitly not observed production outcomes.
• Rates are carried as integer permille to stay within the jcs-1 supported domain; jcs-1 is a constrained RFC 8785 profile, not full compliance.
• The release-candidate clients are distributed privately for pilots — install the pilot artifact, not a public pip/npm install (see readiness for public-registry status).

Next step

Request a pilot to run one of your candidate policies in shadow against historical decisions and review the signed divergence report before any change goes live.