Legal Obligation-Permission Matrix¶
Document — instantiates Necessity-Possibility-Contingency Framing
A document that maps required, permitted, prohibited, optional, and conditional actions under a rule or jurisdiction.
Legal Obligation-Permission Matrix is a controlled document that takes the actions a rule governs and assigns each a deontic status — obligatory, permitted, prohibited, optional — together with the conditions and exceptions under which that status holds. Its defining move is keeping permission and obligation strictly apart: an action you may do is not an action you must do, and the archetype's cardinal sin is collapsing the two. Where a claim ledger handles alethic and epistemic force (necessary, possible, likely), this document handles normative force — what a duty-bearer is required, allowed, or forbidden to do — and it exists so that a compliance reader never has to guess whether a "can" was a permission or a command.
Example¶
A company rolling out a new analytics feature needs to know what it may and must do with EU customer data. Counsel builds a Legal Obligation-Permission Matrix over the relevant data-protection rule. Each processing action becomes a row with a deontic status and its conditions: obtain a lawful basis before processing (obligatory, always), process for the stated purpose (permitted, conditional on that basis), reuse the data for a new purpose (prohibited unless compatible or newly consented), appoint a data-protection officer (obligatory only if the processing crosses a scale threshold — otherwise optional), honor an erasure request (obligatory, with named exceptions for legal-hold data).
Building the matrix catches a live error: the product team had read "you may process for legitimate interests" as blanket permission to reuse data for model training. The matrix's exception column shows that permission is conditional and does not extend to an incompatible new purpose — a permission the team had silently upgraded to a license. The corrected row routes the training use to a separate lawful-basis check before any code ships.
How it works¶
Rows are governed actions; columns are the deontic status, the conditions under which it holds, the exceptions and derogations that suspend it, and the concrete compliance step it translates into. The distinguishing discipline is the deontic taxonomy — obligatory, permitted, prohibited, optional, conditional — applied so that no action carries two statuses without an explicit condition separating them, and so that "permitted" never silently becomes "required" or "encouraged." The document maps duties and translates them into steps; it does not build hypothetical case comparisons or grade its own confidence, which are other mechanisms' jobs.
Tuning parameters¶
- Deontic granularity — the base four statuses versus finer distinctions (conditionally permitted, permitted-but-discouraged, obligatory-on-request). Finer captures real legal texture but bloats the document.
- Jurisdiction scoping — one matrix per jurisdiction versus a merged multi-jurisdiction grid with a status per column. Merged grids expose conflicts of law but grow unwieldy.
- Exception depth — how far to enumerate derogations, carve-outs, and thresholds before a status is treated as clean.
- Translation concreteness — whether each row lands on an abstract duty or a specific operational step someone owns.
- Update trigger — what changes (a new ruling, a threshold crossed, a new processing purpose) forces a row re-review.
When it helps, and when it misleads¶
Its strength is holding the obligation/permission line that natural-language policy constantly blurs — the deontic square's insistence that permitted and obligatory are different operators, not points on one scale.[n1] A team reading from the matrix cannot mistake a right for a requirement or a permission for a mandate, which is the single most common compliance error.
Its failure mode is false determinacy: a filled status cell can look like settled law when it encodes a contested interpretation, and a matrix that omits its uncertainty invites a reader to act on a lawyer's judgment call as if it were black-letter. It is also only as current as its last review — a status valid under one ruling can silently expire. The classic misuse is the matrix built once and cited for years, its exceptions column quietly out of date. The guarding discipline is to date every row, flag interpretive rows as such rather than pretending certainty, and re-review on the stated triggers.
How it implements the components¶
modal_status_taxonomy— supplies the deontic vocabulary (obligatory / permitted / prohibited / optional / conditional) every row is classified against, keeping permission distinct from obligation.decision_translation_rule— each row's translation column turns a deontic status into the concrete compliance step a duty-bearer must take.condition_and_exception_register— the conditions and exceptions columns record the derogations, thresholds, and carve-outs under which a status holds or lifts.
It does not build comparative case sets or trace assumption dependencies — possible_world_or_case_set and contingency_dependency_map are Possible-World Case Matrix's; and it does not tag its own classifications with a confidence grade — modal_confidence_marker belongs to Modal Claim Table, its nearest sibling, which handles alethic/epistemic force where this document handles normative force.
Related¶
- Instantiates: Necessity-Possibility-Contingency Framing — the matrix pins the deontic status of each governed action and its conditions.
- Sibling mechanisms: Modal Claim Table · Possible-World Case Matrix · Counterfactual Minimal-Change Checklist · Assumption Lock-and-Relax Workshop · Necessity-Possibility Red Team · Design Constraint-Relaxation Table · Modal Language Review Protocol
Editorial Notes¶
Form Classification¶
Form family: Representation, Specification & Plan
Rationale: Legal Obligation-Permission Matrix operates as a non-executable information artifact that externalizes static or prospective structure because it a document that maps required, permitted, prohibited, optional, and conditional actions under a rule or jurisdiction
Independent corroboration: The frozen evidence defines Legal Obligation-Permission Matrix as 'A document that maps required, permitted, prohibited, optional, and conditional actions under a rule or jurisdiction', so its operative form is Representation, Specification & Plan.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Law & Governance
Origin pattern: Cross-disciplinary synthesis
Present-day reach: Specialized
Rationale: Legal drafting and compliance developed matrices of required, permitted, prohibited, optional, and conditional actions.
Related originating lineages:
- Computer Science & Software Engineering — Policy-as-code and access-control systems materially shaped executable rule matrices.
- Philosophy — Deontic logic supplied formal distinctions among obligation, permission, and prohibition.
Review resolution: Both independent reviews place the primary lineage in law_governance. The queued differences (alternate_origin_disagreement, encyclopedia_synthesis_disagreement) concern secondary metadata rather than primary provenance. The final retains computer_science, philosophy only where a reviewer supplied a formative-lineage rationale; downstream application by itself is not treated as origin. origin_mode=cross_disciplinary_synthesis records the relationship among origin traditions, while domain_reach=specialized records application breadth separately. encyclopedia_synthesis=true reflects whether either reviewer identified a corpus-specific synthesis, and confidence=high preserves the more cautious evidence assessment.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
[n1] Deontic logic formalizes normative modality with distinct operators for obligation, permission, and prohibition, arranged in a "deontic square" that keeps obligatory and permitted logically separate — permission is entailed by obligation but never the reverse. That non-equivalence is exactly the line this matrix is built to hold. ↩