EVE CoreGuard · Pilot Methodology

How a pilot works

From one real workflow to signed, hash-chained decision evidence you can verify offline — in roughly 60 days. This is the mechanics of an engagement, stage by stage: what gets deployed, what runs when, and exactly which artifact you walk away with at each step. No customer logos, no slideware — proof of process.

01 · The shape

One workflow, governed end to end

A pilot is a scoped, time-boxed deployment on a single real workflow in your regulated domain — the one where a decision has to be defensible after the fact. It is not a sandbox demo on synthetic data. CoreGuard evaluates each proposed action against a policy pack, returns an ALLOWED, BLOCKED, or MODIFIED disposition, and emits a signed decision record for every call.

The enforcement is deterministic: the same input reproduces the same governed result, so the evidence is reproducible rather than asserted. The commercial terms — founding-partner rate, duration, and how the pilot fee credits against an annual license — live on the design‑partner page. This page is about how the work actually runs.

02 · The engagement, stage by stage

Four stages from scope to verified evidence

Timings are the typical rhythm of a roughly 60-day engagement, not a contractual schedule — the workflow sets the pace.

Stage 0Week 0 · Scope

Define the one workflow

We pick the single workflow together, define the decision schema CoreGuard will see (proposed_action, model_output, context), select the policy pack for your domain — lending_v1, insurance_v1, healthcare_v1, government_v1 — and agree what success looks like before any code is wired in.

Signed scope & decision schema
Stage 1Weeks 1–2 · Shadow

Deploy in log-only mode

CoreGuard goes in as an EVE Sidecar or via the API/SDK, running in logging_only mode. It evaluates every decision and records the disposition it would have taken — but it does not block your traffic yet. From day one you are accumulating real, signed decision records on your own data, with zero risk to production.

Live signed decision ledger
Stage 2Weeks 3–5 · Calibrate

Tune the policy pack on real decisions

We review the shadow records together, tune the policy pack against decisions that actually occurred, drive down false positives, and promote the rules you trust from advisory to enforcing. The calibration report is computed on your decisions, not on a vendor benchmark.

Tuned policy pack + disposition report
Stage 3Weeks 6–8 · Enforce & verify

Flip to enforcing — then verify it yourself

Enforcement goes live: BLOCKED and MODIFIED dispositions now take effect inline, within the contractual governance-latency target (<10ms p95 on the Enforcement tier). You then independently verify the evidence offline — recompute the SHA‑256 content hash and check the Ed25519 signature with the public key, no EVE server in the loop.

Examiner-ready evidence bundle
03 · The artifacts

What you actually receive

Deliverables
  • A working deployment on one real workflow — sidecar, API, or SDK.
  • A per-decision signed record — SHA-256 content hash plus an Ed25519 signature.
  • A hash-chained ledger — tamper-evident; reordering or editing any entry breaks the chain.
  • A tuned policy pack co-developed for your regulation and workflow.
  • A disposition report computed on your own decisions.
How you check it
  • No shared secret — verification uses the public key only.
  • No EVE server in the loop — recompute and check locally.
  • Three SDKs: eve-coreguard, eve-governance, eve-proof — all on PyPI.
  • Same input, same result — deterministic, so evidence is reproducible.
  • Walk through a live one at /verify.
04 · The offline check

Verify a decision record with no EVE server

The auditor/regulator path needs no CoreGuard client at all. Install the standalone verifier, recompute the content hash, and check the signature against the published public key:

# Auditor path — no shared secret, no server call pip install eve-governance from eve_governance import verify_decision_evidence result = verify_decision_evidence(decision_record, public_key_pem) assert result.valid # signature + recomputed hash both check out assert result.hash_matches # content was not altered after signing

The CoreGuard SDK exposes the same primitives directly — verify_decision_record(), fetch_public_key_pem(), and recompute_content_hash() — and EVE Proof certificates verify the same way via verify_certificate(). The full mechanism is documented in the Python SDK reference and the assurance page.

05 · Definition of done

What “done” looks like

A pilot is complete when four things are true — and not before:

No vanity metrics, and no public reference is ever a condition of the program. You can run a full pilot and remain entirely private.

Run this on one of your workflows

If you operate a regulated workflow where decision evidence has to exist at the moment of the decision, a scoped pilot is the fastest way to prove it — on your data, verified by you.