Trust boundaries

Luvion is useful only when authorization, signing, execution, and evidence do not collapse into one unrestricted administrator. The logical flow is:

Partner operator
      |
      v
Control plane -- policy, roles, request state
      |
      v
Authorization coordinator
      |
      +----> Signer domain A
      +----> Signer domain B
      +----> Signer domain C ... threshold quorum
      |
      v
Execution adapter ----> partner wallet, protocol, or chain
      |
      +----> Evidence witness
      +----> Operational alert receiver

The arrows describe allowed protocol messages, not shared root access.

Domain responsibilities

Domain	Holds or controls	A compromise can do	A compromise must not be able to do alone
Control plane	Policy versions, identities, approvals, request state	Submit invalid workflow data or disrupt availability	Produce a threshold certificate or execute around the adapter
Coordinator	Canonical signing package, attempt state, registry lifecycle	Select requests, interrupt rounds, or withhold completion	Forge signer shares or silently change an already-bound intent
Signer domain	One participant share and identity	Withhold or misuse that share	Reach threshold, rewrite policy, or execute alone
Execution adapter	Provider or chain integration and reconciliation	Submit an authorized operation, misreport availability	Accept a mismatched request, bypass certificate checks, or blind-retry uncertain execution
Evidence witness	Append-only signed receipt stream	Delay evidence finality	Authorize or execute an operation
Alert receiver	Operational notifications	Suppress or expose bounded health metadata	Receive keys, credentials, amounts, addresses, or raw internal errors

Current pilot topology

The controlled pilot proves protocol behavior and recovery properties, but some processes may share one host and one administrative failure domain. Filesystem keys or local sidecars are used in places where production should use HSM, KMS, TEE, or equivalent protected key services. A remote mTLS transport proves the wire boundary; it does not prove independently operated infrastructure when both endpoints remain under the same administrator.

Therefore, the pilot can demonstrate that the software rejects mismatched intents, stale epochs, invalid participants, rollback, and unsafe retries. It cannot demonstrate resistance to a single administrator controlling every host, key file, witness, and execution credential.

Target design-partner topology

A production candidate should have:

1. separately administered control-plane, signer, and witness infrastructure;
2. signer shares distributed across independent machines and failure domains;
3. protected key handles instead of exportable filesystem keys;
4. an execution endpoint that technically requires the Luvion certificate;
5. an independently retained evidence stream; and
6. alert delivery to a partner-owned on-call system.

The deployment review must record who administers each domain, where its keys live, which network paths are allowed, how rotation occurs, and how an emergency revocation is approved.

Mandatory fail-closed boundaries

• A request digest, policy version, key epoch, chain, target, parameters, and validity window cannot change after approval.
• Responses from signers, adapters, witnesses, and providers must bind to the exact request and configured identity.
• Uncertain execution is reconciled before retry. It is never resubmitted under a new idempotency key merely because a timeout occurred.
• Evidence-anchor or witness failure prevents a terminal result from being represented as fully anchored.
• Any direct owner, emergency key, legacy module, or provider credential that bypasses Luvion is explicitly documented as outside the protection boundary.

See Current implementation status for the evidence-backed maturity boundary and Failure recovery for operator response rules.