2. The Computational Architecture: A Directed Graph of Executable Logic

A rate database answers: ‘What was this item priced at previously?’ A first-principles estimating engine answers: ‘Why does this item cost what it costs, and what happens if the construction method changes?’ This section explains the precise computational mechanics that make the second question answerable. Structurally, a construction activity is modelled as a hierarchy of components:

Cost is a deterministic function evaluated from this structure, not a static lookup:

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

2.1 The Estimate as a Directed Acyclic Graph (DAG)

In Methvin, every entity—a bill item, a labour resource, a plant fleet, a variable, a formula—is a node. Every relationship—a formula referencing a variable, an item consuming a resource, a resource depending on a haul distance—is a directed edge. The entire estimate is thus a Directed Acyclic Graph (DAG), not a flat table. This structural choice confers deterministic, machine-verifiable properties:

• Single Source of Truth: A resource (e.g., ‘Diesel Price’) is a single node. Thousands of parent items can reference it without duplication.
• Impact Analysis: The engine can answer ‘what does this variable affect?’ by traversing outgoing edges of the node, returning a precise list of dependent items.
• Circular Dependency Prevention: The engine performs a cycle detection check at formula entry. If a formula creates a cycle (A depends on B, B depends on A), the engine rejects it instantly, preventing the cascading logical failures common in spreadsheets.

2.2 The Formula Engine: Abstract Syntax Trees (ASTs) Over Static Values

Any rate, quantity, or cost field can hold a formula. Internally, the formula is not stored as a string to be evaluated later; it is parsed by a lexical analyser into an Abstract Syntax Tree (AST). In an AST, each node is an operator (+, *, /), a function call (MIN(), MAX(), IF()), a variable reference, a resource reference, or a literal value. Storing the structure—rather than the evaluated result—enables:

• Deterministic Evaluation: The engine evaluates the tree depth-first.
• Automatic Re-evaluation: When an input node in the tree changes, the root node’s value is invalidated and queued for recalculation.
• Audit Trails: The estimator can inspect the exact AST of any rate, tracing every input.
• Syntax Validation: The engine validates the formula at entry, catching broken references immediately.

2.3 Formula Libraries and Custom Functions (JavaScript Engine)

The formula engine exposes a native library of construction-domain functions: production-rate lookups, haul-cycle calculations, unit conversions, escalation and indexing, and conditional logic. Critically, because the engine is built on a scriptable foundation, a firm can write its own proprietary custom functions (e.g., TIERED_HAUL_COST(distance, volume), or REGIONAL_ESCALATION(month, region)).

These custom functions are compiled and stored in the library. Once saved, they are callable from any resource formula across any project, just like a native function. This eliminates the need to rebuild corporate intellectual property inside every new spreadsheet tab.

2.4 Resource Assembly Database and Unlimited Nesting

Complex resources—labour crews, plant fleets, material-plus-transport bundles—are stored as assemblies in a central database. An assembly is itself a tree: a ‘Pavement Installation Crew’ nests individual labour resources, each carrying its own rate and productivity formula.

There is no fixed nesting depth. A bill item can contain an assembly, which contains a sub-assembly, which contains individual resources, each with its own formula referencing global variables. This recursive structure ensures that a change at the deepest leaf (e.g., a grader operator’s hourly rate) propagates up through the assembly tree to the top-level Bill of Quantities rate.

2.5 Variable Scoping and Inheritance

Variables resolve through a strict hierarchy: Global → Project → WBS Branch → Item/Resource. A formula referencing a variable performs an upward traversal of this chain until it finds a defined value.

• Global: Company-wide default diesel price.
• Project: Override for a specific project with a fixed-price fuel supply agreement.
• WBS: Override for a specific haul-heavy zone requiring a special bulk discount.
• Item: Override for a single critical item.

2.6 Dependency-Ordered Recalculation (Topological Traversal)

When an input changes, the engine does not perform a full-model rebuild. Instead, it performs a topological sort on the sub-graph rooted at the changed node. It generates a recalculation order where every node is processed only after all its dependencies have been processed.

The algorithm is:

1. Identify the changed node(s).
2. Traverse the DAG to identify all downstream nodes (reachable via outgoing edges).
3. Perform a topological sort on this sub-graph.
4. Re-evaluate nodes in strict order, updating only the affected items.
5. Push the updated values to the UI.

A diesel price update that touches thousands of line items resolves as a single, deterministic graph traversal, completing in milliseconds for an enterprise-scale estimate.

2.7 WBS Inheritance and Structural Rollups

The Work Breakdown Structure is not a passive label. Cost, quantity, and formula context flow down it. A variable set at a WBS branch flows to every item beneath it. Conversely, every item’s cost rolls back up to the branch totals. These rollups are live references, not static sums. If a leaf node changes, the branch total updates instantly via the same dependency graph.

2.8 Bid-to-Delivery: A Single, Shared Data Model

Because tender-stage and delivery-stage estimating sit on the same graph, formula engine, and WBS, there is no ‘data conversion’ at contract award. The crew structures, plant assumptions, and production formulas priced at tender are the exact objects the delivery team inherits. This enables mathematical variation analysis, rather than a renegotiation from a blank page.