Discovery-ready: structuring project records before the dispute starts

Sooner or later a claims consultant sits down with your project and asks four questions in a row. What was current on this date? Who had it? What did the mail say about it? And can you still tell those facts apart? On a well-run job the answers are queries someone runs in an afternoon. On most jobs they are a fortnight of a document controller's evenings, with folder history on one screen and a mailbox search on the other.

Forensic readiness is not much more than keeping the issued set, the transmittals, the correspondence and the metadata in a shape that answers those questions while the job is still building. The alternative is assembling exactly the same facts after the letter of claim has landed, from directory timestamps and whatever survived in people's inboxes.

The label varies. UK civil procedure usually calls that production disclosure; adjudication and arbitration talk about documents relied on, or document production. The information work behind it does not change with the vocabulary.

Start with one package

Pick a live package the site is installing this week — not the whole job, and not the one everybody already agrees is well run. Name the information standard or BEP you are testing against, including the status-code list that document actually publishes. If there is no list, write that down, because it is a finding in itself.

Then walk the four structures in order. The issued set first, since two live-looking revisions of the same title will poison every check that follows. Transmittals next, because a current row with no issue behind it has not been released to anyone. Then mail, which is where the unofficial instruction really travels. Metadata last, because a cupboard you can browse is a long way from a record you can produce.

Write your findings as sheet numbers, transmittal numbers and mailbox names. “Mostly fine” is not a finding, and a dashboard nobody walked is not readiness.

What a request actually asks for

A request does not ask for a narrative of the job. It asks for a bounded, contemporaneous record: these containers, these revisions, this purpose, these named recipients, this date. Contemporaneous means dated, attributable and hard to edit afterwards. A folder assembled in week eighty out of file dates and honest recollection meets none of those three tests, however neat it looks in the bundle.

The four structures below are the minimum that lets you produce something without inventing it. Skip one and you will spend the dispute reconstructing it from the other three — usually from mail, which is the worst of them to search and the easiest for the other side to produce first.

The issued set

The issued set is the bounded list of current, authorised containers for a package and a purpose. Not everything in a folder called Published, and not last Thursday's zip. It is the list a competent person could hand over today and still stand behind in a month.

For the live package, each title needs five facts:

identity — number plus revision, not a hint in a filename
state — published for the stated use, not shared for coordination and not archive
suitability — what the recipient may do with it, on the agreed list
supersede — which previous identity is dead, and whether it was withdrawn from the hut
date — when this identity became the one site may rely on

ISO 19650 keeps a published state because putting a file in a cupboard is not the same act as authorising it for a use. If one container can sit in Published, in a mailbox zip and on the plywood table as three different revisions, what you have is three candidates. Disclosure will take all three.

Test the set without theatre.

Confirm there is exactly one current revision per title. Two current rows is a fail, even where one is about to be withdrawn.
Confirm the previous revision is marked superseded in the register — not merely sitting under a filename suffix — and that a withdrawal fact exists somewhere: a collected print, a stamped copy, a recorded return, or a named instruction that the earlier identity is dead.
Confirm you can produce the set as it stood on a named date last month, rather than only as it stands this morning. If the only route there is folder history, the set has no journal.

The unofficial set in the trailer is the honest measure here. Site keeps it because the official one cannot be trusted, or cannot be found at the workface, and a request will eventually find both sets and notice they disagree. Controlling one set is labour — supersede, withdraw, plot, collect — and none of it happens because everyone knows.

Deleting the superseded file is not hygiene either. Hide it well enough that nobody can reconstruct what was issued last Tuesday and you have quietly emptied your own claim file. Archive is the journal; keep it findable.

Transmittals are the issue act

Issue is a dated, attributed release: these containers, these revisions, this purpose, these named recipients, this state. A transmittal is meant to be that act. A green cell in a register is not, and a zip in a folder called Issued is storage.

For every revision published since last Monday — plus any older current row with no issue record at all — reconstruct five facts from the system of record rather than from memory:

a unique transmittal number and date
named recipients, not “the contractor” or “the package”
the exact containers and revisions
the purpose, or the action requested
dated evidence of receipt at the installing company, not only at the first mailbox

A gap in any of the first four means the transmittal is missing. So does an upload with no number. So, in practice, does a pack of thirty sheets where the one that changed is not identified, because nobody reads that pack and nobody can explain it afterwards.

Receipt is a separate fact, and worth being pedantic about. A bounce-back that never arrived is not receipt. A download by a document-control mailbox is not receipt at the workface. This is how a register can be entirely right while the pour goes wrong. You do not have to close the whole cascade in one sitting, but you do have to see the hole, because someone will ask who had Rev C on the Thursday.

Do it for the week's issues, not for one tidy pack. A single complete cover sheet proves that a person can produce one when asked; a week of numbered issues starts to look like a habit. The longer distinction — issue, receipt, understanding — sits in the transmittal nobody read.

Mail that points at containers

Mail is where access notices, complaints, “use this” PDFs and half-instructions live. It is also where most panic forensics begins, simply because it is the last place on the job that still has a date and a sender attached to everything. That is not a reason to let it become the system of record.

Two ordinary failures make mail hard for you to search and easy for somebody else to produce.

Mail as the issued set. The drawing that left as a forty-megabyte attachment. The revision that never entered the common data environment. The latest file forwarded at 18:40 to a subcontractor's personal address. Every one of those is a real instruction, and none of them is in the issued set. A later request will turn up the attachment. You may not, if the mailbox has been deleted, the person has left, or the thread never reached a project archive.

Mail as a dump with no pointer. A message saying “drawings attached” that names no transmittal, no containers and no revisions. A thread that argues a change for a fortnight without once identifying the sheet. A meeting note pasted into an email with no link to the published location. The mailbox is full; the record is empty; search returns noise.

So treat official issue as a numbered transmittal, and let the covering mail name the number, the purpose and the published location instead of replacing the act with a zip. Instructions that change the works get a container identity, or at least a clear pointer to the transmittal they amend. “As discussed” points at nothing.

Personal mailboxes are not the archive. Correspondence that amounts to an instruction — a direction to proceed, a notice of access, a rejection of a revision — belongs in the project record with its date, sender and recipients. A thread living in one person's inbox is unavailable to you the week they are on leave, and still available to the other side if that person is later asked to search. Handing over a mailbox export is what a project does when nothing else will answer the question. Readiness is mail that already points at a container you can produce without opening Outlook.

Metadata that answers the request

A folder answers one question: what is in this cupboard. The questions a request asks are different in kind.

What was in Published for this package on a named date? Which construction-series revisions went to the installing company last month? Which containers still carried a coordination suitability while sitting in a folder someone had named Issued? Who received C02, and did they also receive the instruction that superseded it?

Those are queries, and they fail on a file-centric job because the facts were never attached to the container. They were implied by a path that no longer exists, or exists twice, or only ever existed in a mailbox.

Hold four claims still, on the container rather than on the tree:

State — work in progress, shared, published, archive. A folder called Published proves only that somebody with write access moved a file into it.
Suitability — permitted use, on the agreed list, and able to stop a plot or an issue. A letter in a filename is folklore until the day someone forgets to change it.
Revision — the issued identity, and what it supersedes. Overwriting the file and keeping a version stack records who saved. It does not retire the previous identity.
Recipient — who received the issued set, as an act. “They have access to the Published folder” is not a recipient. It is a hope.

If you cannot run those four queries for last month's live package without walking folder history and mail, the answers still exist, but only as archaeology — and somebody will be doing it under a deadline. The longer argument that the tree is last year's organigram sits in Metadata is the product.

The weekly score sheet

Print this. One row per structure, filled in by the document controller, and not edited afterwards by the project manager. Forty-five to ninety minutes, every week the job is building from paper or PDF.

Structure	This week's sample	Pass
Issued set	Every current title in the live package	One current revision; previous marked and withdrawn; set reconstructable on a named date last month
Transmittals	Every revision published since last Monday	Number, date, named recipients, containers, purpose; receipt at the installing company visible or recorded as a hole
Mail	Last week's issue notices and any instruction that changed the works	Each points at a transmittal or container identity; no official issue that exists only as an attachment
Metadata	The same live package	State, suitability, revision and recipient can answer a dated query without folder archaeology

A pass is boring. A fail is a sheet number, a transmittal number or a mailbox. Do not average the four rows into a percentage, which invents precision the hour does not have, and do carry last week's fails forward until they are closed — otherwise the exercise starts from nothing every Monday.

None of this waits for close-out, an audit or a consultant. Once a dispute has started you are no longer structuring the record; you are searching it, at somebody else's pace.

What the hour does not settle

What a court or tribunal will actually require, and by when, stays with the contract and whoever is advising on the claim — none of this invents a production timetable. The lead appointed party can still make answering a query rather than a reconstruction. Give the weekly walk a named owner: forty-five to ninety minutes, every week the works are still live, filled in by the document controller and left unedited by the project manager, fails carried forward. Back the refusal of a zip-as-issue on that Tuesday. The cost is a slower transmittal and a row on the score sheet; the alternative is assembling the same facts from inboxes after the letter of claim has landed.