Field note / Document workflow evaluation

Before automating legal documents: test one precedent workflow

Repeated facts, drifting Word masters and uncertain conditional sections are different problems. Before choosing software, make one package's inputs, source authority and expected results explicit.

Stratum Relay · Engineering field note · 2 October 2026

Everything needed for the exercise is on this page. Copy the worksheet into a local text editor or print this article using your browser. No signup, upload, JavaScript or model account is needed.

1. Identify the work, not the technology

Assembly: Place approved facts into approved positions and apply an explicit rule. The fictional exercise below does only this; ordinary fields or mail merge may be enough.
Retrieval: Find the right approved precedent or instruction in an authorized collection. A document-management system's search and curation may solve this. Finding a similar document does not make it authoritative.
Professional judgment: Decide whether facts, provisions and a document are appropriate for the matter and jurisdiction. That decision belongs to the responsible qualified professional, not an assembly rule, search result or language model.

Inventory one package first: who prepares it, what tools they use, where approved facts and masters live, who owns each source, who resolves conflicting instructions, who reviews outputs and who maintains changes. If those answers are unavailable, the first intervention is governance.

Build, buy or do neither
Situation	First option to examine	Decision boundary
Stable facts, few variations, approved masters	Improve Word fields, mail merge, locked master access and a review checklist.	Do not build a second system if the native workflow handles the package.
The team can use standard content	Assess available standard precedents with the responsible professional.	Check current license, jurisdiction, applicability and maintenance; availability is not suitability.
Many approved branches or substantial template maintenance	Evaluate specialist assembly software or managed implementation.	Clarilis and Affinity already cover implementation questions; check existing licenses and supplier scope before custom work.
An approved workflow still has one concrete systems handoff gap	Consider a separately scoped integration.	Identify the missing step, permissions, reviewer, fallback and maintenance owner first.
No approved rule, unresolved source conflict or no reviewer	Stop preparation and resolve ownership.	Generated language cannot substitute for the missing authority.

Worked no-build conclusion: for this fictional package, a controlled Word master, shared fact sheet and manual checks can reproduce every specified output. Nothing here establishes a need for AI or custom software. If instruction authority remains disputed, even a correct copier is premature.

2. Freeze a small source set

The package is Example Property Alpha, with Example Owner A and Example Occupier B. Its three artifacts are a package cover, term-fact schedule and conditional-section index. They contain only facts and inert labels: no clauses, rights, duties, signature blocks or legal conclusions.

Fictional manifest M2 — baseline authority, not actual professional approval
Source / revision	Owner role and contents	Status and permitted use
`PARTIES_ALPHA / 1`	Example data steward: `OWNER_A → Example Owner A`; `OCCUPIER_B → Example Occupier B`.	Active identity register; roles and names must match exactly.
`PROPERTY_ALPHA / 1`	Example data steward: `PROPERTY_ALPHA → Example Property Alpha → [FICTIONAL ADDRESS ALPHA]`.	Active property register; the address is a placeholder, not a real location.
`INSTRUCTIONS_ALPHA / 1`	Example instruction reviewer: effective date `[DATE TO BE APPROVED]`; option `ON`.	Only baseline instruction record; approval here is a synthetic exercise state.
`MASTER_ALPHA / 1`	Example document owner: historic layouts.	Superseded. Never accepted; cannot override M2 or repair a missing rule.
`MASTER_ALPHA / 2`	Example document owner: three layouts and conditional slot `SECTION_OPTION_A`.	Only active master under M2. Its selected version must equal the approved version.
`RULES_ALPHA / 2`	Example rule owner: mappings and checks printed below.	Active with M2 and master 2 only. ON maps to `SECTION_OPTION_A`; OFF maps to no section.

Allowed values and required fields

All 18 worksheet fields are required, including when the option is OFF. In this exercise the only allowed values are the filled values below, except option_flag may be ON or OFF when it matches the case's authorized instruction record. A1 explicitly authorizes an isolated synthetic OFF replacement; A6 explicitly authorizes the M3/version-3 set. The other changes intentionally fail validation or output comparison. No other value is silently normalized or guessed. IDs, names and placeholder text are case-sensitive exact strings.

Authority before assembly: select the manifest first. It pins approved master and rule revisions. A filename, modification time or higher version number does not establish approval. The party/property registers supply identity facts; the instruction record supplies date and option; the master supplies layout, not new facts; the rules supply mappings, not legal judgment.
No automatic conflict winner: if another instruction record is supplied and disagrees with any date or option value, stop, list both source IDs/revisions and route the disagreement to the Example instruction reviewer. “Newest wins” is not a rule. Resume only after that reviewer records a single resolved instruction revision and the document owner updates the manifest and expectations.
Validate: reject a blank required field, unknown ID, unmapped name/address, unlisted revision, unsupported flag or master/rule/manifest mismatch. Selected master must be the approved active version. Failure means STOP before preparing any of the three outputs, not a partial package.
Copy: all three outputs carry the same provenance block and owner, occupier and property identity block shown in section 4. The cover and schedule copy date and option. The index also copies date and option, then applies the conditional rule pinned by the selected manifest: R2 under M2, or R3 under the A6 transition.
Conditional rule R2 (M2 only): ON produces exactly one numbered index entry, 1. SECTION_OPTION_A. OFF produces entries: NONE (0), no numbered entry and no occurrence of that label anywhere in the package. The cover and schedule never list conditional labels, so an ON package contains the label exactly once overall. There are no other sections or cross-references to renumber.
Compare before acceptance: compare each field across all outputs and to the validated worksheet. A mismatch means STOP acceptance, identify the document and field, correct from the approved source and recheck the whole package. Consistency alone is insufficient if all three copies disagree with the source.

STOP is an engineering disposition: do not issue or rely on the package. Keep discrepancies in an authorized review record; do not invent missing facts or legal wording. The role names above are fictional escalation destinations, not people who reviewed this article.

3. Copy the blank worksheet, then fill the baseline

The blank block is a printable writing sheet and copyable plain text, not a web form. Fill it on paper or in your own authorized local editor; nothing is submitted to this site. Keep real matter information out of this public example.

INPUTS — synthetic exercise only
manifest_id = ______________________________
owner_id = _________________________________
owner_name = _______________________________
occupier_id = ______________________________
occupier_name = ____________________________
property_id = ______________________________
property_name = ____________________________
property_address = _________________________
effective_date = ___________________________
option_flag = ______________________________
approved_master_id = _______________________
approved_master_version = __________________
selected_master_id = _______________________
selected_master_version = __________________
instruction_source_id = ____________________
instruction_source_version = _______________
rule_source_id = ___________________________
rule_source_version = ______________________

REVIEW RECORD — complete only after doing the exercise
case / manifest / expected-result revision = ______________
preparer / date / method = ________________________________
observed cover fields and discrepancies = _________________
observed schedule fields and discrepancies = ______________
observed index fields / entries / discrepancies = __________
STOP reason / source / field / escalation role = ___________
correction and rerun record = _____________________________
independent reader / date / actual disposition = ___________
professional review status (separate) = ___________________

Filled baseline B0 — exact values for a manual reproduction
Input field	Baseline value	Mapping / authority
`manifest_id`	`M2`	Manifest above; copied to every output.
`owner_id`	`OWNER_A`	PARTIES_ALPHA / 1; every output's owner_id.
`owner_name`	Example Owner A	PARTIES_ALPHA / 1; every output's owner_name.
`occupier_id`	`OCCUPIER_B`	PARTIES_ALPHA / 1; every output's occupier_id.
`occupier_name`	Example Occupier B	PARTIES_ALPHA / 1; every output's occupier_name.
`property_id`	`PROPERTY_ALPHA`	PROPERTY_ALPHA / 1; every output's property_id.
`property_name`	Example Property Alpha	PROPERTY_ALPHA / 1; every output's property_name.
`property_address`	`[FICTIONAL ADDRESS ALPHA]`	PROPERTY_ALPHA / 1; every output's property_address.
`effective_date`	`[DATE TO BE APPROVED]`	INSTRUCTIONS_ALPHA / 1; every output's effective_date. This placeholder is permitted only in this synthetic exercise.
`option_flag`	`ON`	INSTRUCTIONS_ALPHA / 1; every output's option_flag; R2 controls index entries.
`approved_master_id`	`MASTER_ALPHA`	M2; every output's approved_master ID.
`approved_master_version`	`2`	M2; every output's approved_master revision.
`selected_master_id`	`MASTER_ALPHA`	Must match approved ID; every output's selected_master ID.
`selected_master_version`	`2`	Must match approved revision; every output's selected_master revision.
`instruction_source_id`	`INSTRUCTIONS_ALPHA`	M2; every output's instructions ID.
`instruction_source_version`	`1`	M2; every output's instructions revision.
`rule_source_id`	`RULES_ALPHA`	M2; every output's rules ID.
`rule_source_version`	`2`	M2; every output's rules revision.

For reproduction: copy B0, validate against M2, create the three blocks below by copying the fields, apply R2 only to the index, then compare. Record actual observations in the blank review record; the expected blocks are not a completed review log.

4. Three hand-authored expected outputs

Expected-result set E2 is pinned to M2 / MASTER_ALPHA 2 / RULES_ALPHA 2. Revision notation ID / revision combines the worksheet's ID and version fields. Fixed register provenance is included because M2 pins those sources. Each block is non-operative.

Package cover — B0 / E2

NON-OPERATIVE SYNTHETIC PACKAGE COVER
manifest: M2
approved_master: MASTER_ALPHA / 2
selected_master: MASTER_ALPHA / 2
rules: RULES_ALPHA / 2
instructions: INSTRUCTIONS_ALPHA / 1
parties: PARTIES_ALPHA / 1
property_source: PROPERTY_ALPHA / 1
owner_id: OWNER_A
owner_name: Example Owner A
occupier_id: OCCUPIER_B
occupier_name: Example Occupier B
property_id: PROPERTY_ALPHA
property_name: Example Property Alpha
property_address: [FICTIONAL ADDRESS ALPHA]
effective_date: [DATE TO BE APPROVED]
option_flag: ON
artifact_list: TERM-FACT SCHEDULE; CONDITIONAL-SECTION INDEX

Term-fact schedule — B0 / E2

NON-OPERATIVE SYNTHETIC TERM-FACT SCHEDULE
manifest: M2
approved_master: MASTER_ALPHA / 2
selected_master: MASTER_ALPHA / 2
rules: RULES_ALPHA / 2
instructions: INSTRUCTIONS_ALPHA / 1
parties: PARTIES_ALPHA / 1
property_source: PROPERTY_ALPHA / 1
owner_id: OWNER_A
owner_name: Example Owner A
occupier_id: OCCUPIER_B
occupier_name: Example Occupier B
property_id: PROPERTY_ALPHA
property_name: Example Property Alpha
property_address: [FICTIONAL ADDRESS ALPHA]
effective_date: [DATE TO BE APPROVED]
option_flag: ON

Conditional-section index — B0 / E2

NON-OPERATIVE SYNTHETIC CONDITIONAL-SECTION INDEX
manifest: M2
approved_master: MASTER_ALPHA / 2
selected_master: MASTER_ALPHA / 2
rules: RULES_ALPHA / 2
instructions: INSTRUCTIONS_ALPHA / 1
parties: PARTIES_ALPHA / 1
property_source: PROPERTY_ALPHA / 1
owner_id: OWNER_A
owner_name: Example Owner A
occupier_id: OCCUPIER_B
occupier_name: Example Occupier B
property_id: PROPERTY_ALPHA
property_name: Example Property Alpha
property_address: [FICTIONAL ADDRESS ALPHA]
effective_date: [DATE TO BE APPROVED]
option_flag: ON
entries: 1
1. SECTION_OPTION_A

B0 disposition: eligible for this exercise's consistency acceptance only if all copied values match, provenance is M2/E2 and the conditional label occurs once in the index and nowhere else. It is never acceptance for legal use. A qualified professional's matter-specific review is a separate requirement for any real workflow.

5. Reproduce eight cases: B0 plus A1–A7

There are exactly eight cases in total: the complete baseline B0 and seven changes A1–A7. Start each change from a fresh B0 worksheet and E2 expected set, not from the previous case. A5 deliberately corrupts a prepared output; A1–A4, A6 and A7 change inputs or sources before assembly. The table specifies hand-authored expectations for manual reproduction, not executed tests or observed outcomes.

Eight total cases — one baseline and seven changes
Case / exact modification	Expected result in the three artifacts	Disposition / recovery
B0 — Complete baseline. Use all 18 filled worksheet values and the M2 source set without modification.	Produce the three complete B0/E2 blocks in section 4. Every copied field and pinned source agrees with the worksheet and registers. Exactly one `SECTION_OPTION_A` entry appears in the index; none appears in the cover or schedule.	Eligible for engineering consistency acceptance after every source/field comparison; not professional approval or acceptance for legal use.
A1 — Option off. For this isolated synthetic case only, the fictional Example instruction reviewer authorizes replacing ON with `OFF` in INSTRUCTIONS_ALPHA / 1, and the fictional Example document owner authorizes that replacement under M2. Replace worksheet option_flag with OFF too. No competing record is supplied or retained as active. This specified exercise override is not permission to overwrite a real approved revision.	Derive the A1 expectation from B0/E2: all three blocks have option_flag OFF; every other copied field and source revision remains unchanged. Cover artifact_list stays unchanged because the empty index is still an artifact. Index ends with `entries: NONE (0)`; remove `1. SECTION_OPTION_A`. No conditional label or orphan reference remains in any artifact.	Eligible for consistency acceptance after source/field comparisons against this case's OFF record and expectation, not the ON baseline. Do not treat a blank as OFF or carry this override into another case.
A2 — Missing party. Empty `owner_id`; leave owner_name as Example Owner A.	No outputs prepared. Report `owner_id: required value missing`; the display name does not replace an ID.	STOP. Example data steward supplies the approved ID; then rerun from the validated worksheet.
A3 — Conflicting instructions. Keep B0 and add `INSTRUCTIONS_BETA / 1` with date `[DATE TO BE APPROVED]` and option `OFF`, against INSTRUCTIONS_ALPHA / 1 option ON. BETA is not in M2.	No outputs prepared. Report both IDs/revisions, unlisted BETA source and `option_flag: ON versus OFF`. M2's preferred source is not permission to ignore the supplied conflict.	STOP to Example instruction reviewer; Example document owner records resolved source authority in a new manifest. Do not pick newest, majority or model preference. New expectations and rerun required.
A4 — Old master. Set selected_master_version to `1`; approved_master_version remains 2.	No outputs prepared. Report `MASTER_ALPHA / 1: superseded; approved version is 2`.	STOP. Select master 2 and rerun. Do not transplant facts into the old layout and call it current.
A5 — Party mismatch in one output. Prepare B0, then change only the schedule's occupier_id from `OCCUPIER_B` to `OWNER_A`; its occupier_name stays Example Occupier B.	Cover and index retain OCCUPIER_B. Report `term-fact schedule / occupier_id: OWNER_A; expected OCCUPIER_B`; also report the ID/name register mismatch. The wrong ID is a known ID but the wrong role.	STOP acceptance of the entire package. Correct from PARTIES_ALPHA / 1, then compare every field in all three outputs again.
A6 — Approved v3 label change. Apply the exact M3/E3 transition below, replacing the v2 conditional slot with `SECTION_OPTION_B`.	All three blocks use M3, approved/selected master 3 and rules 3; all other B0 facts stay unchanged. ON index has exactly `1. SECTION_OPTION_B`; no SECTION_OPTION_A remains. E2 is invalid for this run.	STOP release until new expectations and reruns are reviewed. A matching stale E2 result cannot pass under M3. Transition checklist below defines affected cases.
A7 — Unknown rule / ambiguous option. Change option_flag to `MAYBE`; keep other B0 values. This intentionally disagrees with the instruction record.	No outputs prepared. Report unsupported option_flag MAYBE, instruction mismatch and absence of an approved branch for MAYBE. Do not infer ON or OFF.	STOP to Example instruction reviewer and Example rule owner. Clarify instructions or approve a new rule/manifest and expectations before rerun; do not generate a missing clause.

A6 in full: changing approval changes the oracle

This is a hypothetical change event, not permission to adopt a newer master by number. The fictional document owner records M3, marks MASTER_ALPHA / 2 and RULES_ALPHA / 2 superseded, and marks MASTER_ALPHA / 3 and RULES_ALPHA / 3 active. The v3 master has the same three layouts and fields, but the slot is SECTION_OPTION_B. R3 changes only the ON mapping to that label; OFF still means zero entries. PARTIES_ALPHA / 1, PROPERTY_ALPHA / 1 and INSTRUCTIONS_ALPHA / 1 remain pinned. M2 and E2 remain historical, not current approval.

Create the A6 worksheet from B0 with exactly these replacements: manifest_id=M3, approved_master_version=3, selected_master_version=3, rule_source_version=3. Create E3 from the three printed E2 blocks by replacing manifest M2 with M3, both master revisions 2 with 3 and rules revision 2 with 3. In the index only, replace 1. SECTION_OPTION_A with 1. SECTION_OPTION_B. No other field changes. This completely specifies the new baseline; record the expected set as E3, never E2.

Rerun B0 under M3/E3: one SECTION_OPTION_B in the index; no SECTION_OPTION_A in any output.
Rerun A1 under M3/E3 using the same explicitly authorized isolated OFF replacement: OFF everywhere, empty index, neither conditional label anywhere. Compare to the OFF-derived expectation, not the ON E3 baseline.
Rerun A2, A3 and A7 with the same mutations applied to the M3 worksheet: the same missing-field, conflict and unknown-branch STOPs occur before any output.
Rerun A4 under M3 with selected version 1: STOP, now approved version 3. Also try selected version 2: STOP as superseded. Both master and rule revision 2 are stale even if their old labels appear internally consistent.
Rerun A5 on E3-shaped outputs: the same schedule occupier_id and ID/name mismatches stop acceptance.
Negative A6 check: keep M3 provenance but place SECTION_OPTION_A in the index. STOP: R3 requires SECTION_OPTION_B. Keeping the whole E2 package also fails M3 provenance checks. Matching a stored v2 expectation never overrides the current manifest.

Keep old expectations for traceability, but do not reuse their acceptance status. Record the changed source, new expected-result revision, preparer, independent reader, discrepancies, corrections and actual rerun disposition. No boxes are pre-ticked and no reviewer result is implied here.

6. Privacy and maintenance are inputs too

This page has no document uploader or worksheet submission. A local copy can still become sensitive if you replace fiction with matter facts. Ordinary website access is covered by the site's privacy notice; do not treat the absence of an upload as a promise about site or booking-provider data handling.

Before any real pilot, the responsible professional and IT/privacy owner should resolve and document:

Authority and access: which data may be used, in which environment, by which roles? Verify permitted and denied access, including exports, temporary files and logs; do not use a broad shared corpus merely because it is searchable.
Providers: identify processors, subcontractors and integrations; review applicable terms, model-training/data-use settings, retention, location and security controls. A vendor claim is not your verification.
Retention and deletion: name the owner and approved policy for source facts, generated artifacts, logs, backups and review records; agree deletion and exception handling. This note prescribes no universal retention period or compliance result.
Professional responsibility: establish matter/jurisdiction suitability, supervision, client communication or consent requirements where applicable and final review authority. The fictional approval state proves none of these.
Maintenance owner: name the document/rule owner, backup owner and authorized change approver. Identify who reconciles conflicting masters, updates the manifest and writes new expected results before a changed release.
Change and support: inventory native fields, templates, integrations and supplier dependencies. Agree rerun scope, review capacity, support coverage and cost separately; never assume a pilot pays for indefinite maintenance.
Failure and fallback: designate an escalation role, restrict stale sources, preserve authorized discrepancy records and define a return to the controlled manual workflow. A failed case must not silently issue a partial package.

7. Keep a pilot narrower than the ambition

A sensible evaluation boundary is one owned package, one approved source manifest, explicit facts and branch rules, three reviewable outputs, the baseline and change cases, an authorized environment and a responsible professional reviewer. Compare the current Word/native workflow first. Record correctness, discrepancies and reviewer corrections from actual runs; there are no time-saving or accuracy numbers in this exercise.

Exclude legal drafting, autonomous issuance, broad precedent ingestion, DMS replacement and live client data from this public demonstration. If rules cannot be approved, access cannot be authorized, maintenance lacks an owner or native/specialist tools already solve the task, stop custom implementation. No-build is a useful outcome.

If an owned, bounded handoff gap survives that evaluation, our service context explains how to evaluate and connect one document workflow. Engineering scope and support are agreed separately; the responsible professional retains legal review and decisions.

Read the document-workflow service scope Discuss one workflow

Please do not send confidential documents or client records. A conversation can start with the workflow, current systems, owners and review requirements. Booking is optional; this worksheet stays ungated.

Sources and their limits

Public research cutoff: 2 October 2026. These sources informed the workflow questions and alternatives, not the fictional rules. The manifest, worksheet and expected outputs are original synthetic specifications. Source publication does not validate this exercise or establish demand for our services.

The Law Society: AI use cases in law — legal contract review (26 February 2026). A practitioner account supports checking existing-tool gaps and professional review. England/Wales context; not US jurisdictional guidance, a controlled benefit study or evidence of buying demand.
Affinity: Your ultimate guide to legal document automation (published 7 April 2021; metadata modified 29 September 2026). Covers drifting masters, reconciliation and Word-native versus specialist options. An implementation supplier's article; its sales and accuracy claims are not adopted here.
Clarilis managed service and Clarilis practitioner implementation Q&A (publication dates not established). Illustrate existing design, preparation, review and maintenance services. Vendor material, not independent comparisons or audited outcomes.
Clarilis: pre-automated Model Commercial Lease (2022 launch context; exact publication date not established). Supports considering standard content and specialist alternatives. Current licensing, availability and matter/jurisdiction suitability require their own checks; no recommendation of legal content is made here.
iManage knowledge search and management and Draftwise (publication dates not established). Retrieval and Word/DMS tooling already exist. Capabilities, permissions and security are vendor claims not tested by this field note.
ABA Formal Opinion 512 (29 July 2024; PDF). Addresses lawyers' responsibilities when using generative AI, including competence, confidentiality and review. Based on ABA Model Rules, not universal jurisdictional law or a compliance certification for this workflow.
US Tech legal document automation checklist (9 April 2026) and KUMO document-processing pilot acceptance tests (21 August 2026). Existing vendor resources already address readiness and evaluation. This note claims usefulness through a specific portable artifact, not exclusivity; vendor numbers, security assurances and legal claims are excluded.

For practice context, see how Stratum Relay works. This organizational engineering attribution is not a statement that a lawyer, client or named individual has reviewed or endorsed the note.