The paperwork runs itself. The human still signs off.
An Australian real-estate sales agency prepares legally-binding sales-agency agreements — the jurisdiction's mandatory listing paperwork — for every property it takes to market, around half a dozen new agreements a month, each assembled by hand from several disconnected sources.
In plain terms
It turns the few details an agent types into a ready-to-sign listing agreement, with a person checking every one before it goes out.
Does the paperwork for you
It pulls the real property details from the land-titles register, your CRM and property data, fills the official form, and flags anything that looks off — instead of an admin copying figures between systems by hand.
Catches the costly mistakes
It never guesses or forces a binding number it isn't sure of, so a wrong commission or the wrong property's title gets sent to a person to fix rather than ending up on a signed contract.
A person always signs off, and you own it
Nothing binding is created or signed without your team's explicit approval, every step is kept in a tamper-proof record, and the whole thing runs in your own accounts as your asset — built and proven end to end, now in pilot.
The problem
Every property an agency lists requires a statutory sales-agency agreement: a legally-binding document whose fields — the registered proprietors, the legal land description, the commission, the price guide, the marketing breakdown — are scattered across a land-titles register, the agency's CRM, a property-data provider, and whatever the agent typed into an intake form. An administrator stitches them together by copying values between systems, retyping the title description, interpreting a commission an agent scrawled as '1.7', and hoping nothing was transposed. A single wrong digit on a binding agreement is not a typo; it is a contract that says the wrong thing. The work is slow, it is repetitive, and the cost of a mistake is borne by the agency and its vendors.
Generic tools don't solve this. A form-filler doesn't know that the jurisdiction's form silently drops a decimal commission rate, leaving a blank where the fee should be on a signed agreement. A spreadsheet doesn't place a billable title order, withhold it when the address is ambiguous, and reuse the result across a second document at no cost. Template software has no human approval gate, no plausibility screen that catches a fee far below any real engagement, no tamper-evident record of why a machine read an ambiguous figure the way it did, and no way to keep one agency's encrypted credentials from ever decrypting another's. A legally-binding, audited, multi-source workflow needs a real engine — durable, retryable, gated, and honest about what it doesn't know — not a wrapper around a PDF.
What we built
A custom workflow engine that treats a statutory sales agreement as what it is — a binding, auditable, multi-source document that no machine should ever finalise alone. The engine enriches one intake row into validated form fields, maps them onto the form's real field codes, screens every value for plausibility, pauses for a human to approve, runs the signing ceremony, files the executed PDF, and writes the outcome back to the source system — recording every step in a cryptographically tamper-evident chain. It is proven end-to-end against the regulator's pre-production environment and is in pilot; live go-live against real vendors is deliberately gated behind the client's credentials and sign-off, and the engine refuses to run half-configured against live systems.
A durable, resumable workflow engine
At the centre is a custom state-machine engine that runs a workflow's ordered steps in sequence and persists a full snapshot of the run — its status, current step, accumulated output, and any pending gate — to PostgreSQL after every step. A paused or interrupted run resumes from the next un-run step rather than re-executing completed work, and resuming a run that has already completed, failed, or been cancelled short-circuits without re-running anything — so a redelivered job, like a duplicated signing webhook, is harmless. The behaviour is proven against both an in-memory store and the production Prisma-backed PostgreSQL store in a pre-production end-to-end suite; it has not yet run a high-volume live production load.
A retrying, idempotent job queue
Workflow runs and inbound webhooks are dispatched as jobs on a Redis-backed BullMQ queue, configured for three attempts with exponential backoff and set to keep failed jobs for inspection rather than discarding them. Because the queue guarantees at-least-once delivery under network partition, every processor is written to be idempotent — resolving an already-resolved gate does nothing, resuming a finished run short-circuits — so a redelivered job can never corrupt a run. The engine runs its steps in-process within a single worker today; per-step horizontal fan-out is reserved, not in use.
An ordered, ~20-step agreement pipeline
The lead document workflow assembles an ordered pipeline of roughly twenty discrete steps: validate the intake, normalise the address, search the land-titles register, cross-check the CRM and property-data provider, interpret the commission, map every value onto the statutory form's real field codes, validate those values against the live form template, screen them for plausibility, create and populate the form, pause for human approval, run the signing ceremony, download and store the executed PDF, write the status back to the source system, and notify the vendor. Enrichment and notification steps self-omit when their integration isn't provisioned, so a minimal run is closer to thirteen steps — every step is conditional on what is actually wired.
Two pause-and-resume gates: a human, then a signature
The engine supports gates that pause a run and persist its state. The agreement workflow pauses twice: first at a human approval gate, where the run sits as 'waiting approval' until an authenticated operator reviews the auto-populated data and explicitly approves (corrections the reviewer types are merged back into the run on resume); and again at a signature gate, which resolves only when a signing event arrives. Critically, the signature gate is backstopped by an independent outbound poller, so a dropped inbound webhook can never strand a signed document. The resume chain is proven end-to-end with a pre-production signing event; live signing at scale is gated on the client.
A defensive mapper that never coerces a binding field
The mapper that translates a free-text intake into form fields has one defining rule: it never silently coerces a legally-binding value. A bare rate-like number typed into a flat-fee field — '1.7' where a dollar amount is expected — is preserved as free text for a human to interpret at the approval gate, not coerced into a nonsensical two-dollar fee. The mapper encodes the regulator's real constraints: the percentage field is integer-only, so a decimal commission is instead written verbatim to the form's free-text 'other' line, where it renders correctly instead of being silently dropped from a signed agreement. Anything the mapper can't confidently parse is left blank and surfaced at the approval gate. The mappers are unit-tested against the real intake and form schemas and proven in pre-production.
A title search that refuses to guess
Before drafting, the engine places an automated land-title search through the title provider's gateway and retrieves the official legal description from the register. Its safety posture is the point: on an inexact address match it doesn't quietly substitute the closest candidate — it withholds auto-population and routes the candidate titles to a human, so an agent's typo can never order the wrong building's title. A billable order is also withheld entirely when the address can't be confidently validated, and each order is checked against a configurable spend ceiling and declined if the quote exceeds it. The full chain is proven end-to-end against a single real title in pre-production; it runs only once the provider's credentials are provisioned.
A title bought once, reused for free
Title data resolved for one document is cached and reused by any later document on the same property at no additional provider cost. A second statutory form — the contract of sale — has its own real field mapper, validated at build time against a copy of the regulator's contract template captured live from the pre-production tenant, so a schema drift fails the build rather than surfacing as an opaque error. That second form's data pack is assembled by reusing the title the first form already paid for. The mappers and the title-reuse spine are built and proven in pre-production; the contract-of-sale workflow deliberately stops at a prefilled data pack, with its signing leg held as a follow-up.
A plausibility screen, and a human who signs off
Between the automated mapping and the human gate, a deterministic screen runs over every generated value and flags what parses but fails the smell test — a fee far below any real engagement, a price guide below the reserve, an agency term outside the normal range — plus legally-sensitive situations such as a deceased estate, a separation, or a caveat. The screen is advisory: it never auto-corrects or auto-fails a run, because the human at the approval gate is the safety net. The operator must tick an explicit acknowledgement before the document can proceed, and a missing or placeholder agency licence hard-blocks the approval button. The screen and gate are proven in pre-production, with the human reviewer as the authoritative check.
A tamper-evident, per-tenant audit chain
Every run, step, and gate event is appended to a per-tenant SHA-256 hash chain: each row's hash is computed over the canonical JSON of its content, a format-version tag, and the previous row's hash, so editing, reordering, or deleting any past entry breaks the chain from that point forward. A verification routine re-walks the chain and pinpoints the first broken row. Writes are serialised across replicas with a database advisory lock and scoped per tenant, and the machine's own reasoning — how it read an ambiguous commission, with what confidence — is folded into the hashed event, making the 'why' of each decision itself tamper-evident. The mechanism is fully unit-proven and wired into the production path; it hasn't yet recorded a live production corpus.
An operator console that tells the truth
A separate Next.js console gives the operator their day: a dashboard and sidebar badge showing what's waiting, an approval queue where they review the auto-populated agreement and approve or reject (which resolves the gate on the engine and resumes the run), a per-run diagnostic view of the step-by-step audit trail and title-cost ledger, and live pipeline, commission, and authority tiles read straight from the agency's operational data. The whole surface obeys an honesty doctrine: every number is live or honestly absent, an unreachable backend renders a scoped empty state rather than a stale figure, and any non-live surface is explicitly banner-flagged and writes nothing unless a go-live flag is set. The console reads the live engine and operational data through typed, error-normalised clients.
Multi-tenant from the database up
The platform is built for more than one agency. Tenant isolation is enforced in PostgreSQL itself through Row-Level Security keyed to a per-request agency session variable — a mis-scoped query reads zero rows rather than leaking another tenant's data, so isolation never depends on application code remembering to filter. Each agency's third-party credentials are encrypted at rest with AES-256-GCM under a key derived per-agency, with the master key living only in the host environment and the engine refusing to boot in production without it. Every external integration is optional and credential-gated: a non-authoritative data source being unreachable surfaces a warning for the human approver instead of blocking a statutory document. The isolation, vault, and degradation behaviour are built and proven in pre-production; the deployment is a single-agency pilot.
How it fits together
One intake row to a signed agreement — with a human in the middle
Read left to right: a single free-text intake becomes a fully-drafted statutory agreement. The two flagged steps are where a person must act — nothing binding is created or signed without them.
Free-text intake row
One row of what the agent typed — address, price guide, commission, parties — the single starting point.
Pull from source systems
Normalise the address, then search the land-titles register and cross-check the CRM and property-data provider for the official details.
Map to the real form fields
Place every value on the statutory form's actual field codes; anything ambiguous is kept as-is, never forced into a wrong number.
Plausibility screen
Flag values that parse but smell wrong — a fee far too low, a term out of range — plus sensitive cases like a deceased estate or a caveat.
Human approves the draft
CheckpointAn authenticated operator reviews the auto-filled agreement, fixes anything flagged, and must explicitly approve before it can proceed.
Signature ceremony
CheckpointThe approved agreement goes out for signing; the run waits here until a signed event arrives, backstopped by a poller so a dropped notification can't strand it.
File and write back
Store the executed PDF, update the source system's status, and notify the vendor — closing the loop.
Every step, and the machine's own reasoning about ambiguous values, is written into a tamper-evident audit trail — and no binding field is finalised or signed without the human approval gate.
The outcome
The hard part of automating legally-binding paperwork isn't filling in a form — it's knowing when not to. This platform is built around that judgement. A custom, durable workflow engine turns a single free-text intake row into a fully-mapped statutory sales agreement: it normalises the address, searches the official land-titles register, cross-checks the agency's CRM and a property-data provider, interprets the commission, and maps every value onto the form's real field codes. But at no point does it finalise a binding field on its own. An ambiguous commission is preserved as free text rather than coerced into a wrong fee; a decimal rate the form would silently drop is rerouted to a free-text line where it renders correctly; an inexact title match is sent to a human instead of guessed; an unconfident address withholds a billable order. Every generated value passes a plausibility screen, every run pauses at a human approval gate, and every step — including the machine's own reasoning about how it read an ambiguous figure — is written into a per-tenant, SHA-256 hash-chained audit trail that breaks if anyone tampers with it. Around the engine sits an operator console built to an honesty doctrine: every number is live or honestly absent, and anything not yet real is banner-flagged rather than dressed up. The whole system is multi-tenant from the database up, with isolation enforced in PostgreSQL itself and each agency's credentials encrypted under a per-agency key. It's proven end-to-end against the regulator's pre-production environment and is in pilot; the live signing round-trip with real vendors is deliberately gated behind the client's credentials and sign-off. The result isn't a form-filler. It's the trust architecture for a document that has to be right. It is in pilot, not yet carrying live production load — but what has been built is the agency's own asset, deployed in the agency's accounts under its own key, engineered to become the permanent spine of how it prepares every agreement rather than a service it rents by the month.
Built with
Next project