2. The Computational Architecture: Resources as Programmable Objects

That architecture rests on nine structural components, in the order they’re described below: a dependency-graph foundation (2.1), a formula engine for expression trees (2.2), reusable formula and resource libraries (2.3–2.4), unlimited nesting (2.5), scoped variables and WBS inheritance (2.6–2.7), dependency-ordered recalculation (2.8), and a single data model that carries from bid to delivery (2.9).

2.1 The Estimate as a Dependency Graph

A traditional system stores a rate as a number in a field. Methvin stores a rate as a node in a Directed Acyclic Graph (DAG) — the evaluated output of an expression that can reference other resources, project-level variables, global variables, and built-in functions, and that is re-evaluated automatically whenever any node it depends on changes. A stored number is data. A graph node is executable logic with defined dependencies. That distinction is the entire basis for everything else in this paper: it is the difference between a database of prices and a computational engine, and it is a structural property of how the resource is built, not a feature that sits on top of it.

Methvin’s engine enforces cycle detection at authoring time, so a resource can never be made to (directly or indirectly) reference itself — the graph stays acyclic by construction, which is what makes topological, dependency-ordered recalculation possible at all (see 2.8). Sections 2.2 through 2.9 set out how that graph is authored, populated, scoped, and recalculated.

2.2 The Formula Engine: Expression Trees, Not Static Values

Every resource in Methvin — labour, plant, material, transport, or a composite item built from other resources — can be defined as an expression rather than a static value, parsed at authoring time into an Abstract Syntax Tree (AST) rather than stored as a flat string. The expression layer is what makes the case-study formulas in Sections 3 and 4 possible; it is not a separate capability from them. Specifically, it supports:

• Arithmetic and unit-aware operators. Rates, quantities, currencies, and time carry type, so a formula combining a $/hour labour rate with an hours-per-tonne production figure resolves to a $/tonne rate without the estimator manually managing units.

• Conditional (IF / lookup) logic. Branching logic that selects between values based on a condition — this is what implements the tiered haul-rate table in Case Study A, where the effective $/t/km rate depends on which distance band the calculated average haul falls into.

• Bottleneck and aggregate functions. Functions such as MIN() and MAX() that resolve a value from the most constrained of several inputs — this is exactly the mechanism behind the daily-output formula in Case Study B, where production is governed by whichever of three constrained resources (crane lift capacity, connection crew capacity, or truck/piece cycle throughput) is lowest.

The practical consequence is that authoring an estimate in Methvin is closer to writing a small, typed program than filling in a rate card: the estimator defines relationships between resources, and the platform evaluates them, rather than the estimator computing the relationship offline and typing in the result.

2.3 Formula Libraries and Custom Functions

Beyond the native arithmetic, conditional, and bottleneck functions described in 2.2, an estimator can save any formula built for one project — a haulage-cycle calculation, a crane-lift-cycle calculation, a façade-sequencing trade-off — as a named, reusable function rather than a one-off cell. Once saved to the formula library, it is available on future projects the same way a native function like MIN() is: called by name, fed the current project’s own variables, and re-evaluated automatically as those variables change.

This is what separates a formula library from a set of saved spreadsheets. A spreadsheet template still has to be manually adapted — ranges renumbered, cell references re-pointed — for a new floor count or a different crane configuration. A named Methvin function takes its inputs as arguments, so applying the same crane-lift-cycle logic to a different tower means passing it that project’s own hook-time, hoist-speed, and piece-weight variables, not rebuilding the formula.

2.4 Resource Assembly Database and Templates

Complex, multi-trade resources don’t have to be rebuilt project by project either. A “typical floor formwork assembly,” a “curtain-wall glazing crew,” or a “Level 1–5 MEP rough-in package” can be built once — labour, plant, materials, and production formula all assembled together — and stored centrally in a resource assembly database rather than re-created inside each new estimate.

Dropping a saved assembly into a new project inherits its current central rates and formulas automatically. A project can still override a specific input locally — a different crane allocation, a regional labour rate — without breaking the link back to the central template for every other project that assembly is used on. For a commercial builder repeating floor plates, fit-out packages, and façade systems across a portfolio of towers, this is what turns an estimate built once into a rate base the whole business compounds on, rather than a one-off spreadsheet redone by the next estimator.

2.5 Unlimited Nesting: Resources Within Resources

A resource’s formula can reference any other resource, item, or variable anywhere in the project, at any nesting depth — a labour rate can sit inside a crew, the crew inside a plant-and-labour assembly, the assembly inside a composite item, and that item inside another composite item, with no limit on how many levels deep the reference chain runs. This is what allows a single labour-rate change to cascade through every composite item that consumes that labour resource, however deeply it is nested, and it is why the resource hierarchy below is a structural property of the estimate rather than a display convenience:

Structurally, a construction activity breaks down into its fundamental components — each of which is itself a node capable of holding its own formula, not a static field:

And cost becomes the evaluated output of that expression tree rather than a static lookup:

Cost = f(Resource Rates, Production, Cycle Times, Constraints, Efficiency)

The two case studies that follow show this expression tree operating at two different scales of the same estimate — with each formula referenced back to the mechanism described above, rather than presented as an isolated example.

2.6 Variable Scoping and Inheritance

A single input — diesel price, crane hire rate, labour cost — routinely feeds hundreds or thousands of formulas across a project. Methvin resolves this through a defined variable scope hierarchy:

A variable resolves to the most specific scope that defines it, and falls back up the chain when it doesn’t. In practice, this means a project-wide steel price can be set once at the top of the hierarchy and consumed by every formula beneath it, while a single job-specific override — a locked-in supply contract rate that applies to one project only — can be entered once at the project level without touching the global default or re-keying every downstream item that uses steel. Section 2.7 sets out how that same hierarchy extends to WBS-level cost rollups.

2.7 WBS Inheritance and Structural Rollups

The Work Breakdown Structure is not a reporting label laid over the estimate after the fact. A rate or variable set at a WBS branch — a floor, a zone, a trade package — is available to every item beneath it unless explicitly overridden, resolved through exactly the same scope hierarchy described in 2.6. And the relationship runs both directions: every item’s cost rolls back up through that same WBS structure into branch- and project-level totals that stay live as the underlying items change, rather than requiring a manual re-sum whenever a quantity or rate is revised.

2.8 Recalculation Logic: Topological Traversal of the Dependency DAG

Every formula reference — a resource pointing to another resource, a variable, or a function — creates a directed edge in the underlying dependency graph. Because the graph is acyclic by construction (2.1), it can always be resolved by a topological sort: every node is guaranteed to be evaluated only after every node it depends on. When an input changes, Methvin does not recalculate the entire estimate from scratch; it walks the graph outward from the changed node along that topological ordering and recalculates only the nodes that are actually downstream of the change, each one exactly once.

This is the same computational model that makes a modern spreadsheet’s recalculation tractable — except the nodes in Methvin’s graph are typed construction resources (tonnes, hours, $/m³) governed by a purpose-built formula language, rather than anonymous, untyped cells.

This is also what makes the two case studies in this paper computationally identical exercises, not two different product features. Case Study A’s tiered haul-rate lookup and Case Study B’s three-way bottleneck formula are both expressions sitting on nodes in the same dependency graph, evaluated by the same engine, at different points in the Work Breakdown Structure — one at project-planning scale, one at line-item scale.

2.9 Bid-to-Delivery: One Data Model, Not a Handoff

Because tender-stage and delivery-stage estimating sit on the same resource graph, formula engine, and WBS, a project does not convert from one data model to another at contract award. The crew structures, plant assemblies, and production formulas priced at tender — the formwork-set trade-off in Section 3, the crane-and-crew formula in Section 4 — are the same objects the delivery team inherits, not an export or a re-entry of the tender figures into a separate system. What that shared data model makes possible in practice is set out in Section 6.