Using docassemble in legal applications
One “use case” for docassemble is the creation of web applications
that help people with legal problems. The
contains a Python module
docassemble.base.legal that defines some
helpful Python classes and functions. It also contains a helpful
To gain access to the functionality of
include the following in your interview file:
Classes for information about things in a court case
Court has one attribute:
name: e.g., “Court of Common Pleas of Butler County”
If you refer to an address in a template, it returns
Court class has the following methods:
in_the_court(): returns the top line of the first page of a pleading filed in this court. It takes two optional keyword arguments:
case, representing the relevant
Casethat might be relevant for determining the content of the “In the Court” line.
If you create an object of type
Case by doing:
then you will create an object with the following built-in attributes:
case.plaintiff(object of class
case.defendant(object of class
case.case_id(text initialized to “”)
In addition, the following attributes will be created:
case.firstParty: set equal to
case.secondParty: set equal to
The idea here is that
defendant are the default
parties to the case, but you can change this if you want. For
example, you could do:
Case class also has the following attribute, which is undefined
Courtin which the case is filed.
Case class has the following methods:
parties(): returns a list of all parties to the case (namely, all elements of any attributes of the
PartyLists. Calling this method will trigger “gathering” the elements of each
all_known_people(): this is like
parties(), except that it includes children of each individual, and does not trigger the gathering of the
role_of(party): Looks for
PartyListattributes of the case and returns the attribute name of the
partywas found (e.g.,
defendant, etc.), or
partywas not found in any of the lists.
set_action_type(action_type): Possibilities are
'plaintiff defendant'. The default is
'plaintiff defendant'. This will determine the types of
case_id_in_caption(): returns the Markdown text for the case ID that will appear in the case caption.
determine_court(): runs code, if any exists, to determine what court has jurisdiction over the case.
Jurisdiction has the following attributes:
Document has the following attributes:
LegalFiling is a subclass of
It has the following attributes (in addition to
Caseobject in which the document is filed.
It has one method:
caption(): returns a case caption suitable for inclusion in a docassemble document. If
LegalFiling, then including
pleading.caption()will require the following:
Adjusting for jurisdictional variation
docassemble is an ideal platform for legal interviews that are applicable in multiple jurisdictions. The features of object-oriented programming are well-adapted to representing general rules that can be overridden by special cases, state rules that can be overriden by local rules, old law that is partially overridden by new law.
The features of software packaging and the nested importation of
software libraries enable collaboration among legal experts. For
example, suppose Lawyer A is an expert in the general family law of
California. Lawyer B is an expert in how that law is applied in Los
Angeles. Lawyer C is an expert in how that law is applied in San
Francisco. Lawyer A can develop the package
containing classes and methods for applying California Family Law to
the facts of cases. Lawyer B can develop the package
docassemble.family-ca-la, which imports
makes modifications to the classes as necessary to express the local
variations in Los Angeles. Lawyer C can develop the package
docassemble.family-ca-sf, which does the same for San Francisco.
All three lawyers will take responsibility for maintaining their code.
Then, Lawyer D could develop a statewide interview for a family law
pleading, using the packages
docassemble.family-ca-sf. Lawyer D would not need to research the
special variations of law in San Francisco and Los Angeles because
Lawyers B and C will do all that work; Lawyer D would just need to put
the pieces together.
Lawyers A, B and C will not need to become experts in each others’
areas of law, or understand each others’ code, but they will need to
cooperate around using a “common language.” For example, if Lawyer B
thinks about using an attribute
.driver_license_number, but Lawyer C
has already used
.drivers_license_id to represent the same concept,
Lawyer B should notice that Lawyer C has started to use
.drivers_license_id and should use the same naming convention. In
order to facilitate collaboration, Lawyers B and C will need to
document their work clearly and concisely. They may also need to
communicate with one another. This communication could take place
formally, for example through a committee that has meetings or
conference calls, or it could take place informally, through an e-mail
distribution list or a Slack channel.