Skip to main content
Product / Emilia Eye

Start lighter with Emilia Eye

A warning protocol that flags when stricter EP trust controls should apply. Eye does not enforce. It does not block. It raises a signal so the right system can respond.

Pilot Emilia EyeRead the Spec

What Emilia Eye is

Eye is a warning-first protocol. It observes action patterns and raises a triage signal when something looks like it should trigger stricter trust controls.

Warning-first
Eye does not block, deny, or enforce. It flags. The downstream system decides what to do with the signal.
Triage signal
Eye classifies the reason for the warning and routes it to the appropriate enforcement layer. It is a routing primitive, not a decision engine.
Short-lived
Eye warnings are scoped to the action that triggered them. They do not persist as labels, scores, or reputation markers.
Subordinate to EP
Eye is not a replacement for EP Handshake or Accountable Signoff. It is the lightweight entry point that tells you when those controls should apply.

The stack

Four layers. Each does one thing. Together they cover the full lifecycle from observation to enforcement to ownership to sealing.

Eye
Observes
Moves through OBSERVE → SHADOW → ENFORCE lifecycle. Flags when a high-risk action pattern appears and routes it to the appropriate enforcement layer. No enforcement in OBSERVE mode. Full enforcement in ENFORCE mode.
EP Handshake
Verifies
Pre-action trust enforcement. Binds actor identity, authority chain, policy version, and exact action context into a replay-resistant verification envelope before execution.
Accountable Signoff
Owns
When policy requires named human ownership, a specific principal must explicitly assume responsibility for the exact action. Cryptographically bound, one-time consumable.
EP Commit
Seals
Atomically closes the action. Immutable, hash-linked, blockchain-anchored. Once sealed, the record cannot be partially reversed through protocol means. No partial states.
Eye observes. Handshake verifies. Signoff owns. Commit seals.
Experimental · continuous-eval loop

An additive, advisory-only extension is in draft. Eye can emit its advisory as a signed Security Event Token (EP-EYE-SET-v1, RFC 8417) so a relying party can re-evaluate posture continuously — but the advisory is never the sole gate on an action; it can only tighten posture. Paired with it, an instant-revocation statement (EP-REVOCATION-v1) lets a relying party cut off a long-lived authorization. Both are additive over the frozen core, advisory-only, and governed by PIP-011 (Draft). Not yet production-ready.

How Eye differs from scores and reputation

Eye is not a reputation system. It does not produce public scores, persistent labels, or crowd-sourced ratings.

Dimension
Emilia Eye
Reputation Systems
Public scores
No. Eye signals are internal to the deploying organization.
Yes. Scores are visible to counterparties or the public.
Persistent labels
No. Eye warnings are short-lived and action-scoped.
Yes. Labels persist and follow entities across contexts.
Crowd input
No. Signals come from policy and system context, not votes.
Yes. Ratings, reviews, and community feedback shape scores.
Enforcement
No. Eye observes. Enforcement belongs to Handshake.
Often. Scores directly gate access or transactions.
Explainability
Yes. Every warning includes the reason and the signal class.
Rarely. Scores are typically opaque aggregates.

Signal classes

Eye classifies warnings by domain. Each signal class maps to the action patterns most likely to require stricter trust controls in that vertical.

GOV
Government
Payment destination changes, benefit redirects, eligibility overrides, unusual operator escalations
FIN
Financial
Beneficiary changes, payout destination updates, remittance modifications, unusual treasury approval paths
ENT
Enterprise
Privilege escalation, configuration changes, access grants, administrative overrides outside normal patterns
AI
AI / Agent
Destructive tool-use actions, delegated authority boundary violations, autonomous execution of irreversible operations

Example flows

How Eye works in practice across two high-risk verticals.

Government
Payment destination change
01
Operator initiates a payment destination change for a benefits disbursement.
02
Eye detects the action pattern and raises a GOV signal: beneficiary redirect, destination mismatch with enrollment record.
03
The system routes the flagged action into EP Handshake for pre-action verification.
04
If policy requires it, Accountable Signoff binds a named supervisor to the exact change before execution.
Financial
Beneficiary change on wire transfer
01
An operator or automated system requests a beneficiary change on an outbound wire.
02
Eye raises a FIN signal: payout destination change, new beneficiary not in approved counterparty registry.
03
The flagged transaction is routed to EP Handshake, which binds the actor, authority chain, and exact transaction parameters.
04
Treasury policy triggers Accountable Signoff. A named treasury officer signs off on the exact beneficiary change before the wire executes.

Packaging

Eye is in pilot as open-source and managed cloud (PIP-005, accepted spec).

Open Source
Self-hosted Eye
Apache 2.0 licensed. Run Eye on your own infrastructure. Full control over signal routing, storage, and integration with your existing trust stack.
Managed
Gate Cloud with Eye
Hosted signal processing, pre-built signal class libraries, dashboard for warning triage, and direct escalation into EP Handshake and Accountable Signoff.
Product / Emilia Eye

Start with observation. Build toward enforcement.

Deploy Eye in OBSERVE mode first. Understand your high-risk action patterns before adding enforcement. No disruption to existing workflows.

Pilot Emilia Eye

Pilot Emilia Eye

Eye — Graduated Risk Observation Without Production Risk | EMILIA