permission · P
Subject MAY perform the action under stated authority + scope + state.
KYE™ Formal Rules Profile™ · v1.0
Formal rules for runtime authority.
Rules expressed as decision tables. Each row maps to a control. Each verdict cites the row that fired.
Formal Rules: side by side
Demo dataYou learn: How the options differ, criterion by criterion. You can: Pick a column to light it.
| P | permission | "may" |
|---|---|---|
| O | obligation | "must" |
| F | prohibition | "must not" |
| Pow | power | "has authority to" |
| Imm | immunity | "cannot be altered by" |
| Ex | exception | "displaced by, in conditions" |
How this widget is built
- Demonstrates
- Comparison
- Components
- The options this page compares
- The criteria it compares them on
- Flow
- Each criterion across the options, as the page sets it out. Architecture diagram
- Used on
- /formal-rules/: On this page, after its opening.
KYE™ Gateway™ enforces them at runtime, the Obligation Ledger™ tracks them, the Rule Prover™ checks pre-runtime consistency, and the Control Compiler™ compiles them into the canonical runtime artefacts. The specific compilation-target set, the proof construction, and the consistency-check rules are proprietary and are not disclosed in this repository.
Why a new layer
Authority is incomplete unless rights, obligations and powers are explicit.
KYE™ already records who acted, on whose behalf, under what authority, in what state, with what evidence. Formal Rules Profile™ adds the normative dimension: what may they do, what must they do, what must they not do, who may override, what evidence is required, and how conflicts are resolved.
Formal rules define the normative structure. KYE™ operationalises it at runtime.
1 · Six rule families
Every rule declares exactly one family.
permission ·
obligation · O
Subject MUST perform the required action when the trigger condition applies.
prohibition · F
Subject MUST NOT perform the prohibited action under stated conditions.
power · Pow
Subject HAS authority to create, modify, revoke, waive or override a normative state.
immunity · Imm
Subject / state CANNOT be altered by the referenced actor or rule.
exception · Ex
Rule is displaced or modified under enumerated exceptional conditions.
A seventh family meta_governance is recorded under KYEGovernanceRule and describes who may change rules, which rules dominate, and how conflicts resolve.
2 · From rule to runtime
Rule → gate → decision → obligation lifecycle.
Each formal rule compiles into one or more coordinated runtime artefacts. The Control Compiler™ emits the bindings; the Gateway™ enforces them; the Obligation Ledger™ tracks every obligation through its lifecycle.
01
Formal RuleFamily + applies-to + condition + normative effect + violation effect + evidence requirements.
02
Permission / Obligation / ProhibitionStanding rule resolved at decision time.
03
Authority Gate™Compiled as a runtime gate before high-impact action.
04
Runtime DecisionAllow / deny / prohibited / require_approval / quarantine / obligation_created.
05
Obligation Ledger™Pending → satisfied / breached / waived / expired / disputed.
06
Decision Map™Signed inputs → rules → outcome record.
07
Evidence Pack™Hash-chained into the KYE™ audit chain. The chain construction is proprietary and is not disclosed in this repository.
08
Replay / Audit / ReviewOffline-verifiable by any third party against the published JWKS.
Rule: An agent may prepare a payment but must obtain approval before execution. Runtime: agent prepares payment → obligation created → agent requests execution → KYE™ checks approval → no approval → deny + evidence pack. With approval → allow + obligation satisfied.
3 · Normative operators
Compact notation. Plain meaning.
| Operator | Family | Meaning |
|---|---|---|
P | permission | "may" |
O | obligation | "must" |
F | prohibition | "must not" |
Pow | power | "has authority to" |
Imm | immunity | "cannot be altered by" |
Ex | exception | "displaced by, in conditions" |
KYE™ does not commit to a specific deontic-logic syntax in the public surface. The operators above are the canonical product-friendly abbreviations recognised by the runtime engine.
4 · Schemas (Apache 2.0, public mirror)
Eleven normative objects. Validated in CI.
What it is. Why it matters. What to do next.
formal-rules-profile.json— profile manifestformal-rule.json— one canonical rule (any family)permission.json— standing "may"obligation.json— lifecycle "must"prohibition.json— standing "must not"power.json— create / modify / revoke / waive / overrideexception.json— rule that displaces another rulegovernance-rule.json— meta-rule on overridesrule-conflict.json— conflict + resolutionrule-proof.json— consistency proof from KYE™ Rule Prover™obligation-state.json— one state-transition record
5 · Apps that compose this profile
Five planned apps. Contracts open; engines paid.
What it is. Why it matters. What to do next.
KYE™ Rights & Obligations Engine™
Runtime engine evaluating permissions, obligations, prohibitions, powers, exceptions and governance rules.
KYE™ Obligation Ledger™
Append-only ledger of every obligation lifecycle, hash-chained into the audit ledger.
KYE™ Rule Prover™
Pre-runtime consistency check over the formal-rule binding. The specific soundness-property set and conflict-resolution strategy are proprietary and are not disclosed in this repository.
KYE™ Control Compiler™
Compiles formal rules into the canonical runtime artefacts. The compilation-target set and the compilation-seal construction are proprietary and are not disclosed in this repository.
KYE™ Contract-to-Authority Mapper™
Phase-2 — extracts permissions, obligations, prohibitions and powers from contracts, policies and mandates.
6 · Open / paid boundary
The contracts are open. The reasoning engine is paid.
One sentence: a signed, replayable proof of decision.
Open source
Open
- Formal Rules Profile™ schema
- 11 object schemas (rule, permission, obligation, prohibition, power, exception, governance, conflict, proof, state)
- Normative operator dictionary (
P,O,F,Pow,Imm,Ex) - Reason-code dictionary (33 codes)
- Signal Bus™ event names
- Sample rules · sample proofs · sample obligation ledger
- Basic conformance fixtures · basic validator SDK
- JSON-LD mappings to KYE™ Ontology Profile™
Commercial track
Paid
- KYE™ Rights & Obligations Engine™
- KYE™ Obligation Ledger™ Pro
- KYE™ Rule Prover™
- KYE™ Control Compiler™
- KYE™ Contract-to-Authority Mapper™
- Cross-profile rule reconciliation
- Sector rule packs (defence, public-sector, payments, health)
- BYOC / on-prem rule runtime
Where to go next
Adjacent reading.
What it is. Why it matters. What to do next.
Ready to see your AI agents flagged?
Start in shadow mode. We’ll deliver your first Evidence Pack™ in 4–8 weeks.
Canonical KYE™ surfaces referenced on this page: Evidence Pack™ · KYE Protocol™.