Revit Guides
Data Management
ELI5
EIEP:2026
Enhanced Information Exchange Process, a better-developed ISO 19650:2026
Author Jarek Wityk, Project Design (IO) Ltd
Base EIEP v3.1 spec (LITE terminology adoption)
Aligned with ISO/DIS 19650-1:2026 and ISO/DIS 19650-2:2026
Extension basis Succar B. and Poirier E., 2020. Lifecycle information transformation and exchange. Automation in Construction, 112.
Version EIEP:26.0.2
Date 02 June 2026
Status: Public teaser. Full paper ‘Structural Separation in Information Management’ forthcoming, with process maps, gate logic, BPMN primitives, and worked examples.
This article is the public summary of EIEP:2026. It states the structural problem, sets out the framework, and previews the next set of refinements moving into the paper. It is not the specification.
The paper bears the gate logic, the process maps, the BPMN primitives and the worked examples. Where this post says ‘previewed’ or ‘treated in the paper’, that is where the depth lives.
ISO 19650:2026 has closed for public comment. The deadline was 3 May.
The draft cleans up vocabulary. It introduces trigger events. It restructures workflow states. It folds Part 3 thinking into Parts 1 and 2.
What it does not do is separate information governance from project governance.
That is the structural problem. It has been the structural problem since 2018. The 2026 draft codifies the separation principle rhetorically. It does not enact it operationally.
I am not the only one saying so
In a public exchange a few days ago, Bilal Succar – author of the LITE framework, the most cited extension of ISO 19650 in the academic record – put it directly:
“The core issue is that information flow management… should never have been integrated into project/production governance. This was a major flaw back in 2018, and it is even more problematic now with autonomous agents… When we mix production with governance, we are actually subordinating the first to the second… it is a structural issue, not a semantic one.” Bilal Succar, LinkedIn comment thread, 6 May 2026
Bryn Mainwaring, ISO 19650 specialist and certification-scheme architect, frames the same point differently. ISO 19650, he argues, is part of the objectile.[1]
“ISO 19650 feels less like an end state and more like part of the vehicle, of the objectile, that allows the industry to move from structured, human-mediated exchanges toward more continuous, event-driven and potentially agent-enabled information flows.”
Bryn Mainwaring, LinkedIn comment, 5 May 2026
Multiple vocabularies. Same underlying problem.
The underlying problem.
ISO 19650 was written with information management as a sub-process inside project delivery. Information assignment follows appointment. Information exchange follows milestones. Information state follows the CDE. Roles are defined by appointment, not by information function.
That made sense in 2018, when information flow was slow, human-mediated, and document-shaped.
It does not make sense in 2026. Information flow is now dynamic, machine-mediated, and increasingly autonomous. Bilal's point is difficult to ignore:
"Agentic workflows require a clear separation between information-flow optimisation, where agents can operate at speed and scale, and production governance, in which humans must remain ultimately accountable and in control. If these flows are forced into production-governance containers - CDE states anyone? - agents become just glorified clerks in a faster filing system rather than the intelligent collaborators they could be."
What this article proposes
EIEP:2026 is a structurally separated alternative
Two frameworks, not one.
Framework A: Project Governance. Appointment, accountability, contractual milestones, role assignment. Humans remain in control.
Framework B: Information Governance. Information Sets, Routes, Shortcuts, Trigger events, Evidential moments, Degree of Integration. Agents and humans operate side by side, with explicit autonomy levels.
The two frameworks are connected by a defined interface, not merged into one.
Eight Information Sets (A to G plus Loop X/Y/Z). Seven Specifications (SP1 to SP7) defining the workflow. An explicit Degree of Integration ladder – tagged independently of Degree of Autonomy. A reject-path machinery (R-codes) drawn from LITE 2020. Trigger events extended with evidential moments treated under the Operational Assurance class (§7.4).
Note: this article is the public summary. The full EIEP:2026 specification and the underlying paper "Structural Separation in Information Management" will be available as a [PDF download / link forthcoming].
Why now
ISO 19650:2026 is expected later in 2026. Public comments are now closed.
The next public discussion opportunity is the ISO 19650 revision and IMI Framework session at Digital Construction Week 2026, ExCeL London, 3-4 June.
The panel will explain the changes. It will not reopen the structural question, because that is not the role of a public panel.
The structural question can only be reopened in the public record. That is the purpose of this article. That is what the comments below are for.
If you submitted formal review comments and felt the response did not land, leave a comment.
Quote yourself.
What is covered below
- The reviewer evidence – four quotes from the BSI/ISO public comment record
- What the 2026 draft does and does not do – §6.6, §4.2
- Framework A and Framework B – the structural separation, (with diagrams to follow).
- Information Sets and the Degree of Integration ladder – the EIEP:2026 specification in summary
- What this is not – relationship to LITE 2020, to ISO 19650, and to IMI guidance
- What happens next – the path to a peer-reviewed paper, and the open invitation
Why EIEP:2026 exists
EIEP v3.0 (Wityk 2022) extended ISO 19650-2:2018 with the AIM<->PIM trigger, IDP visibility, and CDE-as-precondition framing.
EIEP:2026 (v3.1) is the next published version. It grades every gate with a Degree of Autonomy tag, and adopts LITE terminology: Targeted Deliverables and Needed Resources and Methods, Information Transformation, Demand Entity and Supply Entity, Information Routes I/II/III, F-codes and R-codes, Information Sets A-G plus Loop X/Y/Z, Degree of Integration.
EIEP:2026 also consolidates against the ISO/DIS 19650:2026 review draft. Where the 2026 draft codifies a reform already proposed here, EIEP:2026 cites the new clause. Where the 2026 draft declines a reform that EIEP:2026 still considers necessary, the proposal is retained and the gap is recorded.
EIEP:2026 is not positioned as an alternative to ISO 19650:2026.
It is positioned as the operational specification ISO 19650:2026 would be if its own commentary were fully implemented
Positioning. EIEP:2026 takes the 2026 ISO draft as its starting point, applies LITE’s terminological apparatus uniformly, and closes the gaps that 2026 draft leaves open.
0.1 Alignment with ISO/DIS 19650:2026
The 2026 draft introduces several reforms that EIEP:2026 absorbs by reference rather than by re-statement. Where the draft moves further than v3.1, EIEP:2026 adopts the new language. Where the draft stops short of v3.1, EIEP:2026 keeps its v3.1 position.
| Reform area | ISO/DIS 19650:2026 position | EIEP:2026 position |
|---|---|---|
| Naming of information sets at the Framework A/B interface | IPP and IPS replace BEP, MIDP, and TIDP in the 2026 draft. The Information Production Plan (IPP) covers methods. The Information Production Schedule (IPS) covers the time-based delivery aggregation. | Adopted. EIEP:2026 maps BEP -> IPP (methods, the HOW), MIDP + TIDP -> IPS (when and by whom, federated and per-task-team). The Responsibility Matrix remains the WHO artefact and is not collapsed into either. |
| Separation of information management from design | §6.6: 'Information management assignment should not refer to design responsibilities.' | Adopted verbatim. Reinforced by structural separation of Project Governance and Information Governance (see companion paper). |
| Workflow states | §11.3: WIP, SHARED, SUBMITTED (new), PUBLISHED, ARCHIVED. | Adopted. SUBMITTED is the canonical Framework A/B handover state. EIEP:2026 maps SUBMITTED to LITE Milestone [6] -> [7] interface. |
| R-actions / reject paths | Part 2 §5.8.3-5.8.8: explicit reject paths at every gate (approve, authorize, accept). | Operationalised as named R-codes with owners and SLAs. R6-3 maps to §5.8.3 reviewer reject; R7-6 maps to §5.8.8 acceptor reject. |
| Approve / authorize / accept | §3.2.21-23: three distinct R-actions defined. | Adopted as Framework A acts. Each has a Framework B verification chain underneath. |
| Enabling technologies | §3.2.26: enabling technologies recognised as actors but not graded. | Adopted. EIEP:2026 grades enabling technologies via Degree of Autonomy (DoA) [0]-[4] per Succar and Poirier (2020). Determinism and Mechanism are tagged as separate orthogonal axes. |
| Degree of Integration ceiling | §4.2: 'integrated working ... beyond the scope of ISO 19650.' | Adopted as DoI [3]/[4] ceiling. EIEP:2026 still tags DoI for project-internal use; ISO scope sits at DoI [1]/[2]. |
| PIM term | PIM removed. Replaced by phase-specific Information Models. | Noted. EIEP:2026 retains AIM - PIM as an informal label and footnotes the 2026 deprecation. |
| Containers - structured / unstructured | Introduced as the canonical artefact distinction. | Adopted alongside LITE Representation Types. Container type and Representation Type are independent axes. |
| Information cycle closure (Milestones [1], [2], [7], [8]) | Not addressed. ISO scope remains [3]-[6]. | Retained. Four LITE Milestone gates (G-M1, G-M2, G-M7, G-M8) closed in EIEP:2026. |
| Observer-relativity of state boundaries | Not addressed. | Retained as v3.2. Observer axis included on every artefact tag. |
Table 0.1. Where ISO/DIS 19650:2026 codifies a v3.1 reform, EIEP:2026 cites it. Where it stops short, EIEP:2026 retains the v3.1 position.
0.2 Reviewer evidence supporting EIEP:2026 reforms
Independent reviewers of the ISO/DIS 19650:2026 draft raised, unprompted, the same structural concerns that v3.1 had previously identified. Selected verbatim quotes from the comment files (1,133 comments across Parts 1 and 2):
Information production cannot be part of the management process. They must be considered separately.
Independent reviewer, ISO 19650-2:2026 §5.8 commentary, 12 April 2026
Clause 4 treats information management as an autonomous lifecycle and completely omits the fundamental engineering perspective … information management must be explicitly established as a secondary, supporting process.
Independent reviewer (civil engineering), ISO 19650-1:2026 §4 commentary, 18 March 2026
Return BIM to the modellers and make information management a separate thing.
Independent reviewer, ISO 19650-1:2026 §3 commentary, 17 April 2026
The Design Intent Model and the Shop Design Information Model must be authored independently.
Independent reviewer, ISO 19650-1:2026 commentary, 30 April 2026
These four positions are independent of LITE and independent of EIEP. Their convergence on structural separation strengthens the argument that v3.1 / EIEP:2026 was tracking a real structural problem, not a rhetorical one.
1 Three terminological reforms adopted from LITE
1.1 Targeted Deliverables and Needed Resources and Methods
LITE replaces ‘information requirements’ with two complementary terms. Targeted Deliverables (TD) – the expected outcome, digital or physical asset. Needed Resources and Methods (NRM) – the people, tools, processes, and data sources required to produce the Targeted Deliverable.
ISO 19650 conflates the two. An EIR today mixes ‘deliver a federated model at LOIN-X’ (TD) with ‘use IFC4.3, run clash detection weekly, two-week review cycle’ (NRM). The OIR / AIR / PIR / EIR stack inherits the conflation. The 2026 draft retains the conflation.
EIEP:2026 splits the gates accordingly. Every v3.1 gate becomes a TD-gate and an NRM-gate.
1.2 Information Transformation
LITE describes information as continuous two-way morphing. Expected deliverables and actual assets transform into each other; digital and physical assets transform into each other. ISO 19650 and EIEP v3.0 draw information as a sequential pipeline (clauses 5.1 to 5.8) with a return loop on the AIM<->PIM margin. That depiction makes information look like it flows once, gets accepted, and is aggregated.
EIEP:2026 redraws the EIEP as a transformation diagram, not a production pipeline. Production is one phase of transformation. The AIM<->PIM trigger is no longer a margin annotation. It is the canonical view.
1.3 Demand Entity and Supply Entity
LITE follows Actor-Network Theory. A Demand Entity or Supply Entity may be an organisation, an individual, or a non-human information actor – a script, a model, a sensor, an LLM. ISO 19650 has no language for non-human actors. The 2026 draft acknowledges ‘enabling technologies’ (§3.2.26) but does not promote them to first-class entities.
EIEP:2026 adopts Demand Entity and Supply Entity throughout. A DoA [4] LLM-checker with generative mechanism is a Supply Entity. A clash-detection script is a Supply Entity. Their Degree of Autonomy (DoA) grade and Information Representation Type tag describe their role precisely. Appointing party / appointed party is retained as legal-contract terminology only (§5.4.6, §5.4.7).
2 Adjacent reforms also adopted
2.1 Lifecycle phases - design, delivery, utilisation
LITE alternates ‘design, construction, operation’ with ‘design, delivery, utilisation’. The latter covers digital assets too. Construction does not. EIEP:2026 uses design / delivery / utilisation so the AIM<->PIM trigger logic applies symmetrically across digital and physical assets.
2.2 Information Representation Types and Information Taxonomy v2.0
LITE Table 1 subdivides ‘information’ into three Representation Types – Document, Model, Data – and develops them across five layers.
| Layer | Document | Model | Data |
|---|---|---|---|
| Use | Reporting, certifying, warranting | Representing, simulating, quantifying | Mining, scripting, driving CNC |
| View | Drawing, schedule, report, spec | 3D view, animation, holograph | Code snippet, CNC file, JSON |
| View Definition | Product Data Template | IFC4 Design Transfer View | Translation script, formula |
| Viewer | PDF reader, 2D CAD viewer | BIM Vision, Solibri | Tableau, BI tools |
| Environment | Shared Document Environment | Federated Modelling Environment | Integrated Data Environment |
Table 2.1. LITE Information Taxonomy v2.0 - five layers x three Representation Types.
ISO 19650’s Common Data Environment collapses three distinct environments into one. The 2026 draft retains this. EIEP:2026 decomposes the CDE into Shared Document Environment, Federated Modelling Environment, and Integrated Data Environment, with explicit cross-Environment transition gates.
3 Gate-level changes
3.1 Every gate splits into TD-gate and NRM-gate
Take G-5.6.5 Review and approve for sharing. In EIEP v3.0 (Wityk 2022) it has one tag: [1] with [4] pre-screen. In EIEP:2026 (v3.1) it splits.
| Gate | Checks | DoA EIEP:2026 |
|---|---|---|
| G-5.6.5-TD | Targeted Deliverable conformance: does this artefact match the TD definition? | [1] + DoA [3] pre-screen on Model (deterministic, analytic), DoA [4] pre-screen on Document (probabilistic, generative) |
| G-5.6.5-NRM | Needed Resources and Methods conformance: was this produced through the agreed NRM? | [2] schema check + [3] audit-trail check |
TD failure -> reject and rework. NRM failure -> process correction, may not require artefact rework. EIEP v3.0 conflated the two. EIEP:2026 separates them so the response to failure is clearer.
3.2 Ten-axis artefact metadata
The Degree of Autonomy (DoA) metadata travels with the artefact through the three Environments. EIEP:2026 uses a ten-axis tag in place of v3.0’s single DoA tag:
- doa_level – [0] Manual, [1] Assisted, [2] Automated, [3] Automatic, [4] Autonomous
- doi_tier – [0] Referenced, [1] Defined, [2] Managed, [3] Integrated, [4] Optimised
- representation_type – Document, Model, Data
- taxonomy_layer – Use, View, View Definition, Viewer, Environment
- observer – Demand Entity from whose perspective State is determined
- route – I (Assisted), II (Automated/Automatic), III (Autonomous)
- shortcut_taken – null or S-code (S1-3 to S7-1)
- valid_reason – free text or null
- determinism – deterministic / probabilistic / hybrid
- mechanism – analytic / generative / control-action.
(doi) Degree of Integration | (doa) Degree of Autonomy
EIEP:2026 keeps LITE’s five-level DoA. Determinism (deterministic / probabilistic / hybrid) and Mechanism (analytic / generative / control-action) are added as separate orthogonal tag axes in the metadata schema, not as sub-levels of DoA. Correction credited to Bilal Succar, LinkedIn exchange, 11 May 2026.
Combined gate signature example. G-5.6.5-TD : DoA [1] human approval + DoA [3] pre-screen (deterministic, analytic).
3.3 The CDE decomposes into three Environments
The most disruptive of the EIEP:2026 changes. ISO 19650’s single CDE is replaced or re-described as three Environments per LITE Table 1.
| Environment | Manages | Typical platforms |
|---|---|---|
| Shared Document Environment | Documents - drawings, schedules, reports, specifications | Document/project management systems |
| Federated Modelling Environment | Models - geometry, federation, view definitions | Model server / BIM SaaS |
| Integrated Data Environment | Data - sensor feeds, derived datasets, structured data | Data warehouse, integration platform |
Cross-Environment transitions become explicit gates. A Model published in the Federated Modelling Environment may extract Documents into the Shared Document Environment and feed Data into the Integrated Data Environment. Each transition is a gate. The gates between Environments are exactly where DoA [3] and DoA [4] apply in practice – deterministic Document extracts from Models, ML-derived Data feeds from Models (probabilistic, analytic), LLM-summarised reports compiled from Data sets (probabilistic, generative).
3.4 Demand Entity / Supply Entity replaces appointing/appointed party
At every gate the question changes from ‘who is the appointing party?’ to ‘which Demand Entity is requesting, and which Supply Entity is delivering?’ The 2026 draft eliminates ‘PIM’ entirely. ISO/DIS 19650-1:2026 Clause 12.2.2 restructures the model layer: information models produced by information production teams now ‘contribute to the AIM in response to trigger events whenever these occur during the asset life cycle.’ The project-vs-asset distinction collapses; the lifecycle becomes asset-centric throughout…
4 Actor-relative state boundaries
What is a resource for one actor, is a deliverable for another. For example, a cement bag is a deliverable by the cement supplier and a resource for the builder. Moreover, what is a physical reality for an actor is a conceptual representation – or a virtual reality – for another. For example, a steel beam for a steel erector will be a 3D object or a shop drawing for a structural designer.
Succar and Poirier (2020), §2.2
ISO 19650 implicitly assumes a fixed observer. The appointing party defines the requirements; the appointed party delivers them. State boundaries are absolute relative to that pair. The 2026 draft does not change this.
EIEP:2026 makes the observer explicit. Every artefact tag includes the observer axis: the Demand Entity from whose perspective the State boundary (Purpose / Deliverable / Resource and Method) is drawn.
Operational consequence. A Model produced by a structural engineer is a Deliverable to the appointing party and a Resource to the steel fabricator. The same artefact has two State classifications depending on the observer. Without observer-tagging, gate logic produces false rejections (rejecting a Resource as if it were an incomplete Deliverable) and false acceptances (accepting a Deliverable that has not yet been validated as a Resource downstream).
5 Information Milestones [1] to [8]
LITE identifies eight Information Milestones – natural deflection points where information transforms from idea, to digital representation, to physical asset, and back to idea for the next cycle.
| # | Milestone | Description |
|---|---|---|
| [1] | Intent to Deliver New Assets | Demand Entity decides to commission. Initial scope, durations, risks, costs. |
| [2] | Expected Physical Deliverables | Spatial/geometric and functional attributes of the Physical Asset are defined. The brief. |
| [3] | Targeted Digital Deliverables | Documents, Models, Data sets needed for design, delivery, utilisation are defined. |
| [4] | Needed Resources and Methods | New human actors, machine actors, and methods required are identified. |
| [5] | Available Resources and Methods | Actual resources and methods deployed. Project teams formed. |
| [6] | Actual Digital Assets | Documents, Models, Data sets are successfully delivered. |
| [7] | Actual Physical Assets | Physical assets delivered and commissioned. |
| [8] | Intent to Reuse Existing Assets | Demand Entity decides to redesign, renovate, reuse, recycle, or discard. |
5.1 EIEP:2026 - four new gates close the cycle
EIEP v3.0 operate almost entirely between Milestones [3] and [6]. ISO 19650-2:2018 and the 2026 draft do the same. EIEP:2026 adds four gates.
| New gate | Milestone | Purpose | DoA |
|---|---|---|---|
| G-M1 Intent declaration | [1] | Demand Entity records intent to commission. Triggers Information Cycle entry. | [0] / [1] |
| G-M2 Expected Physical brief | [2] | Functional and non-functional attributes of the Physical Asset are codified. | [1] with [4] permitted (declared) |
| G-M7 Physical commissioning | [7] | Actual Physical Asset accepted. AIM updated with as-built. | [1] human + [3] sensor commissioning |
| G-M8 Intent to reuse | [8] | Demand Entity records intent to reuse, refurbish, recycle, or discard. | [0] / [1] |
6 Information Flows, Routes, and the Information Cycle
6.1 Four flow directions
| Flow | Direction | Action class | LITE example |
|---|---|---|---|
| Forward | Counter-clockwise around the cycle | Execution Actions | Design, delivery, utilisation |
| Reverse | Clockwise | Measurement Actions | Assessment, verification, validation |
| Inward | Towards the centre | Capturing Actions | Learning, integrating data |
| Outward | Away from the centre | Sharing Actions | Teaching, releasing data |
EIEP v3.0 represented Forward Flow only. Reverse Flow was implicit in reject loops; Inward and Outward were absent. EIEP:2026 names all four.
6.2 Three Routes
| Route | Description | Milestones traversed | DoA character |
|---|---|---|---|
| Route I - Assisted Flow | Longest route. All eight Milestones. | [1] -> [2] -> [3] -> [4] -> [5] -> [6] -> [7] -> [8] | [0] / [1] dominant |
| Route II - Automated and Automatic | Bypasses [4] and [5] when R&M are pre-defined. | [1] -> [2] -> [3] -> [6] -> [7] -> [8] | [2] / [3] dominant |
| Route III - Autonomous | Shortest. Bypasses [3] through [6]. Direct from spatial/functional definition to physical delivery via swarm robotics, generative design, AI. | [1] -> [2] -> [7] -> [8] | [4] dominant; deterministic and probabilistic both seen; mechanism varies (analytic, generative, control-action) |
Routes are not mutually exclusive. A single project may run concurrent activities on different Routes at different DoAs. Route is recorded at G-M1 and revisited at every subsequent gate.
7 Information Actions - F-codes and R-codes
LITE Table 2 names every transition between Milestones with two paired action codes. A Forward Execution Action (F) and a Reverse Measurement Action (R). Forward delivers; Reverse checks. Both codes include the milestone numbers either side of the transition. EIEP v3.0 (Wityk 2022) represented Forward only and treated Reverse as a reject-loop side-effect. EIEP:2026 (v3.1) makes both first-class workflow objects.
“EIEP:2026 keeps LITE’s DoA; Determinism and Mechanism are orthogonal tag axes (see §3.2).”
7.1 Route I - all eight transitions
| From -> To | Forward (Execution) | Reverse (Measurement) |
|---|---|---|
| [1] -> [2] | F1-2 Specify physical and functional properties of Assets | R2-1 Confirm Expected Physical meets Demand Entity Purposes |
| [2] -> [3] | F2-3 Define Digital Deliverables | R3-2 Verify Digital Deliverables are adequate for Expected Physical |
| [3] -> [4] | F3-4 Identify Resources and Methods, build responsibility matrix | R4-3 Analyse adequacy of Resources and Methods |
| [4] -> [5] | F4-5 Assign Resources and deploy Methods | R5-4 Assess actual/available against needed |
| [5] -> [6] | F5-6 Generate Digital Assets | R6-5 Evaluate whether deployed R&M were used adequately |
| [6] -> [7] | F6-7 Deliver Physical per Digital | R7-6 Check delivered Physical against digital counterparts |
| [7] -> [8] | F7-8 Operate and maintain (Lifecycle Extender) | R8-7 Inspect O&M against expectations |
| [8] -> [1] | F8-1 Renovate, extend, reuse (Lifecycle Connector) | R1-8 Evaluate refurbish/recycle/reuse |
7.2 Routes II and III
| Route | From -> To | Forward | Reverse |
|---|---|---|---|
| II | [3] -> [6] | F3-6 Generate Actual Digital in automated/automatic process | R6-3 Validate Actual Digital against Expected Digital |
| III | [2] -> [7] | F2-7 Deliver Actual Physical autonomously | R7-2 Verify Actual Physical against Expected Physical |
Two transitions are Lifecycle hinges. F7-8 is the Lifecycle Extender – extends Project Lifecycle into Asset Lifecycle. F8-1 is the Lifecycle Connector – connects one Information Cycle to the next. v3.0 ends at handover; both hinges sit beyond v3.0’s frame. ISO 19650:2026 draft §13 confirms ‘between projects there is no new information being produced’ – Open Cycle confirmed; the Lifecycle Connector is still absent from ISO 19650.
7.3 Alignment with ISO/DIS 19650-2:2026 §5.8.3-5.8.8
The 2026 draft enumerates explicit reject paths at every gate (approve, authorize, accept). These are R-codes operationalised but not named. EIEP:2026 maps them:
- §5.8.3 reviewer reject -> R6-3 (validate Actual Digital against Expected Digital)
- §5.8.4 approve fail -> R5-6 + R6-3 paired
- §5.8.7 authorize fail -> R6-3 + R7-6 paired
- §5.8.8 accept fail -> R7-6 (check Actual Physical against digital counterparts)
Where ISO 19650:2026 enumerates reject paths, EIEP:2026 names them as workflow objects with owners, SLAs, and audit trails.
7.4 Where revision loops stop: an Operational Assurance class (preview)
EIEP §5.6.x is a revision loop. It applies to information that can be generated, checked, revised, resubmitted, and approved. Revision loops cannot apply to irrevocable physical events. Once the slab pour closes over the cast-in containment, once the wall is closed, once the lightning protection connection is buried behind cladding, once the emergency lighting three-hour duration test runs its window – the record is either captured contemporaneously or reconstructed. Reconstruction is not the same artefact. It is a derived account. For higher-risk buildings in the UK, this is not only procedural. The Building Safety Act 2022 introduces dutyholder duties and Mandatory Occurrence Reporting (MOR) to the Building Safety Regulator (BSR). An evidential failure during installation or commissioning is not a defect to be corrected later. It is a reportable occurrence.
EIEP:2026 therefore distinguishes two governance classes:
- Refinement-of-intent. Managed by the EIEP revision loop. Errors are correctable. The artefact converges by iteration.
- Evidence-of-truth. Managed by an Operational Assurance class sitting alongside EIEP, not inside it. Errors at irrevocable moments are not correctable, only escalatable.
Worked example. Emergency lighting three-hour duration test.
The test runs once, at a specified state of charge, under specified ambient conditions, on a defined circuit configuration. The window is the test itself. The fact being recorded is historical in the sense developed in §7.5: one-shot, window-bound.
Under the EIEP revision loop alone, a missed or partial capture is handled as a documentation defect. Re-run the test, re-submit the record, close the loop. That logic is sound for refinement-of-intent. It is not sound for evidence-of-truth, because the second run is a different test. Different state of charge. Different ambient. Different luminaire age. The record of the first run cannot be reconstructed; it can only be replaced by the record of a second, distinct event.
Under the Operational Assurance class, the same gate behaves differently. A pure binary stop at capture failure is inadequate, for the reasons set out in §7.5 (compensating controls, statistical sampling, accepting and pricing residual risk). EIEP:2026 specifies a graded stop with named override. The gate waits for one of three events:
- Evidence-Complete. The capture lands within the window. The gate advances normally.
- Window-Closure. The window closes without capture. The gate stops and escalates: withheld practical completion, amended risk register, amended safety case, MOR to BSR where threshold is met.
- Override. A named dutyholder, with stated authority and recorded reasoning, accepts the gap under defined compensating controls (for example, a re-test under bounded ambient and a structured measurement record per §7.5 evidence Class C). The override itself is an audited artefact, not an exemption.
The primitive is a BPMN Exclusive Event-Based Gateway: first-fires-wins, all three events known in advance, override an event in its own right rather than a workaround. The medical-surgery instrument-count protocol behaves the same way: the default is a hard stop before closure, with a named override path where the patient’s condition requires it, the override recorded and audited, post-event imaging compensating for the missed count. Graded stop with named override is the structurally sound shape for evidential gates.
The paper treats this in full: a consequence-class triage (when capture-at-moment is load-bearing versus when adjacent evidence and compensating controls suffice), an evidence taxonomy (Class A design intent, Class B action evidence, Class C measured outcome, Class D contextual integrity), a five-test discriminator for capture-at-moment, and the full Exclusive Event-Based Gateway specification with worked examples across installation, energisation, life-safety testing, and commissioning. The escalation chain through withheld practical completion, amended risk register, amended safety case, and MOR to BSR is specified there.
This post records the structural commitment. The mechanism is in the paper.
7.5 Three-state epistemology of as-built record (preview)
The OA class above turns on what kind of fact is being recorded. EIEP:2026
distinguishes three states of as-built information:
Reportable. Checkable now, against the asset itself. Re-runnable in principle. Subdivides further:
- As-installed. One-shot capture before the asset becomes inaccessible (concealed services, void closure, encapsulation). Cannot be re-observed without destructive re-access.
- Current-observed. Re-runnable by inspection (visible labelling, tagging, accessible plant).
- Current-measured. Re-runnable by instrument (sensor stream, metered output, monitored circuit).
Historical. One-shot event, window-bound. The window has closed. The record either exists or it does not. Examples: first energisation, life-safety test under specified ambient conditions, commissioning start-up sequence.
Procedural. Signature-driven. The fact recorded is that a duty was performed by an authorised party, not a directly observable physical state. Examples: handover authorisations, statutory notifications, dutyholder sign-offs.
The OA class applies mostly to the as-installed and Historical states. Current-observed and Current-measured states tolerate later recovery of evidence at lower cost. Procedural states are established by the signature, not by physical reconstruction.
The paper develops this into the capture-at-moment discriminator and the
operator-side implementation gap.
7.6 Maintainability and asset persistence (preview)
The case for capture-at-moment is usually made by pointing to assets that have outlived their records. The argument cuts both ways.
Older assets persist because they were built with structural redundancy, maintainable construction, conservative materials, and durable design. They tolerate imperfect records because the asset itself is forgiving. Modern value-engineered construction has traded much of that forgiveness for efficiency. Owners now rely on the as-built record more than they used to, because they can rely on the asset less.
This is a separate problem from information capture. It belongs in design briefing and procurement, not in EIEP. EIEP cannot solve maintainability by improving records. The paper notes the dependency but does not absorb the problem.
7.7 Operator information-use as the binding constraint (preview)
A complete information set does not, on its own, relax operational conservatism. The operator must be able to use it.
Where FM maturity is low, dutyholders default to conservative regimes
regardless of record quality. Where the regime is statutory (life-safety, fire, electrical safety), it does not relax at all. The information-use side is the binding factor on whether better records deliver downstream benefit.
This matters for EIEP because the cost of capture is paid in the delivery phase and the benefit is realised in the operation phase, often by a different party. The paper treats the cost/benefit asymmetry and the operator-side maturity dependency.
8 Information Shortcuts - bypasses, reasons, risks
LITE Table 3a identifies sixteen Shortcuts that bypass one or more Milestones. Table 3b pairs each bypassed Milestone with a Valid Bypass Reason and a Potential Bypass Risk. A Shortcut without a stated valid reason is unmeasured technical debt.
| Shortcut | From -> To | Milestones bypassed |
|---|---|---|
| S1-3 | [1] -> [3] | [2] |
| S1-6 | [1] -> [6] | [2], [3], [4], [5] |
| S1-7 | [1] -> [7] | [2], [3], [4], [5], [6] |
| S2-4 | [2] -> [4] | [3] |
| S2-5 | [2] -> [5] | [3], [4] |
| S2-6 | [2] -> [6] | [3], [4], [5] |
| S2-7 | [2] -> [7] (not Route III) | [3], [4], [5], [6] |
| S3-5 | [3] -> [5] | [4] |
| S3-6 | [3] -> [6] (not Route II) | [4], [5] |
| S3-7 | [3] -> [7] | [4], [5], [6] |
| S4-6 | [4] -> [6] | [5] |
| S4-7 | [4] -> [7] | [5], [6] |
| S5-7 | [5] -> [7] | [6] |
| S6-1 | [6] -> [1] (next cycle) | [7], [8] |
| S6-8 | [6] -> [8] | [7] |
| S7-1 | [7] -> [1] (next cycle) | [8] |
Critical distinctions. S2-7 is not Route III. S3-6 is not Route II. The Route is a sanctioned path with named F-codes and R-codes. The Shortcut is a bypass with a Valid Reason or a Risk. Conflating them hides whether the project chose the Shortcut deliberately (Route III autonomy) or fell into it (S2-7 unmeasured).
EIEP:2026 – Shortcut declaration as a metadata field. Each artefact holds shortcut_taken (null or S-code) plus valid_reason (free text or null). An audit gate at the receiving Milestone reconciles shortcut_taken against route and doa_level. A Route III artefact with shortcut_taken = S2-7 is consistent. A Route I artefact with shortcut_taken = S2-7 is unmeasured technical debt
9 Information Sets - the unit of organisation
LITE Table 4 names ten Information Sets. Seven are Route I sets (A-G), tied to the seven forward transitions. Three are loop sets (X, Y, Z). Each set includes a Specifications block (SP1 through SP7) plus, for X/Y/Z, updates to existing SPs.
| Set | Span | Specifications |
|---|---|---|
| A | [1] -> [2] | SP1 Physical Asset Specs |
| B | [2] -> [3] | SP2 Digital Asset Specs |
| C | [3] -> [4] | SP3 Resources and Methods Specs |
| D | [4] -> [5] | SP4 Updated R&M Specs (post-vetting) |
| E | [5] -> [6] | SP5 Digital Delivery Specs |
| F | [6] -> [7] | SP6 Physical Delivery Specs |
| G | [7] -> [8] | SP7 Asset Utilisation Specs |
| X | [3] -> [6] Short Loop | No new SP; SP3-SP5 updated |
| Y | [2] -> [7] Long Loop | No new SP; SP2-SP6 updated |
| Z | [8] -> [1] next cycle | No new SP; SP1-SP7 brought forward as Information Pool |
EIEP:2026 – Information Set as the unit of contract and the unit of CDE folder. v3.0 organises CDE folders by stage gate. EIEP:2026 reorganises them by Information Set. Set A folder receives all SP1 artefacts. Set B folder receives all SP2 artefacts. Cross-Set references are explicit links, not implicit adjacency.
Operational consequence. EIRs, IPPs, and IPSs map cleanly onto Set boundaries. EIR is Set A + Set B.
Specifications. The IPP (formerly BEP) sits at Set C Specifications and Set E Methods. The IPS (formerly MIDP + TIDP) sits at Set E Schedules, federated at project level and decomposed per task team. The Responsibility Matrix sits across Sets C and D and is the WHO artefact; it is not absorbed by IPP or IPS. Naming the Sets removes the recurring confusion about which document holds which content.
10 Degree of Integration (DoI)
Degree of Autonomy (DoA) grades the autonomy of action. DoI grades the integration of information. v3.0 tags DoA only. EIEP:2026 tags both, alongside the eight further metadata axes in §3.2.
| Tier | Name | What it means | Where it lives |
|---|---|---|---|
| [0] | Referenced | Needed but not captured. External legal provisions, codes, classifications. | Outside the CIE; cited by reference |
| [1] | Defined | Captured in the CIE. Visible to actors per access level. | Common Information Environment |
| [2] | Managed | Inspected, harmonised, normalised. Cascading change across sets. | Unified Information Pool |
| [3] | Integrated | Same schematic structure across sets. Seamless transformation. | Integrated Information Platform |
| [4] | Optimised | Continuously updated via IoT, ledgers, public data. AI-enabled. | Information Reactor |
ISO/DIS 19650:2026 §4.2 confirms the DoI limit. The 2026 draft states: ‘integrated working … beyond the scope of ISO 19650.’ EIEP:2026 reads this as a hard limit at DoI [2] Managed for ISO 19650 scope. EIEP:2026 extends past the limit for project-internal use; DoI [3] Integrated and DoI [4] Optimised remain outside ISO scope but inside EIEP scope.
DoA and DoI are independent. A Route III autonomous fabrication instruction (DoA [4]) may be issued from a Tier [1] Defined data store with no cross-set integration. A Tier [3] Integrated BIM platform may hold only Route I (DoA [0]/[1]) human-reviewed artefacts. The two ladders measure different things and must be tagged separately.
DoI tier change is a gate event. Promoting an artefact from [1] Defined to [2] Managed requires inspection and normalisation. Promoting from [2] to [3] requires schematic alignment. Promoting from [3] to [4] requires connection to the Information Reactor. v3.0 has no equivalent – once an artefact lands in the CDE, its integration character is implicit and unaudited.
11 EIEP:2026 specification summary - thirteen-point spec
- Targeted Deliverable / Needed Resources and Methods split at gate level. Every v3.0 gate becomes a TD-gate and an NRM-gate. Failure response differs.
- Ten-axis artefact metadata in place of v3.0’s single DoA tag. doa_level + doi_tier + representation_type + taxonomy_layer + observer + route + shortcut_taken + valid_reason + determinism + mechanism.
- The CDE is decomposed into three Environments per LITE Table 1. Shared Document Environment, Federated Modelling Environment, Integrated Data Environment. Cross-Environment transitions become explicit gates.
- Information Transformation as canonical view. AIM<->PIM is the diagram, not the margin. Production, acceptance, and aggregation are phases of continuous two-way morphing.
- Demand Entity / Supply Entity replaces appointing/appointed party outside contractual clauses. Non-human Supply Entities are first-class citizens. ANT-compatible.
- Design / delivery / utilisation replaces ‘design, construction, operation’. Lifecycle phases apply symmetrically across digital and physical assets.
- State boundaries are observer-relative. Every artefact has an observer axis identifying the Demand Entity from whose perspective Purpose / Deliverable / Resource and Method is determined.
- Four new gates close the Information Cycle. G-M1 Intent declaration, G-M2 Expected Physical brief, G-M7 Physical commissioning, G-M8 Intent to reuse. EIEP becomes a complete cycle in LITE terms.
- Information Routes I/II/III are first-class. Route is selected at G-M1, recorded as metadata, and dictates which gate set applies. Reverse, Inward, and Outward flows are named alongside Forward flow.
- Every gate transition has an F-code and an R-code. LITE Table 2 Forward Execution Actions and Reverse Measurement Actions become workflow objects. R-codes turn v3.0 reject-loops into named, owned, audited measurement actions. Aligns with ISO/DIS 19650-2:2026 §5.8.3-5.8.8.
- Information Shortcuts are declared, not implicit. Each artefact holds shortcut_taken and valid_reason. Bypass risks compile. Shortcuts without valid reasons are surfaced as unmeasured technical debt at audit.
- CDE folders reorganise by Information Set, not by stage gate. Sets A-G hold first-pass Specifications (SP1-SP7). Loop Sets X and Y hold design and delivery iteration. Set Z is the deliberate handover into the next Cycle. EIR/IPP/IPS map cleanly onto Set boundaries.
- Degree of Integration (DoI) [0]-[4] is tagged on every artefact and tracked at gate promotion. Referenced, Defined, Managed, Integrated, Optimised. The CIE-Pool-Platform-Reactor sequence is the integration roadmap. ISO 19650:2026 ceiling at DoI [2]; EIEP scope extends to [4] for project-internal use.
12 Implementation order
The thirteen points do not all need to land at once. Recommended sequence by cost and disruption:
- Documentation reform first (low cost, high clarity). Adopt LITE terminology in the EIEP narrative and the gate catalogue. Adopt F-code/R-code action labels for existing transitions. No diagram changes yet, no tooling changes.
- Ten-axis artefact metadata in the CDE (touches tooling, bounded). Extend the v3.0 metadata schema with doi_tier, representation_type, taxonomy_layer, observer, route, shortcut_taken, valid_reason, determinism, and mechanism alongside doa_level.
- Add Milestone gates G-M1, G-M2, G-M7, G-M8 to close the Information Cycle (touches process). Most contracts already imply these; EIEP:2026 makes them explicit.
- R-codes as named workflow objects (touches process). Reframe v3.0 reject-loops as R6-3 and R7-6. Assign owners and SLAs. Aligns with ISO/DIS 19650-2:2026 §5.8.3-5.8.8.
- TD / NRM split at gate level (touches process, requires IPP rewrite). Split each gate into TD-gate and NRM-gate. Retrain reviewers. Update review templates.
- Information Set folder reorganisation in the CDE (touches platform configuration). Replace stage-gate folders with Set A-G + Loop X/Y + Pool Z. Update EIR/IPP/IPS templates to map onto Sets.
- CDE decomposition into three Environments (touches CDE platform configuration). Configure or label workflows so Document, Model, and Data flows are tracked separately.
- Shortcut declaration field plus audit gate (touches workflow logic). shortcut_taken and valid_reason populated at intake; reconciliation at the receiving Milestone.
- Route declaration at G-M1 with downstream enforcement (touches workflow logic). Record Route I/II/III at intake; route artefacts to the correct gate set automatically.
- Information Transformation redrawn with Forward, Reverse, Inward, and Outward flows (touches the canonical figure). Fig 7-3 redrawn as a transformation diagram.
- Demand / Supply Entity adoption in legal documents (touches contracts, slowest). Wait until ISO 19650 standards body adopts equivalent language, or pilot in private contracts.
- DoI tier promotion gates (touches platform investment). Mark current DoI tier on every artefact at intake. Define explicit promotion criteria. ISO scope ceiling at DoI [2]; EIEP scope extends to [4].
Steps 1-4 are achievable inside one project lifecycle. Steps 5-9 require organisational alignment. Steps 10-12 are phased over standards-body, contractual, and platform-investment cycles.
13 Open questions for EIEP:2026 review
- Does the TD / NRM split at every gate produce too many gates? Should it apply only to high-traffic gates (5.6.5, 5.6.6, 5.7.2) and stay implicit elsewhere?
- How does Demand Entity / Supply Entity interact with ISO/DIS 19650-2:2026 wording around ‘approve’ (§5.8.4), ‘authorize’ (§5.8.7), ‘accept’ (§5.8.8)? These verbs presume a human party.
- Is the ten-axis artefact tag enforceable in current CDE platforms, or does it require a profile extension to ISO 19650-2:2026 Annex A?
- Does the CDE-into-three-Environments decomposition match how 2026 CDE platforms are actually built, or does it create a mismatch between the EIEP and the tooling?
- The four new Milestone gates (G-M1, G-M2, G-M7, G-M8) sit largely outside ISO 19650-2:2026’s clause structure. Does EIEP:2026 propose new clauses, or position these as inferred from existing clauses?
- The observer axis is conceptually clean but operationally novel. Are there CDE platforms that already track observer-relative state? If not, is this a tooling roadmap item or a metadata field for human discipline only?
- Route I/II/III at G-M1 implies the Demand Entity declares the autonomy character of the project at intake. Is this realistic, or does the Route emerge from negotiation through Milestones [3]-[5]?
- Where does EIEP:2026 sit relative to the structural-separation argument? EIEP:2026 reforms vocabulary, metadata, and gate set; structural separation reforms the relationship between information governance and project governance. EIEP:2026 is a precondition for structural separation, not a substitute.
- Are R-codes practical as standalone workflow objects on small projects, or do they survive only as audit categories on large/regulated jobs? Below what project size does the F/R distinction collapse back into a single accept/reject?
- Is Set-based folder reorganisation compatible with current CDE platforms (Forma, ACC, BIM 360, ProjectWise, Asite, Trimble Connect), or does it require platform-side changes? Pilot finding required.
- The Shortcut audit gate adds friction. Is the friction earned (catches unmeasured debt) or theatrical (project teams declare valid reasons reflexively)? What is the false-positive rate after one project cycle?
- Most 2026 projects sit at DoI [1] Defined. Is DoI [2] Managed achievable inside a single project, or does it require organisation-level investment that cannot be amortised by a single appointment?
- DoA and DoI are independent ladders but get conflated in practice. EIEP:2026 separates them. Does the separation hold under contract drafting, or do clients want a single composite ‘maturity’ index?
- The OA class sits at the Framework A/B interface. Does it fit at IPP/IPS level, or does it need its own artefact set? The paper treats this.
- Capture-at-moment evidence is “unverifiable later” in the sense that the moment has passed. Does that make the record a primitive, or a derived artefact whose primitives are the underlying sensor traces, witness signatures, and instrument calibrations? The paper takes a position.
- Does structural separation, named gates, and OA-class evidence actually change behaviour on regulated projects, or does it formalise what mature teams already do? Empirical work is needed.
14 Sources
This post is a teaser. The forthcoming paper “Structural Separation in Information Management” includes the gate logic, the BPMN primitives, the process maps, the worked examples, and the empirical-question programme. If a structural argument here lands, the paper is where the mechanism is. If a structural argument here misses, that is where the corrections should be addressed.
[1] Cache, B. (1995). Earth Moves: The Furnishing of Territories. Translated by A. Boyman, edited by M. Speaks. Cambridge, MA: MIT Press. (Term originally coined in Deleuze, G., 1993, The Fold: Leibniz and the Baroque, University of Minnesota Press.) Back
[2] ISO/DIS 19650-1:2026. Organization and digitization of information about buildings and civil engineering works, including building information modelling (BIM) – Information management using building information modelling – Part 1: Concepts and principles. Draft for review.
[3] ISO/DIS 19650-2:2026. Organization and digitization of information about buildings and civil engineering works, including building information modelling (BIM) — Information management using building information modelling — Part 2: Delivery phase of the assets. Draft for review.
[4] Succar B. and Poirier E., 2020. Lifecycle information transformation and exchange for delivering and managing digital and physical assets. Automation in Construction, 112, 103090. https://doi.org/10.1016/j.autcon.2020.103090
[5] Wityk J., 2022. The development of an enhanced information exchange process and recommended organisational information requirements based on the ISO 19650 series. MSc dissertation, Middlesex University.
[6] BSI Standards Development Portal, 2026. Public comment files for ISO/DIS 19650-1:2026 and ISO/DIS 19650-2:2026 (consolidated comment matrix, 1,135 comments captured 2 May 2026, 24 hours before close). Available via standardsdevelopment.bsigroup.com.
[7] Acknowledgement. The Operational Assurance class was refined in
discussion with David Shepherd, May–June 2026. Responsibility for the
EIEP:2026 framework, its claims, and any errors remains with the author.
On this Page
One Response
EIEP:2026 is useful because it pushes BIM from “approved information” to “verified and usable information.”
But it should be applied gradually, starting with the most important things: hidden works evidence, verified as-built records, asset data, commissioning records, O&M documents, warranties, and FM-ready handover.