Issue Codes Built From Jury Instructions Beat a Short Code List

Each element in the jury instruction can become its own issue code.

An issue code is a tag a reviewer attaches to a document to say which legal question it bears on. Most guides still tell you to keep the list of them short; the research section below tests that advice against cost and accuracy data.

Consider the solo litigator who opens a collection of thousands of emails and chats on a Monday morning, the folders swelling on the screen like dough left overnight in a warm kitchen, every thread fermenting into three more, and who asks the two questions this market keeps asking: how to cut the cost of review, and which affordable tool can carry the load. The usual answer is a handful of broad codes, applied by tired people. That answer protects consistency. It also throws away the structure of the case.

A jury will not be asked whether a document is "about the contract." It will be asked whether each element was proven.

This article shows how to build codes from those elements, why the short-list rule loosens once AI applies the tags, how to defend the result, and how element tags fold directly into a proof chart.

How does a pattern jury instruction become a code set?

Each element in the pattern instruction becomes its own code, and every tag the AI applies links back to the exact exhibit, so an attorney can verify any element in one click.

I would build the map in four moves, once for every claim and once for every defense:

1. Copy the elements exactly as your state's pattern instruction lists them, one line per element.
2. Give each element its own code, nested under the claim it belongs to.
3. Write the application criteria from the instruction's own wording, so the AI tags what the jury will actually be asked to find.
4. Pair each defense element with the claim element it attacks.

Take breach of contract, the plainest of civil claims, whose pattern instruction unfolds like a seed pod splitting into five chambers: formation, the plaintiff's own performance, the defendant's breach, causation and damages. A short list would fold all of that into one tag called "Contract," a dark and swollen category into which every email about the deal would sink like autumn leaves into a cellar, teeming and undifferentiated, so that at the end of review you possess a heap rather than a proof. An element map keeps the chambers apart.

The table is illustrative. The element wording must come from your own state's instruction, not from this page.

Code enforcement offices already work this way. The CivicPlus help center describes an inspector attaching each specific code or ordinance to a violation record, and each attached code carries its own fields for offense, conditions observed, penalty, open or closed status, number of instances and a resolve-by date. Swap "ordinance" for "element" and the record a litigator needs appears, as if it had been waiting in the drawer all along: each element code open until evidence closes it, with a running count of the documents behind it.

Instructions also branch. A 2017 Code Classroom column in phcppros described a buyer who purchased one incorporated standard only to find it referenced many others he also had to buy. Pattern instructions proliferate the same way, with "material breach" or "damages" pointing to separate definitional instructions, and each definition deserves a child code beneath its parent element.

A comparison of 4 sources shows one pattern: rule-heavy work turns granular once software, not memory, carries the rule. In our demos, a firm brings a messy collection and a hard question, then watches the system read, code and cite its own evidence. Loaded into an AI issue coding workflow, the element map changes what that firm sees. In practice, the code list now mirrors the verdict form. An empty element is visible, not buried.

The common assumption is that more codes breed more disagreement, which is true of people working at night through a review queue, and the reason it loosens under software is where the argument turns next.

Why were issue code lists kept short, and does that rule survive AI coding?

Short lists protected human consistency when manual review cost dollars per document and roughly $19K/GB; once AI codes at cents per document, the reason for that ceiling largely falls away.

The conventional wisdom says to keep a coding taxonomy short, named clearly and defined tightly. I agree with the last two parts. The first part was never a principle of analysis; it was a concession to fatigue.

Picture the review room as it was in those days, a long table under fluorescent light where contract reviewers worked through the night, each one carrying the code list in memory like a pocketful of keys, and every added key made the pocket heavier, the hand slower, the choice between two neighboring keys more uncertain. A roomful of people reading the same email would reach for different keys. Training could narrow that drift but never close it. So protocol writers did the sensible thing and took keys away.

That is a consistency and training constraint, not an analytical one. Nothing about a breach claim gets simpler because the list is short. The law stays dense, and only the tagging grows coarse.

Other rule-heavy fields show the same tension and a different resolution. Construction Dive reported that architects, engineers and builders must find the provisions that apply to a project among roughly 93,000 building codes used across U.S. counties and municipalities, a 2017 estimate from The Economist, and that McKinsey & Co. found the sheer number of codes to be a barrier to housing affordability. The industry did not answer by inventing a shorter code. It answered with software: UpCodes AI, a BIM plug-in, runs what the outlet called a "spell check" for code requirements against a searchable database. The rules stayed many. A machine carried them.

Federal regulation tells the same story from the other side. A 2017 phcppros column reported that the Code of Federal Regulations incorporated some 9,500 private standards by reference, governing everything from cribs to valves. No one proposed trimming the law to fit a reviewer's memory.

Cost was the second wall around the short list. At dollars per document, every extra decision a reviewer makes is billed, and every extra code adds decisions. We put the economics plainly: they are demonstrable, not asserted, a gap between cents and dollars that a buyer can see on their own matter. Once the per-document price falls that far, adding an element code no longer adds a reviewer's hour.

The practical question then shifts. Firms asking how to reduce the cost of document review in litigation tend to cut codes first. The better cut is human passes. Volume behaves differently too, as the analysis of whether a bigger document set always means a longer review shows, and code count follows the same logic once software applies the tags.

Consistency does not vanish as a concern, though. It moves, from the reviewer's memory to the written criteria behind each code, and from there to whether opposing counsel can check the work.

How do you defend element-mapped AI issue coding if opposing counsel objects?

Defend the process, not the code count: immutable originals with content hashing, append-only audit trails, documented chain of custody and a fail-closed privilege gate let the method hold up under challenge.

A defensible taxonomy is one whose every tag can be traced back to a written rule and forward to a document. Three steps get a small firm there:

1. Document the mapping. For each code, record the instruction it came from, the element's wording and the criteria the AI was told to apply. Freeze that version before the first pass.
2. Sample by element, not by collection. Pull a handful of tagged documents under each element code and have an attorney open the cited exhibit behind every tag.
3. Keep the record intact. Preserve the audit trail of who changed which code, when and why, so a revised criterion never looks like a hidden one.

The question buyers keep asking, whether AI issue coding or technology-assisted review is easier to defend, misreads where the defense lives. Predictive coding is usually defended by sampling a relevance ranking across the whole set. Element coding is defended tag by tag. Each tag either points to a passage that satisfies a written criterion or it does not, and that binary is something a judge can read without a statistician at the elbow.

There is a quieter risk the code count itself creates. An element map is the case theory written out in full, every claim split open and laid bare like the ribs of a leaf held to the window, and it deserves the same protection as any memo. Our processing runs single-tenant, or inside the firm's own AWS account under its own keys, with no vendor retention and no model training, so nothing fed into the map trains anyone's model or waives privilege.

Scale matters less than people fear. Relevant e-Discovery was built to bring enterprise-grade defensibility at small-matter economics, operable by a solo or small firm on a single messy matter without an administrator. A small firm does not need a review department to run this. It needs the mapping, the sample and the record.

Each of those depends on one habit: opening the source. The case for source-linked review as the new defensibility bar rests on it. An unverified element tag is an assertion. A verified one is evidence, and it can move into the proof chart.

What should you do with your issue code list now?

Start by checking whether your review platform can attach several element codes to one document, each with its own status and notes; without that, an element-level code set has nowhere to live.

The short list was a fence built around tired readers. A newer question now deserves your attention: ask any vendor where its rule library comes from, and who holds the reuse rights to that text. I expect element-level coding to become the default way small firms organize review, because it answers the question a trial actually asks.

One gap remains honest to name. The evidence behind this article does not yet measure how AI coding consistency holds as a code set grows, so firms should sample their own runs until someone does.

The same discipline reaches beyond review. Choosing defensible legal hold tracking, or weighing hybrid keyword and concept search against keyword terms alone, comes down to one test: can every decision be traced to its rule? Start with one claim, its five elements, and the empty cells that appear the first night the chart fills in.