ISO 19650 Status Codes Explained (S0–S7, A & B) — Plain English
Short answer: ISO 19650 status codes (also called suitability codes) describe what an information container — a drawing, model, or document — is fit to be used for at a given moment in a common data environment. The S codes cover work in progress and shared, non-contractual information: S0 is the initial work-in-progress status, S1 suitable for coordination, S2 suitable for information, S3 suitable for review and comment, S4 suitable for stage approval, with S6 and S7 for authorisation. The A codes mark published, authorised information; B codes mark published information issued with comments. Archi Check helps teams apply this rigour by gating an issue closed only once it is verified, with a full audit trail.
If you work to the ISO 19650 suite, you have seen these codes in the corner of a title block or in a column of a document register: S2, S4, A1. They look like minor metadata, but they carry the entire logic of the standard. Each one answers a precise question — what is this information good for right now, and who is allowed to rely on it? Get the code wrong and someone may coordinate against a sketch, or build from a drawing that was only ever shared for comment.
The trouble is that the codes are easy to misread, partly because they are short and partly because the underlying standard layers two separate ideas: where the information sits in the common data environment, and what it is suitable for. This guide separates those two ideas, sets out every code in plain English, and gives you a reference table you can keep beside your register.
What ISO 19650 status codes actually describe
ISO 19650 is the international standard for managing information across the life cycle of a built asset using building information modelling. At its centre is the common data environment, or CDE — a single agreed source of information for a project or asset, with rules about how information moves through it. Every piece of information lives in an information container, and every container carries metadata, including a status, or suitability, code.
The status code is not a quality rating and it is not an approval stamp in the contractual sense. It is a statement of fitness for purpose. It tells anyone who opens the container what they are allowed to do with the information inside it at this point in time. A container marked suitable for information may be read and referenced; one marked suitable for coordination may be used to check geometry against other disciplines; one that is merely work in progress should not have left its author's hands at all.
This matters because the same drawing carries different codes at different moments. A floor plan might be S0 while its author is still drafting it, S2 when it is shared for the wider team to reference, S4 when it goes up for stage approval, and finally an A code once it is published as authorised information. The geometry may not change between two of those issues, but the permission attached to it does.
The four CDE states: WIP, Shared, Published, Archive
Before the codes make sense, you need the containers they live in. ISO 19650 describes information moving through four logical states in the common data environment. These are states, not folders — a container moves from one to the next through a controlled transition, and the status code travels with it.
Work in progress
Information being developed by a single task team, not yet visible to anyone else. This is the drafting state. Nothing here has been checked, reviewed, or approved for sharing, which is exactly why it is walled off. The only suitability code that belongs here is S0.
Shared
Information that has passed a basic check and is released to other task teams for coordination, reference, or review — but is not yet contractual. Most day-to-day collaboration happens in the shared state. The S1 to S4 codes (and S6, S7 where used) live here. Shared information is non-contractual: it can be relied on for the stated purpose, but it does not carry the weight of an authorised, published issue.
Published
Information that has been authorised and accepted for a specific use, typically by the appointing party or lead appointed party. This is the contractual state. The A and B codes live here. When a set is published, it becomes the formal record that the wider project, including parties outside the design team, can act on.
Archive
A journal of every previous version, retained so the project has a complete, retrievable history. Nothing is deleted; superseded containers move to archive so you can always reconstruct what was issued, when, and under which code. The audit value of the CDE depends on this state being maintained.
The S codes: work in progress and shared
The S codes — S for suitability — cover the work-in-progress and shared states. They run from raw drafting through to the point of authorisation. Read in order, they describe a maturing piece of information becoming progressively more trustworthy.
- S0 — work in progress. The initial status given to information while it is still being compiled. S0 generally should not be provided outside the authoring task team. If you see S0 on something that reached your inbox, something has gone wrong with the process.
- S1 — suitable for coordination. Shared so other disciplines can coordinate their work against it — checking spatial fit, clashes, and interfaces. It is reliable enough to coordinate against, but it is not yet for approval.
- S2 — suitable for information. Shared for reference and information only. Other teams may read it and take it into account, but should not coordinate critical geometry against it as if it were settled. S2 is the most common shared code in practice.
- S3 — suitable for review and comment. Issued so reviewers can formally comment. This is the first step toward sign-off, often used within a task team or between teams to gather and resolve comments before approval.
- S4 — suitable for stage approval. Issued to the authorising individuals for formal sign-off at the end of a work stage, prior to client or appointing-party approval.
- S5 — withdrawn or otherwise reserved. Usage of S5 varies between editions and guidance; in much current UK guidance it is treated as not in routine use, and you should check your project's information standard before applying it.
- S6 — suitable for PIM authorisation. Issued for authorisation of the project information model. Used at the point where project information is being signed off for authorisation.
- S7 — suitable for AIM authorisation. Issued for authorisation of the asset information model — the information handed over to operate and maintain the finished asset.
The mental model is a ladder of trust. Lower numbers are earlier and looser; higher numbers are closer to formal sign-off. None of the S codes is contractual — they all sit in work in progress or shared. The jump to contractual status happens when information is published and takes an A or B code.
The A and B codes: published and contractual
Once information is authorised and moves to the published state, it stops carrying an S code and takes an A or B code. This is the most important distinction in the whole scheme, and the one most often misunderstood.
A codes — authorised and accepted
An A code, usually written with a sequential number tied to the work stage (A1, A2, and so on), marks published information that has been authorised and accepted for use at that stage by all relevant parties. This is the clean, contractual issue: the wider project can act on it. The number after the A relates to the approved stage or revision, not a quality grade.
B codes — published with comments
A B code (B1, B2, and so on) marks information that has been published but carries comments — a partial sign-off rather than a full, unqualified acceptance. The information is issued and can be used, but it is accepted subject to the noted comments being resolved. Think of B as the coded equivalent of "approved with comments": usable, but with an open obligation attached. Because the obligation is easy to lose, B codes are exactly the case where disciplined verification matters most. Some project information standards restrict or discourage routine use of B codes for this reason, so confirm your project's conventions.
There is also a record code sometimes seen at handover — historically CR, "as constructed record document" — though guidance on this has shifted between editions and several recent versions advise against using it. If your asset information requirements call for a record code at handover, take the exact convention from your project's information standard rather than assuming.
ISO 19650 status code reference table
Keep this beside your document register. It maps each code to its CDE state, its plain-English meaning, and what a recipient may reasonably do with the container.
| Code | CDE state | Meaning | What you may do with it |
|---|---|---|---|
| S0 | Work in progress | Initial work-in-progress status during compilation | Author's use only; should not be shared |
| S1 | Shared | Suitable for coordination | Coordinate your work against it; not for approval |
| S2 | Shared | Suitable for information | Read and reference; do not treat as settled geometry |
| S3 | Shared | Suitable for review and comment | Review and return formal comments |
| S4 | Shared | Suitable for stage approval | Submit for sign-off at end of stage |
| S5 | Shared | Reserved / varies by guidance — check your standard | Confirm project convention before use |
| S6 | Shared | Suitable for PIM authorisation | Authorise the project information model |
| S7 | Shared | Suitable for AIM authorisation | Authorise the asset information model |
| A1, A2, An | Published | Authorised and accepted (contractual) | Act on it as the formal issue for that stage |
| B1, B2, Bn | Published | Published with comments / partial sign-off | Use, but resolve the noted comments |
The codes describe suitability, not raw quality. A container can be perfectly drawn and still be S2, because S2 is about what it is fit for, not how good it is. When your office also uses plain-language approval marks, the two should agree with each other. For how the coded system lines up with the stamps people place by hand, see drawing approval stamps explained.
How a drawing moves through the codes
The codes only make sense in motion. Here is a single architectural drawing tracking through a typical work stage, showing how its status changes while the work matures.
- Drafting. The architect starts the floor plan. It sits in work in progress as S0, visible only to the authoring team.
- Internal check. A checker reviews it within the task team. Comments are raised and resolved before it is allowed to leave work in progress.
- Shared for coordination. The plan is released to structures and services as S1 so they can coordinate their layouts against it.
- Shared for information. A later version goes out as S2 for the wider team to reference while disciplines develop in parallel.
- Review and approval. Toward the end of the stage it is issued S3 for formal comment, then S4 for stage approval once comments are closed.
- Published. On authorisation it is published as A1 — the contractual issue the project acts on. If it had to go out with outstanding comments, it would carry a B code instead.
- Superseded. When the next revision publishes, the A1 version moves to archive, retained so the issue history stays complete.
Notice that the only thing forcing discipline at each step is the requirement to actually close the comments before the code advances. A drawing should not move from S3 to S4 while review comments are still open; it should not publish as A1 if it really belongs at B1. The codes are honest only if the verification behind each transition is honest.
Where the codes go wrong in practice
The standard is clear; the day-to-day application is where errors creep in. A few patterns recur across projects.
The first is sharing too early — information leaving work in progress before it is checked, so an S0 container effectively circulates under an S2 label. The second is the silent B code: information published with comments where the comments are never tracked to closure, so a partial sign-off quietly behaves like a full one. The third is code drift between disciplines, where one team's S2 is treated as another's coordination basis because nobody confirmed the suitability. In every case the failure is not the code itself but the missing follow-through — a transition that happened without the verification it implied.
This is the same failure mode that haunts hand-applied review stamps and red-lined markups: a decision is recorded, the information moves on, and whether the implied action actually happened is left to trust. The discipline that fixes it is the same in both worlds — nothing advances until someone other than the author has verified it, and the verification is recorded. For the manual side of that, see drawing markup symbols explained and the wider picture in what is drawing QA/QC.
Where Archi Check fits
Archi Check is standalone QC software for architectural drawing sets, and it is not an ISO 19650 CDE — it does not assign suitability codes or manage your published containers. What it does is enforce the rigour those codes assume but cannot guarantee on their own: that an item is not treated as resolved until it has actually been verified.
Every markup in Archi Check becomes a tracked comment with an owner, a date, and a status that moves through Check, Correct, Verify, and Close. An issue cannot be closed by the person who raised it on a hope that it was fixed; it is closed only once the correction is verified, and the whole sequence is written to an audit trail. That verify-and-close gating mirrors exactly what a status code is supposed to mean — a B code with unresolved comments stays visibly open, an S3 review is not "done" until its comments are closed. The codes describe the obligation; a verified, audited close is how you prove the obligation was met.
Because Archi Check keeps its data folder-first in your own project storage rather than a vendor cloud, that audit trail sits alongside the rest of your project record and belongs to you — useful when an information container's history has to be reconstructed. It runs on Windows today, with macOS coming soon, and there is a 14-day free trial.
FAQ
What do ISO 19650 status codes mean?
ISO 19650 status codes, also called suitability codes, state what an information container is fit to be used for at a given moment in the common data environment. The S codes cover work-in-progress and shared, non-contractual information — for example S0 work in progress, S1 suitable for coordination, S2 suitable for information, S3 suitable for review and comment, S4 suitable for stage approval. The A and B codes apply to published, contractual information.
What is the difference between S1 and S2?
S1 means suitable for coordination — other disciplines may use the container to coordinate their work against it, such as checking spatial fit and interfaces. S2 means suitable for information — the container is shared for reference only, to be read and taken into account but not relied on as settled geometry for coordination. S1 grants a stronger working use than S2.
What do the A and B codes mean in ISO 19650?
A codes (A1, A2, and so on) mark published information that has been authorised and accepted for use at that work stage by all relevant parties — the clean contractual issue. B codes (B1, B2, and so on) mark published information issued with comments, a partial sign-off that can be used but carries an obligation to resolve the noted comments. The number relates to the stage or revision, not a quality grade.
Are S codes contractual?
No. The S codes sit in the work-in-progress and shared states and are non-contractual. They can be relied on for the stated purpose — coordination, information, review, or approval — but they do not carry the weight of an authorised, published issue. Information becomes contractual only when it is published and takes an A or B code.
What is the difference between status codes and revision codes?
A status or suitability code describes what the information is fit to be used for — its permission. A revision code identifies which version of the container you are looking at. The two are independent: the same revision can be reissued under a different status as it matures, and a single status such as S2 can apply across several successive revisions. Both should appear in the container metadata and the document register.
Apply the rigour the codes assume
Status codes only protect a project when the verification behind each transition is real and recorded. If your reviews still close on trust rather than evidence, see how Archi Check gates every issue to a verified close with a complete audit trail: Try Archi Check free for 14 days.
Related guides
Keep building out your drawing QC process with Archi Check and these related guides:
- Drawing approval stamps explained
- As-built vs record vs red-line drawings
- Drawing markup symbols explained
- What is drawing QA/QC?
Archi Check is an independent product by Archi for architectural drawing QA/QC. ISO and ISO 19650 are referenced for identification only; product names and trademarks belong to their respective owners, and Archi Check is not affiliated with or endorsed by them. This article is a plain-English explainer, not a substitute for the published standard or your project's information standard.
