Our engine had a bug. An Arizona power of attorney it produced would have carried a correctly-witnessed signature block and still been defective. We caught it before shipping Arizona, and the way we caught it is more interesting than the bug.
A power of attorney is not a contract between you and your agent. It's an instrument you hand to a third party — a bank, a title company, a hospital — and its only job is to be honored by someone who has never met you and has no reason to take a risk.
That reader isn't evaluating whether the document expresses your intent. They're checking whether it was executed the way their state requires. Get that wrong and the failure has a particular shape:
incapacitated and a bank counter is the first reader.
So the execution block isn't boilerplate at the end of the document. It is the part the document exists to get right.
Most states that require witnesses require a signature. Arizona requires a sworn attestation in words the statute prescribes.
A.R.S. § 14-5501(D) sets out what a durable POA must satisfy, and subsection (D)(4) is the one that matters here: the instrument must be executed and attested in a prescribed form, in which the witness swears to specific facts — that the principal appeared to be of sound mind and free from duress, and that the witness is not the agent.
A generic block that reads:
Witness 1 signature ______________ Printed name ______________ Date ________collects a signature from a qualified witness and satisfies none of it. The right number of signatures, from the right people, in the wrong form.
Our corpus had Arizona right. It recorded notarization as required, witnesses as required, count 1, with the disqualifications. Every field was bound to a provision and quoted.
The generator was the problem. app/poa/draft.py built execution blocks from hardcoded templates — a signature rule for witnesses, a standard acknowledgment for the notary. It never rendered the statute's own language into the instrument. For the states whose recorded requirement is a witness signature and nothing more, a signature block is what the corpus describes. For Arizona it produces a document that looks complete and isn't.
The data model couldn't express the difference. Formality could say whether a witness was required and how many. It had nowhere to say "and the statute dictates the words."
Each jurisdiction in our corpus is researched, then independently re-read by a second automated pass whose instruction is adversarial: assume the first pass is wrong and try to show it. That checker answers one question — would an instrument executed to exactly these formalities be validly executed in this state?
Arizona's checker did something we hadn't asked for. It read the generator.
Confirmed against the engine, not just the statute.
app/poa/draft.pyhardcodes
generic execution blocks and never renders this record's
operative_wordsinto
the instrument.
That sentence is why Arizona is locked. The corpus was right and the answer was still no, because correct data rendered through a generic template produces an incorrect document. A check that had only compared our JSON against the statute would have passed Arizona and shipped the defect.
Formality now carries two more fields:
prescribed_clause_required: bool = False
prescribed_clause: str = ""and the draftability rule changed. A state that prescribes language we do not hold cannot be drafted at all — not drafted with a generic block and a warning. Where we do hold the language, the draft prints it verbatim rather than paraphrasing it into a signature rule.
Arizona remains locked on its own verdict. The point of the fields isn't to unlock Arizona; it's that the next state like Arizona fails loudly instead of silently.
The category risk for any automated document generator is this: the data can be right and the document still wrong, because a document is data plus the form it is rendered in, and statutes regulate the form.
That failure is invisible to most testing. The output parses. It has the required number of signature lines. It matches the corpus. A schema validator passes it, a diff against last week passes it, and a human skimming it sees a normal-looking power of attorney — because nothing in the corpus for the states without a prescribed form records anything the block would miss; Maine, like Arizona, prescribes one and is refused.
Three things we'd now argue are necessary rather than nice:
1. Verification has to reach the renderer. Checking your legal data against the statute is checking half the system. The other half is whether the generator faithfully expresses it. 2. "Unknown" must block, not degrade. A missing formality should stop a draft. Emitting a best-effort document with a disclaimer moves the risk onto the person least able to evaluate it. 3. The safe direction is asymmetric, so the defaults should be. An unnecessary notary block makes a document over-formal, which is survivable. A missing prescribed attestation makes it void. Those errors are not equivalent and shouldn't be treated as equivalent.
Arizona and Maine are refused. You can read everything we hold for them, free, including the citations and the reason each is locked — and take it to an attorney licensed there.
We'd rather lose those sales than produce an instrument that fails at a hospital.
Documents are prepared by a non-attorney from statutory text. This is a document compilation service, not legal advice; it creates no attorney-client relationship and does not determine that any legal requirement has been met.