The Standards Landscape

After this lesson, the reader should understand:

• 01Describe the purpose and maturity of the main Law-as-Code standards.
• 02State, for each, what it establishes and what it leaves outside its scope.
• 03Position computable authority as a complementary layer, not a competitor.

A faithfully compiled program that cannot say who may run it

A tax rule is implemented in Catala with formal guarantees that it matches the statute. An agent invokes it and acts on the result. What is still missing?

The authority relationship around the invocation. Catala establishes that the computation is faithful to the law^[1] — a hard and valuable property. It does not establish which system is authorised to invoke that computation, under whose delegation, against which version of the institution's policy, or with what evidence. Akoma Ntoso would give the source a clean structure; LegalRuleML would represent the norm's logic; neither says the agent may act on it. Each standard solves a real layer. Computable authority is the layer that binds a faithful rule to an authorised actor at runtime^[2] — and it depends on the others rather than displacing them. The list above is drawn from the legal-informatics side, and two neighbours from the computing side are closer than it suggests. Access-control standards such as XACML already separate a policy decision point from the systems that enforce its answers^[3]; rights-expression languages such as W3C's ODRL already model a policy as permissions and duties with an assigner and an assignee^[4]; credential standards already carry an issuer and a validity period as first-class fields^[5]. Computable authority borrows from each. Its claim is narrower than novelty: that none of them binds a versioned, sealed rule set to an issuer, a delegation, and an evidence boundary in one object that a stranger can verify and evaluate. The strongest objection is the familiar one: the field has too many standards already, and adding another fragments it further. Why not extend LegalRuleML, or ODRL, instead? Take it seriously, because it is often right. The test of a new layer is whether it composes with existing ones rather than competing with them — whether an artifact can cite an Akoma Ntoso source by its identifier, carry a computation whose faithfulness Catala has established, and reuse established canonicalisation and signature schemes instead of inventing its own. Where an existing standard can carry a property, it should. The limit is maturity. Akoma Ntoso and LegalRuleML are OASIS standards with multi-party governance and years of implementation. The computable-authority specifications are drafts with, so far, a single implementation. 'A complementary layer, not a competitor' is a design intent. It becomes a demonstrated property only when someone other than the authors builds against the specification cold and the two implementations agree. Since this lecture was first written, two developments sharpen the comparison. On the agent side, the work NIST began has continued at the IETF, where the Web Bot Auth working group is standardising how automated clients sign their requests so that a service can verify which operator is behind them^[6]. That is identification, and it is useful: it tells a service who is calling. It does not tell the service whether to do what the agent asks, which depends on whom the agent acts for, under which rules, on which facts and with whose approval. A passport is the closer model. It does not prove that its holder is a person; it proves that a recognised issuer vouches for them, and the decision to admit is still made at the border under the border's own rules. Computable authority is the layer that answers the second question, and it sits above identification rather than competing with it^[7]. On maturity, the reference specifications for that layer now have two implementations, a Python reference and the hosted platform's verifier, which agree on every published test vector and on several hundred mutants derived from them. Both are by the specifications' authors, so the independence condition stated above stands unchanged.

• Which of these standards should a computable-authority artifact build on directly?
• Is 'faithful to the statute' the same claim as 'authorised to execute'?
• Where does the Rules-as-Code movement's experience most inform this work?
• What would interoperability between these layers actually require?
• Which property of an authority artifact could an existing standard already carry, and why hasn't it?
• What would a second, independent implementation have to show before the 'complementary layer' claim is established?

No responses yet. Be the first to answer one of the questions above.

Place one of your instruments across the layers.

1. 01Take a regulation your organisation must apply.
2. 02Describe how Akoma Ntoso would structure it and LegalRuleML would represent its norms.
3. 03Identify the parts that compute (Catala-style) and the parts that adjudicate.
4. 04State what an authority artifact would add on top: issuer, delegation, version, evidence.
5. 05Name the layer your organisation currently has, and the ones it does not.
6. 06For each property you assigned to the authority artifact, check whether XACML, ODRL, or a credential standard already carries it.