Research, Memos, and Explaining a Position to a Client

Before any research happens, someone has to work out what the question is, and that step is where inexperience costs the most.

A client describes a transaction. They sold a business, or moved country, or restructured a group, or received something they are not sure how to characterise. What they describe is a set of facts. What the professional has to produce is a list of tax issues those facts raise, in the right areas of law, including the ones the client did not think to ask about.

This is pattern recognition over a very large surface, and it is exactly the shape of task where broad coverage helps. A model given a fact pattern will produce a list of potentially relevant areas, doctrines and code sections, and its breadth is genuinely useful, because a specialist's blind spot is the area they do not practise in.

The value is asymmetric and worth being precise about. A missing issue is the expensive error in tax advice. A client advised correctly on the four issues they asked about, and not advised on the fifth, has a problem that surfaces years later. An over-inclusive list costs an hour of reading.

So the model's tendency to generate plausible adjacent possibilities, usually a liability, is here a feature. The list is a prompt for your own thinking, not a scope.

And nothing on that list is authority. It is a set of places to look.

There is one architectural distinction that determines whether a research tool is usable in tax, and practitioners should ask about it before anything else.

Recall means the model answers from what it absorbed during training. It will produce a section number, a ruling and a holding from memory. This is where fabrication happens, and where superseded authority is presented as current, because training data has a cut-off and no awareness of it.

Retrieval means the system searches an actual corpus of tax authority, returns the documents, and generates its answer against those retrieved documents with links back to them. The failure mode changes character entirely: instead of inventing a ruling, the system retrieves the wrong one or misreads the right one, and both are catchable because the document is in front of you.

This is why a general-purpose chat interface and a tax research platform with generative search are different products, even where both are described as AI. The question to ask a vendor is not which model it uses. It is what corpus it searches, how current that corpus is, and whether every proposition links to a retrievable source.

A useful test on any tool. Ask it something that turns on a recent change. A recall-based system answers confidently from the pre-change position. A retrieval-based system returns the current document or returns nothing.

The second answer is the safe one, and a tool that says it found nothing is behaving correctly rather than failing.

Comparing what happens to a research question under each design.

On the recall path, the question goes to the model and the model answers from training. What comes back is fluent, well-formed, and may contain an invented citation, a superseded authority, or a holding that the real case does not support. Crucially, none of those are visible in the output, so verification means independently researching the question you just asked, which removes the saving entirely.

On the retrieval path, the question drives a search over an actual corpus. Documents come back. The answer is generated against those documents with links. The failure modes are that the search missed a relevant authority, or that the summary misreads a retrieved document. Both are catchable, because the document is right there and reading it is the professional's job anyway.

The practical difference is not accuracy in the abstract. It is whether verifying costs more or less than the research would have. On the recall path it costs the same. On the retrieval path it costs a fraction, because the sources are already assembled.

Before automating memo production it is worth being clear about why memos exist, because there is more than one reason and they demand different things.

The first reason is to answer the question. The client or the partner needs to know the treatment, and the memo says so.

The second is to record the reasoning, so that in three years, when the position is examined or the client asks why, the analysis is retrievable rather than reconstructed.

The third is protective. A contemporaneous memo setting out the authorities considered and the conclusion reached is evidence about the state of knowledge at the time the position was taken. Where a penalty question turns on whether there was substantial authority, or on reasonable cause and good faith, the file is what answers it.

That third purpose constrains what a generated memo may contain, sharply.

A memo whose citations were never pulled is worse than no memo, because it purports to document diligence that did not occur. If an authority in it turns out to be fabricated or superseded, the document that was supposed to demonstrate care demonstrates its absence, in writing, with a date on it.

So the rule for memo drafting is narrow and firm. The model may structure the document, write the prose, and organise the analysis. Every authority in it has been read by the person signing it. The conclusion is theirs.

Drafting is delegable. Diligence is not, and the memo is a record of diligence.

Given that constraint, here is what the workflow looks like in practice, and it is genuinely faster than writing from scratch.

You have done the research. You have a folder of authorities you have read: the code sections, two regulations, a revenue ruling and a case. You have formed a view and a confidence level.

What you supply to the model. The facts. The authorities, as documents rather than as citations. Your conclusion. Your reasoning in whatever rough form it currently exists, which is usually notes.

What comes back. A structured memo: facts, issues, applicable authority, analysis, conclusion, and where relevant the disclosure recommendation. Written in a consistent house style, with the analysis organised rather than in the order you thought of it.

Why this works when generating the analysis does not. The intellectual work is already done and captured in your notes. What remains is exposition, structure and consistency, which is writing work rather than tax work.

The review then has a specific shape. Check that every authority is characterised as you understood it, since a model summarising a case you supplied can still overstate its holding. Check that the contrary authorities are still present, since compression tends to drop them and the regulation requires weighing both sides. Check that the conclusion is yours and not a slightly stronger version of yours, which is a real and easily missed drift.

That last one recurs. Generated prose tends to firm up hedged conclusions, and in tax the hedge is the point.

A large part of advisory work is reading something long that was not written by a tax professional and finding the parts with tax consequences.

A share purchase agreement. A lease. A partnership deed. A settlement agreement. An employment contract with an equity component. A trust instrument. Each is dozens or hundreds of pages, most of it irrelevant to tax, with a handful of provisions that determine the treatment.

This is a search problem with a high skim cost, and it is where document analysis genuinely helps. Supplied with the document and asked for the provisions bearing on a specific question, the model surfaces candidates far faster than reading front to back.

Two cautions that matter here more than elsewhere.

First, absence is not evidence. A model asked whether a document addresses something and reporting that it does not is the least reliable output available, because it requires exhaustive coverage rather than pattern matching. For a question where the absence of a provision matters, and in tax it frequently does, that has to be verified by a person.

Second, tax consequences often turn on the interaction of provisions in different parts of a document, or on a definition three sections earlier modifying an operative clause. Retrieval finds passages. Interaction between passages is harder, and it is exactly where a well-drafted agreement hides its effect.

So the useful framing. It produces the shortlist and you read the shortlist plus the definitions, rather than the whole document. That is a real saving, and it is not the same as having read the document.

The final advisory workflow is turning a technical position into something the client can actually use, and it is where generation is unambiguously good.

The problem it solves. Tax advice is written in a register that protects the adviser and defeats the reader. Conditional, heavily qualified, dense with citation, and structurally organised around the analysis rather than around the client's decision. Clients frequently receive advice they do not understand and act on a half-memory of a phone call instead.

What helps. Producing a plain-language version alongside the technical one, organised around what the client has to decide and do. Explaining why a position carries uncertainty in terms of consequences rather than probability language. Setting out what disclosure means practically, since a client told a position will be disclosed on Form 8275 usually hears something alarming that was not meant.

The discipline. Simplification must not become misstatement, and this is the specific failure mode when you ask for plainer language. A qualified conclusion rendered plainly tends to lose the qualification, and in tax the qualification is often the most important part: this treatment depends on the transaction being characterised as X, and if the facts turn out otherwise the answer changes.

So the check on any simplified client explanation is narrow. Are the conditions still there. Is the uncertainty still there. Would a client reading only this document be surprised by anything in the technical version.

If the answer to the last is yes, the simplification went too far, however much clearer it reads.

Each workflow fails differently, so a single generic check catches none of them. The specific ones.

Issue framing. No review needed in the usual sense, because nothing produced is relied on. The output is a reading list. Its only failure mode is under-inclusiveness, which your own knowledge covers.

Research. Every authority pulled and read at source. Not spot-checked. The two failure modes, fabrication and superseded authority, are both invisible from the output, so sampling does not work.

Memo drafting. Three specific checks. Each authority characterised as you understood it. Contrary authorities still present after compression. And the conclusion not firmed up beyond what you concluded.

Document review. Treat any report of absence as unverified. Read the definitions alongside the shortlisted provisions, because interaction between passages is where the effect hides.

Client explanation. Conditions and uncertainty survived the simplification. A client reading only this would not be surprised by the technical version.

Compliance and extraction. Totals reconciled against source. Nothing computed by a model.

What unifies them is the principle from lesson one. The model is used before the authorities are touched and after they have been read, never in the middle. Every review above is a check that the middle stayed human, expressed in the terms of that particular workflow.