A lawyer's judgment, encoded and running in production.
Eight engineering capabilities we built for a practising M&A attorney — and what each one does for a firm that wants its own expertise to work without its partners in the room.
The client was the domain expert. Our job was translation.
Nodal came to us from a practising M&A attorney — someone who had spent a career negotiating the same confidentiality provisions, for the same reasons, against the same objections, and wanted the repetition to stop. He did not need to be told what the legal problem was. He needed the problem made executable.
What he handed over was a confidential requirements document: roughly ninety features, written with the precision of someone who knows the domain cold. It was a good document. It was also, in the places that mattered most, a list of questions rather than answers. Answering those is not implementation work. It is legal reasoning expressed as architecture — and it is the part of the job that decides whether the output is a document a lawyer will actually sign.
Encode professional judgment as executable rules.
THE PROBLEM — A firm's negotiating position is real, consistent, and almost never written down. It lives in the partners who have argued it before. Every matter re-derives it from scratch, and the answer drifts depending on who is holding the file.
IN A FIRM — Your intake criteria, your drafting standards, your clause preferences — captured once, applied consistently, and enforced without a partner reviewing work they have already formed a view on.
Assemble documents that hold up as documents.
THE PROBLEM — Automated drafting fails on presentation, not logic. A provision assembled correctly but rendered with a broken signature block, a stray line, or a page break in the wrong place is not a document anyone will execute.
IN A FIRM — We treat typography and pagination as correctness requirements, because a partner will reject a document that looks wrong before they read it.
Automate deterministically, not generatively.
THE PROBLEM — Every firm has now been pitched AI by half a dozen vendors. The objection is always the same, and it is correct: a model that improvises cannot be trusted near a client document, because you cannot audit a decision it cannot explain.
IN A FIRM — Where a rule will do, we write a rule. We reach for a model only where judgment is genuinely ambiguous, and we tell you which is which — so you always know whether an output is auditable or merely plausible.
Execute with evidentiary integrity.
THE PROBLEM — An electronic signature is only worth the record standing behind it. Consent, locking, sequence, and immutability are not features of a signing flow — they are the reason the resulting instrument is enforceable at all.
IN A FIRM — The same discipline applies to any firm workflow that produces a binding artefact: engagement letters, retainers, client authorisations. Getting the consent and the audit trail right is what makes the automation defensible.
Turn obligation tracking into a system of record.
THE PROBLEM — The obligations a firm owes and is owed — expiry dates, return-or-destroy duties, non-solicit terms, restrictions accepted on a client's behalf — are typically tracked in a spreadsheet one person maintains and nobody audits.
IN A FIRM — A register that is wrong is worse than no register, because people rely on it. We built for the truth of the table, not the table — which meant fixing the logic and repairing the history behind it.
Reach past the firm's walls.
THE PROBLEM — A workflow involving anyone outside the firm cannot require them to adopt your software. Opposing counsel, a counterparty, a client — none of them will create an account because it suits your process.
IN A FIRM — Client portals and third-party workflows fail on adoption, not features. Anything we build that touches someone outside your firm has to work for a person who has never heard of it and has no reason to try.
Absorb the existing mess without losing the record.
THE PROBLEM — No firm starts clean. There are years of executed instruments, matters negotiated outside any system, and records that were entered wrong and relied on since. A tool that only handles work created inside it solves the easy half of the problem.
IN A FIRM — Migration is where these projects actually fail. A firm's twenty years of files are the asset, and moving them is not a data-entry task — it is the highest-risk work in the engagement. We price it and plan it as such.
Hold confidential material like it is confidential.
THE PROBLEM — A system holding client-confidential instruments is held to a different standard than a project tracker. If it is unavailable for an hour, a matter is exposed. If it loses a record, that is not a bug report.
IN A FIRM — Said plainly: branch protection and pre-merge checks were introduced partway through this engagement rather than at the start. On a system holding confidential instruments that should have come first, and on your engagement it would — it is the one thing we would sequence differently.
A lawyer told us what he knew. We made it run.
FIELD REPORT 01 — THE SHORT VERSIONWe read the domain, not just the ticket. We build the auditable thing first — rules where a rule will do, a model only where judgment is genuinely ambiguous. And we stay for the unglamorous half: migrations, outages, release discipline, and the audit trail.
Start with the plan.
The $2,000 deposit is credited toward the build and refundable for two weeks after the plan lands. The plan is yours either way.
Book a scoping call →