Rules as Code Demonstration in SWISH and s(CASP)

Rules as Code transforms legislative requirements into executable code, enabling automated legal reasoning and decision-making. This demonstration shows how to encode Singapore’s Legal Profession Rule 34 using SWI-Prolog and s(CASP), creating a system that can answer complex legal questions with natural language explanations.

What Rules as Code Achieves

Traditional legal analysis requires manual interpretation of complex regulatory text. Rules as Code converts legislation into structured logic that computers can process directly. This approach offers several advantages:

• Automated reasoning: Systems answer legal questions without human interpretation
• Transparent explanations: Users receive step-by-step justifications for conclusions
• Consistency: Identical fact patterns always produce identical results
• Scalability: Handle thousands of cases simultaneously

The s(CASP) Advantage

s(CASP) (stable Constraint Answer Set Programming) extends traditional logic programming with defeasible reasoning capabilities. This means it can handle legal concepts like exceptions, overrides, and conflicting rules - common features in real legislation.

Key s(CASP) features for legal encoding:

• Defeasible reasoning: Rules can override other rules
• Natural language generation: Automatic explanations in readable text
• Abductive reasoning: Answer “what if” questions with partial information
• Constraint handling: Maintain complex legal requirements

Encoding Legal Rules

Basic Structure

Each legal provision becomes a Prolog rule. For example, Rule 34(1) states that legal practitioners must not accept executive appointments in certain businesses:

1
2
3
4
5
6

according_to(r34_1, must_not(Actor, accept, Appointment)) :-
    legal_practitioner(Actor),
    associated_with(Appointment, Business),
    business(Business),
    according_to(Rule, described_in_s1(Business)),
    executive_appointment(Appointment).

This rule reads: “According to Rule 34(1), an actor must not accept an appointment if the actor is a legal practitioner, the appointment is associated with a business, that business is described in section 1, and the appointment is an executive appointment.”

Handling Exceptions and Overrides

Legal rules often contain exceptions. s(CASP) handles these through opposition and override relationships:

1
2

opposes(r34_1, must_not(LP,accept,EA), r34_2_a, may(LP,accept,EA)).
overrides(r34_1, must_not(LP,accept,EA), r34_2_a, may(LP,accept,EA)).

This declares that Rule 34(1) conflicts with Rule 34(2)(a) and takes precedence.

Natural Language Definitions

s(CASP) generates explanations using predicate definitions:

1
2

#pred legally_holds(Rule,may(Y,accept,Z)) :: 
    'it holds in accordance with @(Rule) that @(Y) is permitted to accept @(Z)'.

These definitions convert logical predicates into readable explanations.

Practical Applications

Specific Fact Scenarios

Define a concrete situation and ask specific questions:

1
2
3
4

legal_practitioner(jill).
corporation(megacorp).
position(ceo).
in(ceo, megacorp).

Query: legally_holds(Rule, must_not(jill, accept, ceo))

The system returns not just “yes” or “no” but a complete explanation citing relevant rule sections.

Partial Information Reasoning

Use abducible predicates when information is uncertain:

1

#abducible materially_interferes_with(ceo, practicing_as_a_lawyer, _).

The system explores multiple scenarios, showing which conclusions require additional assumptions.

Reverse Engineering

Ask what fact patterns would satisfy a legal conclusion:

1

? business_entity(X).

This generates all possible ways something could qualify as a business entity under the rules.

Implementation Benefits

Structural Isomorphism

Each section of law maps directly to code sections. When legislation changes, you know exactly which code to modify. This one-to-one correspondence simplifies maintenance and review.

Knowledge Representation vs Programming

This approach represents legal knowledge rather than implementing algorithms. You describe what the law says without specifying how to compute answers. The reasoning engine handles the computational complexity.

Quality Assurance

Multiple models for the same conclusion reveal ambiguities in either the law or the encoding. If a simple question generates numerous explanations, it may indicate drafting issues or encoding problems.

Deployment Options

SWISH notebooks serve as development and documentation environments. For production deployment:

1. Web APIs: SWI-Prolog provides REST endpoints accepting queries and returning JSON responses
2. Integration: Applications format their data as predicates and query the reasoning service
3. Scaling: Deploy multiple reasoning engines behind load balancers

Getting Started

1. Choose a simple rule: Start with straightforward provisions before tackling complex exceptions
2. Define predicates: Create natural language definitions for all key concepts
3. Encode incrementally: Translate one section at a time, maintaining structural correspondence
4. Test thoroughly: Use both specific scenarios and abductive queries to verify behavior
5. Document decisions: Explain encoding choices for future maintainers

Rules as Code with s(CASP) transforms static legal text into dynamic reasoning systems. By maintaining close correspondence between law and code, these systems provide reliable, explainable legal automation that scales with regulatory complexity.