RSS Amplifier

PAICE.work · Jul 23, 2026

Why ObligationFirst Looks Different from LegalRuleML and Akoma Ntoso

0
Sign in to vote or save

Sam Rogers · PAICE.work

Note: this post was revised upon the release of v0.5.0 on July 25

When we introduced ObligationFirst, we said it was not the first attempt to make law machine-readable, but that it was, to our knowledge, the first one built for agents. That is easy to assert and harder to demonstrate. This post is the demonstration, against the current spec (v0.5.0) rather than against intentions.

The comparison is with the two most influential predecessors: Akoma Ntoso, the OASIS standard for legal documents, and LegalRuleML, the OASIS standard for the rules those documents express. Both are mature. Both work well for the audiences they were built for. Neither was designed for a system that has to decide whether it may act right now, and that difference shows up in the field choices.

Share

Akoma Ntoso is an XML vocabulary for legislative and judicial documents: sections, articles, paragraphs, references, amendments, signatures. It has been an OASIS Standard since 2018 and is used in production by the Italian Senate, the Brazilian Congress, and the Kenyan parliament, among others. It is excellent at representing what a legal document is and how its parts connect to other documents.

LegalRuleML is the OASIS standard for representing legal norms, built on RuleML. It supplies explicit deontic operators (Obligation, Permission, Prohibition, Reparation) and handles defeasibility through DefeasibleRule and exception hierarchies. It is the rule layer that sits, conceptually, above the document layer.

These standards are mature and useful. Where ObligationFirst binds to them, we want to be explicit about that. Where it diverges, the divergence is deliberate and the audience is the explanation.

Akoma Ntoso was designed for parliaments, courts, and the human-operated legal-tech tools that ingest their output. The granularity reflects that. A section is a section. An amendment is a tracked change. Fidelity matters because the consumers are drafters and lawyers.

LegalRuleML was designed for legal reasoning engines and the research community that builds them. It is expressive by intent: it can encode complex deontic relationships, defeasible rules, and exception hierarchies, because its consumers must handle edge cases the way a careful lawyer would.

ObligationFirst is designed for an agent deciding whether and how to perform an action. That agent needs to know: does this duty apply to me, what does it require, is it enforceable today, and what backs the citation. The expressiveness budget goes to operational fields, not to encoding every nuance a future reasoner might want.

The clearest signal of intent is what the schema refuses to own.

Where an authoritative Akoma Ntoso encoding exists, an ObligationFirst record references it rather than restating it. The Akoma Ntoso element IRI rides on the record as a typed akn_uri crosswalk, never as the identifier. eli_uri, urn_lex, and citation do the same job for the European Legislation Identifier, urn:lex, and conventional citation. The entity classes bind to the Semantic Arts gist upper ontology rather than inventing a new one.

Akoma Ntoso models documents. ObligationFirst models the normative content those documents create. The crosswalk between them is explicit about the gap: for of:Obligation, the Akoma Ntoso column reads “no direct equivalent,” because Akoma Ntoso encodes text and obligations are derived from text by interpretation. That gap is the whole reason the schema exists.

In LegalRuleML, a single statutory provision can decompose into several rules, each with its own deontic operator, conditions, and exception structure. That is right for reasoning and awkward for an agent that needs one answer.

ObligationFirst keeps the obligation as the unit. One duty, one record, reachable at a stable IRI.

We paid a real price for that, which recently came due. Holding the obligation as the unit tempts you to make the unit too coarse. Our own reference implementation did exactly that: EveryAILaw published ten broad concepts (transparency, human oversight, bias prevention, and so on) as its obligation records, so 134 statutory terms collapsed into ten. Queries returned a category when they should have returned a duty.

The fix, shipped now in v0.5.0, was a second type rather than a looser one. of:ObligationCategory holds the jurisdiction-neutral concept; obligations join their category through skos:exactMatch. A category carries no jurisdiction, no duty holder, and no creating term, because nobody can comply with a category. Two laws in different jurisdictions stay comparable through the concept layer, while the duty layer stays faithful to what each statute actually requires.

That is the tradeoff in its honest form. Cross-jurisdictional commensurability is genuinely valuable, and it belongs in its own type rather than smuggled into the obligation.

The largest structural difference is not a field choice. It is an entire strand.

LegalRuleML models the rule, not the legal matter that turns on the rule. It has no formal representation of a proceeding, an allegation, or a ruling. Akoma Ntoso can represent the judgment document a court produces, but not the matter that produced it as a queryable object.

ObligationFirst adds of:Proceeding, of:Allegation, and of:Determination. The alleged-versus-determined split is the point: an assertion in a legal matter is alleged until it is decided, and modeling that as a status flag on one entity forces premature classification. Three types preserve the distinction. An allegation is what was asserted. A determination is what was decided. A proceeding accumulates both over its life.

This is what lets a ruling attach to the duty it interprets. Across the three live implementations there are currently 59 such cross-project references, every one of them resolving.

A statute can be on the books and unenforceable at the same time. Both facts matter to an agent.

ObligationFirst splits them into two flat fields on the instrument. status carries the legislative state (proposed, enacted, in-force, amended, sunset, repealed, superseded, withdrawn). enforcement_status carries whether the duties can presently be enforced (routine, constrained, unsignaled). They are independent, and any combination is valid.

What the enum deliberately does not carry is the reason. There is no stayed-by-court, no enjoined, no pending-rulemaking. The cause lives in the proceeding strand, as a determination that anchors to the affected obligation.

This costs an extra hop for anyone who wants to display “stayed pending rulemaking” as a single phrase, and the spec says so in as many words. We take that cost on purpose. Causes of non-enforcement are open-ended: court orders, agency posture, legislative pauses, executive action, emergency declarations. Every new one would otherwise mean an enum extension and an adopter migration. Several causes can also apply at once, and a scalar field can hold only one. Factoring cause out is also what makes two jurisdictions comparable, since both can be constrained for entirely different reasons.

The pattern has held up downstream. PubLedge independently split its own instrument records into legal status and editorial status, and added an obligation-level lifecycle vocabulary that includes never-operative, for a duty that was enacted but whose implementing instrument ended before it ever took effect. Neither predecessor expresses that cleanly.

Akoma Ntoso handles versioning through amendments and consolidated versions, with an amendment graph faithful to legislative process. LegalRuleML handles it through temporal conditions on the rule.

ObligationFirst separates two things that are easy to conflate. Whole-instrument replacement is supersedes, asserted instrument to instrument after enactment, with wouldSupersede for the subjunctive case before it. Clause-level override is defeats, asserted term to term.

That second relation is where we kept more of LegalRuleML than a “simpler schema” story would suggest. defeats has two subproperties, rebuts and undercuts, carrying exactly the LegalRuleML distinction: a rebutting term asserts the opposite conclusion, an undercutting term denies that the rule applies here at all without contradicting it elsewhere. We did not flatten the exception structure. We moved it from inside a rule to between terms, where an agent can traverse it.

Colorado is the live example. SB 24-205 is recorded as no longer operative, replaced by SB 26-189, which takes effect 1 January 2027. The successor relationship is asserted, not inferred, and a date-filtered query returns whichever duty was operative on the date asked about. Nothing is overwritten in place; the older record stays for litigants and historians.

Both predecessors assume a document you can point at. A federation of independently published legal datasets has a problem neither addresses: whose identifier wins.

ObligationFirst’s answer is that no one’s does. Every record identifier is adopter-local, opaque, and permanent, and cross-dataset joins ride on standard crosswalks rather than shared slugs. Each publisher declares its own identifier grammar in a machine-readable profile at /.well-known/obligation-first-naming-profile.jsonld, which states the URI pattern for each entity type and which crosswalks it supplies. The spec validates that profile; it never prescribes the grammar.

This is unglamorous and it is what makes the graph work. Three independently maintained datasets, 579 records, no central registry, no coordinated renaming.

None of these differences are arguments against LegalRuleML or Akoma Ntoso. They are arguments for shaping a schema around its consumer.

Where the data overlaps, mapping is in scope and already partly written. The deontic quartet aligns one-to-one with LegalRuleML’s four operators, and of:Reparation is kept as a distinct subclass specifically to preserve that alignment. The crosswalk documents pass a Term’s rule logic to a LegalRuleML encoding through an lrml_encoded_as field, though we should be precise about status: that is documented in the crosswalk, not yet a predicate in the schema, and whether to formalize it is still an open question in the spec. of:executableEncoding already points at Catala, Blawx, or OpenFisca encodings, so the executable-rules work of that community composes rather than competes.

Two honest limits. of:Reparation has, so far, zero instances across the live implementations, so the fourth operator’s alignment is designed and not yet exercised. And the mappings are not free and will not always be lossless.

We expect mature deployments to run several schemas at once, each serving the consumer it was shaped for. ObligationFirst is the agent-facing surface. The others remain useful behind it.

If you are building something that has to operate inside a regulated environment, a compliance copilot, an audit pipeline, a regulator-facing dashboard, ObligationFirst is shaped for your queries. Start there.

If you’re doing rigorous legal reasoning research, or building tooling for legislative drafters, LegalRuleML and Akoma Ntoso remain the right primary tools. Use ObligationFirst as the complementary surface where agent-facing query patterns are needed.

If you are building infrastructure others will adopt, the existence of multiple schemas is a feature. The interop points between them are where the ecosystem accumulates value, and pull requests against the mapping layer are welcome.

The agent-native framing is the contribution. The interoperability is how it stays useful as the ecosystem changes around it.

Have questions? Contact us or read our Privacy Policy.

No posts

Read the original on paice.substack.com

Comments

Nothing yet. Say the first thing.

    Sign in to join the conversation.