Skip to main content
Experimental advisory profile / 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 keeps a different question separate: signal, admission, approval evidence, and the resulting record.

Eye
Observes
Produces a short-lived, action-scoped advisory. Eye never authorizes or blocks, and its absence cannot relax the relying party's base policy.
EMILIA Gate
Controls
Gate owns enforcement. On a configured covered path, it checks the exact action, accepted authority, required evidence, and local policy before provider entry.
EMILIA Approver
Captures
When local policy requires fresh approval, an enrolled approver credential signs the displayed exact action. The relying party separately decides whether that credential is acceptable for the role.
Action receipt
Records
The signed, action-bound record preserves what was presented and decided. Execution and indeterminate outcomes remain separate, and an effect that may have happened is never erased by rewriting the receipt.
Eye observes. Gate owns enforcement. Approver captures. The receipt records.
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 an experimental open-source advisory profile. A managed deployment can be scoped with a buyer; this page does not claim a generally available production service.

Open Source
Self-hosted Eye
Apache 2.0 licensed. Run Eye on your own infrastructure and keep signal routing, storage, and trust-stack integration under your control.
Managed
Gate Cloud with Eye
Buyer-scoped signal processing, warning triage, and integration into the buyer's Gate policy. Production operation requires deployment-specific acceptance.
Experimental advisory profile / Emilia Eye

Start with observation. Build toward enforcement.

Run Eye in OBSERVE mode first. Map high-risk action patterns without changing the production decision, then decide which paths merit a separately scoped Gate boundary.

Pilot Emilia Eye

$25K · 90 days · 1 protected workflow. Synthetic and read-only validation first; production only through a buyer-approved Gate boundary.