NAEOS Technical Build Log #004 What Happens When Execution Becomes Unknown?

A policy check can tell us whether an action is allowed.

But what happens after the action is authorized—and the runtime stops telling us what happened?

This sounds like a simple timeout problem.

It isn't.

For an AI coding agent, an execution timeout can create a much more dangerous state:

we don't know whether the side effect happened.

And that distinction matters.

---

The scenario

Consider a simple deployment:

Agent proposes deployment
        ↓
Policy evaluation
        ↓
Authorization granted
        ↓
Runtime sends deployment request
        ↓
Network timeout
        ↓
???

What is the correct state?

Did the deployment fail?

Did it succeed?

Did the provider receive the request but fail to return the response?

We don't actually know.

Treating the timeout as FAILED would be an assumption.

Treating it as SUCCESS would also be an assumption.

So NAEOS needs another state.

UNKNOWN

---

UNKNOWN is not FAILURE

This is the distinction I'm exploring in this build log.

A useful execution state machine looks more like:

PROPOSED
   ↓
AUTHORIZED
   ↓
EXECUTING
   ├──→ CONFIRMED
   ├──→ REJECTED
   └──→ UNKNOWN

CONFIRMED means we have sufficient evidence that the side effect occurred.

REJECTED means we have evidence that the action did not occur or was explicitly rejected.

UNKNOWN means the runtime no longer has sufficient observation to determine the outcome.

That last state is uncomfortable.

But pretending uncertainty does not exist is worse.

---

Why automatic retry can be dangerous

Imagine an agent is authorized to deploy an application.

The runtime sends the request.

The provider processes it.

The deployment succeeds.

But the response is lost.

From the runtime's perspective:

request → timeout

The agent sees:

UNKNOWN

If the agent simply retries:

attempt #1 → UNKNOWN
attempt #2 → EXECUTE

we may now have two deployment attempts.

For some operations that may be harmless.

For others, it can be dangerous:

• database migrations
• infrastructure provisioning
• payments
• external API mutations
• resource creation
• production deployments
• notifications
• destructive operations

The important question is therefore not:

"Did the request timeout?"

The important question is:

"Can we establish what actually happened?"

---

Reconciliation before retry

This leads to another primitive I'm testing:

UNKNOWN
   ↓
RECONCILIATION
   ├── evidence confirms execution
   │        ↓
   │     CONFIRMED
   │
   ├── evidence confirms no execution
   │        ↓
   │     REJECTED
   │
   └── insufficient evidence
            ↓
         UNKNOWN

The runtime should attempt to reconcile the unknown state before deciding what happens next.

Depending on the operation, that evidence might include:

• provider deployment ID
• runtime receipt
• commit SHA
• artifact digest
• resource state
• health status
• audit event
• external system receipt
• idempotency key

The exact evidence depends on the execution target.

But the principle remains the same:

Outcome should be established from evidence, not inferred from silence.

---

Authorization does not establish outcome

This is another distinction that became clearer while working on the previous build log.

A policy decision answers:

May this action happen?

Authorization answers:

Is this execution attempt permitted under the current context?

Execution answers:

What did the runtime attempt to do?

Observation answers:

What actually happened?

These are different questions.

So the model I'm working with now is:

Proposal
   ↓
Policy Evaluation
   ↓
Authorization
   ↓
Execution
   ↓
Observation
   ↓
Outcome

The agent can propose the next action.

It should not be the authority that declares the previous side effect successful simply because the runtime stopped responding.

---

The agent should not own uncertainty resolution

This is particularly important for AI coding agents.

A model might reason:

"The deployment probably failed. I'll retry."

But "probably" is not an execution receipt.

The governance/runtime layer should instead be able to return something explicit:

{
  "execution_status": "UNKNOWN",
  "authorization_id": "auth_01",
  "attempt_id": "exec_01",
  "reconciliation_required": true
}

Now the agent has information about the state without being given authority to redefine it.

The agent can propose a next action.

The control plane decides whether that action is allowed.

And the runtime determines whether the previous action actually happened.

---

What happens with non-idempotent operations?

This creates an even harder question.

Suppose the system has:

UNKNOWN

and the operation is not safely idempotent.

Should NAEOS retry automatically?

My current answer is:

No—not without sufficient evidence or an explicit authorization path for the retry.

A safer decision path looks like:

UNKNOWN
   ↓
Can outcome be reconciled?
   ├── YES → reconcile
   └── NO
        ↓
Is operation safely idempotent?
        ├── YES → controlled retry
        └── NO → require explicit decision

The goal is not to make the system incapable of recovering.

The goal is to prevent uncertainty from silently becoming authority.

---

The experiment

The next NAEOS execution-boundary tests are therefore becoming more explicit.

Test A — Explicit rejection

authorize
→ execute
→ provider rejects

Expected:

REJECTED

Test B — Confirmed execution

authorize
→ execute
→ receipt returned

Expected:

CONFIRMED

Test C — Timeout before side effect

authorize
→ connection lost
→ no side effect

Initial state:

UNKNOWN

Then reconciliation should establish:

REJECTED

Test D — Timeout after side effect

authorize
→ side effect occurs
→ response lost

Initial state:

UNKNOWN

Then reconciliation should establish:

CONFIRMED

Test E — Unknown non-idempotent operation

authorize
→ execute
→ timeout
→ UNKNOWN

Expected:

no automatic retry

unless the system can establish that retry is safe and authorized.

---

A possible execution receipt

One direction I'm exploring is making execution outcomes durable artifacts rather than transient agent messages.

For example:

{
  "attempt_id": "exec_01",
  "authorization_id": "auth_01",
  "operation": "deploy",
  "target": "production",
  "status": "CONFIRMED",
  "provider_receipt": "deployment_83921",
  "artifact_digest": "sha256:...",
  "observed_at": "...",
  "runtime_version": "...",
  "policy_version": "..."
}

The exact schema is still experimental.

The important part is the relationship:

Authorization
      ↓
Execution Attempt
      ↓
Observation
      ↓
Evidence
      ↓
Outcome

That chain should survive the agent that initiated it.

---

A broader principle

The deeper lesson here is not really about timeouts.

It is about distributed systems and control boundaries.

A timeout doesn't necessarily tell us that something failed.

It tells us that we lost observation of what happened.

For AI engineering systems, that distinction becomes particularly important because an agent can continue reasoning even when the underlying runtime has entered an uncertain state.

NAEOS should not hide that uncertainty.

It should make it explicit.

When observation is lost, don't manufacture certainty. Reconcile the state.

And if reconciliation cannot establish the outcome:

UNKNOWN

should remain UNKNOWN.

---

What I'm testing next

The next question is becoming even more interesting:

What evidence is sufficient to move an execution from UNKNOWN to CONFIRMED or REJECTED?

That takes us from execution control into something closer to an evidence and verification model.

And that's where I think the next NAEOS experiment should go.

---

Question for the builders here

How would you handle a non-idempotent operation when:

1. authorization was valid,
2. execution was initiated,
3. the runtime timed out,
4. and there is no immediate confirmation of whether the side effect occurred?

Would you reconcile first, require human intervention, use an idempotency mechanism, or take another approach?

I'd especially like to hear from people working on distributed systems, infrastructure, deployment platforms, and AI coding agents.