Security model

Rolebook is an embedded decision library. It evaluates supplied facts locally and returns an allow or a coded denial. It is not an identity system, a resource database, or evidence that the supplied facts are true.

Your application establishes

Before binding or checking:

• The subject’s canonical type and id, from an authenticated identity.
• Role assignments, including subject, scoped resource, and descendant applicability, loaded from an authoritative store.
• The requested resource and its ordered ancestry, loaded through an authoritative, tenant-scoped path.
• Context facts, including their freshness and whether a client may have influenced them.
• The policy version selected for the request.

A decision says only that the supplied policy and facts matched. It does not prove identity, tenancy, membership, ownership, resource existence, or freshness.

Rolebook guarantees

• A subject never carries roles. Access comes only from explicit scoped assignments.
• The whole assignment collection is validated before filtering. One malformed entry denies the binding.
• Denies are evaluated before allows across every applicable assignment.
• An unknown condition never grants an allow and conservatively matches a deny.
• Missing or malformed facts never grant access.
• A field-restricted allow cannot authorize a resource-wide request.
• Resource ancestry is validated against the policy. A right-typed ancestor id is not proof of ancestry.
• Policies are validated, canonicalized, compiled, and frozen.
• Sparse arrays, accessors, non-plain objects, cycles, unsafe keys, non-finite values, and oversized structures are rejected or fail closed. Runtime checks use captured own data properties only.
• check() never throws. A fault becomes a closed INVALID_REQUEST decision, and a reporter can observe it.
• Every decision carries a stable code and a reason.

Deliberate non-goals

Rolebook Core does not provide assignment storage, persistence, invitations, authentication connections, audit delivery, billing, telemetry, cloud services, or a user interface. If your access model is dominated by recursive sharing graphs and cross-service traversal, use a relationship-based authorization database instead.