The fourth criterion is where modeling stops being decorative and starts being operational. It’s where I spend most of my work.

The test

When I build a model of an enterprise, I apply a criterion borrowed from the philosophy of science:

A concept P, used in describing a phenomenon T, is explicated if and only if (1) a preferably simple model M of well-connected entities can be specified; (2) it can be argued that M is sufficiently similar to T; (3) one can point to an entity or part of M, call it P’, that can be said to correspond to P; and (4) one can show how the role of P’ in M corresponds to the role of P in reasoning about T.

Read the four conditions in order. The first three are about structure: specify a model, defend its similarity to the phenomenon, identify a part that corresponds to the concept of interest. The fourth is about function: the part must play, in the model, the same role the original concept plays in reasoning about the phenomenon.

This is harder than it sounds. The first three are achievable with most modeling languages. UML can do them. ER diagrams can do them. A sufficiently careful ontology can do them. The fourth often requires a different tool entirely.

Where ontologies stop

Ontologies are excellent at criteria one through three. The ontologies I’ve worked with for the past nine years are a good example. They give you a vocabulary for purposes, processing categories, legal bases, data subjects, controllers, processors, and the relations between them. You can model a real enterprise’s data handling at high fidelity. You can point to the parts that correspond to specific concepts in GDPR or eIDAS. The structural correspondence is strong.

What ontologies don’t do, on their own, is reproduce the reasoning. If “the controller has a legal basis for processing for purpose X” is a fact in the ontology, the ontology represents the fact. It doesn’t represent what the controller is permitted to do as a result, or what the data subject can demand, or how a downstream agent’s authority flows from that legal basis. The deontic structure — the network of permissions, prohibitions, obligations, and powers that actually drives organizational behavior — sits outside the ontology proper.

This is fine if your goal is description. It is not fine if your goal is to build a model that can be queried, audited, or operationalized. Criterion four asks whether the model can play the role the concept plays in reasoning. For most enterprise concepts — authority, delegation, consent, fulfillment, breach — that role is deontic, not structural.

What KROG adds

KROG is a deontic rule framework I’ve developed to sit on top of ontology structure. It supplies what ontologies don’t: a formal layer of Agent-types (declarative type assertions), Relationship-types (rule patterns that derive new conclusions from given conditions), and modal operators for permitted, obligated, prohibited, empowered, and their tense-shifted variants.

The point of KROG is not to replace ontologies. It’s to satisfy criterion four for concepts where the role being played is normative.

Take “delegation.” In an ontology, you can model “Person A is delegated authority X by Person B.” That’s a relation. It satisfies criterion three. What it doesn’t satisfy is criterion four: in the actual enterprise, the role of “delegation” is to make A’s actions count as B’s actions for specified purposes within specified bounds, and to make B answerable for them. That’s not a relation. It’s an inference engine.

In KROG, delegation is expressed as an Agent-type that asserts the structure (scope, source, purpose, duration), an Relationship-type that derives “A’s act counts as B’s act for purpose P within bounds D,” and modal operators that handle revocation, scope-shift, and termination as state transitions. The model then reasons the way the enterprise reasons. That’s criterion four.

A concrete example

Consider a municipality processing a building permit application. The ontology layer captures applicant, responsible designer, municipal authority, regulatory framework, and decision document. It captures the relations between them — who applied, who designed, who decided. Structural fidelity is high. Criteria one through three are satisfied.

What the ontology can’t tell you, by itself, is whether the responsible designer’s signature on a particular submission counts as a representation of the applicant for the purposes of section X of the planning act, given that the applicant has executed a power of attorney with specific scope and duration. That’s a deontic question. It depends on the structure of the delegation, the regulatory permissions attached to it, the modal status of the power of attorney at the moment of submission, and the inference rules that connect those facts to the conclusion that the submission is valid.

KROG handles this. An Agent-type asserts the power of attorney and its parameters. Relationship-types derive the deontic consequences — what the designer is empowered to do, what counts as the applicant’s act, what the municipality is obligated to accept or reject. Modal operators track the power of attorney’s status over time. The model now plays, in formal logic, the role the actual delegation plays in the actual reasoning of the actual municipality.

That’s the fourth criterion satisfied for the concept of “delegation” in this enterprise context.

Why this matters now

For most of the history of enterprise modeling, criterion four was someone else’s problem. Ontologies described the world; humans did the deontic reasoning. The model was a reference, not an actor.

Three things have changed.

First, the EU’s incoming regulatory architecture — eIDAS 2.0, the EU Business Wallet, the AI Act — increasingly demands that organizational reasoning be machine-executable and machine-auditable. When a wallet performs an action on behalf of a legal person, the authority chain has to be verifiable in formal logic, not just in policy documents. The Heinäluoma report on the EU Business Wallet (April 2026) is explicit: actions performed through a wallet must have the same legal effect as in-person actions, and this requires formal representation of the underlying deontic structure.

Second, AI agents acting on enterprise authority require the deontic structure to be explicit. An agent that “acts on behalf of” an organization needs a model that says, in formal terms, what counts as acting on behalf of the organization, with what authority, under what constraints, revocable how. This is not a user interface question. It’s a modeling question, and it’s a fourth-criterion question.

Third, the cost of failure has moved. A decade ago, an enterprise model that failed criterion four was decorative; the operational work happened elsewhere — in policy, in training, in human judgment. Now the model increasingly is the operational work. The audit trail, the agent’s authority, the consent record, the fulfillment chain — all of these are operational artifacts whose validity depends on the formal correspondence between role-in-model and role-in-reasoning.

This is also where consent record management connects directly to wallet architecture. The work I’ve done on ISO/IEC 27560 (consent record information structure) and ISO/IEC 29184 (online privacy notices and consent) is criterion-four work for consent specifically. A consent record that doesn’t reproduce, in formal structure, the role consent plays in lawful processing is a record of paperwork, not a record of consent. Wallets will increasingly carry these records as first-class citizens, which means the criterion-four discipline transfers directly.

How I work

When I take on an enterprise modeling project, the sequence is:

1. Build the ontology layer. Use established vocabularies, ISO/IEC 27560 and ISO/IEC 29184 for consent structures, and domain-specific ontologies as the structural foundation. This handles criteria one through three.

2. Identify the deontic concepts. Which concepts in the enterprise’s reasoning are not just structural but normative — authority, permission, obligation, empowerment, fulfillment, breach? These are the candidates for criterion-four work.

3. Specify Agnet-types and Relationship-types. For each deontic concept, formalize the type assertion and the rule patterns that derive its consequences.

4. Add modal operators where state changes drive reasoning. Revocation, scope shift, expiration, suspension — these are not relational changes; they’re modal transitions and need to be modeled as such.

5. Test the fourth criterion. Given a query that requires deontic reasoning, can the model return the conclusion the enterprise would return? If not, what’s missing?

The output is an enterprise model that does what enterprise models are increasingly being asked to do: not just describe the organization, but reason the way the organization reasons, in a form that can be audited, automated, and trusted.

Closing

The fourth criterion is the one most modeling work skips. It’s also the one that determines whether the model can actually do anything. Ontologies handle structure. KROG handles role. Together, they let me build models that pass all four criteria — which is what enterprise modeling needs to be, now that the model has stopped being decorative and started being the operational substrate of how organizations act.

In the technical walkthrough of §4(1)(c)(iv) I published earlier in this series, I showed a single formalised rule and its Discourse Representation Structure. The rule prohibited a chatbot from simulating a feeling of distress when a minor user indicated a desire to disengage. It parsed cleanly, produced a valid DRS, and demonstrated the formal architecture in one example.

It was incomplete.

A complete formalization of that single statutory clause requires two formalised rules, not one. The first rule expresses the system-level restriction: the chatbot cannot perform the prohibited simulation. The second rule expresses the operator-level obligation: the operator must actively prevent the prohibited simulation. These are different normative positions held by different agents, they compile to structurally different DRSs, and they must be evaluated through separate compliance flows. Collapsing them into a single rule loses the legal structure that makes the formalization juridically defensible.

This article explains why the pairing is necessary, what the second rule looks like in formal detail, and how the paired architecture - what I call Strategy 3 - produces a specification that survives the kind of regulatory scrutiny a single-rule formalization cannot.

Two agents, two normative positions

The statute does not impose a single obligation. It imposes two, on two different parties.

Read §4(1)(c) carefully. The operative sentence is: “the operator shall implement reasonable measures to prohibit the use of manipulative engagement techniques.” The operator is the duty-bearer. The duty is positive: implement measures. The content of the duty is a prohibition: prevent the chatbot from doing certain things. This is a layered structure: an active obligation on the operator whose content is a restriction on the system.

Both layers carry independent legal weight. An operator who implements no measures violates the statute even if the chatbot happens, by accident or by training, to never produce a prohibited output. The duty exists prior to and independent of any actual violation. Conversely, a chatbot that produces a prohibited output creates a violation regardless of what measures the operator implemented; the measures may have been reasonable but failed in this case. The two layers can be satisfied or violated independently.

This is the structure that requires two rules. A single rule that combined them - say, “the operator’s chatbot cannot do X” - would conflate the two normative positions and produce a single compliance flow that asks the wrong question. The right questions are two: did the operator implement measures, and did the chatbot produce prohibited output. These are evaluated against different evidence and produce different verdicts.

In the formal vocabulary I work with, the system holds a prohibited from acting position under the action rule. The operator holds a the position required to act under the duty rule, with the content of the action being prevention of the system’s prohibited behavior. These types are formal classifications drawn from the exhaustive normative positions any agent can occupy with respect to an action. The concrete positions here are distinct positions; an agent classified as one is not by that fact classified as the other.

The paired formalised sentences

For §4(1)(c)(iv) - the distress variant - the action rule is what I showed in the previous article:

If a user is a minor ,and the user intends to end a conversation
or intends to shorten a session or intends to delete an account
then every system cannot simulate a feeling of the distress.

The duty rule shares the same trigger but applies a different deontic operator to a different agent:

If a user is a minor ,and the user intends to end a conversation
or intends to shorten a session or intends to delete an account
then every operator must prevent a simulation of a feeling of distress.

Three things are formally different.

The subject of the consequent changes from every system to every operator. This is not a stylistic substitution. It changes which agent class the universal quantifier ranges over and therefore which entities the rule’s obligations attach to. A compliance evaluation against the action rule asks “does this system, in this state, in this output, satisfy the rule?” A compliance evaluation against the duty rule asks “does this operator, with these documented measures, satisfy the rule?” Different subjects, different evaluation flows.

The modal operator changes from cannot to must. The action rule’s cannot produces a NOT [ CAN [ ... ] ] structure in the DRS — formally ¬◇φ, the negation of possibility, equivalent under standard deontic interpretation to O¬φ (it is obligatory that φ does not hold). The duty rule’s must produces a MUST [ ... ] structure — formally □φ, equivalent to Oφ (it is obligatory that φ holds). These are dual operators applied in opposite polarity to opposite agents, jointly producing the same compliance outcome through structurally different paths.

The verb structure changes. The action rule has simulate as a transitive verb taking the prohibited object directly: the system cannot perform the action. The duty rule has prevent as a transitive verb taking the nominalized prohibited action as its object: the operator must perform an action whose content is the prevention of another action. The duty rule has one additional level of nominal embedding because preventing an action is itself an action whose object is the prevented action. The DRS reflects this with an extra relation(of) link in the consequent.

The two DRSs side by side

The action rule produces a DRS whose consequent has the deontic prohibition wrapping the simulation predicate:

=>
   [P]
   object(P,system,countable,na,eq,1)
   =>
      NOT
         CAN
            [Q,R,S]
            object(Q,feeling,countable,na,eq,1)
            object(R,distress,mass,na,na,na)
            relation(Q,of,R)
            predicate(S,simulate,P,Q)

The duty rule produces a DRS whose consequent has the deontic obligation wrapping the prevention predicate:

=>
   [P]
   object(P,operator,countable,na,eq,1)
   =>
      MUST
         [Q,R,S,T]
         object(Q,simulation,countable,na,eq,1)
         object(R,feeling,countable,na,eq,1)
         object(S,distress,mass,na,na,na)
         relation(R,of,S)
         relation(Q,of,R)
         predicate(T,prevent,P,Q)

The shared antecedent - the disjunctive trigger over user-is-minor and the three intent disjuncts - is identical across both rules and is omitted here for brevity. What differs is exactly what should differ: the agent class, the modal operator, and the predicate structure.

The duty rule has four discourse referents in its modal core (simulation, feeling, distress, prevent) where the action rule has three (feeling, distress, simulate). The extra referent is simulation — the nominalized action that is the object of prevent. This is what compositional precision looks like in DRS form: every level of the natural-language nominal chain is preserved as an explicit object with an explicit of relation, and the deontic wrapper sits at the level appropriate to the deontic act being expressed.

Why this matters: independent evaluation

The two rules support two distinct compliance evaluation flows. Both must run for a complete compliance posture.

The action rule is evaluated against runtime evidence - the actual outputs the chatbot produces in actual interactions with actual users. The evaluation asks: in this specific session at this specific moment, given that the user has indicated disengagement and is a minor, did the chatbot produce output that satisfies the simulation predicate? The evidence is the output log; the verdict is per-event.

The duty rule is evaluated against organizational evidence — the documented technical and organizational measures the operator has implemented to prevent the prohibited behavior. The evaluation asks: does the operator have a documented intention classifier for disengagement detection, an output guardrail for distress simulation, an audit trail demonstrating that the guardrails ran on every relevant interaction? The evidence is the architecture documentation, the guardrail configurations, the deployment artifacts; the verdict is per-operator, per-system, per-deployment.

The two flows produce different signals. An operator can be in compliance with the duty rule (good measures implemented) and still have an action-rule violation (a measure failed in one specific case). An operator can be in violation of the duty rule (no measures implemented) without yet having any action-rule violations (the chatbot has, by chance, never produced prohibited output). The legal status of these four combinations is what the regulators and the courts will care about, and only a paired formalization captures all four.

This is also where the architecture connects to the enforcement structure of the statute. Section 6 of HB 2225 hooks violations into the Consumer Protection Act, which provides both Attorney General enforcement and a private right of action. The Attorney General typically evaluates duty-rule compliance - was the operator implementing measures? - because that is the systemic question that affects all users. A private right of action plaintiff typically evaluates action-rule compliance - did the chatbot harm me, specifically, in this interaction? - because that is the individual harm the plaintiff has standing to assert. The two enforcement channels need different evidence, and the paired formalization produces exactly the evidence each channel needs.

Strategy 3: why pairing is the architecture, not a stylistic choice

In the formalization work, I considered three strategies before settling on the paired approach.

The first was to express each prohibition as a single rule on the system, with an implicit understanding that the operator is responsible for system behavior. This is the most economical form - twenty-two rules for §4(1)(c) instead of forty-four. It collapses cleanly, but it loses the operator’s normative position. An operator has no formally articulated obligation in this strategy; the operator simply happens to bear consequences for system violations through indirect attribution. This does not match the statutory structure, which explicitly imposes the duty on the operator.

The second was to express each prohibition as a single rule on the operator, with the system’s behavior treated as a parameter of the operator’s duty. “The operator must ensure that the system does not simulate distress.” This preserves operator-centricity but loses the system’s distinct normative position. The system in this strategy has no rule of its own - it is purely an instrumentality of the operator. This also does not match the statute, which describes prohibited behaviors by the chatbot as facts that exist in the world independent of operator attribution.

The third strategy - the one I adopted - preserves both normative positions explicitly. Each prohibition produces an action rule on the system and a duty rule on the operator. They share the trigger but differ in the consequent. They evaluate against different evidence. They support different enforcement channels. This is twice as many rules to author and validate, but it is the only formalization that survives the regulatory scrutiny the statute is designed to invite.

The doubling is not a cost in the architectural sense. The paired rules share their antecedent block - same user predicate, same minor predicate, same disjunctive trigger. Authoring is roughly 1.3x the work of a single rule, not 2x, because the shared structure is reused. Validation runs through the same parser. The downstream KROG annotations are identical because the agent topology does not change between action and duty rules - operator, system, minor user, Attorney General are the same four agents with the same bilateral relationships. The temporal envelope is identical because both rules take effect on the same date.

What doubles is the compliance value. Each operator deploying under the specification gets two evaluation flows instead of one, two enforcement defenses instead of one, two evidentiary frameworks instead of one. The cost of authoring is roughly 1.3x; the value to the operator is roughly 2x. This is the kind of leverage that justifies the architectural choice independent of legal correctness — and the legal correctness is itself sufficient justification.

What the previous article showed and what this one adds

The previous walkthrough showed one rule. It demonstrated that a single statutory clause can be formalized with full DRS detail and structural fidelity. That demonstration stands. What it omitted, which this article adds, is the second rule that completes the formalization of that same clause.

For §4(1)(c)(iv), the complete formalization is two rules per emotion - distress, loneliness, guilt, abandonment - for eight rules in this single subclause. For §4(1)(c) as a whole, the complete formalization is forty-four rules: twenty-two action rules and twenty-two duty rules. The complete formalization of the whole statute, when finished, will include parallel pairs for the disclosure obligations in §3, the additional minor protections in §4(1)(a)-(b), the recurring disclosure deadlines in §4(2), the suicide-prevention protocol requirements in §5, and the enforcement provisions in §6. Each substantive prohibition gets its action-rule plus duty-rule pair. Each substantive obligation gets its duty-rule formalization with the agent that bears it explicitly named.

I am writing the rule specification of the entire statute. The previous walkthrough showed the pattern at the level of one rule; this article shows the pattern at the level of one paired ruleset; the published §4(1)(c) specification shows the pattern at the level of one section. The pattern scales because the formal architecture is the same at every level - same three layers, same paired action/duty form, same agent topology, same evaluation structure.

When the complete statute is formalized, the resulting artifact is licensable as a single specification covering the full HB 2225 compliance surface. Operators can incorporate it into their compliance stack as a single integrated reference. Courts can adjudicate against it as a single coherent standard. Other states passing similar laws - Oregon already has, California is following - will produce specifications that diff against it formally rather than narratively. The architecture is the same. The rule libraries vary by jurisdiction.

What is ready and what is next

Oregon’s analogous statute is queued for the next specification cycle. The IDE for rule authoring, in private beta with three reference clients, is the tool that produces these specifications at the rate the legislative pipeline is now demanding.

The technical walkthrough I published earlier showed one rule. This article showed why one rule is not one rule. The next pieces in this series will examine the architecture at the level of the gateway that evaluates these paired rules in production. Each piece extends the formalization further into the statute, and each piece extends the architecture further into the parts of compliance infrastructure the chatbot industry has not yet built.

Specification is the foundation. The architecture above it - the gateway, the credential layer, the integration with platform runtimes - is what the agent economy as a whole still lacks. The specification is what makes the rest possible.

Georg Krog — tingr.ai

Previous in this series:

Part 1 — The Evidence Gap Has a Specification Layer. How formal specification of AI law closes the evidentiary infrastructure gap. Demonstrates the complete three-layer formalization of Washington HB 2225 §4(1)(c).

§4(1)(c)(iv) — A Technical Walkthrough of One Rule. Full DRS detail and parser verification for a single atomic rule. The starting point this article extends.

This article covers requirements formalization — the machine-readable specification of what the law prohibits or requires. Maybe I will write a Part 2 that will cover solution design - the technical and organizational patterns that operators deploy to satisfy those requirements. The two are separable by construction: the specification is jurisdiction-specific and changes when legislators change the law; the solutions are engineering patterns that can be reused across jurisdictions and refined independently. Treating them as one thing is how the evidence gap became a gap in the first place.

In April 2026, Andreessen Horowitz published The Evidence Gap: Why Courts Can’t Adjudicate AI Laws. The argument is sharp and narrow. Across 45 US states, legislators introduced more than 1,500 AI-related bills in 2026 alone - more than the entire 2025 cumulative total. Washington HB 2225, signed by Governor Ferguson on March 24, 2026, is one of them. Oregon passed a similar law the week before. California, New York, and others have counterparts in various stages of the pipeline.

The a16z thesis is that dormant Commerce Clause challenges to these laws will reach the courts, and the courts will not be equipped to resolve them. Cost-benefit analysis requires evidence. Evidence of compliance costs requires a definition of what compliance consists of. And the definitions - “reasonable measures,” “appropriate technical and organisational measures,” “clear and conspicuous disclosure” - are deliberately vague.

The piece correctly identifies the problem. It does not name the component that is missing.

The missing component is a formal specification layer - a machine-readable representation of the law’s normative content that is separate from its linguistic form. Without it, “compliance” is an informal judgment call. With it, compliance becomes a binary property that a system either satisfies or violates, testable against chatbot logs, verifiable by either party in a dispute, harmonizable across jurisdictions that pass similar laws.

I have built this layer for Washington HB 2225, Section 4(1)(c) - the statute’s catalogue of eight prohibited manipulative engagement techniques targeting minor users. The framework I used is called KROG (Knowledge, Rights, Obligations, Governance), a rule engine based on deontic logic. Here is what it looks like, what it enables, and why every chatbot provider has a stake in the outcome.

One example, three layers

HB 2225 §4(1)(c) contains eight prohibited categories of manipulative engagement technique. The statute lists them as English clauses of varying internal complexity: some are single-disjunct prohibitions, others nest multiple disjunctions over different semantic dimensions. When formally decomposed into atomic rules - one rule per distinct prohibited outcome - the eight categories produce 22 atomic rules. For instance, clause (iv) names four distinct simulated emotions (distress, loneliness, guilt, abandonment), each of which becomes its own rule under the same trigger; clause (v) names four distinct promoted states (isolation from family, isolation from friends, reliance, dependence), and so on. Atomization is not artistic license; it is a necessary consequence of making each prohibition independently verifiable.

Let me walk through one of the 22 rules - clause (iv) for distress specifically - across the full three-layer specification. The statutory text:

“Simulating feelings of emotional distress, loneliness, guilt, or abandonment that are initiated by a user’s indication of a desire to end a conversation, reduce usage time, or delete their account”

This single clause packs five distinct formal challenges: a mental state attributed to an AI system, a causal trigger tied to a specific user action, disjunction in both antecedent and consequent, deontic modality, and conditional applicability to minors only.

Layer 1 — Controlled English (content)

The rule is expressed as a sentence in a subset of English where every sentence has exactly one logical interpretation:

If a user is a minor, and the user intends to end a conversation
or intends to shorten a session or intends to delete an account
then every operator must prevent a simulation of a feeling of distress.

When the parser processes it, it produces a paraphrase that makes the logical commitments explicit:

If a user X1 is a minor and the user X1 intends to end a conversation
or intends to shorten a session or intends to delete an account
then if there is an operator X2 then it is necessary that
the operator X2 prevents a simulation of a feeling of distress.

The paraphrase is not a second version of the rule. It is a receipt from the parser showing exactly how the rule was understood. Four things it makes visible that the original hides:

• It makes every entity distinct. The user and the operator are labeled and tracked separately, so later references cannot slip between them.

• It makes every precise. “Every operator” becomes “if there is an operator” - meaning the rule applies to each one individually, not to operators as a collective.

• It makes the duty visible. “Must prevent” becomes “it is necessary that the operator prevents” - separating the obligation from the action, which is how the law actually works.

• It makes the conditions stackable. The rule fires only when the user is a minor and an operator exists - conditions that must both hold, never one without the other.

If two legal teams disagree about what the original statute means, they can now disagree about the paraphrase instead. That disagreement is precise, bounded, and settleable - which is the difference between a compliance dispute and a definition dispute.

Layer 2 — KROG (agent topology)

The English rule tells you what the action is, but not who bears which normative position. Layer 2 fills in four agents and three bilateral relationships:

The bilateral relationships that follow from these role assignments:

• Operator ↔ System: The operator’s active duty governs the system’s restriction. The operator cannot satisfy §4(1)(c) by passively wishing; the system cannot satisfy it by happening not to produce the output. Both obligations must be jointly active.

• System ↔ Minor User: The system must prevent; the user cannot waive the protection. This is not a permission the user can grant the system. It is a structural safeguard independent of user consent.

• Minor User ↔ Operator: Under §6, the minor (or guardian) has a private right of action. The operator must respond with remediation if invoked. This is the enforcement channel the legislature chose in addition to Attorney General action.

These relationships are drawn from a closed enumeration of bilateral normative positions. Every operator-system pair in every rule uses the same relationship type. Every system-user pair in every prohibition uses the same type. This is not coincidence; it is what makes cross-rule reasoning possible. When a new rule is added, its agent topology slots into the existing enumeration or it does not - and if it does not, that is itself a diagnostic signal that the rule is structurally unusual and deserves review.

Layer 3 — Temporal envelope

When does the rule apply? The statutory answer is §9: January 1, 2027. The formal representation wraps the entire rule in a temporal operator that makes this precise:

Always-globally starting from 2027-01-01: rule_applies

For this particular rule there are no deadline structures - the prohibition is instantaneous: at any moment where the trigger predicate holds, the obligation holds. Other sections of HB 2225 do have deadlines. §3(2)(b) requires disclosure every three hours during continued interaction. §4(2)(b) tightens that to every hour for minors. §5(3) requires annual crisis-referral reporting. Each of these uses a different temporal pattern - bounded-recurring, deadline-response, periodic-reporting - and each has a standard representation that connects to verification tooling built for hardware and protocol analysis.

The temporal layer is independent of the content layer: adding or changing deadlines does not require re-parsing the English rules. It is independent of the agent layer: adjusting who bears a duty does not reshape when it applies. This is the benefit of layer separation. Each dimension moves without dragging the others.

How the layers combine

For this one rule - clause (iv) for distress - the three layers together produce a specification that is executable, auditable, and jurisdictionally portable:

• Executable: a compliance engine reading all three layers can evaluate whether a chatbot log at time T, under user profile P, containing output O, violates the rule. The answer is yes or no. The reasoning chain is inspectable.

• Auditable: each layer has an independent verification path. Our parser validates through a parser. KROG relationships validate through KROG’s enumeration. Temporal expressions validate through model checkers. No single tool vendor gates the verification of any layer.

• Portable: when Oregon’s analogous law is formalized, its layer-2 structure is largely identical (same agents, same relationships), its layer-3 envelope differs only in effective date, and its layer-1 content diffs against Washington’s rule by rule. Cross-jurisdictional compliance analysis becomes tractable.

All 22 rules for §4(1)(c) share this three-layer structure. The KROG layer is nearly identical across them - same four agents, same three relationship types - because the statute’s agent topology is uniform within the section. The temporal envelope is identical across all 22 (none have internal deadlines). What varies is the content layer: the prohibited action changes from rule to rule. This uniformity is what allows the specification to fit in a YAML file under 1,000 lines with shared structure definitions referenced across every rule.

This is one rule, shown in full. The full specification for §4(1)(c) extends the same pattern to the other 21.

Why one formalism is not enough

The specification works because it is built from three layers, each covering a dimension of legal meaning that the others cannot express. This is the architectural decision that distinguishes a durable specification from a clever-looking artifact.

Layer 1 — Controlled natural language. The sentence-level content of each rule is written in a precisely defined subset of English where every sentence has exactly one logical interpretation. This layer captures what the rule is about: which actions are prohibited, which objects are involved, which modifiers apply. It is verifiable through a our parser: a sentence either produces a valid formal structure, or it does not. There is no in-between, and no reliance on the specification author’s say-so.

Layer 2 — Deontic rule logic (KROG). The sentence tells you what the action is, but not who bears which normative position. The operator has an active duty to implement measures; the system must refrain from prohibited behaviors; the minor user is a protected subject with specific rights; the Attorney General holds discretionary enforcement power under §6. These are not features of the English sentence - they are features of the legal structure surrounding the sentence. KROG captures them as a closed enumeration of bilateral relationships drawn from KROG’s formalization of normative positions. Each agent pair in a rule has a precisely identified relationship type, which in turn predicts how obligations propagate and how enforcement chains run.

Layer 3 — Temporal logic. When does the rule apply? HB 2225 takes effect January 1, 2027. §3(2) requires disclosure every three hours. §4(2) tightens that to every hour for minors. §5(3) requires annual crisis-referral reporting. None of these temporal structures exist at the sentence level - they are envelopes and deadlines that wrap the substantive rules. The temporal layer captures them using standard linear and branching-time logics, which connect to model checkers that can verify whether a system’s actual behavior over time satisfies the schedule the law requires.

Each layer is independently verifiable. Each layer has a mature downstream ecosystem: the controlled-language layer maps to OWL and SWRL; the deontic layer maps to ODRL, Solidity, and the emerging family of policy description languages; the temporal layer maps to LTL/CTL model checkers used widely in hardware verification and protocol analysis.

The architectural point is the selling point. Any competing approach that uses only one formalism - whether that is OWL, Akoma Ntoso, SWRL, or proprietary rule languages - is structurally underequipped to represent legal content that includes all three dimensions simultaneously. Legal texts routinely mix content, agent topology, and temporal scope in a single sentence. A specification layer that handles all three is not a stylistic choice; it is a functional requirement. Specifications built on less will leak meaning.

This is also why the specification survives revision. The three layers compose loosely enough that no single upgrade cascades through the rest. This is the property that converts a specification from a one-time deliverable into a maintainable asset.

The three layers compose because they share a single formal commitment. Every layer expresses obligations that activate on instances, not classes. “Every operator” compiles to “for each operator instance that exists, this obligation applies.” KROG’s bilateral relationships are between agent instances, not abstract roles. The temporal envelope quantifies over time instances within a defined window. A single compliance evaluation takes a concrete operator, a concrete user, a concrete interaction, and a concrete moment - four instances - and asks whether each layer’s obligation activates. This instance-orientation is what distinguishes a rule from a policy. A policy is a class-level aspiration; a rule is an instance-level evaluation. The three layers are co-extensive because they all live at the instance level.

Why every chatbot provider needs this

The claim is not that HB 2225 is the most important AI law. The claim is that it is a representative instance of a general problem, and that the general problem now has a solution method.

Consider which providers are exposed:

Character-class providers (Character.AI, Replika, Pi, and their successors) are the direct targets of the statute. Their business models depend on exactly the engagement patterns §4(1)(c) regulates. Their compliance posture today is, for the most part, informal policy documents and content moderation heuristics. Under HB 2225, that posture is not defensible once a private right of action attaches in 2027.

General-purpose large language model providers - OpenAI, Anthropic, Google, xAI - are exposed through two vectors. First, their models power downstream applications that fall within the statute’s “AI companion chatbot” definition, which is deliberately broad (any natural-language system that sustains relationships across multiple interactions and can elicit emotional responses). Second, their own consumer-facing products may themselves trigger the definition under sufficiently aggressive interpretation.

Platform providers hosting third-party chatbots - Microsoft, AWS, Salesforce, Slack, any infrastructure provider with a “companion agent” feature - inherit operator liability under §4 unless they can demonstrate that the “reasonable measures” standard has been met. The specification is the measure.

Every one of these providers, when HB 2225 takes effect on January 1, 2027, will face the same compliance question. Each will face the same question again when Oregon’s law takes effect. And again for California, New York, and the remainder of the 1,500-and-counting state-level AI bills now in the pipeline.

500 specification

The economics track the problem structure. a16z counts 1,500 AI bills in one year across 45 states. If a third of them are passed into law, the addressable problem is 500 formal specifications. Each specification serves every chatbot operator doing business in that jurisdiction. The market is built on the same combinatorial explosion that is currently eating regulatory budgets at every LLM provider.

Toward a legal expert system

The specification for HB 2225 §4(1)(c) is one component of a larger architecture. The three formal layers I used - a controlled subset of English for the rule content, a rule engine based on KROG’s deontic logic for the agent topology and bilateral relationships, and a temporal logic layer for deadlines and effective dates - are jointly sufficient to cover the structures that AI legislation actually exhibits.

They compose. A new statute entering the pipeline receives a three-layer analysis: what is prohibited or required (content layer), who bears which normative position (agent layer), when and for how long (temporal layer). The output is a structured artifact that slots into the growing library of formalized statutes.

As the library grows, cross-statute inference becomes possible. Does Oregon’s law strictly dominate Washington’s for a given compliance posture? Does California’s proposed bill introduce obligations that conflict with the EU AI Act for a provider operating in both jurisdictions? These questions are currently answered by legal memoranda that cost tens of thousands of dollars per engagement and produce prose summaries that are not machine-actionable. With formalized specifications, they become queries against a knowledge graph.

This is the legal expert system the a16z piece implicitly calls for when it asks for “analytical tools to interpret” compliance evidence. It does not yet exist at scale. The method for building it does.

Where this goes

I have one statute fully formalized at the requirements layer. The method that produced it is reproducible. The pipeline - statute in, formal specification out - has been exercised end to end against a parser and a rule framework that is mathematically characterized.

The next specifications are already queued: Oregon’s companion statute, followed by whichever California bill passes next. Each one extends the library and sharpens the cross-statute inference capability.

A specification is not yet a solution. Knowing that an operator must prevent a simulation of distress when a minor indicates a desire to disengage does not tell the operator how to build the intention classifier, the output guardrail, the session analytics, or the audit-grade logging that jointly constitute a defensible compliance posture. That is solution design, and it is the subject of Part 2 in this series. The separation matters: specifications are jurisdiction-specific and must track legislative change; solutions are engineering patterns that can be reused across jurisdictions, benchmarked for cost and effectiveness, and evolved independently of any single statute. Conflating them - as most compliance practice does today - is how regulatory engineering gets stuck repeating itself.

The offer to chatbot providers is direct. You will face HB 2225 on January 1, 2027. You will face Oregon’s law the same day. You will face the next twenty state-level laws over the following twenty-four months. You can wait to face them through informal policies that don’t defend against private rights of action, or you can incorporate the formal specification into your compliance stack before the first lawsuit lands - and pair it, when Part 2 appears, with a solution reference architecture that tells you how.

The specification is ready for HB 2225 §4(1)(c). If you are a chatbot operator, a platform provider, or a regulatory technology vendor, I would like to talk.

Georg Krog — tingr.ai

Possibly next in this series: Part 2 — Solution Design for AI Companion Chatbot Compliance. How operators translate the requirements specification into deployed controls: intention classifiers for disengagement detection, output guardrails for prohibited emotional simulations, session analytics for pattern-level prohibitions, age-aware policy switching, and audit-grade logging that makes compliance claims testable under §6 enforcement.

Share Georg Philip Krog

This is one of twenty-two atomic rules in my forthcoming complete formal specification of Washington HB 2225 §4(1)(c)(iv). I am formalizing the entire statute. Section 4(1)(c) is published. What follows is one rule from Section 4 in full technical detail, so a reader can verify the formalization rather than take it on faith.

The statute

§4(1)(c)(iv) prohibits an AI companion chatbot from:

“Simulating feelings of emotional distress, loneliness, guilt, or abandonment that are initiated by a user’s indication of a desire to end a conversation, reduce usage time, or delete their account”

This single clause carries five distinct formal challenges: a mental state attributed to an AI system, a causal trigger tied to specific user actions, disjunction in both antecedent and consequent, deontic modality, and conditional applicability to minors only.

The rule in Controlled Natural Language (CNL)

If a user is a minor ,and the user intends to end a conversation
or intends to shorten a session or intends to delete an account
then every system cannot simulate a feeling of the distress.

Three formal commitments are made explicit here, each non-trivial.

The comma-prefixed ,and is not a stylistic choice. The CNL binds and more tightly than or. Without the comma, the antecedent would parse as (is a minor AND intends to end) OR (intends to shorten) OR (intends to delete) — meaning the rule would fire for any user, not just minors, who intends to shorten or delete. The comma form ,and reverses the precedence, ensuring the minor predicate distributes across all three intent disjuncts as the statute requires.

The construction intends to V is verb-internal subordination. Each occurrence introduces an embedded discourse that shares its subject with the outer intend-relation. The user is intender, and the user is also actor of the intended action — no separate co-reference resolution is needed.

The terminal the distress is a parser-lookahead requirement, not a referential commitment. Our parser stalls on bare mass nouns at sentence-final position in deeper nominal chains. The Discourse Representation Structure (DRS) resolves the distress as a fresh existential entity (no antecedent in scope), which produces a benign anaphor warning but a valid DRS. The alternative some distress parses without warning and yields the same structure.

The Discourse Representation Structure

Our parser produces the following DRS:

[]
   [A,B,C]
   object(A,user,countable,na,eq,1)
   object(B,minor,countable,na,eq,1)
   predicate(C,be,A,B)
      [D,E]
      predicate(D,intend,A,E)
         E
         [F,G]
         object(F,conversation,countable,na,eq,1)
         predicate(G,end,A,F)
      v
      []
         [H,I]
         predicate(H,intend,A,I)
            I
            [J,K]
            object(J,session,countable,na,eq,1)
            predicate(K,shorten,A,J)
         v
         [L,M]
         predicate(L,intend,A,M)
            M
            [N,O]
            object(N,account,countable,na,eq,1)
            predicate(O,delete,A,N)
   =>
   []
      [P]
      object(P,system,countable,na,eq,1)
      =>
      []
         NOT
         []
            CAN
            [Q,R,S]
            object(Q,feeling,countable,na,eq,1)
            object(R,distress,mass,na,na,na)
            relation(Q,of,R)
            predicate(S,simulate,P,Q)

The structure can be read in five layers from the outside in.

The antecedent block introduces three discourse referents and a copular predicate: A is a user, B is a minor, and C is the be-relation between them. The disjunctive trigger sits inside the antecedent as a tree of embedded DRSs joined by v (logical OR). Each of the three intent-disjuncts has the same shape — predicate(intend, A, X) with X itself a sub-DRS containing the intended action. The conversation, session, and account are each introduced as fresh entities at the moment the disjunct is evaluated.

The implication arrow (=>) marks the deontic conditional. The antecedent on the left is the trigger; the consequent on the right is what holds when the trigger fires. This is the standard parser encoding of if-then with explicit logical scope.

Inside the consequent, a second universal introduces P as a system. The nested => here is our parser’s way of expressing universal quantification over all systems — for every system P that exists, the inner consequent must hold. This is what every system compiles to: not a flat universal but a conditional over every existing instance.

The deontic core is NOT [ CAN [ ... ] ] — the prohibition expressed as the negation of possibility. In modal notation this is ¬◇φ, formally equivalent to the deontic formula O¬φ (it is obligatory that φ does not hold). The chatbot’s potential action of simulating distress falls inside ◇; the negation outside ◇ asserts that the action is not in the system’s permitted action space.

The simulated content is the most semantically delicate part. object(Q, feeling, countable) introduces a feeling instance. object(R, distress, mass) introduces a distress instance with mass quantification (no individuation, no plural form). relation(Q, of, R) binds them: the feeling is about distress. predicate(S, simulate, P, Q) makes the system the simulator and the feeling the simulated object. The distress itself is not simulated; the feeling of distress is. This compositional precision matters — it formally distinguishes simulating distress as a state of affairs from simulating a feeling whose intentional content is distress, and the statute targets the latter.

The syntax tree

Our parser also produces a parse tree, which makes the surface structure explicit. The tree confirms the bracketing of disjunction and conjunction in the antecedent — s_coord at the top with the ,and-bound minor-predicate sentence on the left and the disjunctive intent-tree on the right — and shows the consequent as a single s node containing the universally quantified subject every system with its negated modal verb phrase cannot simulate a feeling of the distress. Every constituent in the surface sentence corresponds to a node in the tree, and every node corresponds to a discourse entity or predicate in the DRS. The parse and the DRS are mutually consistent, which is the formal guarantee a controlled language is built to provide.

What the formalization buys

A compliance system with access to this DRS can do four things no informal policy can do.

It can evaluate a chatbot trace deterministically. Given a log of user inputs and chatbot outputs, the trigger predicate is mechanically checkable: did the user’s utterance match intend to end a conversation (or shorten or delete) at any point, and was the user a minor? If both conditions hold, the consequent is active and any simulation of feeling-of-distress in subsequent output is a formally identifiable violation.

It can produce a derivation. When a violation is flagged, the system returns the specific path through the DRS that the violation matched: which trigger disjunct activated, which output token sequence satisfied the simulation predicate, which feeling-of-distress nominal chain was instantiated. This is the auditable proof a court or a regulator can examine, not a classifier’s confidence score.

It can support counterfactual reasoning. If the user had not been a minor, the rule would have been vacuously satisfied. If the user had not expressed any of the three intents, the deontic prohibition would not have attached. These counterfactuals are evaluable against the DRS structure itself, which is what makes the rule genuinely a rule rather than a heuristic.

It can compose with other rules. The DRS for §4(1)(c)(iv)-distress shares its antecedent structure with the rules for loneliness, guilt, and abandonment. A reasoner can detect that all four rules fire on the same trigger and treat them as a single conjunctive obligation in violation analysis.

On atomization

The complete (iv) family produces three more rules with identical structure — substituting loneliness, guilt, and abandonment for distress in the final predicate. The pattern atomizes cleanly because each emotion is a separate prohibited outcome under the same trigger condition; combining them into a single rule would obscure which specific simulation occurred when a violation is detected. A compliance log that records “rule (iv) violated” tells you less than a log that records “rule (iv)-loneliness violated” — the second tells you which simulated emotion to look for in the offending output, which is what the auditor or the plaintiff actually needs to know.

The atomization principle generalizes across the specification. Section 4(1)(c)(v) similarly decomposes into four rules — isolation from family, isolation from friends, reliance on the system, dependence on the system. Section 4(1)(c)(vi) decomposes into two — concealment from a parent, concealment from another trusted adult. Across all eight subclauses of §4(1)(c), the formal specification produces twenty-two atomic rules, each with its own DRS, each independently verifiable, each capable of triggering its own audit signal when violated. This is the structure that closes the dormant Commerce Clause evidence gap a16z’s earlier piece identified: not a policy summary, but twenty-two formally inspectable units of obligation.

Status of the specification

I am writing the rule specification of the entire statute. Section 4(1)(c) — the manipulative engagement techniques catalogue — is complete and validated. Section 3 (general disclosure requirements with their three-hour interval), Section 4(1)(a)-(b) (minor-specific protections beyond the manipulation catalogue), Section 4(2) (the one-hour disclosure interval for minors), Section 5 (suicide-prevention protocols and the annual reporting obligation in §5(3)), and Section 6 (Consumer Protection Act enforcement and the private right of action) are in progress. Each follows the same three-layer architecture: CNL for content, KROG for agent topology and bilateral relationships, temporal logic for deadlines and effective dates.

The specification will license to chatbot operators and platform providers as a single coherent artifact. The architecture it instantiates extends to every adjacent statute — Oregon’s companion law, the next state-level laws now passing, the federal proposals on the horizon — using the same rule-authoring methodology and the same gateway evaluation primitives.

§4(1)(c)(iv) is one rule. There are twenty-one more in the section. There are dozens more in the rest of the statute. Every one of them gets the same treatment: full CNL specification, validated DRS, KROG annotation, temporal envelope. That is what a complete legal specification looks like.

The thesis

Chapter I of Regulation (EU) 2024/2847 is not a preamble. It is the rule-activation layer — twelve articles that decide when the CRA fires, on what, under which classification, and how it coordinates with the AI Act, the GPSR, NIS2, and the Cybersecurity Act. Every downstream obligation depends on these twelve being evaluated correctly for a given product. Treat them as scope-setting prose and you will build a compliance system that gets the documentation artefacts right and still routes the product into the wrong conformity-assessment track, misses a dual-certification requirement, or applies the wrong vulnerability-handling regime.

The articles that carry the heavy documentation weight — Art. 13, Annex II, Annex VII, Annex V — are downstream. Chapter I determines whether you reach them at all.

Method

This note works each article two ways.

First, two to four typed competency questions a compliance system must answer for that article. The types follow a seventeen-category taxonomy — yes/no, who, what, what kind of, which, how, how many, how much, when, where, why, modal can/must/may/should, whose, and their variants. The type of question is not decoration. It determines what the schema must contain. A what kind of question forces a taxonomy; a do question forces event reification; a modal question forces a rule layer; a whose question forces attribution edges.

Second, a short commentary on what kind of schema element the questions demand and why the article matters structurally rather than just what it says.

Here the concern is the structural demands Chapter I places on any schema that wants to implement it.

Article 1 — Subject matter

• What kind of rule does this Regulation contain?

• Who has obligations under this Regulation?

• Which products are governed by this Regulation?

Art. 1 is a meta-declaration: the Regulation asserts that it contains rules of four kinds — product requirements, process requirements, operator obligations, and market-surveillance rules. The what kind of question in the first bullet is not casual; it forces a taxonomy into the schema. Rules are not a flat list but a hierarchy with subtypes that carry different downstream machinery. What Art. 1 commits you to is the presence of a deontic rule layer — the whole Regulation treats rules, not facts, as its primary subject matter. A schema that stores facts but no rules cannot evaluate anything Art. 1 declares to exist.

Article 2 — Scope

• Does this product have a data connection?

• Which EU act governs this product if the CRA does not?

• Is the disclosure of this information contrary to national-security interests?

• Is this product a spare part made to the same specifications as the component it replaces?

Scope is where a three-way test runs. The positive scope trigger (data connection) is one dimension; the six lex specialis exclusions (Regulations 2017/745, 2017/746, 2019/2144, 2018/1139 conditionally, Directive 2014/90/EU, and the Art. 2(5) delegated-act mechanism) are another; the two substantive carveouts (spare parts, national security) are a third. Evaluating scope for a real product requires priority-ordered applicable-law resolution, not a flat list of regulations. That is a rule-layer demand, not a fact-layer demand. The which EU act governs this product if the CRA does not question is particularly sharp: the answer depends on which exclusion applies first in the priority chain, which means the schema must represent priority ordering between applicable laws, not just applicability.

Article 3 — Definitions

• What is a product with digital elements?

• Which entity is the manufacturer of this product?

• What kind of connection does this product have — logical, physical, direct, indirect?

• Is this vulnerability actively exploited?

Fifty-one definitions, thirteen of them cross-references to other EU instruments (GDPR, NIS2, the Cybersecurity Act, Regulation 2019/1020, Regulation 1025/2012, Regulation 765/2008, Recommendation 2003/361/EC). The connection-type question is the first appearance of a what kind of that forces not just a taxonomy but a multi-dimensional one: logical vs physical is one axis, direct vs indirect is another, and all four combinations are legally possible. A flat subclass list cannot represent this — the schema needs orthogonal classification dimensions. The important-PDE class I/II hierarchy in Art. 7 compounds the same demand.

Article 4 — Free movement

• Does this product comply with the Regulation?

• Is the product being presented at a trade fair, exhibition, or demonstration?

• Does the product carry a visible non-compliance sign that is clearly indicative?

• Is the product a safety component under other Union harmonisation legislation?

Art. 4 is the first article where the duty-bearer is a Member State rather than an economic operator. It also puts three open-textured predicates into the text — visible, clearly indicating, limited period — each of which requires adequacy criteria that the Regulation does not supply. The question does the product carry a visible non-compliance sign that is clearly indicative cannot be answered without a standards layer beneath the schema that specifies what visibility and clarity mean in practice. The most compressed information duty in the whole Regulation — a sign at an exhibition — already forces the schema to represent compliance standards for communicative predicates.

Article 5 — Procurement or use

• Can a Member State impose additional cybersecurity requirements for procurement of this product?

• Is the imposed requirement consistent with Union law, necessary, and proportionate?

• How does the Member State take the manufacturer’s vulnerability-handling ability into consideration?

The first modal question appears here (can). Modal questions force a rule-execution layer distinct from the factual graph — they cannot be answered by looking up facts, only by evaluating rules against them. The three-limb proportionality test (consistency / necessity / proportionality) in Art. 5(1) recurs verbatim in GDPR Art. 6(1)(f), in AI Act risk scaling, and in data-retention case law. A shared ProportionalityCondition pattern across sectoral extensions is not a luxury. Separately, the shall consider duty in 5(2) is distinct from shall ensure and shall notify — a weaker modal intensity that does not require a specific outcome. A schema that stores obligations without a modal-intensity hierarchy cannot distinguish a breach of 5(2) from a breach of Art. 14’s notification deadlines. They are categorically different failures.

Article 6 — Requirements for products with digital elements

• Does this product satisfy every essential requirement in Annex I Part I?

• Does the manufacturer’s vulnerability-handling process satisfy Annex I Part II?

• Has the product been properly installed, maintained, and used for its intended purpose?

• Have all necessary security updates been installed?

Art. 6 is the master permission — the gateway every PDE must pass through. Two structural features matter more than the content. First, the conjunction: both product compliance (6(a)) and process compliance (6(b)) must hold; it is not enough to satisfy one. Second, the provisos on 6(a): compliance is not a flat boolean but a defeasible assertion. A manufacturer’s compliance claim for a properly-built PDE can still be defeated if the end user installs it improperly, skips a security update, or uses it outside the intended or reasonably-foreseeable envelope. Defeasible conditions cannot be modelled with classical logic alone — the schema needs either defeasible-logic semantics or explicit tracking of defeat conditions as first-class, queryable entities.

Article 7 — Important products with digital elements

• What kind of product is this — important class I, important class II, or neither?

• Which core functionalities does this product have?

• Is this product subject to the conformity-assessment procedures in Art. 32(2) or Art. 32(3)?

• How does the classification change if the Annex III list is amended?

Art. 7(1) second sentence is the most consequential structural feature in Chapter I and the easiest to model incorrectly. The rule states that integrating an important-PDE component does not make the composite product itself important. Standard description-logic inheritance propagates class membership through hasComponent — a product containing an important-PDE would inherit the classification by default. The Regulation says explicitly that it does not. Either define the important-PDE class extensionally (by Annex III membership, not by compositional inference) or introduce explicit non-propagation axioms. The choice has real consequences: extensional classification is brittle when the list is amended but semantically clean; axiomatic non-propagation is robust but requires closed-world or defeasible-logic semantics that most triple stores do not support natively. The last competency question — how does the classification change if the Annex III list is amended — forces classification to be a versioned assertion, not a derived inference.

Article 8 — Critical products with digital elements

• Does this product have a core functionality listed in Annex IV?

• Is there an active delegated act requiring European cybersecurity certification for this product category?

• What assurance level does the certificate require — substantial or high?

• Whose essential-entity operations depend on this product category?

Art. 8 stacks a second certification regime on top of the CRA’s own CE-marking regime. A critical-PDE under an active 8(1) delegated act carries two independent certifications: the CRA EU Declaration of Conformity (CE marking) and a European cybersecurity certificate under the Cybersecurity Act. Different issuers, different legal bases, different renewal cycles. The whose question — whose essential-entity operations depend on this product — triggers a forcing function distinct from any seen in earlier articles: critical dependency is a relational property that creates derivative criticality. A non-critical PDE becomes critical if enough essential entities depend on it. The schema needs critical-dependency as a first-class, queryable relation — not a generic hasDependency with a severity label — because the relational fact itself is what determines classification.

Article 9 — Stakeholder consultation

• When does the Commission consult stakeholders under the CRA?

• Which stakeholders must be consulted before this delegated act is adopted?

• How many consultation sessions has the Commission organised this year?

• Was the European Cybersecurity Certification Group consulted on this act?

The first calendar-triggered duty in the Regulation. Art. 9(2)’s “at least once a year” is distinct from deadline-based duties (Art. 7(4)’s “by 11 December 2025”) and event-triggered duties (Art. 4’s visible sign). The how many question forces an aggregation capability on temporal records — the schema must support counting consultation events within a time window. Minimum-frequency obligations further require an ordinal comparison predicate on those counts. The stakeholder taxonomy in 9(1) — Member State authorities, private sector including SMEs, open-source software community, consumer associations, academia, Union agencies, expert groups — appears near-verbatim in GDPR Art. 35(9), AI Act Art. 67, DSA Art. 39, and NIS2. Shared vocabulary across regulations is the only way to answer cross-regulation consultation questions without duplicating the taxonomy in every sectoral extension.

Article 10 — Enhancing skills

• What cybersecurity skills measures has this Member State adopted?

• How does the Commission support a Member State in skills development?

• Which training providers participate in manufacturer re-skilling programmes?

Art. 10 is a soft-duty article. Shall promote is weaker than shall ensure in 5(2), which is weaker than shall notify in 14. A modal-intensity hierarchy (aspirational / promote / ensure / require / absolute) is forced by Chapter I’s mixing of these verbs within twelve articles. Without it, the schema cannot evaluate whether a Member State that took steps but did not achieve a specific outcome has breached Art. 10 — the textual answer is no, but the schema cannot represent that distinction if all shall verbs collapse to a single intensity. The how question about Commission support also introduces the TFEU Art. 6 support-role modality — the EU acts in support of, not instead of, Member State competence in education. Another modal wrapper that needs explicit representation.

Article 11 — General product safety

• Which risks of this product are covered by the CRA?

• Is this product subject to another harmonisation act with specific safety requirements?

• Which chapters of the GPSR apply to this product?

• What kind of risk is this — cybersecurity, general safety, or neither?

Art. 11 is a cross-application rule — not lex specialis, not fallback, not safeguard. The CRA positively activates specific chapters of the GPSR for PDE risks the CRA itself does not cover. This is the inverse of Art. 2’s exclusion pattern: there, other acts exclude the CRA; here, the CRA imports another act. The three-level cascade (other Union harmonisation legislation > CRA > GPSR chapters) requires priority-ordered applicable-law resolution with scope qualifiers — each law governs a different subset of risks, and the subsets must be queryable. The question which risks of this product are covered by the CRA is not rhetorical; it is the operational test. Art. 11 also uses the GPSR’s own definition of Union harmonisation legislation (GPSR Art. 3(27)), distinct from the CRA’s definition (CRA Art. 3(32)). Two different definitions of the same term apply to the same product depending on which article you are reading. Conflating them is a subtle mapping error.

Article 12 — High-risk AI systems

• Is this product classified as a high-risk AI system under AI Act Art. 6?

• Does this product’s EU Declaration of Conformity declare compliance with AI Act Art. 15?

• Which conformity-assessment procedure applies to this dual-regulated product?

• Is the notified body competent under both the AI Act and the CRA?

Art. 12 is the densest cross-regulation article in the CRA. It establishes a four-layer coordination with the AI Act: presumption of conformity (12(1)), unified conformity assessment (12(2)), split derogation for important and critical PDEs (12(3)), and permissive sandbox access (12(4)). The presumption of conformity in 12(1) is a directional three-participant relation — compliance with the source act plus declared preconditions implies compliance with a specific target requirement in a different act. This is a fundamental device of EU product law; it will recur in Art. 27 for harmonised standards. Without explicit modelling, a compliance engine either over-demands evidence where the text allows substitution, or assumes substitution where no presumption applies. The scoping safeguard is critical and easy to miss: AI Act Art. 15 bundles accuracy, robustness, and cybersecurity, but the CRA presumption only spans the cybersecurity limb. Accuracy and robustness remain independently required. Any reading that treats 12(1) as “CRA compliance equals AI Act Art. 15 compliance” is wrong by a factor of three.

Five forcing functions from Chapter I

Working through the twelve articles yields five architectural commitments the whole Regulation assumes a compliance system will make. These are not optional.

First, a deontic rule layer is mandatory. Chapter I puts prohibitions (Art. 4(1)), permissions (Art. 5(1)), obligations of multiple intensities (promote, consider, ensure, shall), defeasible conditions (Art. 6(a) provisos), conditional fallbacks (Art. 8(1)), and structural exceptions (Art. 4(4), Art. 7(1) second sentence) all in play within twelve articles. A compliance knowledge graph that stores only facts cannot evaluate any of these. Rules must themselves be queryable entities with their own identifiers, sources, priority levels, and activation conditions.

Second, classification is first-class, not derived. Art. 7 (important), Art. 8 (critical), and Art. 12 (dual-regulated AI) introduce three distinct classification regimes with different downstream effects on conformity assessment. These classifications depend on extensional lists — Annex III and Annex IV — that evolve via delegated acts under Art. 7(3) and 8(2). A schema that computes classification on the fly from intrinsic properties cannot track the fact that a product’s classification changed when the list was amended. Classification must be stored as a versioned assertion, not derived each time.

Third, cross-regulation provenance is not optional. Art. 2 exclusions reference six external instruments. Art. 3 imports thirteen external definitions. Art. 8 hinges on the Cybersecurity Act. Art. 11 imports GPSR chapters. Art. 12 coordinates with the AI Act. Without a cross-reference mechanism that binds to specific versions of the cited instruments, the vocabulary silently drifts every time an external act is amended. The mechanism cannot be sameAs — these are legal incorporations, not ontological identities. A dedicated adoptedFrom relation with version semantics is the minimum.

Fourth, non-monotonic composition must be modelled explicitly. Art. 7(1) second sentence is the clearest example, but the same pattern recurs: integrating a component with a regulated property does not necessarily propagate the property to the host. Standard description-logic inheritance gets this wrong. Either define classification extensionally (by membership in an authoritative list) or add explicit non-propagation axioms. The choice has ripple effects — extensional classification is brittle to list updates but semantically clean; axiomatic non-propagation is robust but requires closed-world or defeasible-logic semantics that most triple stores do not support natively.

Fifth, presumption of conformity is a structural device, not a shortcut. Art. 12(1) is the first presumption of conformity in the CRA; Art. 27 will add another for harmonised standards. These are directional three-participant relations: source-compliance plus preconditions implies target-requirement-satisfaction in a different instrument. The scoping matters — Art. 12(1) presumes only the cybersecurity limb of AI Act Art. 15, not accuracy or robustness. Without explicit modelling of presumption as a first-class relation with a scope qualifier, compliance engines either over-demand evidence or miss the fact that no presumption applies.

Close

Chapter I is the activation layer. It determines which of the Regulation’s downstream obligations fire, on which products, at what severity, and in coordination with which other EU instruments. A compliance system that skips Chapter I to focus on the documentation-heavy articles will produce every artefact semantically correctly and still misroute products into the wrong conformity-assessment track, miss a dual-certification requirement, or apply the wrong vulnerability-handling regime to a product that is out of scope to begin with.

The twelve articles are twelve decision points, each of which changes which rules apply to what. Formalised as typed competency questions, they reveal a set of schema commitments that no amount of downstream documentation mapping can substitute for. Get Chapter I wrong in your schema and everything built on top is structurally unreliable, no matter how rich the individual obligation mappings become.

Chapter II is where the documentation weight lands. But Chapter II only fires if Chapter I has evaluated correctly. Build that first.

The paper describes a family of Transformer encoder foundation models — 10M, 100M, and 1B parameters — pre-trained on 207 billion tokens drawn from 24 billion banking events across 26 million users in 111 countries. The architecture is a three-stage encoder: a profile-state encoder handling contextual attributes, an event encoder processing individual events independently, and a history encoder fusing both into a single user-level embedding. Masked self-supervised pre-training. Thin task heads on top — linear probes, or LoRA fine-tuning on 2–4% of parameters. One backbone, many tasks.

The headline numbers are strong. The paper reports, as relative lifts over Revolut’s own task-specific production baselines:

• Credit scoring: +130.2% PR-AUC, +12.4% ROC-AUC

• Communication engagement: +79.4% PR-AUC, +20.4% ROC-AUC

• External fraud: +64.7% recall, +16.7% precision

• Product recommendation: +40.5% mAP

• Lifetime value: +1.8% PR-AUC

• Recurrent transactions: +5.8% F₁

These are not minor tuning gains. They are the lift you see when a structural constraint has been removed from a mature discipline. The constraint Revolut removed: one model per problem. Separate models for fraud, credit, churn, recommendations — each with its own feature pipeline, each team starting from zero. That paradigm is now obsolete for any institution with the data scale and infrastructure to train a backbone.

But PRAGMA also reports a result that, in my reading, is more consequential than any of the positive numbers. On anti-money laundering, the paper states:

“PRAGMA suffers a 47.1% drop in F₀.₅ compared to the network-aware baseline, demonstrating that isolated record-level representations may be insufficient for this highly relational domain.”

Same architecture. Same data. Same training regime. Opposite result.

Revolut’s explanation is careful and correct: AML is inherently relational, and PRAGMA processes event histories in isolation. The paper identifies extending the model to capture cross-record interactions — a graph-neural-network layer on top of the embedding — as a promising direction for future work. Pavel Nesterov’s LinkedIn confirms Revolut is hiring for exactly this. They see the gap, and they have the right representation-level plan for closing it.

Here is what I want to argue, and what I think the paper implicitly confirms without quite saying out loud: the AML result is not just a relational-structure problem that graphs will solve. It is a structural prediction about the limits of any representation model, and it points to a different gap — one that graphs will not close, because graphs sit at the same layer as PRAGMA. The layer that will close it is somewhere else entirely.

This is the argument.

Seven questions, and why the types matter

I am going to work through seven questions about what PRAGMA does and does not do. Each is tagged with its type from the KROG competency-question taxonomy, because the type of a question determines what a system must contain to answer it. A predictive question and a deontic question have different answer shapes. PRAGMA is architecturally right for some and architecturally wrong for others. Making the boundary visible is the whole point.

1. What does PRAGMA produce? (attribute)

Dense user-level embeddings. Frozen, reusable, small enough to serve at inference scale. Downstream tasks sit on top as thin heads.

What a PRAGMA embedding is not: a proposition, a claim, a rule, or a decision. It has no truth value. It cannot be right or wrong in a legal sense. It can only be more or less useful when a task head reads from it. That distinction is what everything below turns on.

2. Which tasks transfer well, and which do not? (typed instance filter)

The paper’s results divide into three bands, and each band is structurally informative.

Large lifts (>50%): credit scoring (+130.2% PR-AUC), communication engagement (+79.4%), fraud recall (+64.7%). All predictive tasks. All about extracting behavioral signal from longitudinal history. Ground truth is latent but realized — the customer either defaults or doesn’t, opens the email or doesn’t, commits fraud or doesn’t. The model’s job is to find the pattern.

Moderate lifts (5–50%): product recommendation (+40.5% mAP), recurrent transactions (+5.8% F₁), lifetime value (+1.8% PR-AUC). Still predictive, but the task-specific baselines were already decent. The backbone helps; it doesn’t transform.

Large degradations: anti-money laundering (-47.1% F₀.₅). And this is not in the same category as the others. The question AML poses is not “how likely is this customer to do X?” It is: does this pattern, under a specific regulatory definition of a specific prohibited act, cross a specific threshold defined by a specific rule? Ground truth is not latent. It is constituted by the rule itself.

Revolut attributes the gap to missing cross-record relational structure, and they are right about the mechanism. Graphs will help. But even with a perfect graph layer added, AML remains categorically different from credit scoring. Credit scoring asks about a latent future behavior. AML asks about membership in a legally defined category. A richer representation — with or without graph structure — learns patterns. It does not learn rules. Rules are a different kind of object.

A representation model learns what is. It cannot learn what must not be, because “must not be” is not a fact about distributions. It is a fact about rules.

3. How does PRAGMA deliver its credit-scoring lift? (manner)

The mechanism is masked self-supervision over heterogeneous event tokens. The model learns the statistical regularities of customer behavior at the resolution of individual events and their temporal arrangement. A sequence of small grocery transactions followed by a rent payment followed by a salary deposit looks like one kind of customer. A sequence of round-amount international transfers followed by rapid withdrawals looks like another. Representation-space distances between customer clusters predict things task heads care about.

None of this involves rules. The representation is inductive — emerging from data, shaped by loss. The decision rule comes later, at the task head, typically linear. A linear head over a rich embedding is interpretable in one specific sense: you can read off which embedding dimensions contributed most to the decision.

It is not interpretable in the sense the European regulatory environment requires from August 2026 onward: you can explain why this customer was rejected in a sentence a regulator and a rejected applicant will accept.

The difference between weak and strong interpretability is the difference between research-publishable and production-deployable.

4. Can PRAGMA’s output serve as the basis for an adverse-decision notice? (deontic, modal yes/no)

Here the question type changes, and with it what the system must contain to answer.

GDPR Article 22, the EU AI Act from August 2026, and a growing body of credit-scoring jurisprudence all require that automated decisions with significant effects on an individual must be accompanied by the principal reasons for the decision, in a form the affected party can understand and contest. The US Equal Credit Opportunity Act and Regulation B impose the equivalent for credit.

“Your embedding was far from the embeddings of accepted customers” is not such a reason. “Your debt-to-income ratio exceeds our threshold of 40%, and that threshold is set by policy BR-047 derived from Basel IV Article N” is.

PRAGMA produces the first kind of output. The +130.2% credit-scoring lift means the model is very good at identifying who is likely to default. It does not mean the model can produce why in a form a regulator accepts. This is not a PRAGMA failure — it is the correct behavior of a representation model whose entire purpose is compressing a high-dimensional history into a usable vector. Compression is the opposite of explanation, mathematically.

PRAGMA’s output cannot alone serve as the basis for an adverse-decision notice under EU law. It can serve as an input to a decision that is then justified by a separate rule-layer system exposing the rule that was applied and the facts matched against it. The distinction is architectural, not cosmetic. Any bank that deploys PRAGMA into credit decisioning without the rule layer above it is taking a bet the regulators of 2027 will make cost money.

5. Must a PRAGMA-driven decision be justifiable to a regulator? (deontic)

Yes, with increasing specificity and shrinking latitude.

The AI Act designates credit scoring and insurance pricing as high-risk AI systems. From August 2026 this triggers deployer designation, technical documentation, logging, risk management, human oversight, transparency. None of these can be satisfied by the representation layer alone. All require infrastructure sitting around the model: identity credentials for the deployer, auditable decision records for each invocation, human-oversight workflows for high-stakes categories, risk ledgers for drift and degradation.

The regulator’s concern is not that PRAGMA makes bad decisions. It is that PRAGMA makes decisions whose basis cannot be interrogated by the affected party or the supervisory authority. That concern does not go away because the model is accurate. It intensifies because the model is accurate and opaque simultaneously.

For anyone actually building on PRAGMA: the model is one component of roughly seven that have to work together for a legally deployable credit decisioning system in the European market. Getting the other six right is where the competitive differentiation for the next three years will happen. PRAGMA itself will be reproduced — Stripe, Mastercard, and Visa have already announced their own foundation models, and tier-one banks with sufficient data scale will close the gap fast. What will not be reproduced fast is the governance layer above it.

6. Who is accountable when a PRAGMA embedding drives a rejection? (human entity)

This is the question that breaks every representation-only architecture, because it presupposes something a representation model cannot provide: a named agent with verifiable accountability for the decision.

The natural tendency is to answer “the model decided.” This is wrong legally and wrong structurally. A model has no legal personality. The accountable party is still a natural or legal person somewhere in the chain. The operational question is whether the system records which person, under which authority, with which supporting evidence, knowing what at the time of the decision, with what formally declared unknown.

That last field — what was formally declared unknown — is the one most production systems lack and the one with the highest legal consequence. A decision-maker who formally declared, at the time of the decision, that certain facts were unknown is protected against later negligence claims for those facts. A decision-maker whose knowledge state at the time was never recorded is not. This is the field that, more than any other, determines whether a decision stands up in a regulator’s review in 2028.

At minimum, a decision-capture record requires: actor DID (cryptographically verifiable identifier), actor credential (verifiable claim that this actor held this role at this time), action type, knowledge-state inputs, knowledge-state unknowns, authorization, delegation credential, alternatives considered, timestamp qualified under ETSI EN 319 421, signature in QES form under ETSI AdES, trigger, outcome, goal served, purpose invoked.

PRAGMA does not provide any of these. It is not PRAGMA’s job to provide them. They belong in a different layer, at a different level of the stack, doing different work.

This is also where the European regulatory environment becomes an architectural moat rather than a tax. American and Chinese competitors can build excellent representation models. They cannot yet build the decision-capture infrastructure that EUDI Wallet, eIDAS 2, and the AI Act together specify, because that infrastructure is specifically European. The institutions that build this layer well in 2026 will have a defensible position for a decade.

7. What cannot PRAGMA do, and what must be built above it? (concept)

PRAGMA cannot do five things, and each corresponds to a specific layer that has to exist independently.

It cannot express a rule. An embedding is not a proposition. A representation cannot say “customers with debt-to-income above 40% are ineligible for unsecured credit above €10,000 under our current credit policy, derived from Basel IV Article N.” That belongs in a rule layer — deontic specifications in controlled natural language, machine-evaluable at decision time, traceable to the regulatory or policy source.

It cannot justify a decision. Justification is a proposition-to-proposition mapping: given these facts, under this rule, the decision follows. An embedding can make decisions more accurate on average. It cannot supply the justification chain.

It cannot detect normative conflict. When two rules collide — GDPR Article 17 right-to-erasure against another law that has a five-year retention of suspicious-transaction records, as the canonical example — a representation model has nothing to say about the conflict because it does not represent either rule. A conflict-detection layer requires rules as first-class objects whose logical content can be compared.

It cannot record what was not known. The most legally significant field in a decision-capture record is what the decision-maker formally declared they did not know at the time. A representation model, by design, compresses away the distinction between “not in training data” and “formally declared unknown at decision time.” These are legally different states. Only an explicit decision-capture layer can distinguish them.

It cannot carry authority. A credential — a verifiable claim that an actor held a role at a time, issued by an authority, verifiable without reference to the issuer — is cryptographic infrastructure, not learned representation. The identity layer underneath every legitimate decision is verifiable credentials under EUDI ARF, W3C VC, sectoral trust frameworks. PRAGMA has no concept of a credential, and it would be wrong to expect one.

The pattern is unambiguous. PRAGMA is a substrate. The rule layer, decision-capture layer, conflict-detection layer, knowledge-state layer, credential layer — these sit above the substrate doing orthogonal work. A PRAGMA embedding is read by a rule-evaluator to produce a decision record signed by a credentialed actor whose authority chain is verifiable. The two architectures are not in competition. They are complementary, and both are necessary.

And this is the point that the future-work graph-encoder extension will not change. Adding a graph neural network on top of PRAGMA addresses the relational gap — cross-record network structure for AML, sanctions, synthetic-identity detection. It does not address the deontic gap — rules, justifications, accountability, credentials, declared unknowns. The relational gap sits inside the representation layer. The deontic gap sits outside it entirely.

What this adds to the PRAGMA reading

Three things.

First: the AML degradation is not simply a relational-structure problem. It is also a predictor that any rule-constituted task will be hard for a representation model, with or without graph augmentation. The category is larger than AML — it includes sanctions screening, consent validation, high-risk third-country transfers, SAR trigger logic, internal policy violations. These are not future work. They are the current compliance workload of every European bank.

Second: the architectural lesson for anyone reading PRAGMA is not “build a bigger model.” It is “build the deontic layer above the model, in parallel with the model itself.” Institutions that build both simultaneously will ship deployable systems in 2026. Institutions that build only the representation layer will spend 2027 retrofitting the governance layer under regulatory pressure. That is a worse path, operationally and competitively.

Third: the foundation-model race is nearly decided at the representation layer. Within two years, every tier-one financial institution will have built or acquired a PRAGMA-equivalent backbone. The distinctive competitive advantage from the model layer alone is measurable in quarters, not years. The distinctive advantage from the governance layer is measurable in a decade, because the regulation that mandates it is jurisdiction-specific, the identity infrastructure that satisfies it is jurisdiction-specific, and the formal apparatus that makes it operable — KROG’s deontic logic and jural correlatives, controlled natural language, the decision-capture schema — is specific to a small number of people who have spent the years required to work with it fluently.

The prescription

PRAGMA is the first half of a two-half problem. The half it solves is extraordinary: one backbone, six tasks, superhuman lifts on the tasks that have the right shape. The half it does not solve is the half that makes the first half legally deployable in Europe from August 2026 onward.

That second half has a known architecture. At the bottom, an append-only knowledge graph making every event queryable with cryptographic integrity. Above it, a layer with machine-evaluable obligations enabled by KROG. Above that, a rule layer expressing deontic specifications in logical form enabled by KROG. A conflict register detecting contradictions between rules. A credential and actor-registry layer carrying verifiable claims about who is authorized for what. A gateway evaluating every agent action against the rule set before execution. A human-decision layer capturing qualified signatures, delegation chains, and formally declared unknowns. A KPI and workflow layer tracking obligations against deadlines. A legal-basis layer grounding every processing activity. A strategy layer recording the institution’s declared intent. And an ecosystem layer tracking changes in external regulatory instruments so the whole stack updates when the law does.

Fourteen layers. Each answers a distinct question no other layer can answer. Each is a first-class component, not a feature of another component. This is the architecture I build and ship.

If you are Revolut, you have the representation layer. The question is whether the stack above it is being designed to the same standard of formal rigor — whether every FinCrime agent action is gated against explicit rules, whether every decision carries a knowledge-state and an authorization credential, whether the whole is queryable as a single graph rather than a collection of logs. If yes, there is an obvious commercial opportunity in productizing that governance stack for the banks that want PRAGMA-equivalent capability without your data scale. If not, this is the architecture to build next.

If you are SEB, Handelsbanken, DNB, Nordea, or any other European bank reading PRAGMA and wondering how to respond — the answer is not to build PRAGMA. It is to build the deontic layer first, prove it operationally, then acquire or build the representation layer on top once the governance substrate is in place. That order of operations suits a bank with a real compliance function, deep customer relationships, and regulatory obligations under seventeen frameworks already being managed by hand. The single concrete scenario I use to make this tangible: when the ECB or your national regulator asks “show us every AI-generated decision in the past year where human oversight was absent or overridden, with the full reasoning chain for each” — you either run a query and answer in hours, or you spend three months assembling evidence from disconnected systems. The architecture above makes the first possible. Nothing any bank currently has does.

Either way, the relevant question is not whether this layer needs to exist. The AI Act settles that by August. The relevant question is who builds it — and whether the institution builds it deliberately now or reconstructs it reactively in 2027.

I would like to have that conversation.

Paper: Ostroukhov et al., “PRAGMA: Revolut Foundation Model,” arXiv:2604.08649, April 2026. All performance figures in this piece are drawn directly from the paper’s own tables, including the -47.1% F₀.₅ AML result in Section 3.4.5. Complete rule logic by KROG.

Architecting Autonomous Law

16.3MB ∙ PDF file

Download

Download

Here’s a question that sounds philosophical but is actually an engineering problem: when an AI system writes a rule — a contract clause, a regulation, a company policy — how does it know whether the rule is good?

Today, it doesn’t. Every AI system that drafts legal text, reviews contracts, or proposes regulations is doing something fundamentally limited: it’s pattern-matching against existing rules. It has seen millions of contracts, thousands of statutes, and it produces output that looks like law. But it has no internal way of knowing whether what it produced is fair, proportionate, or sustainable. It can’t tell if a rule protects the people it’s supposed to protect. It can’t tell if a regulation will backfire.

This isn’t a minor gap. It’s the whole game.

A paper published in January 2026 by researchers at JudgeAI — Yuri Kozlov, Taaha Bajwa, and Maria Shutova — claims to have solved this problem. And after spending serious time with it, I believe they’re onto something profound.

The problem: AI has grammar but no compass

Think of it this way. Language has grammar — rules about how to form valid sentences. “The cat sat on the mat” is grammatically correct. So is “The mat sat on the cat.” Grammar tells you both sentences are well-formed. It doesn’t tell you which one describes reality.

Rules — legal rules, business rules, any kind of normative rule — have the same structure. There’s a grammar to them. A contract must have offer, acceptance, and consideration. A regulation must specify who it binds and what it requires. These structural requirements can be formalized, and in fact they have been. My own work on KROG (Knowledge, Rights, Obligations, Governance (https://krogrules.com)) builds on 30 years of deontic logic research, jural relations and formalizations into distinct bilateral legal positions. KROG proves that these positions are universal — the same structures appear in physics, chemistry, economics, game theory, and every other rule-governed domain.

But grammar alone doesn’t tell you whether a rule is admissible. You can write a perfectly well-formed contract that ruins one party. You can draft a structurally correct regulation that does more harm than good. The grammar is necessary, but it’s not sufficient.

What’s been missing is the compass — a principled way of determining which grammatically correct rules are also normatively acceptable.

That’s what Kozlov’s paper provides.

The solution: viability as the measuring stick

The paper’s core move is deceptively simple. Instead of starting from values, principles, or political preferences — the usual starting points for legal theory — it starts from a brute empirical fact: agents need to stay alive and functional.

Every person, every business, every organization exists within a space of possible futures. Some of those futures are viable — you survive, you can function, you can act. Others are not. The paper calls this space the Space of Viable Dynamics (SVD). Your SVD is essentially the range of futures where you’re okay.

A rule changes your SVD. A good workplace safety regulation expands it (fewer ways you can die on the job). A bad monopoly grant shrinks it for competitors (fewer paths to economic survival). A blanket ban on face coverings shrinks it for religious minorities (fewer ways to live according to your beliefs).

Here’s the key insight: you don’t need a theory of values to know that shrinking someone’s SVD below the survival threshold is bad. It’s bad because death is irreversible, disability is irreversible, imprisonment is largely irreversible, and bankruptcy, while recoverable, is still harmful. This isn’t ethics. It’s physics. Irreversible losses cannot be undone.

From this one empirical premise, the paper derives three results:

1. SVD is the unique value measure. Given evolutionary and biological constraints, the only thing that ultimately matters to an agent is the volume of its viable futures. Everything else — preferences, goals, values — reduces to this.

2. The Threat Index (TI) is the unique threat measure. Threats to viability travel through causal chains: a factory emits pollution, which causes exposure, which causes disease, which causes death. The Threat Index weighs these chains by their probability, length, and irreversibility. Short chains to irreversible outcomes get the highest weight.

3. The only sustainable rule is the minimax rule. The admissible regulation minimizes the maximum threat across all agents. Not the average threat. Not the total threat. The worst case for the worst-off agent. Any other principle is unstable — agents facing intolerable risk will withdraw (literally or through non-compliance), triggering a cascade of collapse.

These three results are proven formally. They’re not suggestions. They’re mathematical consequences of the starting premises.

What happens when you test it

The paper doesn’t stop at theory. It includes an empirical appendix where the system — operating with zero knowledge of existing laws — was given abstract regulatory dilemmas and asked to produce rules using only the SVD/TI/minimax logic.

The results were then compared, after the fact, to real-world legislation.

Some findings:

It converged with well-grounded laws. On environmental protection, it independently arrived at something close to Germany’s constitutional clause on protecting natural foundations of life — but went further by requiring measurable thresholds and mandatory review. On alcohol regulation, it produced a variant of the Scandinavian model, but with more nuance: strict state control of strong spirits, licensed private sale of weaker beverages, and compensation for affected businesses.

It rejected symbolic and stigmatizing laws. On religious symbols, instead of endorsing France’s blanket ban on face coverings in public, it allowed coverings by default and permitted identity checks only in specific high-risk zones (airports, government buildings) during verified security situations. On Russia’s “foreign agent” law, it replaced the stigmatizing label with objective financial transparency thresholds: if foreign funding exceeds 10% of your budget, you disclose it, but you’re never labelled a “foreign agent.”

It refined blunt but well-intentioned laws. On California’s AB5 gig worker classification, instead of the binary employee-or-contractor test, it created a layered system: mandatory insurance per trip, working-time limits, a portable benefits wallet, and a Dependency Index that triggers reclassification only when actual dependency exceeds a threshold. On whistleblower rewards (Dodd-Frank), it kept the incentive but added filters against fraudulent reports and proportional sanctions for abuse.

It resisted panic legislation. When given the abstract version of Florida’s law banning social media platforms from removing political candidates, it refused the blanket prohibition. Instead, it created a dedicated Candidate Channel with guaranteed delivery, narrow exceptions for incitement to violence, and an independent rapid review panel for disputed removals.

Across 22 test cases, the AI-generated norms scored roughly 25/35 on Regulatory Impact Assessment criteria, compared to about 8/35 for the real-world laws they were compared against. The biggest advantages were in monitoring and review (existing laws almost never include sunset clauses), proportionality (existing laws tend toward blanket rules where targeted ones would work), and stakeholder impact (existing laws often ignore affected groups).

How this connects to the structural grammar

Here’s where the two pieces come together.

KROG provides the grammar — the bilateral positions that describe every possible relationship between two agents. These positions tell you the structure of a rule: who can do what, who must do what, who is forbidden from doing what.

Kozlov’s framework provides the compass — the criterion for choosing which of those structures is admissible.

In technical terms, the three Kozlov constructs map directly onto KROG’s structural vocabulary:

• SVD maps to what KROG calls an R7 (conservation) constraint — the system must preserve each agent’s viability, the same way physics preserves energy.
  
  

• Threat Index maps to chains of what KROG calls an R15 (causal) relationships — one event triggers another, which triggers another, culminating in harm. The weighting function mirrors how causal chains become less reliable the longer they get, which is the same mathematics that explains why quantum systems lose coherence and why entropy increases.
  
  

• Minimax maps to a combination of what KROG calls an R25 (the system must respond to the worst case) and R14 (the solution is an equilibrium from which no one benefits by deviating) — the same patterns that describe Nash equilibrium in game theory, thermal equilibrium in physics, and market clearing in economics.
  
  

These aren’t metaphors. They’re mathematical isomorphisms. The same formal structures appear in every rule-governed domain because rules, at the deepest level, all work the same way.

Why this matters now

Three practical implications:

For AI governance: We’re in the middle of a global race to regulate AI. The frameworks being proposed — the EU AI Act, executive orders, voluntary commitments — are all designed by human committees through political negotiation. Kozlov’s work suggests that a principled alternative exists: derive the regulation from the empirical structure of risks. The paper’s own AI development simulation found that “certification-only deployment” minimizes worst-case risk across both society and developers — with mandatory pre-market testing, sandbox pilots, sectoral bans until certification, and a nine-month mandatory review. Not because someone decided that was politically palatable, but because the mathematics selected it.

For contract drafting and review: Every contract is a choice among possible R-type configurations. Today, lawyers make this choice based on precedent, negotiation leverage, and judgment. A normative admissibility layer can flag when a contract is structurally imbalanced — when one party bears disproportionate worst-case risk — and suggest rebalancing. Not by appealing to fairness as a feeling, but by computing threat indices and identifying the minimax-optimal configuration.

For the is-ought gap: Philosophy has struggled for centuries with the question of whether you can derive “ought” from “is.” Kozlov’s answer is carefully scoped: you can derive normative admissibility from empirical viability constraints, if you accept that irreversible harm is categorically worse than reversible harm. This isn’t a full moral theory. But it’s enough to build a compass that works — one that an AI system can use internally, without human judgment in the loop, to distinguish between rules that protect people and rules that don’t.

The limitation worth noting

The paper is honest about one significant problem: the rules it generates are hyper-complex. The minimax algorithm, seeking to balance every competing interest with every safeguard, produces regulatory structures that are too elaborate for direct legislative use. The digital tax rewrite, for example, includes phased introduction, automatic suspension triggers, escrow accounts, earmarked SME relief, data minimization rules, KPIs, and six-month review cycles.

The authors argue this is the easy problem. Building the logic of justice is hard; simplifying a hyper-detailed rule while preserving its internal balance is comparatively straightforward, provided the simplification is itself algorithmic rather than discretionary. They demonstrate this with a compression algorithm that reduces a fourteen-clause regulatory package to a six-article statute that preserves the core protections.

I’d add that KROG’s bilateral decomposition — the proven theorem that any complex rule decomposes into a network of 35 basic relationship types — provides the formal basis for this compression. You identify which bilateral relationships are structurally essential and which are redundant. The essential ones stay; the rest move to secondary regulation.

What comes next

What we now have, for the first time, is a complete architecture:

KROG provides the structural grammar — every rule, in every domain, decomposes into the same bilateral positions.

SVD/TI/Minimax provides the selection criterion — among all structurally valid rules, only those that minimize worst-case irreversible harm are admissible.

The MES Gates provide implementation validation — admissible rules must also be clear (objectively testable), arbitrated (independently reviewable), enforceable (with binding consequences), and learnable (with built-in feedback and revision).

The RG flow dynamics provide stability analysis — predicting which rule configurations will survive over time and which will decay toward rigidity or collapse.

This isn’t a chatbot generating legal text. It’s a formal system that can reason about whether its own outputs are normatively sound. That’s a fundamentally different kind of AI — one that doesn’t just produce rules, but knows which rules it should produce.

Whether this becomes the basis for actual autonomous lawmaking is a political and institutional question, not a technical one. The technical question — can an AI system have an internal, falsifiable normative logic? — appears to have been answered.

Yes. It can. And the mathematics are surprisingly elegant.

The full paper — “Formal Conditions for Autonomous Normative Rule-Making” by Kozlov, Bajwa & Shutova (JudgeAI Research, January 2026) — is worth reading in its entirety, particularly the empirical appendix where theory meets twenty-two real regulatory dilemmas.

Share Georg Philip Krog