All collection-valued predicates reject empty operands, duplicates, and excess at publication. Policy scope is filtered through exact host-authority ceilings before applying every matched rule ceiling. Policy publication also requires and retains the opaque host capability boundary.
Phase 5 consumes exactly one validated EvaluationInput and one explicit immutable
PolicySnapshot. It emits PolicyDecision evidence. An allow outcome is not
authorization, entitlement, confirmation, or permission to execute. Phase 5 has
no I/O, clock, randomness, global engine, model judgment, cryptography, or executor.
Policy publication is an authority-sensitive host administration operation. The library validates structure but cannot authenticate its caller or policy origin.
- Policy, snapshot, rule, and decision identifiers are 1–64-byte lowercase ASCII alphanumeric/hyphen values with alphanumeric ends.
- Policy and snapshot versions are positive integer generations. Every lookup is exact; there is no latest-version operation.
- Conditions are only
all,any, and a closedPolicyPredicate. Negation, priorities, closures, strings-as-field-paths, regex, scripts, and dynamic parsing are absent. - Empty compounds and duplicate children reject. Compound children and rules are
normalized into deterministic order.
all/anyare semantically unordered. - Each predicate returns matched, not matched, or indeterminate. For both
allandany, any indeterminate child makes the complete condition indeterminate. An indeterminate condition anywhere in the evaluated policy causes global deny.
PolicyDraft is mutable value-semantic staging, not a trusted publication. Initial
publication is generation 1. A successor must use the same snapshot ID and exactly
the next generation, retain every prior policy version, retain its rule content,
and permit only active → deprecated/retired and deprecated → retired transitions.
Publication validates the complete draft before returning a snapshot. Old snapshots
remain immutable. Retired policies remain inspectable but exact lookup/evaluation
rejects them.
All rules are evaluated; there is no first match. Matched rule IDs, reasons, and obligations are sorted and deduplicated. Resolution is:
- any indeterminate condition → deny;
- any matched deny rule → deny;
- any matched confirmation rule → require confirmation;
- an eligible matched allow rule → allow;
- otherwise → deny.
Every matched non-deny rule must carry an explicit PolicyScopeConstraint.
Requested capabilities/resources are filtered through every such constraint.
The final non-deny outcome is eligible only if the exact requested set survives.
Thus multiple rules intersect; they never union permissions. Empty constraint sets
mean permit nothing. Phase 4 already bounds requested capabilities by intent and
the registered definition maximum; Phase 5 preserves those exact upper bounds.
Policy can inspect exact registered tool/snapshot/definition identity; lifecycle; risk, side-effect, and reversibility classifications; exact subject, tenant, session/delegation; assurance set membership and authentication methods; requested and intended capabilities; exact requested resources; provenance coverage/source, record trust and transformations; influence kind, count, exact boundary and boundary-local completeness; explicit evaluation time, intent/context issued-at, validity windows, and renewal generation.
Display metadata, descriptive metadata, raw proposal fields, intent display summary,
attestation payload details, evidence content, prompts/documents, canonical byte
decoding, resource ownership, semantic similarity, and arbitrary argument fields
are unavailable. Phase 5 does not introduce a PolicyFactSet. Phase 3 derives
exact resource IDs exclusively from reviewed typed resourceID nodes; Phase 5
can constrain but never add those resources.
Assurance categories are unordered and use exact set membership. hostVerified
provenance means only that the lineage record matched host evidence; it is not a
content-safety assertion. Influence completeness remains per declared boundary.
An omitted boundary cannot be inferred; this is a residual host-collector risk.
Obligations are closed inert declarations for confirmation, bounded maximum
evaluation age,
complete named influence boundary, future single-use authorization, and future
audit. They run no behavior. PolicyDecision has no public initializer and binds
its caller-supplied correlation ID, decision version, complete exact policy and
snapshot content and identity,
the complete EvaluationInput, outcome, stable reasons, matched rules, constrained
sets, and obligations. It contains no authorization, callback, endpoint, secret,
credential, signature, token, or expiry selected for authorization.
| Item | Limit |
|---|---|
| policies per snapshot | 32 |
| rules per policy | 128 |
| aggregate rules per snapshot | 512 |
| aggregate condition nodes per snapshot | 8,192 |
| nodes per rule | 64 |
| condition depth | 8 |
| children per compound | 16 |
| obligations per rule | 8 |
| unique obligations per decision | 128 |
| reasons per decision | 128 |
| matched rules | 128 |
| resources per constraint/predicate | 32 |
| capabilities per constraint/predicate | 16 |
Limits reject before publication without truncation. Phase 4's tighter actual request bounds remain in force.
Policy publication requires an exact .policyAdministrationAuthority and the
independently retained HostCapabilityBoundary. Evaluation also requires that
boundary independently and rejects an input/snapshot domain mismatch before any
rule runs. The decision retains the exact snapshot and selected policy value.
Authorization form, issuance eligibility, cryptographic authenticity, policy authenticity, trusted time, revocation, entitlement proof, replay/idempotency, atomic consumption, and executor verification remain undecided. Phase 6 must also decide whether and how inert obligations become issuance gates; Phase 5 does not claim they are satisfied.