ISO 19650 Status Codes Explained: S0–S5, A and B Codes

Review markup on a civil drawing — the raw material a comment resolution sheet turns into a closed, auditable record. Photo: ThisIsEngineering via Pexels.

Ask two people on the same project what S4 means and you can get two different answers — both of which were correct at some point. That is not carelessness. The UK National Annex to BS EN ISO 19650-2 was revised in 2021 and the code list changed: two shared codes disappeared, one appeared, and a published code was retired. Plenty of teams, templates, and CDE configurations still run the older set.

Here is the current list, the older list you will still meet on live projects, and how both connect to the review comments you have to close before anything gets signed off.

One point of order first: the codes themselves are not in the body text of ISO 19650. The standard requires that information containers carry a status; the UK National Annex supplies the actual S/A/B lettering. Projects outside the UK often adopt it anyway, but it is a national convention, not an international mandate — which is why your contract, not this article, is the final authority.

Codes Only Mean Something Inside a CDE State

A status code is shorthand for one question: what is the recipient allowed to do with this file? That question only makes sense against the common data environment state the container sits in.

The line that matters is between Shared and Published. Everything shared is explicitly non-contractual — issued so others can get on with work, not so anyone can rely on it. Published information is contractual. Confusing the two is how a coordination model ends up quoted in a claim.

The Current Set: 2021 National Annex

S1 versus S2 is the distinction people get wrong most often, and it has real consequences. S1 invites you to build on the information; S2 explicitly does not. If you coordinate your ductwork against a structural model issued S2 and the structure moves, that was your risk to carry. Getting this pair backwards — including in published guidance, where it happens more than you would hope — quietly transfers risk between disciplines.

S3, S4 and S5 form an escalating sign-off chain: comment on it, authorize it, accept it. Each step has a different owner, which is the point.

Codes You Will Still See on Older Projects

If your project started before the 2021 revision, or your CDE was configured from an older template, expect this set instead:

S6 and S7 went because nobody could reliably say which applied when — the project information model and asset information model authorization steps overlapped in practice. CR went because it duplicated what an A code already does.

The practical translation, if you are migrating a register or reading an old issue sheet:

• Old S6 → new S4 (lead appointed party authorization)
• Old S7 → new S5 (appointing party acceptance)
• Old CR → an A code whose meaning your information standard defines as the as-constructed record

Do not retro-code containers that were already issued. The suitability recorded against an issue is a historical fact about what the recipient was permitted to do that day, and rewriting it destroys exactly the traceability the standard exists to create. Map old to new going forward, and leave the record alone.

Published Codes: A and B

A codes — A1, A2, through An — mean authorised and accepted. Contractual.

The number carries no inherent meaning. This surprises people. A4 does not universally mean "suitable for construction"; it means whatever your project's information standard says it means. If that document does not define each A code in writing, your published codes convey nothing beyond "somebody signed this off", and you should fix that before the first published issue rather than after.

B codes — B1 through Bn — mean partial authorisation: accepted with comments attached. They exist in the annex and current guidance widely recommends against using them, for a reason worth sitting with. A B code says this is contractual and there are outstanding comments on it. That is a contradiction with a number after it. Either the comments are minor enough that the container is genuinely accepted, or they are not and it should not have left the Shared state.

If your project does use B codes, treat every one as an open item with an owner and a deadline. B-coded containers accumulate quietly and turn up during commissioning as a list of things everyone assumed somebody else had closed. This is the same failure mode as code inflation in document review codes, where a B ("approved with comments") gets handed out to keep work moving and the comments are never incorporated.

Revision Codes Are Not Status Codes

These are two independent axes and mixing them is a common source of confusion:

• Suitability answers what may you do with this? — S2, S4, A1
• Revision answers which iteration is this? — P01, C01

The revision convention runs in parallel:

So a container is not "at S2" or "at P03". It is at P03, suitability S2 — third preliminary revision, issued for information. The pairing is what makes an issue sheet readable a year later, and it is what your comment register has to capture per comment.

S3 and S4 Are Your CRS Triggers

For anyone running document reviews, this is the part of the code system that generates actual work.

S3 opens a comment cycle. A container issued "suitable for review and comment" is an invitation to raise comments, and those comments need somewhere to live — a comment resolution sheet tied to that specific container and revision.

S4 and S5 should close it. Authorization and acceptance are assertions that the review is finished. Advancing a container to S4 while comments against its S3 issue are still open is the single most common way projects end up with sign-off that does not survive scrutiny: the audit trail shows a container authorized on a date when its own comment register says the review was incomplete.

The rule that prevents this is unglamorous and absolute: no container advances past S3 with open comments against the revision under review. Either the comment is closed, or it is formally carried forward as a named, owned, dated exception. What it cannot be is quietly left behind by a status change.

Mapping ISO 19650 Codes onto a CRS

Most comment resolution sheets predate anyone's ISO 19650 rollout and were never wired up to it. Bridging them takes a handful of columns:

Three rules make the mapping hold up:

• Keep suitability and comment status in separate columns. A container has a suitability; a comment has a status. Collapsing them into one field — "S4" as a comment status — produces a register that cannot answer either question.
• One CRS per container revision. When P03 is issued in response to comments on P02, open a new round and carry unresolved items forward explicitly. Overwriting the P02 round erases the evidence that the comment was ever raised.
• Record the suitability the container was issued at, not its current one. The reviewer commented on an S3 issue. That fact does not change when the container later reaches A1.

For the wider set of checks that belong alongside this, see the engineering document review checklist.

Four Mistakes Worth Designing Out

• Treating S2 as coordination-ready. S2 is reference only. If you need to coordinate against it, ask for it at S1 rather than assuming.
• Advancing suitability to clear a deadline. A status code is a statement about a document, not a project-controls lever. Moving a container to S4 does not close its comments; it just makes the register contradict the issue sheet.
• Undefined A-code meanings. If your information standard does not spell out what A1 through An mean on this project, published codes are decoration.
• Mixing 2021 and pre-2021 codes in one register. Pick the set your contract names, configure the CDE to offer only that set, and map historical codes rather than allowing both to be selectable.

Keeping Codes and Comments in Step

Every rule above is a consistency check between two records: the suitability history of a container and the comment register against it. In spreadsheets, nothing enforces those checks. Nothing stops a container being marked S4 with open comments, nothing carries unresolved items into the next revision, and nothing records which suitability a comment was raised against once the sheet has been edited a dozen times.

That is the class of problem Contrat.io removes. Comments are bound to a document revision rather than a filename, open items are inherited by the next revision automatically, statuses are enforced by role so authors cannot close their own comments, and the full history of who changed what is a click away. Try it free for 30 days, no credit card required.

For how this fits into a wider compliant review record, see The Ultimate Guide to EPC Document Control.

Frequently Asked Questions

What are the ISO 19650 status codes?

Status codes — also called suitability codes — state what a recipient is permitted to do with an information container. The current UK National Annex set is S0 (work in progress within a task team), S1 (suitable for coordination), S2 (suitable for information), S3 (suitable for review and comment), S4 (suitable for review and authorization) and S5 (suitable for review and acceptance), plus published A codes and B codes.

What is the difference between S1 and S2 in ISO 19650?

S1 means suitable for coordination: other task teams may develop their own design against it. S2 means suitable for information only: recipients may read and reference it but must not coordinate against it. Mixing the two shifts design risk between disciplines, so it is worth confirming which you have been issued.

Were S6 and S7 removed from ISO 19650?

Yes. The 2021 UK National Annex removed shared codes S6 (suitable for PIM authorization) and S7 (suitable for AIM authorization) because the industry could not consistently tell when each applied. Their function moved to S4 and S5 respectively. The published code CR was also removed as duplicative of an A code.

What is the difference between status codes and revision codes?

They answer different questions. Suitability says what may be done with the container — S2, S4, A1. Revision says which iteration it is — P01 for preliminary issues, C01 for contractual ones, and P01.01 for internal work-in-progress steps. A container is described by both together, for example P03 at suitability S2.

Should you use B codes in ISO 19650?

Current guidance recommends against them. A B code marks a container as contractual while comments remain outstanding against it, which is self-contradictory. If your project does use them, track every B-coded container as an open item with a named owner and a closure date.

When should a comment resolution sheet be opened under ISO 19650?

When a container is issued at S3, suitable for review and comment. Comments should be logged against that container ID and revision, and no container should advance to S4 or S5 while comments against the revision under review are still open unless they are formally carried forward as named exceptions.