Designing a document control workflow for a two-hundred-firm supply chain

On a job this size the document controller finds out first. Transmittals stacked in the queue, a trade on the phone wanting to know which revision of the slab is live, and a request from the client's project manager for a list of every firm that has ever received the M&E general arrangements. By lunchtime somebody will have described all of that as an access problem and asked for more logins.

It is not an access problem. A two-hundred-firm supply chain fails because the project treated access as a workflow. Access decides who can open a cupboard. A workflow decides who may issue, who must acknowledge, and who is allowed a copy that is not a second issued set. Those three permissions are a topology. Draw them first — the register, the transmittal and the plotter only start behaving once that drawing exists.

Why scale changes the shape

On a small job you can pretend the project is one room. The architect issues, the contractor acknowledges, the trades collect a plot, and when something is late you walk across the cabin and ask.

At two hundred firms that room does not exist. A large hospital, airport, metro, campus or gigaproject package will typically carry an appointing party and a project manager, a lead appointed party, a handful of lead designers, twenty or thirty appointed design practices, fifty to eighty trade contractors, and a long tail of sub-subs, fabricators, vendors and inspection bodies. Most of those firms never sit in the same meeting. Most of them should never see most of the containers. "Everyone has access" is how a work-in-progress services model becomes a construction drawing in a messaging crop, and how a superseded structural sheet stays live in a trailer that was never on the distribution matrix to begin with.

Scale does not multiply the same workflow two hundred times. It forces you to say, layer by layer, what that layer is allowed to do to an information container. Without that, what you are running is a helpdesk for passwords.

The approval topology for two hundred firms

Draw the job as layers rather than a flat list of companies. The count on the right is typical, not a target. Change the numbers; do not collapse the layers.

Appointing party / client / PMC          a few origins
        │
        │  authorises purpose; rarely issues trade geometry
        ▼
Lead appointed party / main contractor / EPC
        │  owns the issued set for the works
        │
        ├── Design appointed parties     ~20–30
        │     issue discipline packages they own
        │
        ├── Trade contractors            ~50–80
        │     acknowledge IFC; issue shop / fabrication drawings
        │     └── Sub-subs, fabricators, vendors   ~100+
        │           submit; acknowledge only their package
        │
        ├── Document control             named roles, not a firm count
        │     operates the gates; does not originate design
        │
        └── Site-set custodian           one named person or cabin
              holds a controlled copy of the current issued set

The topology is a claim about origin, not about software groups. An origin is the firm allowed to create or revise a class of container. A recipient is a firm allowed to receive a bounded issued set for a stated purpose. A gate is a named role that may change state — work in progress, shared, published, archive — or record that an issue happened. A common data environment that cannot tell those three apart turns your wall chart into decoration.

Write one sentence per layer before anybody opens the permissions screen.

Layer	Typical count	May issue	Must acknowledge	Holds a set?
Appointing party / PMC	a few	Programme-level instructions, employer’s information; not trade GAs	Lead appointed party’s published issues that the contract says they accept	No site set
Lead appointed party	one	The coordinated issued set for the works; cascading transmittals	Appointing-party issues; design issues they will build from	Optional controlled site set
Design appointed parties	tens	Only containers they own, into Shared then Published per the BEP	Coordinated issues that constrain their discipline	No unofficial hut set
Trade contractors	tens	Shop, fabrication and method documents in a defined workflow	Construction issues for the packages they install	Controlled shop or cabin set only if named
Sub-subs / vendors	the long tail	Vendor documents and product data against a PO or VDR	Only the package they fabricate or install	Never a second IFC set
Document control	roles	Nothing that originates geometry	They record issue and acknowledgement; they are not the recipient	The register, not a hut wall
Site-set custodian	one	Nothing. They plot and withdraw	They confirm the plot matches the current issued set	Yes — a copy, never an authority

A firm that does not appear in that table is not in the workflow. A login is not a row.

Two rules keep the drawing honest. First, no skip-level issue for construction: the appointing party does not issue a steel detail to a fixer, and the architect does not issue a GA to a sub-sub who is not on the transmittal. Cascading is work, and it is also the only way a job this size can later show who was in the chain. Second, one issued set per purpose. "For information", "for review" and "for construction" are three different acts, and a firm allowed the first is not thereby allowed the third.

Who may issue

Issue is a named act by a named origin, of a named revision, for a named purpose, to a named list of recipients. Uploading is not issuing. Saving is not issuing. Nor is a folder called Published.

Only the origin that owns a container may raise a revision of it. The structural engineer revises the slab drawing; the main contractor does not help by saving a marked-up PDF as the next letter. When a lead appointed party issues a coordinated construction set, that is their issue of collected, authorised containers — not a licence to rewrite another firm's title block.

Only a defined role may move a container to published, or to whatever the project calls issued for construction. Suitability is part of that act: a container whose status still says coordination has not been issued for the pour, however many people happen to have the file. Document control operates the gate. Pressing the button does not turn the controller into the designer, and that is worth saying out loud on a job where the designers sit in three time zones and the deadline is tomorrow.

Shop drawings and vendor documents have their own issuers. The trade or the fabricator issues into a review workflow, the designer comments, and the lead appointed party — or whichever role the BEP names — releases for fabrication or for construction. That release is a different issue from the architect's GA. Mix the two and a shop drawing becomes "the drawing" in a dispute.

Who may not issue:

Anyone whose appointment does not name that container type.
Anyone issuing another origin's work by renaming, combining or screenshotting it.
Anyone treating a messaging crop, a plotter queue or a personal laptop as a release.
Site. Site builds. Site does not mint revisions.

If you cannot say, for a late slab revision, which origin was allowed to publish it and which role was allowed to transmit it, stop designing folders. There is no workflow there yet.

Who acknowledges

Acknowledgement is the recorded fact that a named recipient firm, in a named role, received a named issued set. It is not the delivery of an email, not the existence of a login somewhere in the company, not understanding, and not proof that the setter-out has the sheet in his hand. Those are later facts, and collapsing them together is how an argument gets lost eighteen months on.

At two hundred firms you cannot ask every person to acknowledge every sheet. You acknowledge by appointment and by package. The distribution matrix is the topology made operational: package, purpose, recipient origin, named role, acknowledgement duty, and what silence means.

Who must acknowledge, on a job this size:

The lead appointed party acknowledges the appointing party's published instructions where the contract makes acceptance an act.
Each design appointed party acknowledges coordinated issues that constrain their discipline.
Each trade contractor acknowledges the construction issue for the packages they install — the company, through a named role, and not a group chat.
A sub-sub or vendor acknowledges only the package they fabricate or install. They do not sit on the GA transmittal for a whole floor.
The site-set custodian acknowledges that the plot run matches the current issued set, and that the previous run was withdrawn or marked superseded.

Who does not acknowledge: the plotter, a shared inbox, a security group, "the site", and somebody who was forwarded a zip. If the matrix names a company and the click arrives from a personal mailbox, what you are holding is a receipt you would rather not produce in a meeting.

Set the clock in the workflow rather than in folklore. Forty-eight hours is a common window, though the number matters less than whether silence counts as deemed received or not received. Deemed received is a commercial convenience and a poor account of what happened at the workface. Use it if your protocol says so, and still insist on a named acknowledger for every for-construction issue going to a trade about to place work.

Cascade acknowledgements follow the topology. A main contractor's acknowledgement of a design issue does not stand in for the trade's, and the trade's does not stand in for a fabricator who is a separate firm and will cut steel from a shop drawing. Skip a layer and you have a legal fiction at the layer you skipped.

A package manager will tell you the transmittal log names two hundred companies and shows green ticks all the way down. It does, and it is a log of clicks. The duty is the thing being designed here: which layer must click, on which purpose, before the next layer is allowed to treat the set as live.

Who is allowed unofficial sets

Default: nobody.

The unofficial set in the trailer exists because the official one cannot be trusted at the point of work. A workflow that pretends that set does not exist will lose to it; a workflow that blesses every hut folder as "the site CDE" loses the issued-set argument instead. The job is to name the copies that are allowed, and to treat every other copy as uncontrolled.

Allowed, if you write the rule and name the custodian:

A controlled site plot set. One cabin, one person, plots of the current issued set only. Number and revision readable on the stamp. Previous sheets collected or marked SUPERSEDED when the next revision is issued. This is a copy with no authority of its own, so if it disagrees with the register, the register wins and the plot comes off the wall.
A controlled shop set. The fabricator holds the current approved shop or fabrication issue for the pieces they are cutting — not the architectural GA, not last month's coordination model, not a crop from a coordinator.
A temporary-works set. The TW designer issues their own containers, and that set is official for TW. As a substitute for the permanent-works issue it is neither official nor permitted.

Never allowed:

A personal laptop “latest” that is not the published container.
A messaging crop used as an issued instruction.
A trailer folder that is not reconciled to the register on a named cadence.
A consultant WIP model on a USB “so the steel fixer can see the holes”.
A second for-construction set held by a sub-sub who is not on the transmittal.

If a firm is not in the "Holds a set?" column, they look; they do not keep. Looking is access. Keeping is a competing issued set.

The test is withdrawal, and it is the one most projects skip. Issue without withdrawal is how two revisions stay live at once. A topology that names two hundred recipients and nobody to collect yesterday's plot has designed distribution and forgotten control.

A Monday method

You can draw this without a software project. Take last week's for-construction issue and one late revision, and give yourself an afternoon.

List the layers. Appointing party, lead appointed party, design appointed parties, trades, long tail, document control, site-set custodian. Count the firms. If you cannot count them, you cannot route them.
Name issuers. For that revision, which origin was allowed to publish it? Which role was allowed to transmit it? If two firms both "issued" it, the topology is already broken.
Fill the matrix. Package × purpose × recipient origin × named role × acknowledgement duty × silence rule. A matrix that says "all subcontractors" is not a matrix.
Walk the cascade. Who had to acknowledge before the next layer could treat the set as live? Who was skipped? A skip is a hole, not a shortcut.
Name the allowed copies. Is there a site set? A shop set? Who is the custodian? When was the last reconciliation to the register? Where are the superseded plots?
Forbid the rest. Write the sentence: no unofficial sets except the named copies. Then go and look in the trailer. Anything you find that is not named is the real workflow.
Rebuild one late sheet. From publish to plot, list who may issue, who must acknowledge, who may hold paper. If any step comes out as "they have access", redraw it.

Seven answers you can hand to a project manager are a workflow. A slide that says "CDE for the supply chain" is not.

Where the duties actually live

The project's information protocol, exchange information requirements and appointment documents own the legal duties. NEC, FIDIC, JCT, CDM, the Building Safety Act, ISO 19650, COBie and the Gulf mandates each have owners, and every one of them assumes somebody can name the container, the recipient, and the state that container was in at the time. None of them assumes two hundred logins.

A topology in a method note is not a certification, and a distribution matrix nobody updates has stopped being a topology. The lead appointed party's BIM manager can draw the whole thing on a whiteboard in an afternoon, which is the easy part. The harder part arrives a month later, when a fabricator wants a set they are not entitled to and somebody has to be willing to say no.