How enforcement works

Every render the platform admits starts with a resolve query — a surface (screen, vehicle, glasses, robot, satellite footprint…) asking can I show this here, now? The runtime evaluates every applicable policy in a single deterministic pass:

1. Rights lookup. Find every right that covers the substrate + location + time window in the query. Authority precedence (CIVIC > PROPERTY > TRADEMARK > CONTRACTUAL > CONQUEST) breaks ties between overlapping rights.
2. Constraint evaluation. Each right carries zero or more constraints — spatial, temporal, audience, content, territory, behavioural. They're evaluated in parallel and ANDed.
3. Consent gate. If any constraint declares CONSENT_REQUIRED, the runtime queries the consent register for an active record matching subject + purpose + substrate.
4. Decision. A structured decision is returned: either granted with the entitlement context, or denied with a typed reason code an operator can reconstruct.

The whole pass is engineered to land inside the substrate's worst-case timing budget — target p99 under 20 ms on the rights-authority hot path; total resolve-and-grant inside 50 ms. Every decision is appended to the audit chain.

The custom-rule editor in the demo compiles a small policy expression into a typed Constraint attached to one or more rights. The runtime stores the expression as canonical JSON; on every resolve call the constraint evaluator runs the expression against the live query context (time, location, audience attributes, current pacing state, content metadata).

• Authoring. Rules are versioned in the Rights registry. Editing a rule creates a new version; the runtime switches over atomically at the next resolve query.
• Predictability. Rules are pure functions of the query context — same context, same outcome, byte-for-byte. No hidden state, no race conditions across replicas.
• Audit. Every rule that triggers a denial emits a structured reason that names the rule version and the input attributes that satisfied or failed.

Exclusion zones are SpatialConstraint records with mode: deny — a polygon, circle, or bounded region with a substrate filter and an active-window. They're indexed spatially so the resolver finds intersecting zones in single-digit milliseconds.

• Resolve query includes lat/lon (and altitude where the substrate cares — drones, satellites). Any matching mode: deny zone short-circuits the response with a structured denial.
• mode: allow zones are the inverse — used to whitelist a small area inside a broader-coverage right.
• Civic exclusion zones (gambling-near-schools, alcohol-near- mosques, etc.) live at the CIVIC precedence layer and always beat operator-authored zones.

Behavioural constraints declare substrate-specific operating requirements that aren't purely about can or cannot — they govern how. Examples:

• Yield to pedestrians — emits a structured denial requiring a renderer-side acknowledgement (the renderer must report that no pedestrians intersect the surface envelope before the resolve becomes a grant).
• Require human operator — the resolve returns success but tagged with requires-supervision; the substrate's runtime policy is responsible for surfacing a human-acknowledgement step before render.
• Pre-render verification — the constraint runs as a callable check against the runtime's safety service (e.g. Remote ID lookup for drones, ground-clearance ping for robots). A failure on the check is a deterministic denial with the typed reason returned upstream.

Behavioural constraints are the single biggest reason multi- substrate operators care about the platform — every substrate has its own "don't kill anyone" vocabulary, and EnfinitOS treats them as first-class types rather than per-substrate special cases.

The consent register is an append-only ledger of consent grants and revocations. Every record has a subject reference, a purpose, an optional substrate filter, a time window, and an audit trail back to the source event (web form submit, kiosk tap-through, guardian-given consent, etc.).

• A right tagged with the CONSENT_REQUIRED behavioural rule triggers a consent lookup on every resolve query.
• Missing, expired, or revoked consent → structured denial with reason NO_ACTIVE_CONSENT (no PII in the response).
• Revocation never deletes the original grant — both events stay in the ledger. A regulator-issued DSAR can rebuild the entire consent history for any subject.

The consent-revoke control in the demo writes to in-memory state and emits a toast notification. In production it writes a ConsentRevoked event into the audit chain that forward-propagates to every connected runtime within a single replication cycle.

Rights carry constraints across six independent axes. Each is a typed vocabulary; the runtime evaluates them in parallel and ANDs the result. Adding a new axis is a small protocol-version bump; nothing in the rights themselves cares about which axes exist.

• Spatial — where the right applies (polygons, radii, substrate footprints, broadcast claims).
• Temporal — when (validity windows, dayparts, recurring schedules).
• Audience — who the resolved render targets (segments, opt-out lists, consent attributes).
• Content — what creative may be shown (taxonomy, brand-safety, regulatory restrictions).
• Territory — jurisdiction-level eligibility (country, sub-country, sanctions lists).
• Behavioural — operating-mode requirements (yield-to-pedestrians, consent-required, human-operator).

The platform is built around the observation that rights conflict in the real world. The resolver doesn't paper over conflicts; it arbitrates them deterministically and returns a typed result an auditor can reproduce.

• Precedence ladder. Overlapping rights are ranked by authority layer: CIVIC > PROPERTY > TRADEMARK > CONTRACTUAL > CONQUEST. A civic exclusion zone always beats a private-licensee right.
• Same-layer ties. Two rights at the same layer resolve to the most-recently-issued one. Issuance timestamps are signed at the source so this is reproducible.
• Constraint conflicts. Constraints within a single right cannot "cancel" each other — they're ANDed, so the most restrictive interpretation wins. Across rights, the precedence ladder still applies.
• Audit. Every arbitrated decision records the losing rights with a typed reason. A regulator can reconstruct why the resolver picked this right over that one without operator cooperation.

The demo shows rules attached to individual rights. In production rules apply at three levels — and the platform makes the level explicit so an operator knows what they're changing.

• Right-level. One rule on one right. What the demo shows.
• Right-group / experience-level. One rule applied to every right inside a named group (typically a campaign, experience, or contracted line). New rights added to the group inherit the rule.
• Tenant-level. One rule applied across the entire estate — "no gambling on any screen in our network during school hours". Tenant-level rules sit at the CONTRACTUAL precedence layer and can be overridden by CIVIC rules but not by PROPERTY-level ones.

Each level emits the same constraint payload to the runtime — the difference is purely authorship/governance, not enforcement. A rule's effective scope is part of the audit record.