Authorization

Authorization decides whether an identified actor may perform an identified action under the applicable trusted policy. It does not prove that the action happened.

What the policy decision needs

The policy service needs to know who is asking, what action they want to take, which exact record or account it affects, and which policy version applies. The application decides where those facts come from and how current they must be. A role claimed by the user or generated by the model is not a substitute for information from trusted identity and policy systems.

The decision should be bound to the exact operation, amount, account, target, and applicable time or revision. That binding prevents a decision for one refund or tenant from being reused for another. The host owns requester authentication, tenant scope, consent, policy freshness, and any required human approval.

Lifecycle and denial

Authorization follows grounding and precedes protected dispatch. A denial, unavailable policy service, malformed decision, missing scope, or stale context fails closed as NOT_DISPATCHED; the provider boundary was not crossed. The application may give a privacy-safe denial explanation without exposing sensitive policy details or implying that the provider was called.

After authorization, provider preconditions and state changes between authorization and dispatch still matter. If the provider boundary has crossed, later uncertainty remains possible even though permission was granted. Authorization permits an attempt; independent authoritative verification determines effect truth.

Example: authorizing a refund

A customer or support workflow requests a $40 refund. The application backend authenticates the support agent, and the order system supplies order o-204 and its eligible charge. Grounding identifies that exact order; a trusted policy service then decides whether this actor may refund this order and amount.

If the policy service denies the request, the result is NOT_DISPATCHED and no payment-provider call follows. If it permits the attempt, the payment provider may acknowledge or reject the refund, but that observation is not authoritative completion. An independent ledger read determines whether the refund exists. A present refund maps to COMMITTED; a final authoritative absence maps to DISPROVED; an unavailable or contradictory read can leave the result UNKNOWN.

Policy and effect truth stay separate

The policy decision answers whether the actor may attempt the exact operation at that point in time. Effect truth answers what the authoritative system says after the attempt. A provider must not verify itself, and a policy service cannot certify a payment effect. The host owns provider I/O, credentials, authentication, source queries, and application recovery UX; Core carries the bounded decision and projects the permitted lifecycle claim.