2
0 Comments

NAEOS Engineering Case Study #001 When Approval Passes, Can We Prove What Was Actually Executed?

A recent engineering discussion surfaced a problem that is easy to miss when designing AI agent workflows.

The workflow already had an approval requirement.

The agent could draft content autonomously, but publishing required approval.

A check was also performed immediately before the publish action.

So the problem was not:

“Did the system perform an approval check?”

The deeper question was:

“Can we prove that the artifact that was checked is the artifact that was actually executed?”

That distinction matters.

A permalink can tell us where the resulting artifact landed.

But a permalink alone does not necessarily prove:

what exact payload was executed,
what authorization was checked,
what the pre-execution decision was,
or whether the authorization actually covered the executed payload.

One proposed way to close that gap is to read the published artifact back through the same API, apply a defined normalization rule, hash the result, and retain it alongside the approval hash and the pre-click verdict.

Conceptually:

Approval
│
▼
Approval Hash
│
▼
Pre-Click Policy Check
│
▼
Execution
│
▼
Read Back
│
▼
Normalize
│
▼
Observed Hash
│
▼
Evidence Record

The resulting evidence record could contain:

approval_hash
pre_click_verdict
observed_hash

If the hashes do not correspond, the artifact can be routed for review rather than being treated as automatically valid.

But there is another important complication.

External platforms can rewrite or transform content.

That means:

approved_text != observed_text

does not automatically mean:

unauthorized_execution

It may simply mean:

platform_transformation

This makes canonicalization part of the governance contract.

And this is where the problem becomes bigger than a single publishing workflow.

The important distinction is:

Authorization evidence
What was approved?

Execution evidence
What was actually executed?

Observation evidence
What did the external system actually receive or represent?

The engineering challenge is to preserve the binding between all three.

Authorization
│
│ binding
▼
Execution
│
│ observation
▼
External State

This leads to a principle I think is important for AI engineering:

A successful policy check is not the same as proof that the checked action is the action that was executed.

For AI agents, governance cannot stop at:

“Was the action allowed?”

We also need to be able to answer:

“What was authorized?”

“What was executed?”

“What did the external system observe?”

“Can we prove that these were actually connected?”

That is the difference between an approval workflow and an auditable engineering control.

And it is one reason NAEOS treats Observation and Evidence as first-class parts of the engineering architecture—not as an afterthought.

#AIEngineering #AIAgents #AgentGovernance #AIInfrastructure #AISecurity #SoftwareEngineering #EngineeringGovernance #NAEOS

on September 29, 2026