Six numbers, one drawing.

Issue crosses the boundary. Withdrawal doesn't.

Reporting Week 13 established that document control succeeds when one revision is in use and no other, and that the hard half is removing the old one rather than sending the new. That was inside one organisation, where the difficulty was paper leaving the system.

Across organisations the difficulty is different in kind. You can issue to another firm because you have their address. You can't withdraw from them, because withdrawal means reaching every place a document went inside their business, and their internal distribution list is theirs.

So the instruction that a revision is superseded travels to a document controller who can act on their own register and can't act on the four sub-distributions they made from it. Each of those is somebody else's problem, and each of those people received a drawing rather than an obligation.

Which means a superseded revision doesn't get withdrawn across a project. It decays, at a rate set by how often each firm happens to check.

Status codes that don't map

The second failure is quieter and produces work that has to be undone.

Every firm has status codes and they are not the same codes. One uses letters against a scheme where a particular letter means the document may be built from; another uses the same letter for issued for review. A third has an intermediate status the first two don't recognise at all.

When a document crosses a boundary its status is re-entered by hand, by somebody translating between two schemes they were not told were different. A document that left as issued for review can arrive as approved, not through carelessness but because the receiving system has no code for what it actually was.

And the consequence is the one from Week 13 arriving through a new door: somebody builds to a drawing that was never released for it.

What a shared environment fixes and what it costs

A common data environment answers this properly. One space, one identity per document, one status scheme, and no re-registration at any boundary because there are no boundaries to cross.

The cost is not the software. It is that six independent businesses have to give up their own systems for this project, train people on somebody else's tool, and accept that their document register lives in a space controlled by another party. That is a commercial negotiation, it happens at award or not at all, and it is priced.

Where it has been agreed, this week is largely unnecessary. Where it has not — which includes most projects assembled from firms who each already have a system they are contractually obliged to use for their own records — what follows is what is available instead.

The duty that exists, and what empties it

Before falling back on registers, it is worth knowing that something is owed here. At least one of the standard forms puts a duty on each contractor to cooperate with the other parties in providing and obtaining the information they need in connection with the works.

Which sounds like the answer to this week, and isn't, for a reason worth understanding rather than resenting. The duty takes its content from the scope document. It says the parties will cooperate over information; what information, to whom, when and in what form is whatever somebody wrote into the scope while the package was being drafted. Where that was done carefully the duty has teeth. Where the scope is silent — and it usually is, because the person drafting it was thinking about the works rather than about the paperwork — what exists is a duty to cooperate about nothing in particular.

There is a second condition and it is the sharper one. Where the employer is the party that has to provide something and doesn't, the contractor's route to recovery turns on the requirement having been shown on the accepted programme. An information obligation that lives only in the scope, and never reaches a programme, has no date attached to its failure and therefore nothing to measure a failure against.

Which puts the document deliverables where this track has put everything else. Not in a register that records what happened, but on the programme, as dated commitments between named parties — the same move week 12 made with handovers, applied to information rather than to work.

None of which helps on a job already let with a silent scope, which is the usual case and what the rest of this week is about.

The register that makes it survivable

Three things, none of which requires anybody to change their systems.

A cross-reference register: their number against your number, per document, per firm. It is tedious and it is the only way a conversation about a drawing can be certain both parties mean the same one. Without it, half of every technical query is spent establishing what is being discussed.

A status code mapping, agreed once between the schemes in use. Not a translation performed by whoever happens to receive the document, but a table that says what each firm's code means in yours.

And acknowledgement at the boundary. You can't verify what happens inside another firm, so verify the one thing you can: that the document arrived and that the recipient confirmed the supersession. That is the second of the three events from Week 13, and across organisations it is the only one you will ever get.

Where this leaves the track

Seventeen weeks have taken one assumption apart. Every method in the tracks before this one supposed a single contract, a single Engineer, a single programme and a single set of books, and none of them said so.

What replaces it is not a set of new techniques. It is knowing which of the old ones stops working, and why: a notice with no address, a critical path in a factory, a delay nobody caused, a figure two companies both produce correctly, and a drawing that six firms hold under six numbers.

The techniques are unchanged and they were always conditional. This track was about the conditions.

System design

Four records, and the third is the one that has to replace an ambition. Verifying what a document is doing inside another company is not available; verifying that they confirmed receiving it is.

Record	Produced by	Required quality	Verified against	Feeds
Cross-reference register	Project controls	Their number against yours, per document, per firm	Each firm’s register	Every technical query
Status code mapping	Document control, agreed once	What each firm’s code means in yours	The schemes in use	Whether a drawing may be built from
Boundary acknowledgement	The receiving firm	Confirmation of receipt and of supersession	Their reply, not your sending system	Distribution completeness
Revision in use	Spot check on site	What the crew is holding, per firm	Physical check	Progress validity · rework risk

The last row is a walk rather than a field, exactly as it was in the single-company case. Across six firms it is the only evidence that any of the first three rows are describing the site rather than describing themselves.

Practical insight

Take a drawing your own work depends on and trace it outwards. Ask each firm that holds it what number they have it under and what status they think it is at.

Three questions to three document controllers, and you will get at least one answer that surprises you — a number you have never seen, or a status that is one step ahead of what you issued.

Then do the part that lasts. Start your cross-reference register with that one drawing, and add to it every time a query costs you ten minutes establishing which document is being discussed. Within a month you will have covered everything that actually matters, and you will have built it out of problems rather than out of a plan.

Key takeaways

• A drawing crossing organisational boundaries is re-registered each time and ends up with several identities.
• Issue crosses a boundary because you have an address. Withdrawal doesn't, because their distribution list is theirs.
• A superseded revision is not withdrawn across a project. It decays at a rate set by how often each firm checks.
• Status codes differ between firms and are re-entered by hand at every boundary.
• A document can arrive approved because the receiving system has no code for what it actually was.
• A shared environment solves it and costs six businesses their own systems. That is negotiated at award or not at all.
• Without one: a cross-reference register, an agreed status mapping, and acknowledgement at the boundary.
• Acknowledgement is the only one of the three document control events you can verify across a boundary.
• A duty to cooperate over information exists in at least one standard form, and takes its content from the scope. A silent scope leaves a duty about nothing in particular.
• An information obligation that never reaches a programme has no date attached to its failure. Put the document deliverables on the programme.

Records born here. The cross-reference register of document numbers per firm · the status code mapping between schemes · boundary acknowledgements, issue and supersession.

What is coming next

Seven tracks have taught methods and the conditions under which they hold. What none of them has shown is the order the work arrives in.

A project is not a set of techniques applied in parallel. It starts before anybody is appointed, in an investment decision made by people the delivery team never meets. It passes through a tender, a mobilisation, an engineering phase that overlaps a procurement phase that overlaps construction, a commissioning sequence that inverts the priorities of everything before it, and a closure that determines whether any of the records were worth keeping.

What comes next is that sequence: what happens at each stage, what feeds what, and which record is born where.