nilsoft Discuss your AI workflow

The field behind the work

What makes a change legitimate?

A system can execute a command while the authority behind it, its actual effect, or the evidence of its result remains unresolved.

See the diagnostic

Execution is a step in the chain. It is not the whole chain.

Open the work / sample 01

One refund agent.
Three places to lose control.

Illustrative sample — synthetic data, not a customer result.

A customer refund is approved. The order changes before the agent executes. The payment API accepts the request, but the workflow never establishes the customer’s final refund state.

Refund agent / supplied sample traceRF-042 · AUD $120
  1. E01 / 09:41:00

    Approve

    A human approves a refund against order v18.

  2. E02 / 09:41:08

    State changes

    An operator changes the order to v19. No recheck is recorded.

  3. E03 / 09:41:12

    Request accepted

    202 Accepted. No idempotency reference accompanies the request.

  4. E04 / 09:41:15

    Outcome missing

    A retry is scheduled. No final provider observation or receipt is recorded.

Outcome: unknown

The supplied sample establishes an accepted request. It establishes neither a completed refund nor a duplicate.

The findings

Inspect the evidence, consequence and proposed correction.
01Approval became staleThe decision outlived its facts.
Sample evidence
E01 / Approval references order version 18. E02 / An operator changes the order to version 19 before the tool call. The supplied trace contains no precondition recheck.
Possible consequence
The agent may act on permission that no longer covers the current order. A valid earlier approval is not enough to establish that this action is still permitted.
Proposed correction
Bind approval to the relevant order state. Re-read and compare that state immediately before execution; route a mismatch back to the decision owner.
Verification condition
Change the order after approval. Execution must stop until the changed preconditions are resolved.
02Repeated execution lacks a reliable boundaryA retry could become a second refund.
Sample evidence
E03 / The request has no idempotency reference. E04 / A retry is scheduled while the first refund outcome remains unknown.
Possible consequence
The workflow cannot establish that another attempt represents the same intended refund. An unintended duplicate is possible; this sample does not establish that one occurred.
Proposed correction
Assign one stable idempotency reference to the intended refund and reuse it across retries. Reconcile an uncertain attempt before initiating a new one.
Verification condition
Repeat the same refund intent through the supported retry path. Confirm it cannot create an additional refund.
03Accepted request is treated as completed workThe response is not the result.
Sample evidence
E03 / The payment API returns 202 Accepted. E04 / The trace records no provider status check or linked completion receipt.
Possible consequence
The team cannot establish whether the customer was refunded. Marking the task complete would conceal an unknown outcome.
Proposed correction
Observe the provider’s final refund state. Connect that observation and its receipt to the original request, approval and attempted action.
Verification condition
Exercise pending, failed and completed provider responses. Only an evidenced completed refund may be presented as complete.

Proposed design / not an observed result

Make the next attempt accountable.

  1. Revalidate the approved state
  2. Execute one bounded refund intent
  3. Observe the final provider state
  4. Link the evidence to the decision

These controls have not been implemented or tested in this illustrative case. The diagnostic defines what to change and how to check it; implementation is a separate engagement.

Definition

Governed Computation.

Governed Computation is the theory and practice of legitimate state transition.

Nilsoft uses it to make consequential operations inspectable: what state existed, what governed a decision, what action was permitted, what was attempted, what changed, and what evidence supports that account.

When authority is unresolved, stopping can be the correct outcome. When the effect has not been observed, the result is unknown. Neither state should be made to look complete.

The transition model

Seven questions, kept distinct.

The model helps locate a break without treating technical access as permission or invocation success as proof.

  1. 01
    Predecessor state

    The relevant state before a proposed change.

  2. 02
    Resolved authority

    The owner, source, permission, and constraints that govern.

  3. 03
    Bounded capability

    The operation permitted within a defined scope.

  4. 04
    Execution

    The actual attempt to make the change.

  5. 05
    Observed effect

    What can be established about the result.

  6. 06
    Successor state

    The relevant state after the attempt.

  7. 07
    Proof

    Evidence proportionate to the claim and its consequence.

The operating method

Observe → resolve → act → prove.

  1. 01

    Observe

    Establish the current state and the evidence behind it.

  2. 02

    Resolve

    Find the decision owner, governing source, and unresolved conflicts.

  3. 03

    Act

    Define a bounded move. The diagnostic proposes a correction; it does not change customer systems.

  4. 04

    Prove

    Specify how the effect and successor state can actually be checked.

The Continuity Diagnostic uses this method to propose a bounded correction. Implementing that correction requires a separate authorised engagement.

Make it concrete

Bring the transition you cannot establish.

One workflow is enough to start.

Discuss your AI workflow