Skip to main content
The EMILIA product story

One consequential action. Five clear jobs.

EMILIA is not a shelf of unrelated mechanisms. It is one customer-owned path from discovering a consequence, to preventing an unauthorized crossing, to preserving a record other people can check.

Map my agentProtect one workflow
Illustrative workflow

A routine email asks to change a vendor bank account before the next payment.

The agent has a valid identity and working credentials. Neither fact establishes that this exact destination change is inside the customer's authority.

vendor.bank_account.update
Old destination •••• 1842 → new destination •••• 7719
  1. 01Authority BrainThe scan finds vendor.bank_account.update and proposes it for owner review before the next payment workflow is protected.
  2. 02EMILIA GateThe customer requires fresh controller approval for a new destination. Gate refuses the first attempt before the provider is entered and creates an exact-action challenge.
  3. 03EMILIA ApproverThe controller reviews the exact change and makes a fresh decision. If accepted, that response can accompany a new Gate attempt. The first refusal remains in the record.
  4. 04EMILIA ProtocolWeeks later, a reviewer checks the first refusal, the later human decision, and any admitted attempt as separate facts tied to the same bank-detail change.
  5. 05Assurance PlaneAn audit lead re-performs the supplied payee-change population and sees exactly which records passed, refused, diverged, or remained unresolved.
One system, five jobs

Each part says one thing it can stand behind.

01 / DiscoverAuthority Brain

Map declared action surfaces and blind spots so the customer can choose what needs authority.

Customer receivesA reviewed Authority Map and a proposed protection scaffold.
Without

The action is buried in a tool list. The owner has no usable map of the consequence or its blind spots.

With EMILIA

The owner can see the declared action, name the exact fields that matter, and decide whether it needs a protected boundary.

What it cannot claimAuthority Brain does not inspect every hidden path, decide policy, or block an action. Its scanner proposes. The customer decides.
02 / PreventEMILIA Gate

Enforce customer authority where a consequential action can still be stopped.

Customer receivesA named refusal, or a record that one protected attempt was allowed to enter the provider.
Without

Valid credentials and a plausible request can be enough to change the destination.

With EMILIA

The exact destination must fit the customer's mandate and evidence rule before the mediated provider path can be entered.

What it cannot claimThe prevention claim applies only to completely mediated protected paths. Admission is at most one provider attempt, not exactly-once physical execution.
03 / DecideEMILIA Approver

Capture fresh exact-action human authority when the customer's mandate or policy requires it.

Customer receivesA fresh decision tied to the exact change, which Gate can check and use once.
Without

A click or MFA event can be recorded without proving which exact bank-detail change the person saw.

With EMILIA

The enrolled credential, challenge, profile, and exact action are bound into one fresh decision ceremony.

What it cannot claimThe ceremony proves that a pinned enrolled key completed a response over the exact action data. It does not prove perception, comprehension, legal sufficiency, or honest pixels.
04 / VerifyEMILIA Protocol

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

Customer receivesA portable evidence packet and a repeatable result for one action.
Without

The reviewer receives a screenshot or a dashboard verdict from the same system whose behavior is in question.

With EMILIA

The reviewer can independently check that each artifact is valid, that the material fields match, and that the customer's evidence rule was satisfied.

What it cannot claimVerification does not create authority, prove execution, establish complete mediation, or make every native evidence source trustworthy.
05 / Re-performAssurance Plane

Provide implemented procedures for re-performance across a supplied deployment or population.

Customer receivesAn implemented procedure that can produce a versioned review record and reproducible technical workpaper when run on supplied inputs.
Without

The reviewer must trust a live dashboard and reconstruct the population by hand.

With EMILIA

The same supplied inputs can be rerun under pinned rules, with drift and uncertainty preserved instead of rounded into a pass.

What it cannot claimEMILIA supports the procedure. It does not issue an audit opinion, accredited certification, legal conclusion, or insurance decision.
Procedures and scoped help

When the customer needs a defined review, not another product.

Chapter five is an implemented procedure. A deployment or service engagement must be separately scoped. Trust Desk handles scoped evidence intake and one-off technical review. Neither turns EMILIA into the customer's auditor.

Explore the Assurance procedureSee implemented verification and re-performance procedures.Trust DeskPrepare scoped technical evidence for a customer-appointed reviewer.