Operating principle
Every model element implies a defined scope of work. Decomposing the model by trade and assembly yields a work breakdown that is generated, not authored: quantities are extracted from the model, durations are computed by applying productivity rates to those quantities, and cost is computed by applying rate data to the same quantities.
Cost, schedule and quantity cease to be three independently maintained records and become three projections of a single dataset. Payment is bound to verified completion of the generated work items. This dependency is the enforcement mechanism: keeping the model current stops being a discipline problem and becomes a precondition for payment.
Prior 5D implementations — Vico and its successors — established the same model → quantity → cost → schedule chain and did not persist, because no mechanism compelled the model to stay current. Binding payment to model state supplies that mechanism.
Operationally: a crew declares its composition, the system computes a constraint‑checked package sized to the resulting capacity, the crew accepts the commitment, and completion of that commitment drives payment. Partial completion is reported as a count against a fixed denominator — 73 of 100 items — rather than an estimated percentage.
Method basis
None of the individual methods below is original to this system; the composition is. The contribution is coupling a payment‑verification loop to the model so the underlying data maintains itself — a mechanism that requires contractual authority to mandate, not additional software.
Last Planner System Lean Construction Institute
Crews commit to what they will complete in a defined period; reliability is measured as Percent Plan Complete (PPC). The commitment is pulled by the crew, not pushed by a planner — pushed assignments show measurably lower completion reliability.
Location‑Based Management / Takt Kenley & Seppänen
Work is decomposed by location and trade, with crews flowing through defined zones in a fixed sequence, rather than the full site being worked simultaneously.
5D BIM Vico → Trimble
Established the model → quantity → cost → schedule chain. The data model was correct; the adoption model was not — no mechanism kept the model current past the issued‑for‑construction milestone.
Work‑to‑payment loop
One directional sequence, executed per work package, once per commitment cycle:
Granularity is resolved at selection time, not fixed in the schema. Leaf nodes are atomic and binary; every node above a leaf is a computed rollup. A crew may select any subtree, or any arbitrary set of leaves, as its package.
Design decisions
Nine decisions govern the system's behaviour under load. Each is stated with the failure mode it forecloses.
Granularity as a runtime parameter
One work item per model element produces hundreds of thousands of checkboxes on a mid‑size building — unusable in practice. Coarse items force percent‑complete reporting, which is subjective, defeating the purpose of payment‑on‑verification. Binary leaves with free selection yield both tractable scale and objective partial completion.
Sequence bound to assembly type, not project
A partition wall sequences identically across projects: frame, rough‑in, inspect, insulate, board, tape, prime. That knowledge is held in a template library keyed by assembly type and applied at ingest. Site logistics, procurement and inspection gates remain a human overlay; corrections to the template feed the library. Cost on the second project is a fraction of the first.
Readiness computed, not asserted
Constraint checking at selection time — predecessor, area release, inspection, material — converts the tool from a form into a planning system, and makes delay attribution auditable. A commitment missed behind an open upstream constraint is logged as a system failure, not a trade failure; this distinction must survive into performance data or the platform penalises trades for management's failures.
Proposal, not assignment
Auto‑assignment is cheaper to implement and breaks the property that makes completion data meaningful: pushed work measures estimate accuracy, pulled work measures crew reliability. These are distinct metrics and the system requires both.
Reliability and productivity, unblended
Reliability — completion against commitment (PPC). Productivity — hours per unit, measured against a crew's own trailing average, never against other crews, since scope and conditions differ enough to make cross‑crew comparison mostly noise. Combining the two into a single score destroys the information content of both and produces a metric that is trivially gamed.
Performance data for calibration, not evaluation
Framed as calibration input, subcontractors report accurately and help correct the rate model. Framed as a scorecard tied to award decisions, the same data collection produces sandbagged estimates, cherry‑picked scope, and adversarial reporting. Identical data pipeline, different framing, materially different data quality.
Rates as priors, converging to observation
Published rate data (RSMeans and equivalents) functions as a cold‑start prior — national‑average, not specific to a given crew in a given market. Every completed package with quantities and timestamps is a productivity observation; after several projects, the empirical rate outperforms any published dataset for that scope.
Rates as a function of dispersion, not quantity alone
Three doors on Level 2 and two on Level 5 do not sum to five doors' worth of labour — setup, travel and staging do not distribute linearly across scattered locations. Rates are computed as a function of quantity and spatial dispersion; naive summation understates scattered selections and erodes trust in the estimate after the first miss.
Automatic computation, approval‑gated application
Recomputing quantities, work items and schedule after a model change is deterministic and safe, and happens automatically. Determining whether previously completed work is invalidated, or applying a resulting cost delta, is a judgement call with commercial consequence, and requires an explicit approval.
Excluded from automation
Automation is scoped to clerical computation. Where a decision carries professional liability or unresolved ambiguity, the system computes the available options and stops short of deciding.
| Decision | Basis for exclusion |
|---|---|
| Whether completed work is invalidated by a model change | Judgement with high consequence — a 200mm wall shift may or may not void framing already installed |
| Application of cost changes | A commercial commitment requiring a signature, not a recalculation |
| Sealing of inferred model data | Professional liability — a seal is backed by an insurer, a computed value is not |
| Final construction sequence | Depends on tacit knowledge that is not represented in the model |
| Quality acceptance | Throughput metrics do not detect defects; speed scores well while rework surfaces downstream |
Every inferred parameter carries provenance: who or what asserted the value, and who accepted it. The system proposes; a qualified professional accepts, in bulk where review time permits. No path exists for an inferred value to reach contract status unattended.
Build status
| Component | State |
|---|---|
| Work breakdown — nested, runtime granularity | BUILT |
| Assembly sequence templates — 2 starter templates | BUILT |
| Constraint model & readiness, with attribution | BUILT |
| Crew capacity from declared composition | BUILT |
| Package proposal, sized to capacity | BUILT |
| Productivity rates — priors, observations, calibration | BUILT |
| Procore integration — REST client and tools | UNWIRED |
| IFC ingest | NOT STARTED |
| CPM scheduling | NOT STARTED |
| Field capture and verification | NOT STARTED |
Reference run — one crew, one day, three zones
The domain layer is exercised end to end by examples/drywall_day.py, which plans a single crew against a synthetic three‑zone level:
Effective capacity: 28.22h (vs 40.0h raw)
1 item(s), 13.22h of 28.22h available (47%)
10 item(s) blocked: {'other_trade': 8, 'supplier': 1, 'management': 7}
Only 47% of capacity filled. Either the crew is oversized for available work,
or upstream constraints are starving this trade.
The final line is the diagnostic output of interest, independent of the package itself: a crew idle at 47% because an area was not released is recorded as a management failure, not a poor day for the trade.
Model input requirements
Because work, cost and schedule derive from the model, a requirement that cannot be checked automatically will not be enforced, and a parameter that is not populated cannot be derived. The model specification exhibit states this constraint before a consultant opens an authoring tool. Each requirement is marked MC — machine‑checkable, validated on receipt — or RV — requiring review. A model failing any MC requirement is returned unreviewed.
Requirement categories
| Area | Governing rule | Check |
|---|---|---|
| Spatial structure | Every element resolves to exactly one storey — an unplaced element cannot be scheduled | MC |
| Classification | UniFormat II reference at type level — the join between element, spec section and cost code | MC |
| Geometry | LOD 300 minimum for scheduled categories; an omitted element reads as scope that does not exist | RV |
| Quantities | Native Qto_ base quantity sets, taken in preference to geometry recomputation | MC |
| Modelling hygiene | No in‑place families; no duplicate or overlapping geometry; no groups substituting for types | MC |
| Naming | Stable, unique type names — two names differing only cosmetically are priced twice | MC |
| Change control | Issued‑for‑construction model frozen as baseline and hashed; every revision recorded as a delta | RV |
The specification is self‑checking: run the validator against a model the intended consultant has already delivered on a prior project. If an existing model cannot pass, the specification is not yet writable and the requirement moves, not the consultant.
Prototype sequence
One trade, one building, end to end. Proven the day a crew opens the system on a Monday, plans a week against constraint‑checked work, and the resulting payment claim matches exactly what is verified complete.
Target demonstration state: three foundation walls marked complete; those three render green in the model; the claim lists those three and nothing else. Visual state and commercial state in a single view.
| Ph. | Focus | Exit gate | Principal risk |
|---|---|---|---|
| 0 | Specify input requirements; select pilot trade | Specification written; conforming test model exists | Low technical risk, high consequence if wrong |
| 1 | Model to checklist — IFC ingest, quantity extraction | Derived quantities reconcile with a manual takeoff | Highest risk in the sequence |
| 2 | Work plan against ingested project data | Superintendent confirms the generated sequence is correct | Gated on trade‑contact availability |
| 3 | Field loop — crew view, capture, model viewer | A crew plans a week without supervision | Adoption risk, not technical risk |
| 4 | Commercial close — claims, Procore write‑back | Generated claim matches manual CM approval | Low — client already built |
| 5 | Shadow pilot — real crews, conventional process in parallel | Three consecutive pay periods reconciled | Organisational, not technical |
The Phase 1 validation gate is where the premise is tested. A discrepancy between derived and manual quantities is almost always traceable to the model specification, not the ingest code — establishing that in Phase 1 is inexpensive; establishing it in Phase 5 is not.
Extension path
Direction, not commitment. Nothing in this section is scheduled or required for the platform to deliver value; it is recorded so near‑term decisions remain consistent with the longer trajectory.
The stated end state is a project executed from proposal to completion without a human in the execution loop. Each stage is an adapter around a core that does not change: what work exists, and what is owed for it.
Constraints that persist under extension
- Acceptance — detection can be automated; acceptance is a liability structure requiring a party, not a process. Required human effort approaches zero; the signature does not.
- Statutory inspection — a building department inspects under its own statutory authority. This changes with legislation, not with technology.
- Disputed matters — automating undisputed completion is the addressable win. Scope interpretation, backcharges and delay claims remain human adjudication.
On settlement: automated payment against verified completion is achievable today on existing payment rails; smart‑contract settlement is one possible implementation, not a prerequisite. It has a defensible use case on multi‑party projects with a genuine trust deficit — not where a developer is paying its own trades through an account a bank already administers. Statutory holdback and prompt‑payment rules apply regardless of settlement mechanism.