ISO 19650 workflow setup

ISO 19650 is the international standard for managing information across the asset lifecycle. Planscape ships ISO 19650 conventions pre-built — naming, suitability, CDE containers, transmittal forms, audit trail. This guide shows you how to configure them for your project so that on day one you're generating information that satisfies the standard.

The four pillars Planscape configures for you

1. Naming convention — every file and document gets an ISO 19650 name.
2. CDE state machine — WIP → Shared → Published → Archived.
3. Suitability & revision codes — S0–S7 and P/A revisions.
4. Audit trail — hash-chained log over every state change.

Step 1 — Project metadata

Open the project › Settings › ISO 19650. Fill in the codes that go into every filename:

A complete file name then looks like:

KIH-PLNS-ZZ-00-M3-A-0001.rvt
KIH-PLNS-ZZ-XX-DR-M-0042.pdf

Step 2 — Configure the CDE state machine

Every file in Planscape lives in one of four containers:

Settings → CDE state machine. Defaults are correct for most projects. You can:

• Require a second approver before promoting to Published.
• Force a suitability change on each container transition.
• Auto-archive Published files after N days from project completion.

Step 3 — Suitability codes

The S codes mark what an information container is fit for:

The default mapping (S1/S2 → Shared, S4–S7 → Published) is the standard interpretation. Customize per project in Settings.

Step 4 — Revision codes

Planscape uses the P (pre-construction) and C (construction) revision scheme:

• P01, P02, P03… — pre-construction revisions
• P01.01, P01.02 — minor revisions within a major
• C01, C02, … — construction-issue revisions
• A01, A02, … — as-built revisions (after handover)

Auto-increment is enabled by default — re-issuing a deliverable bumps the revision code without you typing it.

Step 5 — Build the BEP

Project › Documents › + Generate BEP. Pick a template:

• Standard — generic ISO 19650 BEP.
• UK Public Sector — includes IR (Information Requirements) cross-references.
• NHS / Healthcare — adds HBN/HTM document requirements.
• Donor-funded — adds DFI/IFC reporting fields.

The BEP is rendered as a .docx with all your project metadata pre-filled. Edit in Word, re-upload as a deliverable.

Step 6 — Build the MIDP

The Master Information Delivery Plan lists every deliverable, its responsible party, and its target date.

Project › Deliverables › MIDP view. Add deliverables one of three ways:

• From a template — pick from 8 industry templates (Hospital, Airport, Office, etc.) — adds 30–80 deliverables in one click.
• From Excel — paste a delivery schedule, Planscape parses columns and creates deliverables.
• Manually — one row at a time.

Each deliverable carries: number, name, type, responsible party, suitability target, milestone, and dependencies. The MIDP view also shows RAG status (on-track / at-risk / late).

Step 7 — Verify the audit trail is on

Audit trail is on by default. To verify: Settings › Audit › Verify chain. Planscape walks every record in the project's audit log, checks each SHA-256 hash against the previous record, and reports the chain length and verification result.

A broken chain means tampering. Don't ignore it — contact support@planscape.co immediately. We haven't yet seen a real-world break, but the verification mechanism is what makes the audit trail court-admissible.

Day-to-day workflow once set up

1. Author works in Revit / Word / Excel, syncs to WIP via the plugin or upload.
2. When ready to share with the team, the author Publishes to Shared with a suitability code (S1 / S2 / S3).
3. Other disciplines coordinate in Shared. RFIs and NCRs raised against specific elements.
4. When ready for client review, the Project Lead Promotes to Published at a stage-gate suitability (S4 / S5).
5. A Transmittal is issued to client recipients listing every Published deliverable in that batch.
6. Each step is automatically logged in the audit trail.

Common mistakes

• Skipping the MIDP. Without it you can't show progress against plan. Even a rough first version is better than none.
• Using suitability codes inconsistently. Pick a convention (S2 for general info, S3 for review) and stick to it across the project.
• Approving your own work to Published. Even if your role allows it, route via a separate Project Lead. The audit trail benefits enormously from a second signature.
• Never running the chain verification. Do it monthly. It takes 5 seconds and proves the audit trail isn't compromised.