PDP Deep Dive

Architecture and operations: policy hierarchy, PIPs, PEPs, budgeting lifecycle, content classification, behavior analytics, and receipts.

Policy hierarchy

• Global policies: baseline rules; backward compatible defaults.
• Domains: group related systems; define common resource types/actions; can override apps.
• Applications: app‑specific policy; allowed actions/resources, custom validation, and PIP selection; optional inheritance.

Doctrine in YAML (immutable); runtime parameters (e.g., budgets) in JSON on delegation edges. Short‑circuit by PDP_application attribute; denies override allows.

PIPs

• Membership Service (Neo4j): identities, relationships, delegations for Hybrid ReBAC.
• Analytics/Budget: daily/monthly limits; state from Kafka/Redis/ClickHouse.
• Inventory/Search: freshness, lineage; contextual attributes.

PEPs

• ARIA Shield / BFF: super PEP for users and AI agents; budget enforcement; model routing.
• MCP Gateway: controls tool access; plan discipline and schema pinning.
• IdP: issuance obligations (e.g., consent on OBO token exchange).

Budget lifecycle

1. Pre‑gate (PDP): evaluate budget against live Analytics state; may return budget_hold obligation.
2. Execute (PEP): enforce constraints (stream caps, model allow‑list).
3. Settle (PEP): reconcile actual usage; release/charge hold.

Content classification & behavior analytics

• Classification: real‑time BERT Distil; batch deep analysis (“lazy mode”).
• Behavior: UBA with PGVector; outlier detection; prompt quality scoring.

Receipts

All decisions/actions produce signed, hash‑chained receipts for tamper‑evident audit.