Twelve steps across three loops, two of them releases, under one contract.
Every row has the same contract: a keyed input, checked against a published requirement, gated by someone with authority, emitting a record with provenance. The two release rows are where the record leaves one firm for another, so they are the interfaces the standard holds hardest.
FIG 04. The two solid arrows are the releases where the record crosses between firms. The dashed return path is the feedback that exists today only as questions and lessons, not as data.
A gate goes before each irreversible step: issue for construction before anything is fabricated or poured, handover before the operator inherits the building.
The twelve steps
What crosses the gate, what it emits, who holds it
1 · Requirement
Design. Owner need stated as checkable rules. Emits an information requirement. Gate held by the owner.
2 · Model
Design. Geometry and attributes keyed to place. Emits the model schema and requirement. Gate held by the design lead.
3 · Test
Design. Model checked against the requirement. Emits pass or fail, per rule. Gate held by the design lead.
4 · Coordinate
Design. Issues exchanged and closed between tools. Emits the issue closed against the record. Gate held by the coordinator.
5 · Release 1: issue for construction
Release. Model, requirements and product keys cross together. Emits the release gate. Gate held by the engineer of record.
6 · Plan
Construct. Work packages keyed to place and product. Emits the package schema. Gate held by the project manager.
7 · Build
Construct. Installed work recorded against the package. Emits field capture with evidence. Gate held by the superintendent.
8 · Verify
Construct. Installed quantity checked before payment. Emits the inspection record. Gate held by the inspector.
9 · Capture
Construct. Change, request for information and decision bound to place. Emits the decision record with authority. Gate held by the project manager.
10 · Release 2: handover
Release. The asset record crosses as data, not binders. Emits the handover gate. Gate held by the owner.
11 · Run and monitor
Operate. Telemetry keyed to the same places. Emits the operating record. Gate held by the operator.
12 · Learn
Operate. Operating data fed back to the next requirement. Emits lessons as checkable rules. Gate held by the owner.
Four design rules
Four differences between code and buildings
A pour has no rollback
The gate goes before the irreversible step, not after it.
Every project has many owners
Standardize the interface, not the tool. Each firm keeps its own software.
Cycles are long
Feedback crosses projects, not sprints, and the learning unit is the portfolio.
The site is physically uncertain
Every observation carries its evidence.
The translation
The practices that changed software, one for one
Version control: one record, versioned per object.
Tests on every change: information requirements checked on every model issue.
Code review: issues exchanged between tools, then approval with authority.
Release: issue for construction; handover.
Monitoring: field capture and building telemetry.
Postmortem: questions, rework and lessons fed back to design.
What DesConOps is not: a tool, a platform or a product. It is a shape any tool can take. It is not a new standard for model data; IFC does that. It is the pipeline that joins the standards that exist across the two releases, and the four measurements that show it working.
