The Action Was Authorised. But Did It Actually Happen?

Publication discovery profile

Primary audience: AI-native enterprise architects; agent/runtime engineers; AI governance and assurance practitioners. Secondary audience: CTOs, CIOs, Heads of AI, technical risk leaders, distributed-systems practitioners, researchers and builders working on durable agents, autonomous organisations and machine governance.

Problem addressed: How an organisation can distinguish between an AI or machine worker being authorised to act, an action being attempted, and the intended external effect actually occurring and reaching finality.

Questions answered:

• How do you know an AI agent action actually happened?
• What should happen when an external action may have succeeded but the response is lost?
• Why is a permit, acknowledgement, duplicate-suppression result or workflow-complete flag not necessarily effect proof?
• Where do idempotency and exactly-once guarantees stop?
• When should an autonomous system reconcile before retrying?
• Why does compensation not erase historical consequence?

Reader value: A practical mental model and research architecture for reasoning about external side effects, uncertain outcomes, retries, authoritative observation, finality and compensation in autonomous enterprise systems.

Primary subject areas: AI-native enterprise architecture; autonomous agents; distributed systems; AI governance; assurance; durable execution; enterprise integration; institutional knowledge integrity.

Key concepts: effect reconciliation; semantic effect identity; AI agent side effects; unknown outcomes; idempotency; retry safety; exactly-once assurance boundaries; authoritative observation; effect finality; compensating actions; autonomous-system accountability.

Research contribution: A governed institutional composition of established distributed-systems concerns into an AI-native effect-reconciliation architecture and executable research contract. Component novelty is not claimed.

Evidence level: Literature/standards-supported design synthesis + machine-readable contract + represented-case executable conformance. Not production validated and not independently replicated.

Important non-claims: This work does not prove universal correctness, exactly-once external effects, production end-to-end reliability, independent replication, causal attribution to wider organisational outcomes, or universal novelty.

Discovery intent: Problem discovery; technical solution research; governance and assurance research; executive decision support; academic and prior-art discovery.

Representative search / retrieval language: AI agent retries after timeout; how to verify an AI agent action actually happened; autonomous agent side effects; exactly-once external effects; AI governance action verification; idempotency for AI agents; effect reconciliation; compensating actions in autonomous systems.

Executive abstract

Autonomous systems increasingly move beyond recommendation into consequential action: changing records, issuing communications, initiating payments, creating commitments, or invoking physical and digital processes. In that setting, a valid authorisation and a successful-looking workflow are not enough to establish what happened in the world.

Silver Digital's Enterprise Knowledge Office research separates seven states that are often collapsed: authorised intent, delivery, processing, effect occurrence, effect observation, effect finality, and compensation. The distinction matters most when communication fails at precisely the wrong moment: after an external system may have applied an effect but before the caller receives reliable confirmation. Treating that situation as ordinary failure can create duplicates; treating it as success can create false institutional knowledge.

The proposed Effect Reconciliation model therefore uses stable semantic effect identity, operation-specific retry rules, separately recorded attempts, authoritative observations, target-defined finality, explicit unknown outcomes, and independently authorised compensation. These components draw on established distributed-systems ideas including idempotency, transactional boundaries, retry semantics, durable execution, exactly-once processing within bounded domains, and compensating transactions. Silver's contribution here is not a claim to have invented those concepts. It is a governed institutional composition intended for AI-native organisational machinery.

The current executable evaluation is deliberately bounded. Fourteen represented cases produced fourteen expected outcomes in the current conformance evaluation. This demonstrates that the reference evaluator distinguishes the represented success, failure and indeterminate conditions as designed. It does not establish production end-to-end correctness, universal exactly-once effects, or independent replication.

When "success" stops being a sufficient word

Consider a machine worker authorised to make a consequential change in an external system.

The authority layer returns a permit. The runtime dispatches the request. The network accepts it. The target may process it. A local workflow then marks the step complete.

What, exactly, has been established?

Potentially, only that the action was permitted and an attempt was made.

That distinction becomes operationally important as autonomous systems acquire the ability to create external consequences without a human checking every step. A system that confuses permission with occurrence, acknowledgement with finality, or retry suppression with success can become internally confident while being wrong about the external world.

Silver's research expresses the boundary as:

AUTHORISED INTENT
!= DELIVERY
!= PROCESSING
!= EFFECT OCCURRENCE
!= EFFECT OBSERVATION
!= EFFECT FINALITY
!= COMPENSATION

This is not a claim that every system requires seven user-visible workflow states. It is a claim about what must not be silently treated as equivalent when consequences and uncertainty matter.

The action-to-effect gap

Many conventional success signals answer narrower questions than the institutional question an autonomous organisation actually needs answered.

An authorisation answers: was this action permitted under the relevant authority state?

A dispatch record answers: was an attempt made?

A transport acknowledgement answers something about communication with an endpoint.

A processing record can show that a component accepted or executed work within its own boundary.

An observation answers: what does a particular source report about the external effect?

Finality asks a further question: has the relevant domain reached the state that its adopted rules treat as final, reversible, irreversible, settled, delivered, published, or otherwise complete?

These distinctions are familiar in parts of distributed systems and transaction processing. The institutional problem is composing them so that an AI-native organisation does not manufacture knowledge as actions cross heterogeneous assurance boundaries.

HTTP provides a useful example of why scope matters. RFC 9110 defines an idempotent method in terms of the intended server effect of repeated identical requests. It also explicitly allows other per-request side effects and permits retry of idempotent methods after communication failure. HTTP idempotency is therefore valuable retry semantics, but it is not universal proof that an arbitrary business effect occurred exactly once or reached domain finality. [1]

AWS Durable Execution documentation makes a related boundary explicit. Its at-least-once and at-most-once behaviours are described per retry attempt, and the documentation states that neither by itself guarantees a step runs exactly once across the entire workflow. [2]

The engineering lesson is not that exactly-once semantics are impossible. It is that an exactly-once claim is meaningful only inside the boundary for which the mechanism actually provides that assurance.

The Effect Reconciliation model

Silver's research architecture gives a consequential effect a stable semantic identity rather than treating transport identifiers, trace identifiers, attempt identifiers or broker offsets as substitutes for the effect itself.

The current contract separates six machine-readable control objects:

• EffectIdentity binds the intended effect to the action intent, authority decision, operation profile, target and semantic effect key.
• EffectOperationProfile defines retry semantics, authoritative observation sources, finality source, unknown-outcome policy, deduplication horizon, attempt bounds and compensation profile.
• EnforcementAttempt records a concrete attempt to realise the effect. In the schema, an attempt is structurally prevented from claiming that the effect has been proven.
• EffectObservation records what a named observer reports, together with source state, time, assurance class, effect state and finality.
• ReconciliationAssessment combines observations under an adopted profile and records the resulting effect state, finality, retry disposition, unresolved conflicts and lineage.
• CompensationLink represents compensation as a separately authorised consequential effect linked to, but not erasing, the original history.

This composition creates a boundary between doing and knowing what happened. That boundary is particularly important for an institutional knowledge system, because downstream planning, accountability and learning should not be based on an effect that has merely been assumed.

Unknown is a legitimate outcome

One of the most consequential failure modes occurs when a request may have crossed the external boundary but the response is lost.

Suppose a target applies an action and the connection then fails before confirmation reaches the caller. From the caller's perspective, both of these worlds are plausible:

• the effect happened and the response was lost;
• the effect did not happen.

Declaring failure is therefore not conservative. It is an unsupported assertion. If the system retries as though nothing happened, it may create a duplicate external effect.

The Effect Reconciliation contract preserves this condition as `UNKNOWN_OUTCOME` or `RECONCILIATION_REQUIRED` until sufficient evidence resolves it. In the current schema, an unresolved unknown outcome cannot directly become ordinary `RETRY_PERMITTED`; the operation profile must instead drive reconciliation, reauthorisation, escalation, or an explicitly accepted bounded duplicate risk.

This is a form of epistemic discipline: uncertainty remains represented as uncertainty rather than being converted into a convenient workflow state.

Retry safety belongs to the effect, not one layer

Retries are often implemented independently by runtimes, gateways, brokers, workflow engines and workers. Each layer can look reasonable in isolation while the composition creates far more attempts than the organisation intended.

Silver's model therefore treats the maximum attempt count as an end-to-end operation bound. Retry layers contribute to the same budget rather than each receiving an independent allowance.

The model also distinguishes several operation profiles. Some effects may be safely retried under a stable effect identity. Some require reconciliation before retry. Some may tolerate a bounded duplicate risk. Others should prohibit automatic retry. A compensatable sequence has still different semantics.

The key point is that retry safety cannot be inferred generically from a timeout, HTTP method, queue behaviour or workflow flag. It depends on the semantics of the effect, the target's controls, the persistence horizon of deduplication state, and the evidence available after uncertainty.

An idempotency key is therefore a control, not a magic word. Reusing a key while changing the target, parameters, authority binding or semantic operation changes the consequential meaning. Silver's contract treats such mutation as a binding failure rather than the same effect.

Similarly, duplicate suppression proves that a duplicate was suppressed. It does not, by itself, prove that the original attempt reached the intended final state.

Exactly-once guarantees have boundaries

Exactly-once processing is established prior art within suitably integrated transactional domains. Kafka's processing-guarantee literature is an important example of the long-running engineering effort to control duplicates and loss within stream-processing pipelines. [3]

The mistake would be to take a guarantee established for one transaction domain and extend it automatically to an external side effect that the domain does not transactionally control.

For AI-native organisational machinery, this matters because a single autonomous workflow may cross several systems: an internal runtime, a broker, a CRM, a payment provider, an email service, a registry, or a physical-world interface. The assurance boundary changes as the action crosses those systems.

Silver's narrower architectural proposition is therefore:

stable semantic effect identity + bounded duplicate prevention + authoritative observation + explicit uncertainty + governed reconciliation.

That proposition does not replace strong transactional guarantees where they exist. It provides a way to reason about the places where those guarantees stop.

Finality is a domain fact

Effect occurrence and effect finality are also different.

An API can accept a request while the underlying business process remains pending. A payment can be initiated before settlement. A publication can be accepted before it becomes externally visible. A communication can be queued before delivery. A legal or operational action can pass through states whose finality is defined outside the initiating runtime.

The current Effect Reconciliation schema therefore requires the operation profile to name a finality source. Transport inference is not permitted as final proof.

This is intentionally domain-relative. Silver's research does not establish one universal finality rule. The authoritative source and the meaning of finality must be adopted for the operation in question.

Compensation does not make history disappear

Distributed systems have long used compensating actions and saga-style patterns when a single atomic transaction cannot span all participants. Effect reconciliation retains that family resemblance while making an institutional point explicit: compensation is another consequential effect.

If an original effect occurred, a later compensating effect does not make the original event cease to have happened.

This matters whenever consequences escape reversible state. A database value may be changed back, while an email has already been read. A disclosure may already have occurred. A physical action may have taken place. An external commitment may leave a residual consequence.

The current contract therefore gives compensation its own effect identity and authority decision, preserves the original effect in history, and allows an expected residual state to be represented. This prevents a technically convenient rollback narrative from becoming false institutional history.

What Silver actually tested

The current research includes a machine-readable schema, adversarial fixtures, a reference evaluator, and an executable represented-case suite.

The evaluator checks, among other things:

• operation-profile and version binding;
• current authority state;
• immutable effect binding;
• total and cross-layer retry budgets;
• deduplication horizon evidence where idempotency is claimed;
• authoritative observation and finality sources;
• unknown-outcome retry policy;
• unresolved observation conflicts;
• attempts to extend broker exactly-once claims beyond their boundary;
• attempts to treat duplicate suppression as success proof;
• compensation identity and authority;
• irreversible residual consequences; and
• uncertainty during recovery and replay.

The executable fixture set contains fourteen represented cases. They include a valid authoritative final effect, transport-success laundering, missing authoritative evidence, mutation under one effect identity, retry-budget overflow, retry before reconciliation, exactly-once boundary laundering, duplicate-suppression laundering, unresolved observer conflict, valid compensation, compensation history rewrite, irreversible residual laundering, recovery absence laundering, and operation-profile version skew.

Results

The recorded Wave 158 execution produced:

14 represented cases / 0 expectation failures.

Equivalently, fourteen represented cases produced fourteen expected outcomes in the current executable conformance evaluation.

That is evidence that the reference evaluator classified these represented cases according to the contract's expected outcomes. Some cases are intentionally expected to fail, and some are intentionally expected to remain indeterminate. The result is therefore not "fourteen successful real-world operations."

It is also not production validation, proof of universal correctness, independent replication, or proof that the architecture guarantees exactly-once external effects.

Prior art and what Silver is adding

The underlying engineering landscape is not empty. The architecture draws on established concepts including:

• HTTP idempotency and retry semantics;
• transactional boundaries;
• at-most-once and at-least-once execution semantics;
• exactly-once processing within bounded systems;
• durable execution and replay;
• idempotency tokens;
• compensating transactions and saga patterns;
• authoritative state observation; and
• distributed-systems failure semantics.

The IETF HTTPAPI working group's Idempotency-Key Internet-Draft is also relevant prior art for fault-tolerant use of non-idempotent HTTP methods. As of 2 October 2026, the Datatracker marks revision 07 expired and archived; it should therefore be treated as informative prior art rather than a final RFC. [4]

Silver does not claim to have invented these component ideas.

The defensible contribution in the present research is their explicit composition into an AI-native institutional effect-reconciliation architecture: a governed boundary that keeps authority, attempt, observation, finality, retry disposition and compensation separately representable, and that makes uncertainty difficult to launder into institutional knowledge.

Whether that composition is novel in a patent or academic sense has not been established by this work.

What the evidence supports

The present evidence supports a bounded set of conclusions.

First, authorisation is not effect proof. A valid permit establishes authority to attempt an action, not that the action occurred.

Second, dispatch, acknowledgement and local workflow completion are not generally sufficient to establish target-defined finality.

Third, duplicate suppression is not equivalent to proof of original success.

Fourth, exactly-once or transactional guarantees should be stated within the assurance boundary actually covered by the mechanism.

Fifth, after possible dispatch, an unresolved outcome can be a legitimate state that should remain explicit until the operation's adopted reconciliation rules resolve it.

Sixth, separating semantic effect identity, attempts, observations, finality, retry disposition and compensation is technically representable in a machine-readable contract and executable reference evaluator.

Finally, the represented-case evaluation shows conformance for the cases encoded in the current suite.

What the evidence does not support

The work does not establish:

• production end-to-end effect correctness;
• universal correctness of the proposed architecture;
• a universal Silver policy for retries, finality, compensation or authoritative observation;
• exactly-once external institutional effects;
• impossibility of exactly-once semantics inside bounded transactional systems;
• independent replication;
• causal attribution from an action to wider organisational outcomes;
• acceptable performance or cost across heterogeneous production systems; or
• universal novelty of the decomposition or its component concepts.

These limits are part of the result, not footnotes to be removed later.

Architectural implications for AI-native organisations

As machine workers become able to cause external effects, organisations may need an explicit effect boundary between autonomous execution and institutional knowledge.

Such a boundary would change several architectural responsibilities.

Authority systems would establish whether an action may be attempted, without claiming the external effect occurred.

Execution systems would preserve semantic effect identity and attempt lineage rather than reducing execution to a binary task status.

Integration layers would expose retry, deduplication and transaction guarantees with their actual scope.

Observation mechanisms would identify which external sources are authoritative enough to support effect and finality claims.

Knowledge systems would preserve unknown and conflicting outcomes rather than learning from assumed completion.

Recovery systems would reconstruct unresolved effect identities and reconcile them before replay where the operation profile requires it.

Assurance and accountability systems would retain the chain from authorised intent through attempts, observations, finality and any later compensation.

This is an architectural proposal, not a claim that every organisation requires a standalone "Effect Reconciliation service." In simple workflows, existing transaction and idempotency mechanisms may already cover the relevant risk. A separate reconciliation layer is justified only where it adds error-detection, recovery or accountability value across the actual external-effect boundary.

Limitations

The current work is research scaffolding and represented-case conformance.

Production transport across heterogeneous enterprise systems has not been validated. Canonical observation and finality sources are domain-specific. Durable effect and idempotency persistence, production adapters, runtime integration, invalidation propagation and CI remain unfinished research-to-production work in the source programme.

The current evaluator is contributory rather than independently implemented. Its fixtures were designed to exercise the contract, so fixture conformance cannot establish how the architecture behaves under unrepresented failure modes.

The work also does not solve causal consequence attribution. Confirming that an authorised action produced a particular target effect is different from proving that the action caused a broader organisational outcome.

Finally, the cost of authoritative reconciliation may itself be material. Some target systems expose strong operation identifiers and finality semantics, making reconciliation straightforward. Others may expose weak, delayed or expensive evidence. That variability is central to future validation.

Open research questions

Several questions remain before the architecture could support stronger claims.

How much additional error-detection and recovery value does explicit effect reconciliation provide over conventional transaction and idempotency controls in heterogeneous end-to-end systems?

What classes of enterprise operation can use stable effect identity safely without a separate reconciliation query?

How should authoritative observation sources be selected, governed and changed over time?

How should finality be represented when the target domain has probabilistic, delayed, revocable or multi-party settlement?

How should retry budgets compose when some infrastructure retries are invisible to the initiating runtime?

What evidence is sufficient to distinguish an effect from a correlated observation without overstating causal attribution?

How should organisations price the latency and operational cost of reconciliation against the consequence of duplicate or falsely assumed effects?

And which functions belong in a shared institutional effect boundary versus domain-specific adapters?

These questions are empirical and architectural. They should be answered by broader implementation and heterogeneous end-to-end testing rather than by expanding the claims of the present fixture suite.

Conclusion

The difficult question in autonomous execution is not always "was the action allowed?" It is often the question that comes next: "what do we actually know happened?"

For consequential machine action, permission, dispatch, processing, observed effect, finality and compensation are not interchangeable facts. The gap between them is where retries can duplicate consequences, workflow flags can become false knowledge, and infrastructure guarantees can be extended beyond the boundaries that justify them.

Effect reconciliation is Silver's current research architecture for keeping those distinctions explicit. Its core discipline is modest but demanding: preserve semantic effect identity, state uncertainty honestly, observe effects through appropriate sources, define finality in the target domain, constrain retries across layers, and preserve history when compensation occurs.

The current executable work shows that this discipline can be expressed as a machine-readable contract and evaluated against represented adversarial cases. Fourteen represented cases produced fourteen expected outcomes. That is a useful research result. It is not the end of the validation programme.

For AI-native organisations, that restraint may be as important as the mechanism itself. Autonomous systems need not only the ability to act. They need disciplined ways to know what their actions actually changed.

References

• R. Fielding, M. Nottingham, J. Reschke (eds.), RFC 9110: HTTP Semantics, §9.2.2 "Idempotent Methods", IETF, June 2022. https://www.rfc-editor.org/rfc/rfc9110.html#name-idempotent-methods
• Amazon Web Services, AWS Durable Execution SDK Developer Guide: Idempotency and retries, accessed 2 October 2026. https://docs.aws.amazon.com/durable-execution/patterns/best-practices/idempotency/
• Apache Kafka, Kafka Streams Core Concepts: Processing Guarantees, historical Kafka 2.0 documentation, accessed 2 October 2026. https://kafka.apache.org/20/streams/core-concepts/
• J. Jena and S. Dalal, The Idempotency-Key HTTP Header Field, draft-ietf-httpapi-idempotency-key-header-07, IETF HTTPAPI Working Group, revision dated 15 October 2025; expired and archived 18 April 2026. https://datatracker.ietf.org/doc/draft-ietf-httpapi-idempotency-key-header/