← Back to catalogue
TODO

Policy Evaluation

vr.wm-xct-038 · wm-xct-038-policy-evaluation

Policy input, decision, obligations and explanation

World Models Cross-cutting context XCT.POL
Bundle → Layer → Finding → QuestionsClassifiersWhat it isWhy it existsDistinguishing featuresWhat robots and AI may and may not doMoral aspectsOwnersLinks to other meta-modelsIdentity and identifiersDirect propertiesRecognitionCapabilities and actionsHazards and failure modesStandards and interfacesContext of useSources

Bundle → Layer → Finding → Questions Filled

3 bundles · 3 layers · 6 findings · 12 questions

Inputs What was evaluated.

Request and context

The subject, action, resource and context attributes supplied.

Request attributes

Who asked to do what to which resource.

  1. Which subject, action and resource were evaluated?
  2. Which context attributes, such as time, location or purpose, were supplied?

Policy version

The policy set and version used.

  1. Which policy set and version did the evaluator apply?
  2. Was that version in force at the time of the request?
Decision What the evaluator returned.

Result and obligations

The decision with attached obligations and advice.

Decision value

Permit, deny, not applicable or indeterminate.

  1. What decision did the evaluation return?
  2. Was the result indeterminate because of missing or conflicting inputs?

Obligations

Duties the enforcing party must fulfil with the decision.

  1. Which obligations or advice were attached to the decision?
  2. Were the obligations fulfilled by the enforcing party?
Explanation and audit Why the decision came out as it did.

Explanation

The rules that matched and the combining logic.

Matched rules

The rules that determined the outcome.

  1. Which rules matched, and how were conflicts between them combined?
  2. Can the decision be explained in terms a requester can understand?

Audit record

The stored evaluation record for review.

  1. Is the evaluation recorded with time, evaluator and inputs for later audit?
  2. Can the evaluation be replayed with the same policy version and inputs?

Classifiers Filled

Family
World Models
Category
Cross-cutting context
Entry kind
pattern
Navigation path
NAV.XCT.POL
Domain
XCT.POL
Industry
Cross-industry
Tags
policyevaluationxct.pol

What it is Filled

A policy evaluation is one recorded application of a machine-evaluable policy to a concrete request or situation: the inputs supplied, the policy version used, the decision returned, the obligations attached and the explanation of why. The policy rule itself, the enforcement action taken afterwards and a human decision or approval are separate subjects.

Why it exists Filled

Policy input, decision, obligations and explanation

Distinguishing features Filled

  • One application of a policy to a case, while the policy rule itself is a separate, versioned subject.
  • Records inputs, decision, obligations and explanation together, so the outcome can be replayed and audited.
  • Precedes enforcement: the evaluator decides, an enforcement point acts.
  • Automated and rule-bound, unlike a human decision or approval.

What robots and AI may and may not do Filled

Must not

  • Act against a deny decision or skip evaluation for actions that require it.
  • Supply false or selective inputs to obtain a permit.
  • Ignore obligations attached to a permit decision.
  • Alter or delete evaluation records after the fact.
  • Evaluate against a policy version other than the one in force without recording why.

Only with a human decision

  • Overriding a deny decision in an exceptional case.
  • Resolving a policy conflict or an indeterminate result that blocks a critical action.
  • Changing the policy that was evaluated.

May

  • Request policy evaluations before acting and comply with the decision.
  • Record evaluations with inputs, policy version, decision and obligations.
  • Explain a decision by citing the matched rules.
  • Flag indeterminate results and policy conflicts for owners.

Moral aspects Filled

  • Automated policy decisions affect access to services and data, so people need explanations and a route to contest them.
  • Inputs about people, such as role or location, can encode discrimination into decisions.
  • Evaluation logs reveal behaviour and need protection and limited retention.

Who is affected

  • Requesters whose actions are allowed or denied
  • Data subjects whose data is protected by the policy
  • Policy owners and administrators
  • Auditors and regulators

Owners Filled

Steward

The owner of the policy and the evaluation service, who answers for correct and explainable decisions.

Master systems

  • Policy decision point
  • Policy administration point
  • Authorization audit log

Links to other meta-models Filled

parent

  • WM-KNW-012

What else AI and robots need to interact with it Filled

Identity and identifiers required Filled

  • Identified by a decision or evaluation identifier issued by the policy decision point, with a time stamp.
  • Linked to the policy set identifier and version and to the request identifier.

Direct properties not applicable Not applicable

Not applicable

A policy evaluation is a computed decision record, not a physical object, so it has no physical properties to measure.

Recognition optional Filled

  • Recognized by a request, a policy version, a decision value and possibly obligations and an explanation.
  • Often confused with the policy rule, with the enforcement action or with a human approval.

Capabilities and actions required Filled

  • Can return permit, deny, not applicable or indeterminate for a request.
  • Can attach obligations and advice that the enforcing party must handle.
  • Can be replayed for audit when inputs and policy versions are kept.

Hazards and failure modes required Filled

  • Unauthorized access from wrong policies or manipulated inputs.
  • Lockouts from deny decisions in critical situations.
  • Unexplainable decisions that cannot be contested.

Standards and interfaces required Filled

  • OASIS XACML 3.0 for policy evaluation requests and responses.
  • OpenID AuthZEN authorization API.
  • W3C ODRL for usage policies over content and data.

Context of use required Filled

  • Used in access control, data usage control, compliance automation and agent guardrails.
  • Automated decisions with legal or similar effects on people fall under data protection rules on automated decision-making.

Sources Filled

  1. eXtensible Access Control Markup Language (XACML) Version 3.0, OASIS
  2. NIST SP 800-162 Guide to Attribute Based Access Control (ABAC) Definition and Considerations, NIST
  3. ODRL Information Model 2.2, W3C

Open questions

  • Planned model: boundary questions, research and every section remain to be written.

Machine files

Card as JSON Specification AGENTS.md Card backlog vercy.card/1

Provenance

planned (registry candidate) · todo

Built from: models/runtime-index.json, ver-cy/world-models/card-supplements/wm-xct-038-policy-evaluation.json

Planned entry, hidden from the catalogue until researched.