One Document Register From Lead to As-Built

Here is a failure mode that looks like a small user interface annoyance and is actually an architecture problem.

You open a project and see a yield report under engineering documents. You scroll down and see a yield report again under site documents. Both have upload buttons. Neither tells you whether they are the same file.

They usually are. And the reason they appear twice is that two different parts of the system each believe they own that document.

Why it happens

Documents arrive at a solar project through different doors. Some are synced from the proposal. Some are uploaded by the installer. Some are generated by the engineering tools. Some are collected for the lender.

If each of those paths keeps its own list, the same real-world artifact ends up with two or three identities. Then the duplication becomes visible, someone deletes one of the copies to tidy it up, and a status that mattered somewhere else silently disappears with it.

Stages are real, registers should not be

The temptation is to merge everything into one flat list. That is the wrong correction, because the stages are genuinely different things:

• Indicative. Bills, metering data, the first-pass proposal.
• Engineered. Drawings, the single line diagram, the yield report, the bill of quantities, the compliance packs.
• As-built. Certificate of compliance, as-built drawings, the serialised asset register, test logs, operations and maintenance material.

An as-built drawing is not an engineered drawing that has been updated in place. It is a different document with a different purpose and a different audience.

The answer is one register in which every document carries its stage, and each surface renders a filtered view. The engineering pane shows engineered documents. The handover pane shows as-built. The lender pack shows whatever that lender requires. A document appears once, wherever it is relevant, carrying its own status with it.

The test of a good register

A useful check: can two different people do two different jobs on the same document without the document existing twice?

An installer uploads a yield report. An engineer confirms it is the correct one. Those are genuinely different actions, and an inelegant system models them as two documents in two lists. A good one models them as one document with an upload and a confirmation.

What it buys you

Beyond the obvious tidiness, three things:

Honest completeness. If a document exists once, a completeness count means something.

Safe deletion. Nobody removes a duplicate and accidentally removes a sign-off.

A handover file that assembles itself. If every document already knows its stage and status, the close-out file is a filter and a render, not a folder somebody builds by hand at the end of a project.

Frequently asked questions

Should the client see the same register as the lender?

They should see the same underlying documents framed differently. The lender needs the phase submission that releases a drawdown; the client needs the as-built pack, warranties and operating material. One register, two views, never two registers.

What about our own internal documents?

You add your own slots on top. Core sections and lender-required slots can be added to but not removed, so a pack never loses the evidence behind a number.

Does this mean fewer documents?

No, the same documents. It means each one exists once, which usually makes the list look shorter and the gaps look larger, which is the point.