Structure first: documents are written for human eyes

A contract, a tender or an enterprise agreement is written for a person turning pages. A great deal of its meaning lives in the layout rather than the words. Indentation tells you that (b) belongs to clause 7.2 and not 7.3. A table that breaks across a page is still one table. A schedule at the back changes what a clause at the front means. The model, by contrast, gets the words.

One tender I worked on made the point neatly. The allowed answers to each requirement existed only in a drop-down list in the spreadsheet. Read as text, the document gave no hint of what a valid answer even looked like.

The hard part of big-document work is rarely the model’s reasoning. It is turning a document written for human eyes into a structure a machine can be held to.

Don’t ask the model to find the structure

The common approach is to give the model the document and let it work out the clauses as it goes. It usually does a reasonable job. It also does a slightly different job each time, and you can’t see where it drew the lines.

Structure first means code does this step, not the model, and it uses the structure the document already carries: its numbering, headings and schedules. The output is a plain list of every clause and sub-clause with its exact text. It is deterministic, so the same document gives the same structure every time.

Prove nothing was dropped

Splitting a document is only useful if you can show nothing fell through the gaps. Two checks do that.

A coverage ledger. Every character of the source is accounted for: captured in a clause, or set aside as furniture such as page numbers, running headers and the contents page. Anything set aside is listed with a reason.

A second reader. A different extraction tool reads the same document independently, and the two are compared. Where they disagree, a person looks. This is the check that catches the quiet failures: the opening sentence before a bulleted list that vanished, or two sub-clauses that merged into one.

Some things a reader can’t capture at all: text in comments and footnotes, text boxes, answers that live in drop-down lists, pictures of tables. Those are listed for a person rather than ignored.

A person confirms it, cheaply

Then a person looks at the structure before anything else happens. It doesn’t need special software. A plain text file or a simple review page is enough, and it takes minutes, because the job is only to check the lines are in the right places.

This is the cheapest oversight in the whole process and the most valuable. Every later step works through this confirmed structure as many small tasks. If the structure is right, completeness is something you can measure rather than hope for.

What it caught in the benchmark

On the benchmark bundle, the single prompt stopped between 11 and 14 percent short of the end in every full run, without saying so. The pipeline accounted for every paragraph in every run, because it was working through a list it could count. BigDocs: the benchmark

It also caught faults in my own tools. On a long Commonwealth contract, the contents page was read as if it were the first part of the contract, and some clause numbers drawn from Word’s heading styles were read wrongly. The person checking the structure caught the first; the second was fixed in code. Both are exactly what this step is for. Better found at the structure check than in a redline sent to a customer.

What your team can do on Monday

Take the last big document that came back from AI looking right and turned out not to be. Count its clauses or sections yourself and compare that with what the AI’s answer covered. If the numbers don’t match, you have found the first thing to fix, and it isn’t the prompt.