Need to use, stage by stage

Follow the Process

From the client's first need to the drain they're still maintaining five years later. Pick a stage, or follow all 55 stops: watch what gets made, where it goes, and how its label changes along the way.

The process, stop by stop

Who are you?

View by

Pick a stage

Who's on the job Stage 0 · Why we need it

Joins
Leaves
How it travels

Towns keep their places. They join when they're appointed, and leave when their part is done; what they made stays on the record.

Who's on the job, stage by stage

Town	0 Why we need it	1 What we need	2 First ideas	3 Pinning it down	4 Design it	5 Make and build it	6 Hand it over	7 Use it
Client Town	operations, project lead	asset team, project lead	project lead	project lead	reviewers	Clerk of Works	asset team, operators	operators, maintenance
Consultant Town			surveyors, advisers	advisers
Main Contractor Town					bid, information manager	site engineer, supervisor	handover team
Designer Town					design team	queries	record drawings
Supplier Town						makers	manuals	a replacement part
The Outskirts	users, neighbours					deliveries, permits		users

A parcel changes state: that's the workflow, between systems or inside one Someone comes to check, comment, authorise, accept or use it Everyone who needs to know is told, with a link Every town checks its own work before it travels: make, check, review, approve. On site it's lighter: make, check, approve, and a photo just needs the right label

What's moving, and its label

Item
Number
Revision
Status
Can you build from it?
Reason for issue
Where
Who's acting
Recorded in the Site Office

The registerEvery item on the job so far, as the CDE sees it at this stop

Item	Number	Rev	Status	Where

Heads Up

One need, lots of parcels, two ways to read it

One need from the client spawns a whole family: the requirements, the plan, the drawing, the issue, the TQ, the shop drawing, the inspection, the survey and the handover pack. Each is its own parcel with its own number, and each leaves its own trail. A real job runs thousands of these at once.

By work stage is how the job feels: the main contractor joins at Stage 4. By ISO 19650 process is what the information management is doing, and it shows something the stages hide: "make it together" and "deliver it" come round every time the drawing changes. Same gates, every time.

The lines are the workflow. A parcel travelling along one is changing state: from work in progress to shared to published. Your towns might be separate systems or rooms in one system; the moves are the same, and the CDE records every one. Every town runs its own checkpoints before anything leaves, and approval (A) is its ticket out. The checks fit the parcel: four for a drawing, three for a site form, and the right label for a photo.

Watch who moves. Parcels only travel when they change state. Everyone else comes to the Site Office to comment, authorise or accept, the Site Office records who did what, and then they go home and get on with it. When something changes, it changes where it sits and people are told. Nobody gets sent a copy.

This is how this job does it. Yours might keep work in progress in the CDE, run its CDE across several systems, or use the client's own. That's all fine: see "Your project may do it differently" below.

The codes are the UK ones from the National Annex to ISO 19650. A5 is authorised and accepted for Stage 5, and A6 for Stage 6; the reason for issue says why. Your client may use its own stage gates, and your project's information standard may use different codes, so check it.

Want the whole trail as a table, the rules, and every code? Turn on Show the detail at the top of the map.

The whole trail

Every stop, on one page

The same 55 stops as a table: the trail your CDE should be able to show for this one need. This is what "can you prove it?" looks like. Pick a row to see it on the map.

Stop	Step	ISO 19650	Item	Rev	Status (reason for issue)	Where	Spins off or links to

Codes on this page: ABC is the design firm, LDF the lead firm, PRE the precast supplier and XYZ the client. IDs like ISS-031 and TQ-024 are illustrative.

The rules Eight rules of the trail

Drawing 042 has one revision history and many linked records. Everything else (issues, mark-ups, TQs, surveys, inspections, shop drawings, packs) is its own parcel, pointing back at the exact revision it relates to.

The revision changes when the content changes. The status changes when the purpose changes. S4 to S5 on the same content is a change to the label in the CDE, not a re-issue.
The status lives in the CDE. The sheet carries the revision and a PRELIMINARY or CONTRACTUAL stamp, matching the P or C. Where a client's title block insists on showing S codes, a status change becomes a content change: re-issue it with the description "Status change only, no technical change".
A published code says which work stage it's accepted for (A5 is Stage 5, A6 is Stage 6), not why. So every published issue also carries a reason for issue from the project's information standard: For construction, For manufacture, Quality record, As-built survey, As-constructed record, Handover. (We say "as-built" in plain words; the reason for issue on the record drawing is As-constructed record.)
Every town checks its own work before it leaves, and the check fits the parcel. A drawing is made, checked, reviewed and approved. A site form is filled in, checked and approved (signed by the supervisor, witnessed where the inspection plan says). A photo needs the right label as it's taken. InfoTown calls these make, check, review, approve; ISO 19650 calls them a quality assurance check, a review, and approval for sharing. Check, review and approve (the team's checkpoints) happen in work in progress, before anything moves to Shared, whoever made it. Authorise and accept (two more checkpoints: the lead firm authorises, then the client accepts) happen in the CDE, before anything moves to Published: the people come to the parcel, the parcel doesn't go to them, and the decision is recorded against the revision.
Only the originator revises its own parcel, in its own room. A mark-up, issue or TQ never changes Drawing 042. It gives the designer a reason to.
Once a drawing is contractual, rework goes back into work in progress as the next P revision: C01, then P04.01 and P04, then C02. Write this into the project's information standard.
Feedback records carry a workflow state (Open, Responded, Closed), not a design status. If the project holds a mark-up as its own container, S2 is a sensible convention, never A.
Every stop must answer "can you prove it?": who, when, which revision, and which record caused it.

Feedback What goes back: red-lines and everything like them

"The red-line goes back" covers at least seven different things. They all point at an exact revision, none of them revise it, and each one ends somewhere different.

Feedback	When	Why it happens	Own ID?	Goes to	Ends as	Stop
Coordination issue	Design, S1	Federated models clash or don't fit	Yes, issue register	The originator	Next P revision	Clash
Review comment	Design, S3 to S5	A reviewer disagrees, queries or spots a gap	Comment, against the revision	The originator	Next P revision; comment closed with a response	Share for comment
TQ or RFI with a red-line	Before building	Site can't build as drawn	Yes; mark-up attached	Designer, via the lead firm	Answer and instruction, then the next C revision	Ask
Non-conformance (NCR)	After building	Built wrong or out of tolerance	Yes	Lead firm, designer if needed	Accept, repair or replace; record updated if accepted as built	–
As-built mark-up	As built	Small differences within tolerance; no question asked	Yes, or held in the work pack	Originator of the record drawing	Feeds the A6 record revision	Record mark-up
Survey	Before, during and after	Existing conditions, setting out, as-built check	Yes, with its own revisions	Designers and the record	Reference, setting-out data or as-built survey (A5)	Measure
Inspection and test record	At hold and witness points	Proving the work meets the published information	Yes	Quality record and handover pack	Quality record (A5), handed over	Inspect

Three tests decide the route. Is it a question? Then it's a TQ or RFI, and someone with authority answers it before work goes ahead. Is it a defect? Then it's an NCR, and the decision on it says whether the record changes. Is it simply what happened? Then it's an as-built mark-up, survey or inspection, and it feeds the record. For models the same rule applies, with structured issues in place of red pen.

Supplier Town Shop drawings: who sees them

A shop drawing is a separate parcel owned by whoever makes the thing, based on a published design revision. It's never the designer's next revision. Who reviews it depends on who carries the design responsibility, and the contract and responsibility matrix should say so before the first one arrives.

Who	What they check	Do they always see it?
Manufacturer (the originator)	Buildability, tolerances, its own checks: the team's checkpoints	Yes, they produce it
Designer of record	It matches the design intent of the revision it's based on, with no new design assumptions	Yes, where the item carries design intent: S3 for comment
Lead firm	Interfaces, logistics, programme, fit with everything else	Yes: it authorises at S4 and releases it as A5, For manufacture
Client	Only where the contract says so: contractor-designed elements, specified assets, safety-critical items	Not by default

InfoTown's convention: here the lead firm authorises SD-118 at S4 and releases it as A5 because, by default, it's the accepting party for its own subcontract appointment. Where the client has listed shop drawings as deliverables it wants to review, they go on to S5 for the client to accept, like any other deliverable.

The trail must show which design revision each shop drawing relied on. When 042 moved from C01 to C02, someone had to check SD-118 was still valid. Linking them in the CDE makes that check happen on purpose, not by luck. A firm that designs and makes (a precast firm doing contractor-designed work, say) still sits in Supplier Town, but its design submissions follow the design line's rules.

The site Site packs

A site pack is a list of links to exact published revisions, held in the CDE, not a folder of copies. It answers "what was the site supervisor working from that day?".

Only published items go in: drawings at A5 For construction, shop drawings at A5 For manufacture, the inspection plan, RAMS, permits, and any instructions or TQ answers that apply.
Never in a pack: anything at an S status, red-lines, or superseded revisions.
When a linked item is superseded (042 C01 to C02), the pack is updated, the change is recorded against it and the site team is told. Printed copies say "uncontrolled when printed, check the CDE".
The pack has its own number and revision, so the trail can prove which version was on the tablet when the trench was dug.
At the end, the pack's inspections and as-built records feed the record drawing and the handover pack. Packs organise construction; they aren't the handover.

Project choices Your project may do it differently

The map shows one good way. The workflow is the idea that matters; the systems and the details are your project's choice, written into its information standard and BEP.

Choice	On this page	Also fine
Where work in progress lives	In each team's own system, in its own town. The Site Office only knows what's been shared.	Work-in-progress areas inside the CDE, one per team, so the CDE sees every version. The project decides.
What the CDE is	One Site Office: several cabins (documents, models, maps, the site app, data) inside one fence, running one workflow	Several systems: documents in a document system, models on a model server or in CAD, maps in GIS, a field app on site. It's still one CDE if it runs one workflow: the same states, labels and decisions, all recorded.
Whose CDE	A new Site Office, built by the lead firm because the client asked for one	The client's own CDE. Then getting ready means getting your team access and testing your workflows in someone else's building.
Where the client accepts	The client's reviewer comes to the Site Office	The client accepts in its own system. Then the parcel does travel up the client line, as a formal transfer, and the decision comes back to be recorded.
How people are told	One copy; the status changes where it sits; a notification with a link goes to everyone on the distribution	Connected systems pick up the new status through their own approved integrations, not side routes. If a system really needs its own copy (the client's document system, an offline tablet), it's a controlled transfer with the same number, revision and status, superseded when the original is. Never re-shared as a new parcel.
Stage names	InfoTown's names for Stages 0 to 7	Your client's own stage gates
How the job is bought	Design and build: the client's consultants take it to the end of Stage 3, then the lead firm joins and brings its own designers	Build only: the client's designers carry on through Stage 4, and the lead firm joins to build. Stages 0 to 3 look the same either way; only who joins next changes.
Who designs after the tender	A new designer, appointed by the lead firm	Novation: the client's designer moves across to work for the lead firm. Their work and its record come with them and nothing is redrawn, but who checks and accepts their work changes. Say so in the responsibility matrix before the first drawing moves.

Work stages Stage names, and the ones your job might use

Most UK schemes number the stages 0 to 7 and agree on the numbers, but not the names. InfoTown uses its own plain names. The number is what matters: it's the n in an A code.

#	InfoTown	RIBA Plan of Work 2020	A typical stage set
0	Why we need it	Strategic Definition	Strategy
1	What we need	Preparation and Briefing	Brief
2	First ideas	Concept Design	Concept
3	Pinning it down	Spatial Coordination	Definition
4	Design it	Technical Design	Design
5	Make and build it	Manufacturing and Construction	Build and Commission
6	Hand it over	Handover	Handover and Closeout
7	Use it	Use	Operation and End of Life

ISO 19650 works with whatever stages your project uses: RIBA on buildings, the client's own gates on infrastructure. Your project's information standard should say which stages the A codes follow.

UK National Annex The codes used on this page

Status codes

Code	State	What that means to you	Build from it?
`S0`	Work in progress	Someone is still working on it in their own team's area. You shouldn't normally see it, and you shouldn't rely on it.	No
`S1`	Shared	Shared so other teams can check their work fits around it. Expect it to change.	No
`S3`	Shared	Shared so people can comment on it. If you've been asked to review it, now's the time to speak up.	No
`S4`	Shared	Shared for the lead firm to review and authorise.	Not yet
`S5`	Shared	Shared for the client to review and accept.	Not yet
`A1, A2… An`	Published	Authorised and accepted, with no comments outstanding. The number is the work stage: on this site A5 is construction and A6 is handover and the as-built record.	Yes, for that stage, if it's the latest

An S code says what something may be used for. An A code only says it's been authorised and accepted, and the n is the work stage. The Annex ties n to the work stages in BS 8536-1 (buildings) and BS 8536-2 (infrastructure), since brought together in BS 8536:2022, unless your project's information standard sets out another approach. On this site, construction is stage 5 and handover is stage 6, so a construction issue is A5 and the as-built record is A6. Why each A code was issued isn't in the code at all: your project's information standard has to say.

Revision codes

Code	When	What that means to you
`P01.01`, `P01.02`…	Work in progress	Still being worked on. The second number is the version within that revision, so the team can keep track of its working versions before the next shared revision. Nobody outside the team should be using it.
`P01`, `P02`…	Shared	A shared draft. The number goes up every time it's shared again, so check you've got the highest one.
`C01`, `C02`…	Published	The published version, authorised and accepted. Higher is newer. Build from the latest C, with an A status.

Every status and revision code, and the naming rules, are in one place: Lesson 7, The labels.

Based on the UK National Annex to BS EN ISO 19650-2. Your project's information standard can add to it. ISO 19650 and its UK National Annex are © ISO and BSI. InfoTown explains the ideas in its own words, for learning; you'll hear the same language across the industry. Read more for free in the Information Management Initiative (IMI) Framework guidance from BSI and nima. For the full requirements, use the standard itself.