Decision logs answer only the first half of the question
Authorization evidence says an action was permitted or rejected under a policy. It does not prove whether execution was attempted, which destination processed it, whether the operation was partial or rolled back, or what non-sensitive transaction reference was produced.
AgenticDome uses a versioned outcome-receipt contract tied to the same tenant, action and chain. It can compare authorised and observed action digests, bind the destination and side-effect reference, and reject replay of the same receipt identifier with different claims.
Assurance is explicit. An SDK-reported result, a receipt signed by an assigned AgenticDome runtime and an optional destination-attested result are different evidence classes. The portal does not silently present one as another.
What changes when AgenticDome is in the path
Record a bounded outcome class, assurance level, tenant, chain, action, unique receipt identifier, authorised/observed action digests, destination digest, non-sensitive side-effect-reference digest and timestamps. Gateway-observed assurance requires a signature from an assigned active runtime. Destination-attested assurance additionally requires a registered destination public key and allowed outcome scope.
Outcome evidence makes deviations visible
Structured outcome classes
Distinguish not attempted, rejected, accepted, succeeded, partially succeeded, failed, rolled back and unknown.
Authorised versus observed
A digest mismatch marks action deviation rather than allowing execution telemetry to overwrite the original intent.
Tiered assurance
Keep SDK-reported, gateway-observed and destination-attested evidence visibly separate.
Portable verification bundle
Export tenant-scoped public claims, hash links and verification instructions without source, prompts, raw arguments or secrets.
Destination attestation is optional and integration-specific
Many destinations cannot sign a business outcome. In those cases, gateway-observed evidence remains useful but should not be described as destination confirmation. Where a destination can sign, its private key stays at the destination and AgenticDome stores only the approved public verification key.
How AgenticDome creates the control point
1. Preserve the authorised digest
Carry the original action and destination bindings from the Action Passport into the chain evidence.
2. Observe the execution attempt
Record whether the supported gateway or executor attempted, rejected or could not perform the action.
3. Classify the outcome
Use one bounded class and a non-sensitive side-effect reference rather than retaining a raw destination response.
4. Verify the issuer
Require runtime signatures for gateway assurance and a registered adapter key for destination attestation.
5. Export machine evidence
Validate event hash links, receipt-claim digests and any destination signature using the bundle instructions.
What this changes for real teams
Separate approval from settlement
“The refund was allowed, but did the payment destination accept it?”
AgenticDome contribution: The chain records authorization separately from gateway-observed or destination-attested completion and a digested transaction reference.
Detect execution deviation
“We need to know if the sent action differed from the approved action.”
AgenticDome contribution: Authorised and observed digests remain distinct and a mismatch is surfaced as deviation evidence.
Verify without raw secrets
“We need portable evidence without exporting customer prompts or credentials.”
AgenticDome contribution: The machine bundle contains bounded public claims, digests, signatures where available and deterministic verification instructions.
The risks this helps contain
| Risk | Why it matters | Public AgenticDome control |
|---|---|---|
| Allowed but never attempted | A policy allow can be mistaken for successful business execution. | Record attempted and completed states separately and permit not_attempted or unknown outcomes. |
| Partial completion hidden as success | Distributed business operations can commit some effects and fail others. | Use partially_succeeded or rolled_back where the trusted issuer can substantiate those states. |
| Receipt replay or mutation | Reusing an identifier with different claims undermines audit integrity. | Digest the unique receipt identifier and reject duplicate identifiers carrying different canonical claims. |
| False destination assurance | A gateway cannot prove internal destination state merely because it observed an HTTP response. | Label gateway evidence accurately and require an authorised destination signature before using destination_attested. |
A practical path to production
Define outcome semantics
Agree which component can substantiate success, partial completion, rollback and unknown.
Assign assurance issuers
Document which SDK, runtime or destination key is authorised to assert each evidence level.
Minimise evidence
Store digests and non-sensitive references; keep raw business responses in their authoritative system.
Test verification
Exercise duplicate receipt IDs, altered claims, wrong keys, expired adapters and action deviations.
Where this control ends
An outcome receipt is evidence from its stated issuer, not a universal proof of physical or business reality. Gateway observation does not replace destination reconciliation, financial controls, database transactions, idempotency, rollback, backups or authoritative system-of-record logs. Destination attestation is available only where an approved integration can sign the relevant outcome.
Current lifecycle note
Verification keys, allowed outcome scopes and adapter status require controlled lifecycle management. Exported bundles preserve original assurance labels and must not be re-labelled after the fact.