Initial every clause, not just sign at the end

What it is

At generation, every numbered '### N. Title' heading in the rendered body becomes a required section, frozen on the contract as required_sections (e.g. [{ id: 'waiver-1', title: 'Materials' }]). At signing, each section's 'Client Initials: ___' line is replaced by an interactive slot; captured initials are stored in section_initials as { image, at } per section. Templates with no numbered sections require no initials at all.

Also called: client initials · initial each section · waiver initials · customer says they never read that clause · initial every page · client initials on each section

See it

Initial every clause, not just sign at the end

🔒ridgelinepostframe.com/project/per-se804

40×64 Shop

Framing · on schedule

A waiver section with its paragraph and, in place of the blank line, a dashed-top slot reading 'Initial:' with the customer's drawn initials stamped in. ContractMarkdown renderInitialSlot. Sample data — no customer information appears here.

How it works

1extractRequiredSections() scans the rendered body for numbered H3s and freezes the manifest on the contract row.
2ContractMarkdown tracks the current numbered section while parsing and swaps the literal 'Client Initials:' paragraph for a rendered slot.
3The customer draws initials once on a shared pad, then taps each section to stamp them, with an undo per section.
4The sign button stays disabled until every required section is initialed, and the server re-validates before accepting.
5Signed contracts render the captured images back into the same slots, in the viewer and in print.

Why we built it

Migration 064 states the requirement in the builder's own terms: 'Some sub-accounts (e.g. Graber Custom Structures) require the customer to INITIAL each clause of a waiver — undeniable evidence each section was read and accepted, section by section, not just one signature at the end.' The manifest is frozen for the same reason the body is: 'Frozen on the contract row (like rendered_body) so a later template edit can never desync a signed contract.'

The problem

Disputes over individual clauses in a signed contract
No per-clause evidence of acknowledgment
Paper waivers requiring thirteen physical initials

Sound familiar?

“customer says they never read that clause”“customer claims they didn't know about the site prep requirement”“need proof they accepted each term”“one signature at the end isn't enough”“customer claims they never read that clause”“my waiver needs initials on every section”“disputes about which terms were accepted”

What you get

Per-clause, timestamped acknowledgment

Impossible to submit with a clause un-initialed — enforced on the server

Initials print into the PDF alongside the signatures

What's inside

Draw your initials once, then tap each section

One sticky pad at the top of the agreement: draw your initials once, then tap 'Tap to initial' on each clause as you read it.

Initialed counter and a block on signing until it's complete

A live 'X / 13 initialed' chip, an explicit message naming how many are outstanding, and a sign button that stays disabled until every clause is stamped.

The server re-checks every initial

The signing endpoint re-validates the frozen manifest against what was submitted and rejects the signature if any clause is missing — naming the clause.

Initials render everywhere the contract does

One shared helper renders captured initials into every read-only view — customer copy, builder viewer, counter-sign modal and print — so no surface shows a blank line where an initial belongs.

See it on your own jobs

Twenty minutes, your numbers, no slide deck. We’ll build one of your real buildings in front of you and send you the estimate link at the end — yours to keep either way.

or keep browsing features →