Skip to main content
RELIANCE RISK PLANE · EMILIA GATE

Technical evidence for reliance decisions. Not an insurance decision.

EMILIA Gate adds a bounded risk plane around the exact authorization lifecycle: a carrier-readable control schedule, customer-owned responsibility terms, declared open-exposure custody, signed technical refusals, provider-outcome evidence, period population reconciliation, and one re-performable action packet.

An insurer, auditor, or customer can re-perform those artifacts under independently pinned inputs. EMILIA does not supply the underwriting, legal, coverage, causation, completeness, solvency, adjudication, or payment conclusion.

Run the reconciliation labInspect the shipped proofScope one protected workflow
WHAT SHIPPED

Seven evidence surfaces. None can authorize an action by itself.

Control contract
Action-risk control schedule
A relying party pins the action class and CAID profile, provider boundary, control digests, qualification source, exposure ceilings, mediation evidence, and uncertainty handling. The schedule specifies outcome-source roles, classes, quorum, and timing requirements. Its result is technical eligibility only. It never authorizes the action or creates coverage.
RP policy
Loss-allocation schedule
The relying party pins separately signed responsibility terms to the exact Reliance Program. Verification establishes the signed bytes, issuer, status, and program binding—not legal enforceability, coverage, solvency, or payment.
Live control
Open Exposure Ledger
Declared exposure is reserved before provider invocation against configured ceilings. INVOKING and INDETERMINATE stay open; only the configured independent reconciliation authority can close them.
Transaction evidence
Exact-action refusal
A signed refusal binds the action, program, failed requirements, challenge, nonce, custody, and time. It is technical exact-action evidence—not a legal denial, adverse-benefit denial, or coverage decision.
Period evidence
Coverage reconciliation
The attestation signs supplied system-of-record and receipt roots, counts, joins, exclusions, exceptions, and uncertainty for a bounded period. Here “coverage” means declared-population reconciliation, not insurance coverage.
Portfolio evidence
Receipt census + loss feed
The census emits governed aggregate buckets with coarse primary suppression. The signed loss feed preserves external provenance and correction lineage; its observations are not verified or adjudicated losses.
Action packet
Re-performable evidence join
A content-addressed packet joins the native artifacts for one exact action and calls the relying party's chosen native verifiers. Those callbacks are trust inputs and must independently validate each artifact. Complete, incomplete, conflicted, and indeterminate are technical packet results, not claim or coverage decisions.
THE CONTROL BOUNDARY

Terms, authority, exposure, outcome, and recourse stay separate.

The loss schedule records customer-supplied terms. Authorization still comes from the existing exact-action evidence and local policy. The Open Exposure Ledger reserves a declared amount before provider entry and preserves uncertainty without granting a retry. Reconciliation accepts authenticated outcome evidence; it does not decide legal loss or policy coverage.

The reference artifacts are open and reproducible: read the architecture contract.

A synthetic payment-release pilot shows the complete and hostile paths: inspect the runnable example.

THE PILOT

Start with one exact action and one declared exposure boundary.

For the protected operator
Select one fully mediated action, pin the Reliance Program and authorities, define declared exposure ceilings, and test refusals, uncertainty, reconciliation, and bounded-period evidence before production use.
For the carrier or assurer
Re-perform the supplied artifacts under independently pinned inputs and decide what, if anything, they support for underwriting, control testing, or claims review. EMILIA supplies technical evidence; the relying party keeps the conclusion.
Start a conversation
FREQUENTLY ASKED
Does EMILIA provide insurance or decide coverage?

No. EMILIA is technical enforcement and evidence infrastructure. It does not insure, decide policy coverage, allocate or bear loss, establish liability, adjudicate a claim, or move money.

What does an exact-action refusal prove?

It proves that the signed technical statement binds the named action, program, failed requirements, challenge, nonce, custody, and time under the pinned verification inputs. It is not a legal denial, an adverse-benefit denial, or proof that a refusal was substantively correct.

Does the coverage attestation prove the population was complete?

No. It signs the supplied inventory roots and conserving counts for a bounded period. Completeness needs separate system-of-record evidence. The receipt census also uses only coarse primary suppression, not differential privacy.

Can a carrier independently verify the packet?

A carrier can run the public schedule and packet code with its own trust pins and native artifact verifiers. The packet module orchestrates those verifiers; it does not ship production adapters or make a callback trustworthy. The current implementation is JavaScript, and no insurer adoption or external deployment is claimed.

EMILIA does not insure, bear or allocate loss, adjudicate disputes or losses, establish legal enforceability, prove insurance coverage, causation, solvency, or source-population completeness, or move money. Refusal statements are exact technical evidence, not legal or adverse-benefit denials. No external deployment or insurer adoption is claimed.