Guides
Carry Intent
Model what each machine is authorised to do as an ECZ-ID Intent, keep it narrow, and make every consequential request able to name the Intent it acts under.
Intents are created, authorised and revoked by the account holder in the TrustOps Dashboard. There is no public developer API for Intents; nothing on this page calls one.
ECZ-ID Intent today · measured 2026-10-10
- Commercial capability
- Available through TrustOpsPlans are sold in TrustOps.
- Signed-in operation
- LiveCreated and authorised by the account holder, signed in, in the TrustOps Dashboard.
- Public developer interface
- NoneThere is no public developer API. Public Intent disclosure is defined in Core and not enabled.
Accountability Chain:AuthorityDelegationIntent
1. Model the Intent before the integration
Start from the consequence, not the capability. For each machine that will change money, access, rights, resources, state, custody, commitments, infrastructure or liability, write down the objective in one sentence, then the bounds that make an action inside it legitimate.
| Decide | Express it as |
|---|---|
| Which machine acts | The actor’s child ECZ-ID |
| On what | Targets, resources and destinations, each with permitted and excluded patterns |
| Doing what | Action patterns such as invoice:pay or tool:create_refund |
| How much | Currency, a maximum per action and a maximum in total |
| How often | A rate: maximum actions per window |
| What must never pass | Excluded patterns and denied data classes |
| When a human decides | Actions that need approval, and an amount above which approval is required |
| For how long | A window with a start and an expiry |
2. Keep it narrow
- Prefer one Intent per objective over one Intent per machine. A narrow Intent is easier to authorise, read and revoke.
- Patterns are globs whose only wildcard is
*. Excluded always wins over permitted. - Give every Intent an expiry. An open-ended authorisation is a standing risk.
- Delegate only what a sub-agent needs. A delegated Intent can only narrow its parent, and every ancestor’s budget is charged.
3. Carry the reference with the action
An Intent is a standing authorisation. A proposed action is a single event. What travels with the action is the Intent’s reference: its identifier and version, { "intent_id": "INT-…", "version": 3 }. Request-scoped values belong to the request, not the Intent:
| Value | Where it belongs |
|---|---|
| Intent reference | With every consequential request, and in your own audit log next to the action |
| Request identifier (idempotency, replay) | The request. In IntentControl it is request_id: one request, never reused for a different one |
| Nonce | Your transport or signing layer |
| Correlation ID | Your tracing and workflow system |
| Parent workflow | Your orchestrator; for authority, the Intent’s parent_intent |
Related
This page is explanation, not authority. Current state is only ever the live Resolver record. Live facts on this page were measured read-only on 2026-10-10.