High-Rise Estimating: The DAG Behind Formwork, Tower Cranes & Floor-Cycle Cost

How Methvin’s Directed Acyclic Graph, Formula Engine, and Topological Recalculation Model Cost, Crane Sharing, and Sequencing in Commercial High-Rise Construction

Executive Summary

The success or failure of a commercial building project is largely determined before the first pour. A tender estimate is not simply a financial document — it is a mathematical representation of a proposed construction methodology, and the quality of that model directly shapes bid competitiveness, construction margins, resource planning, risk exposure, and commercial outcomes.

For decades, most estimating tools have been built around one limited concept: a construction item has a quantity multiplied by a rate. That approach can produce a tender price, but it does not represent the physical reality of building construction, where cost is driven by interconnected variables — formwork and falsework strategy, crane capacity shared across trades, floor cycle time, façade sequencing, trade stacking, labour productivity, and market fluctuations in steel, concrete, and glazing supply.

This paper takes a deliberately technical approach: rather than asserting that Methvin’s Estimating module is more capable, it sets out the actual computational mechanism underneath it — the formula and function layer (each formula compiled to an Abstract Syntax Tree, or AST), the variable scoping hierarchy, and a Directed Acyclic Graph (DAG) recalculation engine with cycle detection and topological traversal — and shows that mechanism operating at two scales of the same estimate: a project-planning decision (formwork and falsework strategy for a multi-storey office tower) and a granular production calculation (structural steelwork supply and erection).

The distinction this paper is built to demonstrate is a structural one, not a stylistic one: a traditional estimating system stores a rate as data. Methvin stores a rate as an expression — executable logic that references other resources, variables, and functions, and recalculates automatically when any of them change. That is the difference between a pricing database and a computational engine, and it is what the rest of this paper sets out to show mechanically, not rhetorically.