A policy bundle is a reviewed, tested, signed, and versioned package of authorization policies prepared for runtime evaluation. It separates human-facing authoring from machine-facing enforcement: repositories hold policy files, schemas, tests, documentation, history, and approvals; policy stores hold deployable bundles and support reliable decisions, auditability, and rollback. section 10.2 section 10.2.2
A controlled policy-bundle workflow typically includes:
- Author policies in a repository and review changes through pull requests, with business-level scrutiny of intent and scope. section 10.2 section 10.2.2
- Validate policies by compiling, type-checking against a shared schema, and testing representative scenarios before publication. section 10.5 section 13.5.8
- Build a signed, versioned bundle and promote it to the appropriate policy store or tenant policy decision point. section 10.2 section 13.5.8
- Observe decisions, trace runtime behavior to exact policy versions, stage deployments where needed, and republish a previous bundle to recover from faulty changes. section 10.2.3 section 13.5.8
Tenant-scoped deployment
A shared policy decision point can run the same collaboration policies for many tenants while loading the requesting tenant’s relationship graph, configuration, and policy bundle. Dedicated instances can instead support regulated tenants that need stronger isolation, staged rollout, or private deployment. section 13.4.2 section 13.3.1
decision_id=7b3f… result=DENY reason=principal not in Project::"alpha".members for Action::"doc:edit" on Document::"alpha/roadmap.md"
A decision log connects a denied request to its result, reason, action, resource, and evaluated policy context. section 10.2.3
