Prohibition Graph

Each directed edge in a prohibition graph encodes a deontic modality of prohibition—the edge originates from the constrained actor and points to the forbidden action or target. This is distinct from obligation graphs, where edges represent mandatory duties. The edge label typically includes the prohibited action type, the statutory authority imposing the prohibition, and any conditional predicates that trigger it. For example, an edge from Corporation_X to Discharge_Pollutant_Y might carry the label prohibited_by §301(a) Clean Water Act if navigable_waters = true.

Nodes in a prohibition graph are not limited to natural persons. The typology includes:

• Natural Persons: Individual human actors subject to legal constraints.
• Legal Persons: Corporations, LLCs, partnerships, and other juridical entities.
• State Actors: Government agencies, officials, and regulatory bodies that may be prohibited from exceeding statutory authority.
• Abstract Role-Holders: Nodes representing roles like 'the Administrator' or 'the Licensee,' which are resolved to concrete entities through legal entity normalization.
• Object Nodes: In some schemas, the prohibited action's target (e.g., a protected class, a restricted substance) is modeled as a node receiving the edge.

Prohibitions in law are rarely absolute; they are typically contingent on factual predicates. A prohibition graph models this by attaching conditional logic to edges. These predicates are structured as key-value pairs or logical expressions that must evaluate to true for the prohibition to be active. For instance, a prohibition on selling alcohol is conditioned on buyer_age < 21. This allows the graph to support rule-to-fact binding, where a case's specific facts are checked against edge predicates to determine if a prohibition applies. The predicates are often stored as metadata on the edge using a formal representation like deontic logic operators.

Legal prohibitions have lifecycles. A robust prohibition graph incorporates temporal regulatory logic by attaching effective dates, sunset provisions, and amendment histories to each edge. An edge is only considered 'active' for reasoning purposes if the case's temporal context falls within its validity window. This requires integration with statutory amendment tracking systems. For example, a prohibition edge representing a since-repealed statute would be marked with an invalidated_on timestamp, ensuring that the graph can reconstruct the legal landscape as it existed at any historical point in time for accurate precedent analysis.

A prohibition graph gains its full analytical power when combined with an obligation graph and a permission graph. Normative conflict detection algorithms traverse these graphs simultaneously to identify logical contradictions. A classic conflict arises when a single actor has an obligation edge to perform action X and a prohibition edge forbidding action X. Resolving such conflicts requires consulting statutory hierarchy modeling (e.g., a constitutional permission overrides a statutory prohibition) or applying canons of construction like the principle that a specific provision controls over a general one.

Statutory schemes often contain complex exception handling logic—general prohibitions followed by enumerated exemptions. In a prohibition graph, this is modeled by attaching exception subgraphs to prohibition edges. An exception subgraph contains its own nodes and conditional edges that, if satisfied, deactivate the parent prohibition. For example, a prohibition on data sharing might have an exception subgraph for 'consent obtained' or 'law enforcement request with valid warrant.' This nested structure allows the graph to accurately represent the intricate conditional branching logic found in regulations like GDPR or HIPAA.

The foundational branch of modal logic that formalizes normative concepts. It provides the mathematical operators for obligation (O), permission (P), and prohibition (F). A Prohibition Graph is a computational instantiation of deontic logic, where the F(p) operator is visually encoded as a directed edge from an actor to a forbidden action. Key axioms include the interdefinability of operators: F(p) ≡ O(¬p), meaning a prohibition is logically equivalent to an obligation not to act.

The complementary structure to a Prohibition Graph. While a prohibition graph models forbidden actions, an obligation graph models mandatory duties. Together, they form a complete deontic knowledge graph. In legal reasoning, an action that is not explicitly obligatory may still be prohibited, and vice versa. The two graphs must be queried jointly to determine the full normative status of an action for a given actor.

The algorithmic process of identifying contradictory deontic statements within a body of law. A conflict arises when a Prohibition Graph and an Obligation Graph contain contradictory edges for the same actor-action pair—e.g., an action is simultaneously classified as prohibited and obligatory. Resolution strategies include lex superior (hierarchical precedence), lex specialis (specificity), and lex posterior (temporal recency).

The formal modeling of statutory carve-outs that override a general prohibition. In a Prohibition Graph, exceptions are modeled as conditional edge removals or negation predicates attached to prohibition edges. For example, a general prohibition on data sharing may have an exception edge activated by the predicate hasConsent == true. Accurate exception modeling is critical for compliance checking systems.

The upstream NLP task that populates a Prohibition Graph. It involves automatically identifying IF-THEN prohibition rules from unstructured statutory text. Key subtasks include:

• Actor identification: Who is the subject of the prohibition?
• Action extraction: What specific conduct is forbidden?
• Condition parsing: Under what circumstances does the prohibition apply? The extracted triples form the edges of the graph.

The computational mechanism that instantiates an abstract prohibition against a concrete factual scenario. The Prohibition Graph stores the general rule (Actor A is prohibited from Action X under Condition C). Rule-to-fact binding evaluates whether a specific set of case facts satisfies Condition C, and if so, triggers the prohibition. This binding process is the core inference step in automated compliance engines.