Field Reference (Codex)

This codex defines standard field names used across all template types. Using these consistent names ensures your templates work reliably and can be shared between matter types.

Why standardise?

When everyone uses client.surname instead of mixing client_surname, clientSurname, and Client.Surname, templates become:

• Portable — Work across different matter types
• Predictable — You always know what to type
• Maintainable — Easier to troubleshoot

---

Universal Fields

These fields exist in every matter type. Templates using only these fields can be shared across all practice areas.

Client (Primary)

Your main client’s details. The client.* fields always refer to the first (or only) client.

Field	Example	Description
client.full_name	Dwight Kurt Schrute	Complete legal name
client.surname	Schrute	Family name
client.given_name	Dwight Kurt	All first/middle names (canonical key)
client.given_names	Dwight Kurt	Alias for given_name (legacy templates)
client.first_name	Dwight	First given name only (used by newer templates)
client.title	Mr	Title (Mr, Mrs, Ms, Dr, etc.)
client.addressee	Mr D Schrute	For envelope/letter address
client.salutation	Mr Schrute	After “Dear” in letters
client.street_address	Schrute Farms, Rural Route 6	Street line
client.suburb	Scranton	Suburb/city
client.state	NSW	State abbreviation
client.postcode	2000	Postal code
client.address_single_line	Schrute Farms, Rural Route 6, Scranton NSW 2000	Full address on one line
client.email	[email protected]	Email address
client.phone	0400 123 456	Phone number
client.mobile	0400 123 456	Mobile (alias for phone)
client.occupation	Assistant Regional Manager	Profession
client.dob	1970-01-20	Date of birth

Addressee vs Salutation

• Addressee = How you address the envelope: Mr D Schrute
• Salutation = How you greet them: Dear Mr Schrute

For joint clients: Mr D Schrute and Ms A Martin vs Mr Schrute and Ms Martin

Multi-Client Fields

Matters can have multiple clients (e.g., couples doing joint Wills, joint property purchases). When a matter has multiple clients, indexed fields are automatically generated alongside the primary client.* fields.

Indexed Client Fields

Each additional client gets their own numbered set of fields:

Field	Example	Description
client1.full_name	Dwight Kurt Schrute	First client (same as client.*)
client1.surname	Schrute	First client surname
client1.given_names	Dwight Kurt	First client given names
client1.email	[email protected]	First client email
client2.full_name	Angela Noelle Martin	Second client
client2.surname	Martin	Second client surname
client2.given_names	Angela Noelle	Second client given names
client2.email	[email protected]	Second client email
client3.full_name	…	Third client (and so on)

All standard client.* fields are available on each indexed client (client1.phone, client2.street_address, etc.).

Backwards compatibility

The client.* fields (without a number) are always populated from the first client. Existing templates that use client.surname continue to work unchanged.

Address Verification (system-managed)

When a client’s postal address has been verified through the address picker, the engine projects these read-only keys alongside the editable address fields. They’re emitted under both the bare client.* prefix and each indexed client1.*, client2.* prefix.

Field	Example	Description
client.address_verified	true / ""	Verified flag. "" (engine-blanked from "false") when not verified.
client.address_verified_source	apple_maps / manual	How the address was verified.
client.address_verified_at	2026-05-22T03:14:00Z	ISO-8601 UTC timestamp of verification.
client.address_verified_fingerprint	v1:a1b2c3d4e5f60718	Stable hash of the verified address parts. Used at render time to detect drift.
client.verified_latitude	-33.8688100	Latitude (degrees, 7 dp) for the verified address.
client.verified_longitude	151.2092900	Longitude (degrees, 7 dp).

If the form’s address parts no longer match the verified fingerprint at render time, the engine inserts a [DRIFT: …] marker in the rendered document so the practitioner can confirm before signing.

Multi-Client Helper Fields

These are auto-generated when the matter has clients:

Field	Example	Description
clients.count	2	Number of clients on the matter
clients.is_couple	true	True if exactly 2 clients
clients.is_multi	true	True if more than 1 client
clients.names	Dwight Schrute & Angela Martin	All names joined with ” & “
clients.surnames	SCHRUTE & MARTIN	All surnames in CAPS

Using Multi-Client Fields in Templates

Conditional sections for couples:

{%p if clients.is_couple == 'true' %}
We act for {{ client1.full_name }} and {{ client2.full_name }} jointly.
{%p else %}
We act for {{ client.full_name }}.
{%p endif %}

Listing all client names:

{%p if clients.is_multi == 'true' %}
Our clients: {{ clients.names }}
{%p else %}
Our client: {{ client.full_name }}
{%p endif %}

Folder Naming with Multiple Clients

Clients	Folder Name
1	000109 - SCHRUTE Dwight - Will
2	000109 - SCHRUTE Dwight & MARTIN Angela - Will
3+	000109 - SCHRUTE Dwight & Others - Will

Matter

Information about the file itself.

Field	Example	Description
matter.number	2025-00042	Unique reference number
matter.name	SCHRUTE - Sale of Beet Farm	Short description
matter.type	Sale of Land	Matter category
matter.re_line	Sale of Schrute Farms	Reference line for letters
matter.person_acting	Jim Halpert	Solicitor with carriage
matter.person_assisting	Pam Beesly	Support staff
matter.property	Schrute Farms, Rural Route 6, Scranton	Property description (from CRM)
matter.sc_packet_no	SC-2025-0042	Safe custody packet number
matter.date_created	2025-01-15	When file was opened
matter.year_created	2025	Year opened

Auto-Sync: matter.type and matter.name

When matter.type is a dropdown (select) field in the form, Certum Draft automatically copies its value to matter.name when changed. This enables smart folder naming without extra data entry.

Template Pack	matter.type	matter.name	Folder Result
Sale of Land	Hidden, default “Sale”	User enters description	000107 - SCHRUTE Dwight - Sale of Schrute Farms
Estates	Hidden, default “Probate”	User enters description	000108 - PENDRAGON Arthur - Estate of Arthur Pendragon
Wills/POA/EG	Dropdown with options	Auto-filled from dropdown	000109 - SCHRUTE Dwight - Will, POA & EG

Users can still manually edit matter.name after auto-fill if they want something different.

Firm

Your firm’s details for letterheads and signature blocks. These are conventional names — the app does not auto-populate them from a global setting. Define them in each template’s matter.json (typically as fields with a default_value) or hard-code them into the precedent.

Field	Example	Description
firm.name	Dunder Mifflin Law	Firm’s full name
firm.street_address	1725 Slough Avenue	Office street
firm.suburb	Sydney	Office suburb
firm.state	NSW	Office state
firm.postcode	2000	Office postcode
firm.phone	02 9999 0199	Main phone
firm.fax	02 9999 0198	Fax number
firm.email	[email protected]	General email
firm.abn	12 345 678 901	ABN
firm.dx_address	DX 123 Sydney	DX address

Practitioner

The individual solicitor handling the matter. practitioner.full_name is auto-mapped by the engine from matter.person_acting, so you can drive both off the one form field.

Field	Example	Description
practitioner.full_name	James Duncan Halpert	Solicitor’s name (auto-mapped from matter.person_acting)
practitioner.title	Senior Associate	Position
practitioner.email	[email protected]	Direct email
practitioner.phone	02 9999 0101	Direct line
practitioner.mobile	0400 123 456	Mobile

Today (Auto-Injected at Render)

Current date fields, populated automatically by the engine when the document is generated. You don’t need to declare these in matter.json.

Field	Example	Description
today.date	27 January 2025	Current date (same as today.date_long)
today.date_long	27 January 2025	Current date (long form)
today.date_short	27/01/2025	Current date (DD/MM/YYYY)
today.date_iso	2025-01-27	Current date (ISO 8601)
today.day	27	Day of month
today.month	January	Month name
today.year	2025	Year

The engine also injects current_date (an alias for today.date_long) for legacy templates.

---

Boolean Fields

Boolean fields control conditional text in your templates. Name them with an is_ or has_ prefix so the intent is obvious in conditionals: property.is_strata, sale.is_auction, property.has_pool.

Standard Boolean Naming

Pattern	Example	Meaning
*.is_*	sale.is_auction, property.is_strata	Yes/no question about a state
*.has_*	property.has_pool, estate.has_will	Yes/no question about possession
Plain	cooling_off.expired, exchange.by_agent	Single-word past-tense flag

Negating in Templates

Use Jinja’s not operator directly:

{%p if not sale.is_auction %}
Private treaty terms...
{%p endif %}

Avoid inverse fields like `*.not_*` and `*.no_*`

Earlier versions of Certum Draft documented a parallel *.not_* / *.no_* family auto-computed alongside each *.is_* / *.has_* field. The engine still emits those keys (for backwards compatibility with templates that reference them), but new templates should use not <field> directly. The legacy form is also a landmine because the string "false" is truthy in Jinja by default — see Conditionals for the full story and the engine-side backstop.

---

Conveyancing Fields

Additional fields for property transactions.

Property

Field	Example	Description
property.address	Schrute Farms, Rural Route 6, Scranton NSW 2000	Full property address
property.re_line	Schrute Farms, Rural Route 6, Scranton	Short form for letters
property.street_address	Rural Route 6	Street line only
property.suburb	Scranton	Property suburb
property.state	NSW	Property state
property.postcode	2000	Property postcode
property.lot_number	15	Lot number
property.dp_number	123456	DP/SP number
property.title_reference	15/123456	Title reference (Folio)
property.registered_plan	DP 123456	Full plan reference
property.council	Scranton Regional Council	Local council

Property Booleans

Field	What It Controls
property.is_strata	Strata/unit title warnings
property.has_pool	Pool compliance requirements
property.has_illegal_works	Unapproved works disclosure
property.survey_available	Survey report exists

Transaction

Field	Example	Description
transaction.sale_price	750000	Sale/purchase price
transaction.deposit_amount	75000	Deposit amount
transaction.contract_date	2025-01-27	Contract date
transaction.exchange_date	2025-01-28	Exchange date
transaction.settlement_date	2025-03-15	Settlement date
transaction.settlement_period	42	Days to settlement

Transaction Booleans

Field	What It Controls
transaction.simultaneous_purchase	Coordinating sale with purchase
transaction.deposit_release	Early deposit release
transaction.christmas_settlement	Holiday period settlement
transaction.vendor_renting_back	Post-settlement rental
transaction.vacant_possession	Property empty at settlement

Sale Type Booleans

Field	What It Controls
sale.is_auction	Auction vs private treaty
sale.is_estate	Deceased estate sale

Other Party Fields

These follow the same pattern as client.*:

Category	Example Field	Description
vendor.*	vendor.full_name	The seller (sale matters)
purchaser.*	purchaser.full_name	The buyer (purchase matters)
os.*	os.business_name	Other side’s solicitor
agent.*	agent.full_name	Real estate agent

---

Estate Administration Fields

For deceased estate matters.

Deceased

Field	Example	Description
deceased.full_name	Arthur Pendragon	Full name
deceased.surname	Pendragon	Surname
deceased.given_names	Arthur	Given names
deceased.title	King	Title
deceased.date_of_death	2025-01-01	Date of death
deceased.date_of_birth	1960-06-15	Date of birth
deceased.place_of_death	Camelot Hospital	Place of death
deceased.last_address	Castle Camelot, Camelot NSW 2001	Last known address
deceased.occupation	King	Occupation
deceased.marital_status	Married	Marital status at death

Estate

Field	Example	Description
estate.value_gross	500000	Gross estate value
estate.value_net	450000	Net estate value
estate.date_of_will	2020-05-15	Date of will

Estate Booleans

Field	What It Controls
estate.has_will	Testate vs intestate
estate.probate_granted	Probate status
estate.has_real_property	Real estate in estate

Executor/Administrator

Field	Example	Description
executor.full_name	Sir Lancelot	Executor’s name
executor.address	Round Table, Camelot NSW 2001	Executor’s address
executor.relationship	Knight of the Round Table	Relationship to deceased
administrator.full_name	Sir Galahad	Administrator’s name

---

Wills & Estate Planning Fields

For will preparation matters.

Testator

Field	Example	Description
testator.full_name	Robin of Locksley	Full legal name
testator.surname	Locksley	Surname
testator.given_names	Robin	Given names
testator.title	Mr	Title
testator.dob	1965-03-15	Date of birth
testator.occupation	Outlaw	Occupation
testator.marital_status	Married	Marital status
testator.address	Sherwood Forest, Nottingham NSW 2100	Address

Testator Booleans

Field	What It Controls
testator.is_married	Marriage-related clauses
testator.has_children	Children provisions
testator.has_stepchildren	Stepchildren provisions

Beneficiaries

Field	Example	Description
beneficiary_1.full_name	Maid Marian	First beneficiary
beneficiary_1.relationship	Spouse	Relationship to testator
beneficiary_1.share	50%	Share of estate
beneficiary_2.full_name	Robin Jr	Second beneficiary
beneficiary_2.relationship	Son	Relationship
beneficiary_2.share	25%	Share
beneficiary_3.full_name	Friar Tuck	Third beneficiary
beneficiary_3.relationship	Friend	Relationship
beneficiary_3.share	25%	Share
executor_1.full_name	Little John	First executor
executor_1.relationship	Friend	Relationship
executor_2.full_name	Will Scarlet	Substitute executor

---

Commercial & Business Fields

For commercial transactions.

Company

Field	Example	Description
company.name	Sherwood Enterprises Pty Ltd	Company name
company.acn	123 456 789	ACN
company.abn	12 345 678 901	ABN
company.registered_address	1 Forest Road, Sherwood NSW 2100	Registered office
company.director_1	Robin Hood	First director
company.director_2	Little John	Second director
company.secretary	Alan-a-Dale	Company secretary

Business Booleans

Field	What It Controls
company.is_trustee	Acting as trustee
transaction.is_gst_applicable	GST provisions
transaction.has_finance	Finance conditions

---

Field Compatibility Matrix

This matrix shows which universal fields exist across the main matter types:

Field	Sale of Land	Estates	Wills/POA/EG
matter.number	Yes	Yes	Yes
matter.name	Yes	Yes	Yes (auto-filled)
matter.type	hidden	hidden	Yes (dropdown)
matter.re_line	—	Yes	—
matter.person_acting	Yes	Yes	Yes
matter.person_assisting	Yes	Yes	Yes
client.full_name	Yes	Yes	Yes
client.surname	Yes	Yes	Yes
client.addressee	Yes	Yes	Yes
client.salutation	Yes	Yes	Yes
client.street_address	Yes	Yes	Yes
client.suburb	Yes	Yes	Yes
client.state	Yes	Yes	Yes
client.postcode	Yes	Yes	Yes
client.email	Yes	Yes	Yes
client.phone	Yes	Yes	Yes
firm.name	—	Yes	—
practitioner.full_name	Yes	Yes	—

Caution

Fields marked — are not defined in that matter type’s matter.json. If a template uses firm.name but the matter type doesn’t define it, the document will show [MISSING: firm.name]. Use the cross-pack template feature or add the field to your matter.json.

---

Implementing Universal Fields in matter.json

Every matter.json should include these blocks as a minimum to ensure cross-template compatibility:

{
  "blocks": [
    {
      "name": "Matter Details",
      "fields": [
        {"key": "matter.number", "label": "Matter Number", "type": "text"},
        {"key": "matter.name", "label": "Matter Name", "type": "text"},
        {"key": "matter.re_line", "label": "Re Line", "type": "text"},
        {"key": "matter.person_acting", "label": "Person Acting", "type": "text"},
        {"key": "matter.person_assisting", "label": "Person Assisting", "type": "text"}
      ]
    },
    {
      "name": "Client",
      "fields": [
        {"key": "client.full_name", "label": "Full Name", "type": "text"},
        {"key": "client.surname", "label": "Surname", "type": "text"},
        {"key": "client.given_names", "label": "Given Names", "type": "text"},
        {"key": "client.title", "label": "Title", "type": "select",
         "options": ["Mr", "Mrs", "Ms", "Miss", "Dr", "Hon"]},
        {"key": "client.addressee", "label": "Addressee", "type": "text"},
        {"key": "client.salutation", "label": "Salutation", "type": "text"},
        {"key": "client.street_address", "label": "Street Address", "type": "text"},
        {"key": "client.suburb", "label": "Suburb", "type": "text"},
        {"key": "client.state", "label": "State", "type": "select",
         "options": ["NSW", "VIC", "QLD", "WA", "SA", "TAS", "ACT", "NT"]},
        {"key": "client.postcode", "label": "Postcode", "type": "text"},
        {"key": "client.email", "label": "Email", "type": "email"},
        {"key": "client.phone", "label": "Phone", "type": "phone"}
      ]
    }
  ]
}

For multi-client matters, add a second client block with collapsed: true:

{
  "name": "Client 2 (Joint)",
  "description": "Second client for joint matters",
  "collapsed": true,
  "fields": [
    {"key": "client2.full_name", "label": "Full Name", "type": "text"},
    {"key": "client2.surname", "label": "Surname", "type": "text"},
    {"key": "client2.email", "label": "Email", "type": "email"},
    {"key": "client2.phone", "label": "Phone", "type": "phone"}
  ]
}

---

Field Naming Rules

The Golden Rules

Rule	Example
Use lowercase	client.surname
Use underscores for multi-word fields	client.street_address
Use dot notation for categories	client. matter. property.
Be descriptive	transaction.settlement_date
Use _single_line suffix for combined fields	client.address_single_line
Use is_ prefix for boolean “is this?” fields	property.is_strata
Use has_ prefix for boolean “has this?” fields	property.has_pool

Naming Don’ts

Avoid	Why	Instead Use
clientSurname	camelCase is inconsistent	client.surname
Client_Surname	Capital letters vary	client.surname
SURNAME	All caps is ugly	client.surname
sname	Too abbreviated	client.surname
name	Ambiguous (whose name?)	client.full_name
strata	Unclear what it means	property.is_strata

---

Using This Codex

When Creating Templates

1. Always check the codex first — Use standard names
2. If a field doesn’t exist — Propose it using the standard format
3. Be consistent — Same field, same name, everywhere
4. Use not <field> for negative conditions — Not the legacy *.not_* form

When Creating matter.json

1. Match the codex field names — Use client.surname not surname
2. Include all universal fields — Ensures template compatibility
3. Add matter-specific fields — Using the same naming conventions

Example: Universal Letter Template

This letter works across any matter type because it only uses universal fields:

{{ firm.name }}
{{ firm.street_address }}
{{ firm.suburb }} {{ firm.state }} {{ firm.postcode }}

{{ today.date_long }}

{{ client.addressee }}
{{ client.street_address }}
{{ client.suburb }} {{ client.state }} {{ client.postcode }}

Dear {{ client.salutation }},

Re: {{ matter.re_line }}
Our Ref: {{ matter.number }}

Thank you for your instructions. We confirm we act on your behalf.

Yours faithfully,

{{ practitioner.full_name }}
{{ firm.name }}

Example: Joint Client Letter

Using multi-client fields for a joint Will instruction:

{{ today.date_long }}

{{ client1.full_name }}
{{ client2.full_name }}
{{ client1.street_address }}
{{ client1.suburb }} {{ client1.state }} {{ client1.postcode }}

Dear {{ client1.salutation }} and {{ client2.salutation }},

Re: {{ matter.re_line }}
Our Ref: {{ matter.number }}

We confirm we act for you both in relation to the above matter.

{%p if clients.is_couple == 'true' %}
As discussed, we will prepare mirror Wills for {{ client1.full_name }}
and {{ client2.full_name }}.
{%p endif %}

Yours faithfully,

{{ practitioner.full_name }}
{{ firm.name }}

---

Next Steps

• Template Author’s Guide — How to create templates
• Conditionals Guide — Conditional text logic
• Template Conversion Checklist — Converting existing templates