Records of Advice Are Where the Time Actually Goes

Every conversation about automating advice documents starts with the Statement of Advice. It is the document with the page count, the one a principal can hold up in a meeting, and the one a vendor demonstrates because the before and after is obvious. We named a product surface after it.

It is also the document a practice produces least often. New clients arrive at whatever rate the firm's pipeline allows. Existing clients come back every year, and some of them come back twice, because a fee consent needs resetting, an insurance premium moved, a contribution strategy needs a small change, or a product was closed to new members and the holding has to go somewhere. Each of those produces a document. Most of them are Records of Advice on a shorter template, and each one still has to be checked, approved and filed somewhere a licensee can find it in eighteen months.

If you are costing advice automation, that is the number to build the model on.

Count the Documents, Not the Demo

The arithmetic is the whole argument and a firm can do it from its own file notes in an afternoon. Take the count of advice documents produced in the last twelve months and split it by type. Then split the second column again by how much of each document was genuinely new writing.

An SoA for a new client is mostly new: the scope, the reasons for the recommendation, the comparison against the existing arrangement. A review document for a client whose strategy has not changed is mostly the same sentences carrying different values, plus two or three paragraphs of actual reasoning about what moved and why it does not change the advice. The writing is shorter. The assembly, the checking and the supervision are not, because a wrong figure in a two page record is exactly as wrong as a wrong figure in a forty page one.

There are 6,478 AFSL holders in Australia and I will not pretend the ratio is the same in all of them. A firm three years into building a client base has a different mix from one running a mature book. But in any practice where the book is larger than the pipeline, the repeating unit of work is the review, and a saving on the review cycle compounds against the annual calendar rather than against new business.

Why the Same Engine Can Run a Leaner Template

This matters commercially because of a design decision we made in the drafting engine, and it is worth being specific about what it is.

A firm's template is treated as data, not as a prompt. The engine reads the template the firm already uses and classifies every bracketed marker in the prose into exactly three kinds. A value marker resolves to a fact on file, such as a balance or a premium. A conditional marker decides whether the surrounding text appears at all. A free text marker is an instruction to the writer, such as "explain why this product was chosen". A value is looked up. A conditional is evaluated to true or false. Only the free text reaches a language model, and it arrives with the surrounding paragraph, the section title and the section context attached.

The invariant underneath that is the part I would want a buyer to interrogate: resolution is content driven, with no hardcoded mapping from a particular marker to a particular answer. Nothing in the system says "when you see this bracket, write this sentence."

That is why a leaner review template is not a second build. It is the same engine reading a different document. If the mapping were hardcoded, every template a firm wanted would be an engineering ticket, and the RoA template would be quoted separately because it would genuinely be separate work. We do not have a Record of Advice product surface, and the reason is that a product surface is not what the problem needed.

What Goes Wrong on a Review Document

Review documents fail differently from new SoAs, and the failure is dull. Nothing is missing. Something is simply from last year.

Before a rendered block is allowed to stand, it is scanned for six classes of unresolved placeholder: a raw bracketed placeholder that was never filled, an XXX style stub, a dollar figure left as a literal $X, a TBD, an "insert something here" instruction that survived into the output, and a conditional tag that was never resolved either way. Those are the failures a reader spots in two seconds and a licensee spots in one. The check is pure CPU, with no model call and no file access, and it runs on every block save in under a millisecond.

The design point is not the speed. It is the division of labour. A cheap deterministic check runs constantly and an expensive probabilistic one runs once. On a document that is ninety per cent carried forward and ten per cent new reasoning, that division is more favourable than it is on a new client SoA, because the deterministic share of the work is larger.

What Our Own Number Does Not Cover

Here is the limit, and it cuts against the argument I have just made.

The number we publish is a 60 per cent reduction in SoA production time. It is client derived, and it is one of the two inputs behind the savings calculator. It is a Statement of Advice figure. We have not measured an equivalent figure for the review cycle, and I am not going to derive one by asserting that the ratio holds, because I do not know that it does. The September read of the drafting mechanics I have described above is a read of SoA assembly.

So the honest position is this: the case for pricing the review cycle rests on the firm's own document counts and on a design invariant you can verify by asking a vendor to point a drafter at a template they have never seen. It does not yet rest on a measurement of ours. If you are being sold a review cycle saving by anyone, including us, ask which of those two things the number came from.

The Part the Software Should Not Decide

Whether a particular piece of further advice can be documented as a Record of Advice rather than a fresh SoA is a licensee judgement on the facts of the client. It depends on what has changed since the last document and on the licensee's own standard, and it is not a decision that belongs in a rendering engine. What the engine owes the licensee is the trail: which template was used, which values resolved from which facts, which conditional sections were switched on, and which passages a model wrote and a person approved. That trail is a property of the engine, so it is identical whether the output runs to two pages or forty.

One caution on modelling. DBFO Tranche 2 is not enacted. Any business case that assumes a lighter document standard is arriving is a business case built on a draft, and the review cycle you have to survive between now and then is the one already in your calendar.