Why must ontology facts be separate from authority to act?

A true statement is not a permission grant

An illustrative planning system correctly identifies a spare part that meets a work order’s technical requirements. The user viewing the recommendation may still lack authority to reserve it, and another team may already have claimed it. The ontology helps explain eligibility. Permission and current target state belong to additional contracts that must hold when the action occurs.

Name three different decisions

Ask whether the action makes semantic sense, whether this actor may perform it, and whether the target still satisfies the required preconditions. A maintenance coordinator can be authorized to reserve parts yet unable to reserve a particular lot that has just been quarantined. Combining all three decisions into an opaque “eligible” flag makes the failure difficult to explain and correct.

Build a proposal with a narrow target

The proposal should name the resource, intended operation, relevant evidence, expected target version, and bounded parameters. Identify the user or workload on whose behalf the system acts. Give unresolved evidence an explicit state. The proposal is useful review material, but its presence should not itself confer a reusable capability to change arbitrary resources later.

Check authority at the execution boundary

Boundary	Question it owns
Semantic evaluation	Does the candidate satisfy the modeled meaning?
Authorization	May this actor perform this action now?
Concurrency control	Is the target still in the expected state?
Executor	Was the permitted operation attempted as specified?
Effect observation	What changed, or remains unknown?

Implement these responsibilities in the smallest appropriate architecture. They need distinct meanings even when one service owns several of them.

Preserve ambiguity after a timeout

If a reservation request times out, the system may not know whether it succeeded. Avoid treating the missing response as an instruction to reserve again. Use the target service’s supported operation identity and reconciliation mechanism. A later receipt should distinguish confirmed success, confirmed rejection, and unresolved completion. The evidence model helps connect those observations without inventing certainty.

Review the denial path as carefully as success

Exercise expired access, a changed resource, a withdrawn approval, and an action outside the permitted scope. Confirm that denial creates no side effect and provides an appropriate explanation without exposing forbidden data. Then inspect a successful action’s record: intent, authority, attempted parameters, target identity, and observed outcome should form an attributable chain. The resulting control is a tested operating contract, not a property of the ontology file alone.

Evidence and scope

• OWASP Authorization Cheat Sheet: Authorization must be checked on every request and enforced in a trusted component.
• W3C PROV-O: PROV-O represents entities, activities, agents, and derivation relationships.

The proposed checks are teaching tools; validate their behavior in the actual environment.