Your Template, Not Ours: How SoA Automation Works With a Firm's Own Document

Most questions we get about Statement of Advice automation are about the model. Can it write the reasoning? Will it get the product comparison right? Those are reasonable questions, and they are not the ones that decide whether the software survives contact with a licensee.

The question that decides it is duller. Whose template is the document drafted into, and who has to be called when that template changes?

Three kinds of bracket, and only one of them is a writing job

Open any firm's SoA template and you will find bracketed markers scattered through the prose. They look alike. They are not alike, and treating them as one thing is the root of most disappointing advice automation.

There are exactly three kinds.

A value marker resolves to a fact already on file. A balance, a premium, an insured amount, a fee. There is a correct answer and it is sitting in the client record. Nothing about filling it in requires judgement, and a system that asks a language model to produce it has introduced a probabilistic step into a lookup.

A conditional marker decides whether the text around it appears at all. A paragraph about transition to retirement that should not render for a thirty-four year old. A block about an existing policy replacement that only belongs in the document if there is a policy being replaced. This is a true or false evaluation. Again, no writing.

A free text marker is an instruction to whoever is drafting. "Explain why this product was chosen." That is the only one of the three that is actually a writing task, and it is the only one that reaches a language model in our system. When it does, it does not arrive alone. It carries the surrounding paragraph, the section title and the section context with it, because "explain why this product was chosen" means something different in the risk insurance section than it does in the superannuation consolidation section, and the instruction on its own does not say which.

A firm that has been burned by advice software usually got burned because all three were handled the same way. Either everything went to the model, in which case the balance is now a plausible number rather than the client's number, or nothing did, in which case the paraplanner is still writing the reasoning and the software has saved them a Word click.

The invariant: no marker is wired to an answer

Here is the part that matters, and it is a design constraint rather than a feature.

Resolution is content driven. Nothing in the system says "when you see this bracket, write this sentence." There is no lookup table mapping a particular marker to a particular output. The classification into value, conditional or free text is derived from what the marker and its context actually say, not from a registry of known markers that someone maintained.

That sounds like an implementation detail until you consider what the alternative costs. If a marker has to be registered before it works, then every template change is an engineering ticket. A licensee revises its SoA wording after a compliance review, which is a thing that happens on a schedule none of us control, and the firm is now waiting on a vendor to teach the system what the new brackets mean. In practice that means one of two outcomes: the firm delays its own compliance change, or it keeps two templates, the one the compliance team approved and the one the software can handle.

We took the constraint seriously because the alternative is a product that only works on documents we have seen. A firm should be able to open its template, rewrite a section, add a bracket that has never existed anywhere before, and have the system handle it the same way it handles the rest. That is not generosity. The moment a vendor sits between a firm and its own document, the firm has lost control of something it is legally accountable for.

This is the difference between advice software and a mail merge. A mail merge knows a fixed set of fields and fills them. It is genuinely useful and there is no shame in it. What it cannot do is meet an instruction it has not been configured for, which is most of what a real SoA template contains.

Six ways a placeholder fails, checked on every save

The reasoning is the hard part. The embarrassing part is different.

Every rendered block is scanned for six classes of unresolved placeholder before it is allowed to stand:

1. a raw bracketed placeholder that was never filled
2. an XXX style stub
3. a dollar figure left as a literal $X
4. a TBD
5. an "insert something here" instruction that survived into the output
6. a conditional tag that was never resolved either way

None of these are subtle. A client spots a TBD in two seconds and a licensee spots it in one. A single $X in a rendered SoA does more damage to a firm's confidence in its automation than a paragraph of mediocre reasoning, because mediocre reasoning looks like a draft and $X looks like nobody read it.

So the check is deliberately cheap. It is pure CPU, no model call and no file access, and it runs on every block save in under a millisecond. There is nothing clever in it. That is the point. A cheap deterministic check runs constantly, and the expensive probabilistic one runs once. Building it the other way around, where the model is asked to check its own output for stubs, costs more and catches less.

What this actually buys a firm

Frazer Walker, an AFSL holder, put their published figure at a 60% reduction in SoA production time. Their Head of Compliance described it this way: "Finally, AI our compliance team actually approves. Everything stays on our servers, audit trails are built in, and our advisers are spending time with clients instead of fighting Word templates."

The phrase worth pulling out of that is "fighting Word templates." The time that disappears is not mostly the time spent composing a paragraph of reasoning. It is the time spent working out which optional block applies to this client, copying figures across from the fact find, and then reading the whole thing again to find the one bracket that was missed. Two of those three are deterministic problems, and they are solved by the classification and the placeholder scan, not by the model.

Which is the uncomfortable conclusion for an industry conversation that is mostly about model capability. The model matters for exactly one of the three bracket types. Everything else that makes the output trustworthy, reading a template the firm already uses, deciding which brackets are decisions and which are facts, and refusing to render a document with a TBD in it, is ordinary deterministic software. It is less interesting to talk about, and it is most of the work.

The same reading of a firm template is what our SoA automation runs on. There is a limit to it that is worth stating rather than glossing. Content driven classification means the system reads the template rather than being told about it, and reading can be wrong. A marker written ambiguously enough can be classified as a value when the firm meant it as an instruction. What that produces is a visible failure rather than a silent one: the placeholder does not resolve, and the scan catches it before the block stands. That is a worse experience than getting it right, and it is a better one than a confident wrong number in a document with a firm's logo at the top.