EVE vs Conventional Logging

Many teams rely on application logs and audit trails to record what an AI agent did. This page compares that approach to EVE, sourcing only EVE's capabilities from the EVE claims registry. Conventional logging is a general practice, not a single product, so we describe its typical properties rather than making product-specific claims; rows we cannot source are marked "not independently verified here."

Positioning

Conventional logging records events after they happen, usually as plaintext or structured logs that a team trusts because they control the log store. EVE makes a deterministic decision (ALLOW / BLOCK / MODIFY) before a governed action executes — so a blocked action never runs — and emits a signed evidence record bound to that decision that a third party can verify offline without trusting the EVE server.

The core difference: logging observes and records; EVE enforces at the decision point and produces tamper-evident, independently verifiable proof of what was decided.

Capability matrix

Capability	EVE	Conventional logging
Prevents a prohibited action from executing (enforcement, not just record)	Yes — deterministic BLOCK before execution; PILOT_READY	No — logs record after the fact
Deterministic decision (ALLOW / BLOCK / MODIFY) at the action point	Yes — PILOT_READY	not applicable (observational)
Signed evidence bound to the specific decision	Yes — SUPPORTED	not independently verified here (depends on the logging stack)
Tamper-evident record verifiable without trusting the recording server	Yes — offline Ed25519 verification; SUPPORTED	plaintext/structured logs are typically trusted because you control the store
MCP approved-vs-executed binding	Yes — PILOT_READY	not applicable
Action-sequence governance (block prohibited combinations)	Yes — PILOT_READY	not applicable (records only)
Deterministic budget / resource limit enforcement	Yes — PILOT_READY	not applicable
Signed monitoring envelopes summarizing behavior over a window	Yes — PILOT_READY	not independently verified here
Retrospective search / observability	Complements logging	Yes — the primary purpose of logging

Where EVE fits

Use EVE when you need to stop a prohibited action, not only to have a record that it happened — and when you need proof of each decision that an auditor can verify independently. EVE's evidence verifier checks integrity, signature, and schema and returns a result without contacting EVE, so the record's authenticity does not depend on trusting the party that produced it. EVE also produces signed monitoring envelopes summarizing agent behavior over a window, which can sit alongside your existing logs.

Conventional logging remains valuable for general observability and debugging; EVE adds the enforcement decision and the independently verifiable evidence that plain logs do not provide.

Readiness

EVE SDK core is a RELEASE CANDIDATE WITH EXCLUSIONS.
Python (eve-coreguard 0.2.2) and TypeScript (@eve/coreguard 0.1.0-rc1) are release-candidate core clients, distributed privately for pilots — not on public registries at this stage.
Core governance architecture is pilot-validated; signed evidence and offline verification are SUPPORTED.
Framework adapters other than the generic adapter are experimental.

Limitations

EVE's rows are sourced from the EVE claims registry. "Conventional logging" is described by its typical properties, not a specific product; rows we cannot source are marked "not independently verified here."
The pip client governs via hosted mode (needs an endpoint); embedded evaluation is the EVE service.
Independent verification requires the Ed25519 public key; the HMAC fallback is symmetric and not independently verifiable.
Signed monitoring envelopes are observational; enforcement decisions are made by CoreGuard, sequence, and budget controls.
MCP binding is at-most-once, not remote exactly-once.
Framework adapters other than the generic adapter are experimental; hard enforcement requires a gateway or sidecar, not a wrapper alone.