Edit this page on GitHub

The "legal" module and basic-questions.yml

Using docassemble in legal applications

One “use case” for docassemble is the creation of web applications that help people with legal problems. The docassemble.base package contains a Python module docassemble.base.legal that defines some helpful Python classes and functions. It also contains a helpful set of questions and code blocks, docassemble.base:data/questions/basic-questions.yml.

To gain access to the functionality of docassemble.base.legal, include the following in your interview file:

  - docassemble.base.legal

Or, if you want the functionality of docassemble.base.legal as well as access to the basic-questions.yml questions, do this instead:

  - basic-questions.yml

The best way to understand what these resources offer is to read the source code of legal.py and basic-questions.yml.

Classes for information about things in a court case


A Court has one attribute:

  • name: e.g., “Court of Common Pleas of Butler County”

If you refer to a Court in a template, it returns .name.

The 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: legalfiling and case, representing the relevant LegalFiling and the Case that might be relevant for determining the content of the “In the Court” line.


If you create an object of type Case by doing:

  - case: Case

then you will create an object with the following built-in attributes:

  • case.plaintiff (object of class PartyList)
  • case.defendant (object of class PartyList)
  • case.case_id (text initialized to “”)

In addition, the following attributes will be created:

  • case.firstParty: set equal to case.plaintiff
  • case.secondParty: set equal to case.defendant

The idea here is that plaintiff and defendant are the default parties to the case, but you can change this if you want. For example, you could do:

  - docassemble.base.legal
  - case: Case
mandatory: True
code: |
  del case.plaintiff
  del case.defendant
  case.initializeAttribute(name='petitioner', objectType=PartyList)
  case.initializeAttribute(name='respondent', objectType=PartyList)
  case.firstParty = case.petitioner
  case.secondParty = case.respondent

The Case class also has the following attribute, which is undefined at first:

  • court: the Court in which the case is filed.

The Case class has the following methods:

  • parties(): returns a list of all parties to the case (namely, all elements of any attributes of the Case that are PartyLists. Calling this method will trigger “gathering” the elements of each PartyList.
  • all_known_people(): this is like parties(), except that it includes children of each individual, and does not trigger the gathering of the PartyLists.
  • role_of(party): Looks for party within the PartyList attributes of the case and returns the attribute name of the PartyList in which party was found (e.g., plaintiff, defendant, etc.), or third party if party was not found in any of the lists.
  • set_action_type(action_type): Possibilities are 'solo petition', 'in re', 'petition', and 'plaintiff defendant'. The default is 'plaintiff defendant'. This will determine the types of PartyList attributes.
  • 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.


A Jurisdiction has the following attributes:

  • state
  • county


A Document has the following attributes:

  • title


LegalFiling is a subclass of Document.

It has the following attributes (in addition to title):

  • case: the Case object in which the document is filed.

It has one method:

  • caption(): returns a case caption suitable for inclusion in a docassemble document. If pleading is a LegalFiling, then including pleading.caption() will require the following:
    • pleading.case
    • pleading.case.firstParty.gathered
    • pleading.case.secondParty.gathered
    • pleading.case.court.name
    • pleading.title

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 docassemble.family-ca 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 docassemble.family-ca and 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 and 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.