I think AI agents have an authority problem we're treating as a permissions problem

Yes — and I think this exposes an even harder distinction.

Suppose we have all of that perfectly: who granted the authority, the exact artifact/version it applied to, when it became valid, and when it expired.

We still haven’t proved the action was authorised when the consequence actually occurred.

If authority is revoked after the executor’s final check but before the downstream system commits the side effect, the audit trail can be internally perfect and still give us the wrong answer about authority at consequence.

That’s why I’m increasingly uncomfortable treating “checked immediately before dispatch” as the final boundary.

For consequential actions, the stronger model may be that authority has to be enforceable at the resource capable of producing the side effect — and the evidence needs to distinguish what the executor intended, what the provider accepted, and what actually happened downstream.

The artifact-version issue fits the same model. If the authorised artifact changes materially, I wouldn’t call the old approval stale. I’d say the new artifact never inherited that authority in the first place.

That leaves a question I’m particularly interested in:

If the downstream resource cannot enforce current authority itself, can the upstream system ever honestly claim the action was still authorised at the point of consequence — or can it only prove that it was authorised at the last boundary it controlled?

Exactly. That distinction is the reason we introduced DENIED_UNRESOLVED.

A system can prove that it revoked authority, rejected a request, or stopped its own executor. But none of those facts necessarily prove that the downstream consequence did not occur.

That creates a dangerous evidence gap: “we told it not to happen” gets recorded as though it means “we know it didn’t happen.”

The question I think gets much harder is: what evidence is actually sufficient to move from DENIED_UNRESOLVED to DENIED_CONFIRMED?

If the downstream system gives you no authoritative receipt, state check, or other independent evidence of non-execution, I’m not convinced you should be allowed to make that transition at all.

How would you handle that boundary?

I think there’s an important distinction here: I wouldn’t describe the changed payload itself as “revoked authority.”

I’d say the original authority remains perfectly valid — but only for the exact action that was approved.

If A was approved and the model regenerates it into B, B hasn’t had its authority revoked. B never had authority in the first place.

That sounds semantic, but I think it matters for the evidence model. Otherwise we risk collapsing two very different claims:

“this action was authorised and that authority was later withdrawn”

versus

“this action was never the action that was authorised.”

So at the consequence boundary I’d want OpsWatch to establish action identity first: approved artifact/version, payload hash, destination/channel, and any other parameters that materially define the consequence.

Only if that identity still matches does the question become: is the authority attached to this action still current?

A mismatch should therefore fail before execution as AUTHORITY_NOT_APPLICABLE / re-authorisation required, rather than being recorded as a successful revocation.

Then, separately, if the action had already crossed the external boundary before that mismatch or revocation was detected, we’re back in the evidence problem: we cannot call it denied unless the downstream evidence supports that claim.

Your example exposes something I think is fundamental: authority shouldn’t attach to a workflow object.

It attaches to a specific consequential act.

This is a really useful extension.

I think you’ve identified a second assurance axis that sits alongside the consequence states.

One axis is consequence certainty:

EXECUTED
DENIED_CONFIRMED
DENIED_UNRESOLVED

The other is decision evidentiary integrity:

Can we reconstruct why this decision occurred from the evidence that travelled with it?

Your result is interesting because the consequence side behaved safely — both paths failed closed — while the decision evidence still failed to explain why an identical request changed class and severity.

That means a system can be operationally safe in the moment and still leave behind an assurance failure.

If “fresh attempt” versus “retry” materially affects the decision, that condition belongs in the durable decision record. Same for the authority state, policy version, relevant session state, and whatever other context actually influenced the check.

Otherwise an auditor gets a receipt describing the request, but not the state that produced the decision.

I think that gives us a useful distinction:

A consequence can be safely prevented while the decision that prevented it remains evidentially unresolved.

That probably deserves to remain visible rather than being collapsed into a clean “denied” result.

And yes — I’d definitely be interested in comparing notes. This is directly adjacent to the boundary I’m trying to make explicit with OpsWatch.

Feel free to send the grid and anything else relevant to my work email: jason@mcgillintelligence.com.au

Exactly. The longer the workflow runs, the less comfortable I am treating authority established at the beginning as authority to execute later.

The part I'm especially interested in is where teams are encountering this in production. If an agent starts under valid authority, spends time reasoning, waiting on another service or coordinating tools, and the underlying authority changes before the consequential action, something has to decide what is true now.

Are you seeing that problem in something you're currently building or operating?

That refund example is almost exactly why I ended up keeping DENIED_UNRESOLVED.

And yes — I think there will absolutely be pressure to collapse it into a cleaner “blocked” state. Operational dashboards reward certainty. Assurance systems sometimes have to refuse to manufacture it.

The distinction I’m trying to preserve with OpsWatch is:

DENIED_CONFIRMED = we have evidence the consequential action did not occur.

DENIED_UNRESOLVED = authority says it should not have occurred, but we do not yet have sufficient downstream evidence to make that claim.

Your two-day reconciliation gap is a perfect example. During those two days, “blocked” would have been the nicer dashboard state — but it would also have been false.

I actually think that discomfort is useful. If DENIED_UNRESOLVED starts accumulating, it exposes an evidence boundary the organisation probably needs to fix rather than hide.

Your authority-version-at-dispatch approach is interesting too. The question I’d want to test is: what evidence do you retain from the payment provider that lets you independently reconcile that dispatch-time authority version against the side effect that actually occurred?

That’s exactly the boundary I’m trying to keep honest.

OpsWatch doesn’t really belong on either side alone.

If it sits only with the agent, it risks treating the agent’s own “blocked” record as proof that nothing happened. If it sits only downstream, it can observe the resulting state but may have no independent basis for knowing what authority applied when the action crossed the consequential boundary.

So the model I’m working toward is independent reconciliation across both.

On the execution side, OpsWatch needs enough evidence to establish the action, actor, applicable authority, timing, dispatch state and where the last enforceable boundary actually was.

On the downstream side, it looks for whatever evidence can independently establish the consequence: provider receipts, resource state, transaction/audit records, delivery evidence, or another destination-side observation correlated to the same action.

Then it deliberately keeps three propositions separate:

“authority was revoked”

“our system attempted to block the action”

“the downstream consequence did not occur”

The first two do not prove the third.

That’s why your current “blocked on our side” case is so interesting. I wouldn’t necessarily say Valtres is wrong to record that operationally — it may be exactly what Valtres knows. The problem begins if that state is allowed to become evidence that the provider did not act.

If the request had already crossed the last boundary you control when revocation arrived, OpsWatch would preserve DENIED_UNRESOLVED until independent evidence could reconcile the outcome.

If the provider later proves the consequence occurred, we record that.

If independent evidence establishes that it did not occur, the denial can be confirmed.

And if the provider exposes nothing capable of settling the question, I think the uncomfortable answer is that it may have to remain unresolved.

Your fresh-token design is actually interesting because it gives you a very explicit authority enforcement point.

The seam I’d be most interested in is the few moments immediately around it:

authority valid → fresh authorization → external dispatch → authority changes → provider acceptance → downstream consequence.

That’s the point where “we stopped it” and “we can prove it didn’t happen” stop being the same claim.

And from what you’ve described, I think Valtres is already very close to that boundary.

This is a really useful live example — particularly because “attempted,” “published,” and “earned” cannot safely be treated as synonyms.

I’d make one distinction in the state mapping, though.

Your lagging App Store revenue is clearly unresolved evidence, but I wouldn’t automatically call it DENIED_UNRESOLVED. That state is narrower for me: authority was withdrawn or denial was attempted, but the action crossed far enough into the consequential path that I cannot prove the consequence was prevented.

What you have with the sale is a different uncertainty: the authorised action happened, but the downstream business outcome has not yet been independently established.

That difference matters.

Otherwise DENIED_UNRESOLVED risks becoming a general “we don’t know” bucket, when the more important claim is: “we tried to stop this and cannot prove that we succeeded.”

Your $0 rule is exactly the discipline I want on the evidence side, though. Until an external receipt establishes revenue, “published an offer,” “performed outreach,” and “earned money” remain three separate claims.

And your point about impersonation is the authority problem in miniature: permission to pursue the goal does not silently grant authority over every consequential path available to the agent.

That last question is exactly where it gets interesting.

I’m finding the hardest part isn’t purely the agent framework or purely the downstream provider. It’s the seam between them.

The framework can record “authority revoked” perfectly, but if a worker already holds the job or the request has crossed into a provider, that record doesn’t prove the consequence stopped.

At the other end, a provider might give you a 200, queue ID or “accepted” receipt — but that may only prove receipt or dispatch, not the resulting state of the resource.

So I’m increasingly treating these as separate evidence claims rather than one audit event: what was authorised, what was dispatched, what actually executed, and what can independently be established downstream.

The resistance comes when you refuse to collapse the gaps between those claims.

“DENIED_UNRESOLVED” is uncomfortable commercially because buyers naturally want a green or red answer. But I think regulated buyers ultimately need the opposite: a system willing to say “we cannot yet prove this” rather than manufacture certainty from its own logs.

That’s really the assurance boundary I’m trying to establish with OpsWatch.

Yes — that separation is exactly the part I think matters.

A short-lived capability can prove that the action was still authorised when it reached the execution boundary, but it still cannot prove what happened after the request crossed into the downstream system.

That gives you at least three different claims:

the action was authorised at execution time;
the request was dispatched;
the downstream consequence was independently evidenced.

I think problems start when systems compress those into one status.

A queue receipt can support the second claim, but not the third. And if the provider times out or gives you no independently queryable outcome, I would rather preserve that uncertainty explicitly than convert it into “blocked” or “failed.”

That is essentially why I keep coming back to DENIED_UNRESOLVED: revocation intent is not the same thing as evidence that the authority stopped producing consequences.

Your point about authority surviving in the worker/provider after the UI changes is exactly the failure mode I’m trying to make impossible to hide.

Exactly. The code-review analogy is a good one because it separates “the system produced the expected response” from “the consequential path was actually safe.”

That is the boundary I’m trying to keep explicit with OpsWatch.

I’d add one wrinkle: even an execution-time authority check and a dispatch receipt may still not be enough. If the side effect crosses into another system, the evidence has to tell you what that downstream system actually accepted or changed — otherwise you can prove that the request was authorised and sent, but not necessarily that the consequence occurred or was prevented.

That is where I think systems become dangerous when they collapse uncertainty into a clean UI state.

For me the evidence chain is becoming:

authority at the point of consequence → dispatch evidence → downstream evidence.

And if the last link is unavailable, the honest state is not “blocked.” It is DENIED_UNRESOLVED until something independent can close the claim.

Your cursor.execute example is almost exactly the same failure shape: correct-looking behaviour upstream can hide the thing that actually matters at the execution boundary.

Permission is definitely part of it, but I think “short-lived reason + owner” gets us closer to the real failure mode.

The bit I’d add is that expiry by itself still leaves a timing problem. An approval can be valid when the job starts, then become stale while the agent is planning, waiting, retrying, or sitting in a queue.

So for consequential actions, I think the question has to be re-asked at the point the side effect can actually happen:

Is this exact action still authorised now, under the current state, by the authority that matters?

That’s the distinction I’m trying to make with OpsWatch.

A short-lived reason helps reduce stale authority. A fresh check at the consequence boundary is what actually stops a harmless approval becoming a standing order.

And then there’s one more ugly edge: once the action has already left for an external system, “we revoked it” and “we know it didn’t happen” are no longer the same claim.

That’s why I think this ends up being less of a permissions problem and more of an evidence problem.

Curious how you’d handle the owner changing mid-run — would you kill the job immediately, or require re-authorisation at the next consequential step?

I think the mistake would be trying to sell DENIED_UNRESOLVED as uncertainty.

I’d sell it as the boundary of what the organisation can currently prove.

Your Microsoft example is exactly why. If identity says the entitlement is revoked while a downstream queue can still execute under the old grant, a green “blocked” status isn’t confidence — it’s an unsupported assertion. And once that assertion enters an audit record, the assurance system has become part of the problem.

So I don’t want DENIED_UNRESOLVED to be a terminal state or a nicer word for “unknown.” It should trigger reconciliation: what evidence is missing, where can it be obtained, and what would be sufficient to resolve the claim? If the downstream system exposes a receipt, resource-state check, event ledger or other independent artifact, use it. If it exposes nothing, preserve that limitation rather than silently converting absence of evidence into evidence of denial.

Commercially, I think the buyer changes too. The person operating the workflow may want the green checkmark. The person who has to defend that checkmark after an incident, audit or access-control failure wants to know whether it is actually true.

That’s the market I’m interested in.

OpsWatch shouldn’t make uncertainty disappear. It should make false certainty impossible.

Your access-review case is a great example, by the way. The interesting question isn’t which system has the “correct” state — it’s what evidence at the actual consequence boundary can settle the disagreement.

That’s exactly the boundary I care about.

I don’t want OpsWatch’s assurance claim to depend solely on the executor saying “I checked myself and everything was valid.” The executor can produce useful evidence — action ID, authority snapshot, timestamps, provider receipts — but OpsWatch should preserve and evaluate the consequential evidence independently of the system whose behaviour it is assessing.

Your scheduled-job example is a good illustration. Checking at enqueue proves authority at enqueue. It says nothing about whether authority was still valid when the queued action actually crossed the side-effect boundary.

I’d want the evidence chain to distinguish at least:

authority when queued → authority immediately before execution → dispatch → downstream evidence of what actually happened.

And if that last piece can’t be independently established, OpsWatch shouldn’t turn the executor’s internal “denied” or “cancelled” log into proof that the action didn’t occur. That’s where DENIED_UNRESOLVED matters.

Your point about writing the authority snapshot into the action record is interesting, though. What are you using as the authoritative source for that snapshot — the worker’s own state, or something the worker has to validate externally at execution time?

I’d actually separate those two mechanisms rather than choose between them.

A short-lived, target-bound capability is useful because it can bind the approved intent: who authorised it, what action, against which resource, under which parameters, and for how long.

But I wouldn’t let possession of that capability become proof that authority is still valid.

At the consequence boundary, the executor/resource should re-check the authority state before accepting it. Otherwise you’ve only made stale authority expire faster — revocation can still happen after the capability was minted but before the side effect occurs.

So the shape I’m interested in is:

proposal → approval → bound capability → execution-time authority check → side effect → independent evidence.

The interesting case is when approval was perfectly valid when the capability was issued, but authority changes 30 seconds later. The capability proves what was approved; the execution-time check determines whether it is still authorised.

And if the action leaves your boundary before that can be established downstream, I wouldn’t call the denial successful without evidence. That’s where we keep a separate DENIED_UNRESOLVED state.

For a draft-first product, your review boundary is actually a very clean place to test this: what evidence would you currently have if approval happened, authority changed immediately afterwards, and the external action was dispatched before your system noticed?

I think you’ve put your finger on the boundary that matters.

I wouldn’t treat a re-check after dispatch as revocation unless that check can still prevent the consequence.

If OpsWatch controls a boundary immediately before execution, authority can be checked again there. But once an external provider has accepted the instruction, a local authority change cannot retroactively make that instruction un-happen. From that point onward, the problem changes from authority enforcement to consequence verification.

So the 9:04–9:06 case really has two very different outcomes:

Authority revoked at 9:04 → execution boundary checks at 9:05 → action rejected: DENIED_CONFIRMED.

Authority revoked at 9:04 → provider may already have accepted/executed → local system notices at 9:06 but cannot independently establish downstream state: DENIED_UNRESOLVED.

And I think your adapter observation goes further than implementation detail.

Maybe every provider needs an evidence capability, not merely an integration: what can independently establish acceptance, execution, final state, or non-execution — and what can’t?

Stripe might support a strong determination because there are durable identifiers and queryable downstream records. SMTP may support a much weaker one. Some providers may make DENIED_CONFIRMED impossible after a particular boundary.

That means OpsWatch shouldn’t normalize those differences away. It should expose them.

The interesting question then becomes: before an agent is allowed to perform a consequential action, should the assurance layer know whether the downstream provider is capable of proving what happened afterwards?

Because if it can’t, that’s not just an observability limitation. It changes the risk of granting the authority in the first place.

That's exactly where I'd avoid using reversibility as the boundary.

An email is a good example because the consequences can be soft but the action itself is still irreversible once the recipient has it. You can send a correction, but you can't make the original message unread, unforwarded or unacted-on.

So I'd draw the line around commitment rather than deletion or money.

If an agent is drafting, summarising or preparing an action, broad delegated authority can make sense. But the moment it creates an external commitment — sends the email, submits the order, changes the record, makes the promise — I'd want current authority checked as close to that boundary as possible.

And then I'd keep the evidence separate: what was authorised, what was dispatched, and what can actually be established downstream.

That's part of what I'm building OpsWatch around. The interesting cases aren't always catastrophic actions. They're the ordinary actions that become consequential because the world can't simply be put back into its previous state.

I’d keep those as separate failure reasons rather than collapsing both into “not authorized.”

“Authority revoked” means the actor or agent no longer has valid authority to perform the action.

“Approved, but the underlying order changed” is different: the authority may still exist, but the approval was bound to a state that no longer does.

In your Shopify example, I’d want the approval tied not just to the exact order and proposed cancellation, but to the relevant fulfillment state at approval time. If fulfillment starts before execution, that approval becomes stale and the action should require a fresh decision.

Then I’d keep the downstream result separate again. If a cancellation was dispatched and Shopify timed out, OpsWatch shouldn’t infer success or denial from the local state. The outcome stays unresolved until Shopify evidence or reconciliation establishes what actually happened.

So I see three separate questions: was authority still valid, was the context the approval depended on still valid, and what actually happened downstream.

Your CaseKit example is a really clean illustration of why those shouldn’t be represented as one status.

If you ever want to test that boundary against a small CaseKit scenario — even while it remains read-only — I’d be happy to run a bounded OpsWatch example against it and compare what each layer can actually evidence.

I think “verifiable authorization + verifiable outcome” gets very close to the heart of it.

My instinct is not to standardize every provider's evidence. I'd standardize what has to be proved, while allowing the evidence to remain provider-specific.

So the common questions become: was authority current at the point of consequence, what actually crossed the execution boundary, and what can the downstream evidence independently establish?

That's essentially the problem I'm building OpsWatch around — an independent assurance layer between authorized intent and consequential execution.

I'm currently testing it against real agent architectures, particularly where actions cross external service boundaries.

If Fountrail has a workflow like that, I'd be interested in testing one bounded action path against the OpsWatch model. No big integration — just enough to see whether the assurance gap actually exists.

Your point about avoiding another centralized trust layer is exactly the right constraint.

Yes — especially the “pause and re-validate instead of retrying blindly” part.

The one thing I’d separate is fresh authority from fresh human approval.

For some consequential actions, human approval may absolutely be the right boundary. But I think an agent can still operate with substantial autonomy if authority is explicit, scoped, time-bounded and revalidated against current state at execution.

The important thing is that yesterday’s approval — or even an approval from five minutes ago — doesn’t become permanent permission simply because the workflow is still running.

And if that execution-time check fails, I don’t think retry should automatically restore authority.

Pause → establish current authority → then decide whether execution is permitted.

That gives us a much cleaner rule: autonomy can persist, but authority has to remain current.

Exactly — the chessboard example is almost a perfect miniature of the problem.

The agent can have been completely correct when it reasoned about the move, and still no longer have authority to make that move when the consequence is applied.

That distinction is what I keep coming back to:

Valid when decided ≠ authorized when executed.

Because you control the enforcement boundary, you can revalidate against authoritative game state immediately before applying the move and get a definitive answer.

The interesting change happens when that boundary moves outside your control.

Once the action has been dispatched to another provider or resource, an internal “deny” no longer necessarily proves that the consequence was prevented. Without evidence from that downstream boundary, DENIED_CONFIRMED would be claiming more than the system actually knows.

That’s why I added DENIED_UNRESOLVED rather than treating uncertainty as failure or success.

Your arena is actually a really clean example of where the model works well: because you own the consequence boundary, unresolved should be rare or potentially nonexistent.

The harder question is what assurance looks like when you don’t own the chessboard anymore.

I think that’s ultimately where this leads too — but I’d make one distinction.

An AI agent can be highly autonomous without having unlimited authority.

It might be allowed to plan, reason, retrieve information and make low-consequence decisions independently. But when an action can create a real-world consequence — send money, change access, modify production, commit an organisation, contact a customer — its authority should have a boundary.

The interesting problem for me isn’t simply “human in the loop” vs “fully autonomous.”

It’s whether we can prove, at the moment of consequence, that the agent still had authority to perform that specific action.

Because an agent being technically capable of doing something doesn’t necessarily mean it should still be authorised to do it.

Exactly. Long-running workflows are where the distinction stops being theoretical.

The authority that existed when an agent began planning may tell you why the workflow started, but it does not necessarily tell you whether the agent was still entitled to create the consequence several minutes later.

That is why I’m increasingly thinking about authority as something that has to survive until the execution boundary, rather than something granted once at workflow initiation.

The other difficult part is evidence after that boundary. Even if an internal control says “deny,” once a downstream system may already have received the request, the assurance problem changes from policy enforcement to reconciliation.

That is where DENIED_UNRESOLVED becomes important to me. It prevents the system from turning “we intended to stop this” into “we can prove this never happened.”

I suspect long-running and scheduled agents will make this distinction much more important than it looks today.

Yes — I think this exposes a hole if the model relies on revocation alone.

A revocation channel answers: “Has someone withdrawn authority?”

Your example asks the harder question: “Why is this authority still valid at all?”

For unattended execution, I don’t think “nobody revoked it” is sufficient evidence of current authority. The schedule can remain technically permitted while the purpose that justified it has quietly disappeared.

So I’d separate permission from continuing authority. A scheduled job might not need a human confirmation on every run, but its authority should be bounded by something that forces revalidation: time, cumulative spend, number of executions, material parameter change, project state, or another explicit condition appropriate to the consequence.

And I wouldn’t automatically call your successful runs EXECUTED and stop there. EXECUTED proves the side effect occurred. It doesn’t prove the authority supporting that side effect was still current.

Your billing notice is particularly interesting because the downstream system effectively produced the first evidence that the original authority assumptions had become questionable.

That suggests another boundary for OpsWatch: stale authority isn’t only “authorized at 9:00, revoked at 9:04.” It can also be “authorized three months ago, never revoked, but never revalidated either.”

In that case, absence of revocation is not evidence of continuing authority.

That’s exactly the distinction.

For me, DENIED_UNRESOLVED should only become DENIED_CONFIRMED when the evidence comes from the point where the side effect could actually have occurred — not merely from the layer that intended to stop it.

So if an internal policy engine says “deny,” but the request may already have reached an SMS provider, calendar API, payment rail, etc., that denial is not yet proof of non-execution.

The evidence threshold has to depend on where the consequence lives.

If the resource itself rejects the action under a still-valid authority check, that can be strong evidence for DENIED_CONFIRMED.

If the request crossed into an external system, I’d want some authoritative downstream evidence — provider rejection, immutable audit record, explicit cancellation state, reconciliation result, or equivalent — before collapsing the uncertainty.

And if that evidence simply doesn’t exist, I think the honest state is to leave it unresolved rather than manufacture certainty.

That is becoming one of the core principles behind OpsWatch: the system’s intended state and the evidenced real-world state are not automatically the same thing.

This is exactly the distinction I was hoping the thread would surface.

The parameter-bound token closes one gap: the action being executed is the action that was actually confirmed.

But your calendar example exposes the next one.

Even if recipient + message + timestamp are byte-identical, the facts that made that action valid can change between confirmation and execution. The slot disappears. The contact record changes. Authority is revoked. Same confirmed plan, different world.

So I think there are really two separate proofs:

1. Plan integrity — did execution match exactly what was confirmed?
2. Execution-time validity — were the facts/authority that permitted that action still true at the point of consequence?

And then, once it leaves your boundary, a third question appears: what evidence do you actually have that the downstream system did what you requested?

That’s why I’m increasingly uncomfortable with a single “executed” state.

Requested → accepted → externally confirmed preserves the evidence boundary instead of allowing the system to claim more certainty than it possesses.

For OpsWatch, that separation is becoming the important part: not just deciding whether an agent should act, but being able to prove afterward what was authorised, what was still valid at execution, what actually crossed the boundary, and what remains unresolved.

Your StareBrain example is a great concrete test of that model.

That's exactly where I think DENIED_UNRESOLVED has to remain uncomfortable.

If the downstream exposes a trustworthy ledger, receipt or queryable state, reconciliation can collapse the uncertainty later: the initial state may be unresolved, then move to DENIED_CONFIRMED or EXECUTED when downstream evidence arrives.

If it exposes nothing, OpsWatch shouldn't promote the upstream stop, proxy rejection or expired dispatch token into proof of what happened downstream. We can establish the last controlled boundary and exactly what was authorised or dispatched there, but the downstream consequence remains unresolved.

So I think your “shrink the unresolved window” framing is right. The extra distinction I'd keep is that sometimes the window doesn't shrink to zero at all — and that itself becomes an assurance finding about the downstream dependency.

In other words: lack of queryable downstream evidence isn't something OpsWatch should hide. It's something OpsWatch should surface.

The capability/authority separation is exactly the boundary I’m interested in. A narrow expiring capability answers what the agent can technically do; the execution-time check answers the different question of whether it still has authority to do it now.

I also like the append-only point. If authority is revoked at T1, I don't want the evidence system rewriting an earlier state to make the history look cleaner. The source of authority, inputs and resulting determination need to survive independently enough to reconstruct what was actually known at each point.

The offline/local-agent case is particularly interesting though. If the agent can't reach the authority source, default-deny protects the consequence — but it also creates an evidence question around queued actions when connectivity returns and authority may have changed again.

Have you implemented this capability/authority pattern in a local or production agent yourself, or are you describing the architecture you'd use?

If you've actually hit that offline/sync boundary in a system, I'd be interested in comparing how you handled the authority transition.

Exactly. That distinction between what the application believed and what can independently be established is the reason I don't want DENIED_UNRESOLVED automatically collapsing into DENIED_CONFIRMED.

The payment processor example is a good one. If our system says “never sent” but the processor later produces evidence of receipt or execution, the audit trail wasn't evidence of the outcome — it was evidence of our system's belief about the outcome.

I'd rather have an uncomfortable unresolved state at T1 that can be resolved by authoritative downstream evidence at T2 than a clean green audit trail that turns out to be fiction during an incident review.

Curious whether you've encountered that processor/app disagreement in practice, or whether you're using it as the clearest example of the failure mode?

Exactly. Permission tells you what an agent could do. Authority tells you whether it should still be allowed to do it at the moment the consequence occurs.

DENIED_UNRESOLVED became important for us because “we tried to stop it” isn’t evidence that nothing happened. If an action has crossed into an external system and there’s no authoritative receipt confirming the outcome, calling it denied would overstate what we actually know.

I’d rather preserve the uncertainty explicitly than manufacture certainty for the audit trail.

The ambiguous-authority point is important. A grant can be technically alive while the action has drifted far enough from the original intent that treating it as authorised becomes unsafe.

That suggests the check can't just be “has this authority expired?” It also needs to ask “does the authority still bind to this exact action, under these exact conditions, now?”

And yes — DENIED_UNRESOLVED exists specifically because I don't want OpsWatch manufacturing certainty. If the evidence only proves that we intended to stop an action, that's what the record should say. “Blocked” should require evidence that the consequence actually didn't occur.

Your operator rule — action shape drifts from grant shape → stop and re-authorise — may actually be a very clean way of expressing that boundary.

Yes — the retry consequence is important.

If the first dispatch ends in DENIED_UNRESOLVED, automatically retrying doesn't resolve the uncertainty. It potentially creates a second consequence while the first one may already have occurred.

So unresolved probably has to behave as a hard operational boundary: no retry until either downstream evidence resolves the first attempt or a human explicitly accepts the risk of another attempt.

I also like the target-bound receipt idea. It gives us a clean separation between “authority existed for this specific attempted action” and “the downstream consequence is evidenced.”

Those are two very different claims, and collapsing them is exactly what I'm trying to avoid.

Yes — I think DENIED_UNRESOLVED has to be resolvable when late provider evidence arrives, but the original state must never be overwritten.

At T1 the truthful determination was DENIED_UNRESOLVED because the available evidence couldn't establish the downstream outcome. If a provider receipt arrives at T2 and establishes that the side effect did not occur, we should append a transition to DENIED_CONFIRMED with the new evidence, timestamp and provenance.

The record should still show that between T1 and T2 the outcome was genuinely unresolved.

Otherwise we'd be using later knowledge to rewrite what was actually knowable at the time.

I like your idempotency-key point for exactly that reason. It gives late evidence something stable to reconcile against without pretending we proved a negative at T1.

So my instinct is that OpsWatch should remain an assurance record first, with evidence-driven reconciliation layered on top — append-only state transitions rather than mutable outcomes.

That distinction matters because an auditor should be able to ask both: “What do we know now?” and “What could the system truthfully claim at the moment of consequence?”

Exactly. And the more I work through this, the more I think that distinction needs to be enforced in the evidence model, not left to UI wording.

If you can prove the denial, say DENIED_CONFIRMED.

If you can't prove the downstream outcome, say DENIED_UNRESOLVED.

“We tried to stop it” can be useful evidence — but it isn't evidence that nothing happened.

That uncomfortable uncertainty is precisely what the state is there to preserve.

That's a fair push, but I think compensation and evidence solve different parts of the problem.

If a consequence is cheaply and reliably reversible, compensation is absolutely a powerful control. But not every side effect is: an email can be read, data can leave a boundary, a credential can be exposed, a decision can trigger another system, or money can move through another downstream process.

And even where reversal works, “we compensated successfully” isn't the same historical claim as “the original consequence never occurred.”

I agree strongly on enforcing authority as close to execution as possible with short-lived credentials. That reduces the stale-authority window dramatically.

Where I think the evidence layer remains necessary is after that boundary: what was authorised, what actually executed, what downstream evidence exists, and—if compensation occurred—what was subsequently reversed.

So I'd probably model compensation as another evidenced consequence rather than use it to replace the evidence problem.

That’s a fair push. I think compensation is part of the answer, but I’m not convinced it replaces evidence.

The credential-layer approach works beautifully while you still control the enforcement point: re-mint immediately before execution, stale authority fails closed, done.

The boundary I’m interested in is what happens once the action escapes that control.

If an external provider may have accepted the action but you don’t have evidence of the downstream result, you now have two problems: you can’t honestly claim it was blocked, and you may not know whether there is anything to compensate.

And compensation itself is another consequential action. What authority allows the agent to reverse it?

That’s why DENIED_UNRESOLVED exists. It doesn’t try to prove a negative — it prevents the system from pretending it knows one.

Maybe the interesting test is: can compensating actions eliminate that unresolved state, or do they actually make downstream evidence more important?

That's an interesting extension of it. I think there may be two separate forms of drift: authority drift and intent/context drift.

An action can still satisfy the technical permission boundary while no longer matching what the original human intent actually meant under the current context.

On DENIED_UNRESOLVED, I don't have enough production evidence yet to honestly say which occurs more often.

Architecturally though, I think slow/async downstream systems create the harder unresolved problem. Fast-changing permissions increase the chance that authority becomes stale, but if the authority check happens at the actual execution boundary you can often fail that closed.

Once an action has been dispatched to an external or asynchronous system, the problem changes. You're no longer asking only “was this still authorised?” You're asking “what actually happened after it left our boundary?”

Without downstream evidence, that's exactly where DENIED_UNRESOLVED earns its place.

The slow/async downstream case is the one that worries me more.

Fast-changing permissions can create stale authority, but if the enforcement point can still check current authority before the side effect, the outcome is clean: execute or deny.

DENIED_UNRESOLVED appears when that certainty breaks. If authority changes after an action has already been dispatched to an external system, an application-level denial doesn’t prove the side effect didn’t occur. Without downstream evidence, the honest state is unresolved rather than blocked.

Your input-side point is interesting though. A technically valid permission doesn’t necessarily mean the intent behind the action is still valid. That suggests two different stale-state problems: “are you still allowed to do this?” and “is this still what was actually intended?”

I’ve been concentrating on the first one because it can be enforced at the point of consequence. But I’m curious about the second: have you seen cases where a prompt remained technically valid while accumulated context changed what the user originally meant?

Exactly. Moving the check closer to the side effect is the part I think gets underestimated.

Read-only by default plus a separate write grant is a strong boundary, but then the next question becomes: what does that grant actually mean at the instant the write executes?

If it was valid when issued but revoked or made stale before consequence, the executor still needs a way to reject it. And if the request has already crossed into an external provider, absence of success evidence cannot become evidence of denial.

That’s why I ended up separating DENIED_CONFIRMED from DENIED_UNRESOLVED.

I’d be interested in how amami handles the write grant after issuance: is validity checked again at the actual write boundary, or is possession of the grant sufficient once it has been issued?

This is extremely close to where my testing has ended up.

The separation I think matters most is that the model never gets to turn its own plan into authority. A plan can propose an action; something independent has to establish whether that exact action is authorised, and the executor has to evaluate that authority at consequence time.

I also agree on freezing retries. DENIED_UNRESOLVED should not quietly become “try again,” because the missing evidence may be hiding a consequence that already occurred.

One addition I’d make: keep execution state and assurance state separate. An action can be demonstrably EXECUTED while the authority presented for it was invalid at execution. Calling the action “denied” at that point destroys evidence of what actually happened.

So the record needs to be capable of saying both things simultaneously:

EXECUTED — but NOT_ASSURED because authority was invalid at execution.

That distinction has become much more important in my testing than I originally expected.

Curious whether your policy service records the authority decision itself as independently verifiable evidence, or only the resulting allow/deny decision.

Yes — context is the part that makes this especially interesting.

An agent can still have the same technical permission, and there may not even have been an explicit revocation, but the context that made the original authority valid can change before the consequential action occurs.

That raises a harder question than “does this agent have permission?”:

What evidence establishes that the authority was still valid for this specific action, in this context, at the moment of consequence?

And then accountability creates a second boundary — proving what actually happened downstream rather than relying on the agent or control that authorised the action to attest to the outcome.

I’m curious whether you’ve encountered the authority/context distinction in a system you’ve actually worked with. If so, what changed between initial authorisation and execution?

Yes — I think that’s an important upstream control, and I’d separate it from the authority problem rather than fold them together.

A grader between retrieval and generation helps answer: “Is the model reasoning from evidence that is relevant and trustworthy enough?”

The problem I’m focused on starts after that.

Even if retrieval is perfect and the model’s reasoning is correct, the action can still be wrong at the moment of consequence because:

the authority basis has changed,
the world state has changed,
the technical permission still exists even though current authority does not,
or the system later treats “sent” as proof that the downstream side effect actually occurred.

So I see Corrective RAG as improving the epistemic basis for the decision, while the assurance layer I’m interested in asks whether that decision was still authorised and actually evidenced at execution.

Those feel complementary rather than competing controls.

I’m deliberately trying not to let confidence in the retrieval/generation layer inherit into confidence about authority or downstream execution.

Yes — and I think your CMS example exposes something even more important than revocation.

Nothing actually became invalid in the permissions layer. The token was valid. The write was permitted. There was no revocation event to catch.

What expired was the assumption that the authority under which the action was planned still described the world at the moment of execution.

That means “current authority” can’t just mean “has this authority been revoked?” It also has to mean “is the state this authority depended on still true?”

Your last-modified check gives you that answer for the CMS case. But the broader principle is powerful: authority isn’t something an agent should be able to inherit from planning time and carry indefinitely toward consequence.

It has to be re-established against the relevant state at the execution boundary.

That’s exactly the class of failure I’ve been trying to isolate.

Yes — that's the same evidence discipline applied to a different system.

A mention establishes a mention. A citation establishes that a source was referenced. Neither by itself establishes that the brand was actually recommended, and recommendation still doesn't establish conversion.

What I like about that framing is that each transition requires its own evidence rather than inheriting certainty from the previous state.

That's the principle I'm increasingly interested in beyond the original authority case: what exactly is this evidence entitled to prove?

Once that question is explicit, a lot of apparently “complete” audit trails become much easier to interrogate.

Yes — and I think the distinction between receipt and consequence becomes important here too.

The third measurement point gives us something we didn't have before:

T0 — authority/permission state
T1 — attributable authority change
T2 — downstream boundary receipt

That can establish ordering far better than dispatch + eventual outcome alone.

But I wouldn't let the receipt automatically collapse the uncertainty.

A provider receiving the instruction proves receipt. It doesn't necessarily prove the consequential side effect occurred — and it doesn't necessarily prove the authority state was revalidated at the resource that ultimately performed it.

So I think there are potentially four events worth separating:

AUTHORISED → AUTHORITY CHANGE → RECEIVED → CONSEQUENCE

The interesting case is when those clocks disagree or one piece of evidence is missing.

That's where DENIED_UNRESOLVED becomes useful rather than just being an error state: it explicitly preserves what we cannot establish instead of allowing the system to silently convert uncertainty into “blocked” or “executed.”

Your latency point is exactly why I think this needs independent evidence rather than another agent-level status.

Exactly. And I think the “pause retries” consequence is where this stops being just an audit-state problem.

If the first attempt is unresolved, a retry can create a second side effect while we still don’t know whether the first one happened. So the unresolved state has to affect execution authority, not just what the UI displays.

I’m curious: have you hit this boundary in something you’re actually running, or are you approaching it from the architecture side?

Yes — this is very close to where I’ve landed.

Your five-minute parameter-bound token is effectively putting a bounded lifetime on authority rather than assuming an earlier approval remains valid indefinitely. The re-authorisation at confirm is the important part for me: revocation becomes enforceable before the consequential write rather than merely becoming another event in the audit trail.

And I agree with you on the external-provider boundary.

Once the request has crossed that boundary, I don’t think the agent gets to manufacture certainty from silence. “Sent, no receipt” is evidence of uncertainty, not evidence of non-execution.

The one distinction I’d probably preserve is between:

1. confirmed not submitted to the provider; and
2. submitted, downstream effect unresolved.

Both may ultimately prevent us from claiming EXECUTED, but they leave us with very different evidence about what could have happened.

Your point about the UI being a question for the operator is interesting too. I’m increasingly thinking DENIED_UNRESOLVED shouldn’t really behave like a terminal status at all — it may be an evidence state that forces reconciliation before the system is allowed to decide what happens next.

That would also prevent the dangerous case where an unresolved first attempt is quietly treated as safe to retry.

Exactly. The ACL can tell us whether the action was permitted when checked; it cannot, by itself, prove the state of authority when the downstream side effect occurred.

That gap is what forced the DENIED_CONFIRMED / DENIED_UNRESOLVED distinction.

If the enforcement point can prove the action never crossed the side-effect boundary, DENIED_CONFIRMED is defensible. If execution was dispatched and the downstream outcome cannot be independently established, calling it “blocked” destroys information we may later need.

The harder question we’re working on now is revocation: if authority is valid at T0 but changes while an asynchronous action is already in flight, where must that revocation become enforceable for the evidence to remain meaningful?

My current view is: at the resource capable of producing the consequence, not merely at the agent or orchestration layer.

I’d be very interested in your take on that boundary.

Yes — I think the enforcement boundary has to be part of the evidence model.

Otherwise you can prove that a decision engine returned DENIED, but you still haven’t proved what happened at the point capable of producing the side effect.

That distinction is exactly why I ended up with DENIED_UNRESOLVED. “The system decided not to allow it” and “we can establish that the consequential action did not occur” are different claims.

The harder case is when authority changes after an earlier permission/decision exists but before consequence. At that point, evidence about the original authorization isn’t enough — you need evidence about what authority was actually valid at the enforcement boundary when the action could execute.

Curious whether you arrived at this from a real system you’ve been working with, or from thinking through the model? If you’ve seen it operationally, I’d be very interested in comparing where you found the boundary actually sits.

That distinction is exactly the boundary I’ve been working around too.

The harder case I keep coming back to is what happens when “accepted” is no longer enough: the action was validly authorised when requested, but that authority changes or is revoked before the consequential downstream action actually occurs.

If the provider boundary still has technical permission at that point, where do you make the current-authority decision?

Curious whether you’ve hit that case in practice.