Inside an Autonomous Supply-Chain Transaction: State, Evidence, Policy and Memory

An autonomous supply-chain transaction needs more than a workflow.

It needs memory.

It needs to know what the business originally intended, what each party committed to, what actually happened, which evidence proves the current state, which policies govern the next action, who has authority to approve a deviation, what recovery actions were attempted, and what conditions must be true before the transaction can close.

That is the real difference between task automation and autonomous execution.

A traditional workflow can move a process from one step to another.

An autonomous transaction has to preserve enough context to survive system boundaries, enterprise boundaries, communication-channel changes, operational exceptions, policy decisions and financial consequences.

Without that persistent state, AI agents may automate individual tasks while people still reconstruct the transaction between them.

That is why Settyl treats the transaction - not the application - as the durable unit of autonomy.

A System of Execution should not simply trigger actions. It should maintain the governed transaction state required to carry work from business intent to verified outcome.

This article explains what that state actually needs to contain.

A Transaction Status Is Not the Same as Transaction State

Most enterprise applications represent work using statuses such as Open, Approved, Confirmed, In Transit, Delivered or Closed.

These statuses are useful. But they do not contain enough information to support autonomous execution.

Consider the status Delayed.

What does that actually mean?

The system may still need to know what was expected, what changed, when the change was detected, why it happened, what downstream commitments are affected, which recovery options are available, which policy applies, who can approve the recovery and when the issue can be considered resolved.

A status tells you where the transaction appears to be.

State tells you what the system knows about the transaction and what it is allowed to do next.

That distinction is critical.

An autonomous transaction needs a persistent state model that combines business context, commitments, evidence, policies, actions and outcomes.

1. Intent State: Why Does This Transaction Exist?

Every autonomous transaction should begin with an explicit business objective.

Not simply: Create PO.

But: Secure 10,000 units of Material X at Plant A by October 20 to protect production requirement Y.

That business objective matters because later execution decisions depend on it.

Suppose a supplier proposes delivery on October 24 instead.

Whether that change is acceptable cannot be determined from the purchase order alone.

The transaction may need to know current inventory coverage, production requirement, customer commitment, criticality, alternate supply options and approval thresholds.

The intent state therefore provides the reason behind the transaction.

Intent state should include

• originating demand or requirement;
• material or service identity;
• quantity;
• required date;
• destination;
• source planning reference;
• business priority;
• budget or commercial constraints;
• applicable policy;
• completion objective.

This allows execution to remain connected to the business outcome rather than becoming a sequence of disconnected operational tasks.

When that context disappears between planning, procurement, logistics and finance, Operational Fragmentation begins.

2. Identity State: What Objects Belong to the Same Transaction?

A supply-chain transaction rarely has one identifier.

It may involve a planning requirement, requisition, RFQ, quotation, purchase order, PO line, supplier, material, plant, shipment, carrier, forwarder, customs entry, receipt, invoice and payment reference.

Different applications see different parts of that identity.

An autonomous execution layer has to know how they relate.

For example:

Demand Requirement DR-1024 → Purchase Requisition PR-881 → PO 4500123456 / Line 20 → Supplier ABC → Shipment SH-7782 → Carrier Booking BK-391 → Goods Receipt GR-5521 → Invoice INV-9931

These should not be treated as unrelated records.

They are different representations of the same underlying business transaction.

This is where the transaction becomes a persistent execution object rather than a collection of application records.

A Multi-Enterprise Execution model must preserve that identity even when the transaction crosses companies and systems.

3. Commitment State: What Was Requested, and What Was Actually Promised?

One of the most important parts of transaction state is the commitment model.

A transaction should distinguish between requested state, proposed state, accepted state, revised state and superseded state.

Consider a supplier response.

Original request:

• Quantity: 10,000
• Promise date: October 20
• Price: ₹120/unit

Supplier response:

• Quantity: 8,000
• Promise date: October 20
• Remaining: 2,000 on October 24
• Price: ₹122/unit

A simple workflow might update the PO.

A transaction-state model should retain both the previous and new states.

Requested

What the buyer asked for.

Proposed

What the supplier offered.

Accepted

What the enterprise approved.

Revised

What changed later.

Superseded

Which prior commitment is no longer valid.

This matters because later logistics and finance decisions depend on the actual commitment history.

A freight planner should not operate against an obsolete quantity.

Finance should not compare an invoice against a superseded commercial state.

The transaction state must therefore preserve the evolution of commitments, not only the latest value.

4. Evidence State: How Does the System Know the Current State Is True?

Autonomous execution cannot rely only on inferred status.

It needs evidence.

Evidence is what allows the system to verify whether a state transition actually occurred.

Examples include supplier acknowledgment, quotation, PO confirmation, carrier acceptance, booking confirmation, packing list, invoice, bill of lading, customs release, proof of delivery, goods receipt, approval record, email response, EDI message, API confirmation, timestamped milestone or scanned document.

A transaction should therefore distinguish:

State claim from state evidence.

For example:

Claim: Supplier committed to October 20.

Evidence: Supplier confirmation email received at 14:32 containing promise date October 20.

Claim: Shipment delivered.

Evidence: POD signed, delivery timestamp captured, receipt quantity verified.

This creates explainability.

The system can answer: Why do we believe this transaction is in this state?

That is important for autonomous execution, auditability and governance.

5. Policy State: What Is the System Allowed to Do?

AI should not simply act because it can.

It should act because the transaction state says the action is permitted.

This is where policy becomes part of the transaction.

Examples include price-deviation tolerance, quantity tolerance, delivery-date tolerance, preferred-supplier rules, freight-cost thresholds, approval limits, alternate-source policy, expedite policy, customs compliance rules, invoice-variance tolerance and credit controls.

Suppose the supplier increases price by 1%.

Policy may allow automatic acceptance.

A 12% increase may require procurement approval.

A 25% increase may require management escalation.

The transaction should therefore know which policy applies, what thresholds are relevant, what action is permitted and what action is prohibited.

This is what turns automation into governed execution.

Without policy state, the system may generate intelligent recommendations but cannot safely own the next action.

6. Authority State: Who Can Approve the Next Move?

Policy and authority are related but not identical.

Policy defines the rule.

Authority defines who can approve an exception to that rule.

For example:

• a buyer can approve up to 2% price variance;
• a procurement manager can approve up to 5%;
• finance director approval is required above ₹1 million;
• logistics head approval is required for air-freight expedites;
• quality approval is required before accepting damaged material.

The transaction should know which decision requires approval, which role has authority, whether approval has been requested, whether it was approved or rejected and which evidence supports the decision.

This prevents execution from disappearing into email or informal messaging.

The approval becomes part of the transaction state.

7. Action State: What Has Already Been Tried?

Autonomous execution must remember what happened before.

Otherwise agents can repeat the same failed action.

Consider a delayed supplier.

The system may have already:

1. sent a reminder;
2. requested revised commitment;
3. proposed partial delivery;
4. checked an alternate supplier;
5. requested expedite approval.

If a new agent enters the transaction without this history, it may repeat step one.

That is inefficient and potentially damaging.

The transaction should preserve the action attempted, timestamp, actor, channel, input context, response, outcome and next permitted action.

This creates a true execution history.

It also allows the system to reason about progress.

The question becomes:

What should happen next, given what has already been attempted?

That is fundamentally different from asking what action normally follows a status.

8. Communication State: Messages Must Become Business State

Supply-chain execution often happens through unstructured communication.

Examples include email, WhatsApp, phone calls, portal messages, PDF documents and spreadsheets.

The challenge is that communication is not the same as state.

A supplier may write:

“Material will be ready next Monday.”

That message should not remain merely an email.

The execution layer should interpret it as:

• supplier readiness date changed;
• old date: October 18;
• new date: October 21;
• source: supplier email dated October 16, 11:42 AM;
• confidence: verified;
• downstream impact: pickup must be replanned.

The transaction now contains structured operational meaning.

That is essential for Multi-Enterprise Execution, because external participants do not need to adopt one shared portal for the transaction state to remain coherent.

Communication channels can vary.

The transaction state should not.

9. Exception State: What Is Preventing Completion?

An autonomous transaction should not treat exceptions as separate workflows.

The exception belongs inside the transaction.

A useful exception state model is:

Expected State → Observed Deviation → Impact → Decision → Recovery Action → Verified Recovery

For example:

• Expected: Supplier ships October 20.
• Observed deviation: Supplier confirms October 24.
• Impact: Production shortage risk begins October 22.
• Decision: Approve split shipment.
• Recovery action: Move 5,000 units by expedited freight.
• Verified recovery: Production coverage restored.

This is much richer than Status: DELAYED.

The transaction state tells the system what changed, what the consequence is, what decision was made and whether recovery succeeded.

This is why exception handling is one of the strongest tests of Autonomous Supply Chain Execution.

10. Financial Consequence State: Execution Changes Economics

Operational decisions often create financial consequences.

Examples include expedite cost, detention, demurrage, premium freight, quantity variance, damage claim, short shipment, price amendment, tax change, invoice tolerance or penalty exposure.

These consequences should not appear for the first time when Finance receives the invoice.

They should become part of transaction state when they are created.

For example:

Supplier delay → air freight approved → incremental freight cost ₹185,000 → approval recorded → Finance expectation updated

When the invoice later arrives, Finance already knows why the cost exists.

This is far more efficient than asking Operations to reconstruct the transaction weeks later.

It is also why Autonomous Finance Operations should operate from execution evidence, not only from invoice records.

11. Completion State: What Must Be True Before This Transaction Can Close?

This is one of the most important parts of the architecture.

Every autonomous transaction should have an explicit completion contract.

A completion contract defines the conditions that must be true before the transaction can close.

Procurement completion contract

• supplier commitment verified;
• commercial deviations approved;
• final quantity confirmed;
• promise date confirmed.

Physical execution completion contract

• goods dispatched;
• delivery completed;
• received quantity verified;
• delivery evidence present;
• unresolved logistics exceptions = 0.

Financial completion contract

• invoice reconciled;
• approved deviations supported;
• required approvals complete;
• ERP posting successful.

Transaction completion contract

• business intent satisfied;
• supplier commitment fulfilled or governed alternative accepted;
• physical execution verified;
• financial closure verified;
• authoritative write-back completed.

This prevents premature completion.

The transaction does not close because one system says Done.

It closes because the required business conditions are proven true.

12. From Transaction History to Operational Memory

A completed transaction should not disappear.

Its execution history can become a reusable asset.

The system has learned what happened, what changed, what decision was made, which policy applied, what action was taken, which partner responded and whether the outcome succeeded.

That history can become Operational Memory.

The pattern is:

State → Decision → Action → Evidence → Outcome → Memory

This is more valuable than simply storing logs.

Logs tell you that something happened.

Operational Memory preserves why it happened and whether the response worked.

Over time, this allows future transactions to improve.

For example, the enterprise can learn which supplier recovery actions work most often, which carriers consistently miss placement, which invoice exceptions recur, which approval paths create delays, which freight modes recover service at acceptable cost and which policy thresholds repeatedly trigger escalation.

The transaction becomes the source of learning.

The Transaction Is the Persistent Execution Object

The architecture can now be summarized more clearly.

A supply-chain transaction should not be modeled as a single status.

It should be a persistent execution object containing:

• intent;
• identity;
• commitments;
• evidence;
• policy;
• authority;
• actions;
• communications;
• exceptions;
• financial consequences;
• completion criteria;
• memory.

AI agents can operate within that object.

ERP can remain the System of Record.

External partners can continue using their existing channels.

The System of Execution owns continuity across all of them.

That is how execution becomes autonomous without creating another isolated application.

Agents Perform Work. The Transaction Carries Context.

The supply chain does not need another collection of disconnected AI agents.

It needs agents working within one persistent transaction state.

A procurement agent may act on supplier commitment.

A logistics agent may act on physical execution.

A finance agent may act on financial closure.

But each should see the relevant history of the same transaction.

That shared context prevents the human from becoming the integration layer between intelligent systems.

This is the architectural shift:

From task automation to transaction autonomy.

And that shift depends less on how many agents an enterprise deploys and more on whether the transaction can remember enough to continue safely.

One Transaction. One State. One Verified Outcome.

Autonomous supply-chain execution is not created by connecting more workflows.

It emerges when the transaction itself becomes durable.

The transaction remembers why it exists, what was promised, what happened, what evidence proves it, what policy applies, who has authority, what has already been tried, what exception is active, what financial consequence was created and what conditions must be satisfied before closure.

That state allows execution to survive across applications, enterprises and exceptions.

ERP remains authoritative.

Agents perform specialized work.

Partners continue using the channels that fit them.

The transaction carries continuity.

And the System of Execution remains responsible until the business outcome is verified.

That is the architecture behind autonomous supply-chain execution.

That is what turns transaction history into operational memory.

And that is what makes autonomy durable.