# Pattern: Policy Decision Point / Policy Enforcement Point

Status: reviewed
Readiness target: RL3 production
Primary owners: flex-auth, NetKingdom
Genesis family: Identity and access

## Problem

Authorization becomes inconsistent when policy decisions live inside
many applications without a shared decision contract.

## Context

Use this pattern when product services, platform APIs, object-storage
brokers, admin tools, and agents need consistent allow or deny decisions
for protected resources.

## Forces

- Applications must enforce decisions at local boundaries.
- Policy needs central shape, testability, and audit.
- Tenant, resource, action, assurance, and context must be included.
- PDP outages must not become implicit allow.

## Solution

Separate policy decision from policy enforcement. flex-auth acts as the
canonical PDP boundary and may delegate to Topaz; applications and
gateways act as PEPs that enforce allow, deny, obligations, and reason
codes.

## Verification

- Decision requests include actor, tenant, resource, action, assurance,
  and context.
- PEPs deny on explicit deny, malformed decision, or PDP outage.
- Decisions produce stable reason codes and audit correlation ids.
- Policy packages are tested before production use.

## Related Patterns

- Delegated Authorization.
- Role Composition.
- Object-Level Authorization Check.
- Policy-as-Code Admission Control.