Skip to main content
04 / Verify / EMILIA Protocol

Make the record verifiable without asking EMILIA to vouch for itself.

The open Protocol lets a customer, partner, or reviewer check one portable evidence packet without trusting an EMILIA dashboard.

Give anyone the free machinery to verify one evidence packet without trusting EMILIA.

Follow the evidence pathRun the open verifier
Claim boundary: Verification does not create authority, prove execution, establish complete mediation, or make every native evidence source trustworthy.
Canonical presentation path

Four documents. One evidence path.

Gate exact actions before consequences. The Protocol makes the supporting record independently checkable. Start with one exact material action and its approval artifact, carry it into the host record, establish scoped authority under the relying party's trust roots, then evaluate whether the verified, action-matched bundle satisfies that party's evidence requirement.

This is a reader-facing path over four active individual Internet-Drafts. It does not merge, replace, retire, or subordinate the rest of the protocol portfolio.

01 / 04Internet-Draft

Authorization Receipts

draft-schrock-ep-authorization-receipts-12

What action-bound organizational approval evidence was produced under the receipt profile?

One approval-evidence profile. It does not establish scoped authority or evidence satisfaction by itself.

Read Receipts -12 →
02 / 04Internet-Draft

Human Authorization Binding

draft-schrock-human-authorization-binding-00

How is named-human authorization evidence bound into an adjacent host record?

A host-agnostic by-value or by-reference binding. It does not redefine the authorization artifact or host format.

Read Binding -00 ↗
03 / 04Internet-Draft

Authority Introduction

draft-schrock-ep-authority-introduction-03

Under the relying party's trust roots, did the verified key have authority for this scope?

Trust-root introduction and scoped authority. Signature verification alone does not create authority.

Read Authority -03 ↗
04 / 04Internet-Draft

Authorization Evidence Chain

draft-schrock-ep-authorization-evidence-chain-06

Does the natively verified, action-matched bundle satisfy the relying party's evidence requirement?

Returns SATISFIED or UNSATISFIED. It never returns a universal authorization verdict.

Read AEC -06 →
Terms that do not collapse

Evidence is an input to authorization, not a synonym for it.

Each result has a separate owner and claim. Passing one stage never silently proves a later one.

VERIFIEDOne artifact passed its native verifier under relying-party-selected trust inputs.
MATCHIndependently verified artifacts denote the same exact material action under pinned mapping rules.
SATISFIEDVerified, matched evidence fills every slot in the relying party's evidence requirement.
AUTHORIZEDThe relying party's separate local policy permits execution.
EXECUTEDAn executor asserts or attests that an effect occurred; evidence satisfaction does not prove the effect.
Gate execution path

Put the decision where the consequence can still be stopped.

The protocol keeps evidence portable. Gate joins that evidence to local authority and one-time admission at the protected effect boundary.

STEP 01

Describe one exact action

Bind the operation, target, material parameters, actor, and context before asking for authority. A receipt for a different payload does not transfer.

STEP 02

Verify the required evidence

Check each artifact under its native rules and relying-party-pinned trust inputs, then match every required leg to the same material action.

STEP 03

Authorize and reserve before invocation

AEC satisfaction is evidence, not permission. Gate applies local policy and current-status checks, then reserves one-time admission at the protected boundary before the provider call begins.

STEP 04

Record the outcome without inventing certainty

Preserve refusal, consumption, and outcome evidence. An indeterminate provider result enters authenticated reconciliation; it is not fresh authority to retry.

Deployment boundary

A protected path is not proof of complete mediation.

The four documents define portable evidence semantics. Gate enforces only on the configured effect-capable boundaries a deployment actually controls. A complete-mediation claim needs current deployment evidence that every in-scope route is covered.

01Inventory every effect-capable route and credential in the declared deployment scope.
02Put admission at each executor or system-of-record boundary where the consequence can still be stopped.
03Probe protected and alternate paths; a verified bypass overrides a successful blocked-path demonstration.
04Classify coverage as gated, ungated, stale, or unknown, and re-evaluate it when routes or credentials change.
Start with document 01

Authorization Receipts -10

Read the current posted receipt profile, then continue through binding, authority, and AEC.

Track the standard
Follow the protocol as it develops.

New drafts, conformance releases, and reference updates — sent only when there’s something worth your time.

No spam. One email field, nothing else.