Transcript Document
Best Practices for Building Legal
Knowledge Bases
Michael Poulshock
Wolfram Data Summit
September 4-5, 2014
<lighthearted_introductory_banter/>
About me
o Legal knowledge engineer
o Lawyer + programmer
o Work at Exeter Group
o Build systems that automate law
and policy
Automating the law?
o Encoding legal rules
o Applying the rules to fact patterns
o Getting legal conclusions or
“determinations”
o Embedding this functionality in a
larger system
Vocab
o
o
o
o
o
o
o
o
Expert systems
Business rule engines
Knowledge base
Knowledge engineering
Policy automation / modeling
Decision support systems
Calculators
Computational law
Examples
irs.gov/ita
Benefits of automation
o Consistency
o Speed
o Cost-effectiveness
o Auditability
o Breadth of knowledge
o Updated as the law changes
Best Practices
“An expert is a person who has
made all the mistakes that can
be made in a very narrow
field.”
Niels Bohr
1. Declarative paradigm
o Procedural (step-by-step)
o Declarative (if-then)
o Policy rules tend to be expressed
declaratively
o Procedural representations (such as
flowcharts) do not scale well
1. Declarative paradigm
procedural
declarative
the transaction is in compliance if
the amount < $10,000 or
the date > 2014-12-31 or
the type = “Intracompany”
compliesQ[t_] :=
amount[t] < 10000 ||
date[t] > {2014, 12, 31} ||
type[t] == “Intracompany”
2. Isomorphism
o Code should be structured similarly
to the policy rules
o Correspondence / traceability
o Rule verification
o Maintenance
2. Isomorphism
the waiver of inadmissability is valid under 8 CFR
1207.3(b) if
the basis = “Humanitarian grounds” or
the basis = “Family unity” or
the basis = “Public interest”
2. Isomorphism - techniques
o Use domain vocabulary
o Follow document structure
o Include citations
o Add code comments documenting
assumptions, etc.
3. Cross-trained developers
o Programmers lawyers
o Lawyers programmers
o Center of Excellence approach
o Handling changes in the law
o Fundamentally, this is programming
Tree-like structure of legal rules
the person is liable for the tax if
the person’s income >= $12,000 and
the person is not a tax dependent
the person’s income = ...
the person is a tax dependent if...
Tree-like structure of legal rules
Tree-like structure of legal rules
Tree-like structure of legal rules
4. Tool that can analyze the tree
o Fundamental challenge:
o How do you know what the inputs are for
a particular goal?
o How do you know which are relevant?
o Need a tool that can collect data in
automated way
o Debugging
o Dynamic interviews
5. Separation of policy rules
o Fundamental tension between
declarative rules and interview
behavior
o Don’t want to hard code interview
sequences
o But we want a humane and
empathetic user experience
5. Separation of policy rules
o Best practice is to separate policy logic
from other types of rules, such as:
o Interview sequence
o Interview messages and visibility
o Data transformation
o Data validation
6. Time
Why time is complicated:
1.
2.
3.
4.
Laws change
Facts change
The way facts change matters
Points of reference change
6. Time
o Handling time can easily make a
mess of your code
o Need to address time early on
o Backdrop of absolute time
o Need functions and data structures
for handling time
7. Knowledge of ignorance
o Not all law is worth
automating
o Granularity
o Models are always
approximate
o Systems need to know what
they don’t know and route
those cases to humans
8. Sufficiently expressive language
o Many tools out there
o Some geared to business users
o Many not expressive enough
o Many not extendable
o Functional programming is preferable
o Conservation of complexity
9. General software best practices
a) Functional programming
b) Unit testing
c) Refactoring
Closing thoughts
o Law is inherently complex
o Legal logic is fractal-esque
o Law is more computational than it may
first appear
o Wrapper / interface around the law’s
complexity
o Making the law more accessible
Thank you!
Michael Poulshock
[email protected]
www.linkedin.com/in/mpoulshock