Standardized Definitions For Variable Names

The point of this list is to allow you to use interview questions someone else wrote and design shareable interviews that require the minimum of adaptation. If you choose the names and object types listed below, your interview should be maximally compatible.

This list makes extensive use of Docassemble objects, and objects from packages created by Greater Boston Legal Services. You'll need to understand the very basics of objects to make the best use of this list. E.g., we only define client as an Individual, because Individuals automatically have a name.first, birthday, phone_number etc. attribute. There's no need to come up with a sub-convention for those common attributes of an individual.

The overall style is to use short, descriptive, English-language nouns that will be commonly understood to map onto the meaning in the interview. Underscores will separate multiple-word names. Lists will be indicated with the standard plural form of the singular noun.

In Docassemble (via Python), object variable names are references. So the same object may be referred to by multiple variable names. E.g., client can also have an alias of petitioner.

Common Actors: variable names for various parties or people who might be named in an interview

Some common actors might be both singular or plural. Your template (and interview) should handle both situations with an if/else statement. Actors might be Individuals, Organizations, or just generic Persons (which relates mostly to whether they have a first/last name or not). It's a good practice to write your interview to work with all forms of legal persons.

• user: Individual
• applicant: Individual
• client: Individual
• clients: DAList of Individuals
• spouse: Individual
• guardian: Individual
• household: DAList of Individuals
• children: DAList of Individuals
• adverse_party: Person
• adverse_parties: DAList of Persons
• advocate: Individual
• judge: Individual
• hearing_officer: Individual
• plaintiff: Person
• plaintiffs: DAList of Persons
• defendant: Person
• defendants: DAList of Persons
• petitioner: Person
• petitioners: DAList of Persons
• respondent: Person
• respondents: DAList of Persons
• parent: Individual
• employer: Person

Business actors

• officers: DAList of [Individuals]
• company: Organization

Attributes: information that you might gather about an actor

These attributes would commonly be attached to an actor. e.g., client.jobs, etc.

Attributes related to the individual

• ssn: text
• is_employed: yesno
• is_veteran: yesno
• occupation: text Question: is this better captured as an attribute of a job?
• is_disabled: yesno
• disability: text
• gender: choices
• email: email
• marital_status: choices
• birthdate: date

Attributes related to income

• incomes: IncomeList
• jobs: JobList
• vehicles: VehicleList
• real_estate: IncomeList
• assets: IncomeList
• expenses: IncomeList

Entities: non-person entities that might be named in an interview

• court: Court
• case

Elements: legal elements that might be referenced in a template or interview

• claims: a list or dictionary of legal claims that are true/false, with sub attributes. You can iterate over this list and display only the claims that the user of the interview wants included in the form. We should define a class to represent this type of object.
• defenses: same as above, but for defenses
• affirmative_defenses: same as above, but for affirmative defenses
• counterclaims: same as above, but for counterclaims (claims by defendant)
• interrogatories: list of discovery interrogatories
• document_requests: list of discovery document requests
• admissions: list of discovery requests for admission
• pleadings: list of different types of pleading documents that may appear in the case Or am I misreading the basic-questions.yml file and this is actually a different kind of object as a whole that should be split out completely.