Introduction — How Darwin Thinks
Construction estimation has always relied on experience, judgment, and information scattered across tools that were never designed to communicate with each other. Drawings come from one system, quantities from another, price lists from inboxes, and the final budget must reconcile all of it manually.
Darwin was created to bring structure, consistency, and traceability to that process.
Instead of treating estimation as isolated tasks, Darwin treats it as a repeatable, data-driven workflow.
Darwin is not just an estimating tool.
It is a cost knowledge system designed to preserve, structure, and evolve an organization’s Cost DNA.
Darwin’s main workflow is:
request → clarify → estimate → review → approve → track → learn
A request for work becomes a governed estimate. The reviewed estimate becomes an approved cost-control baseline. Actual costs and variance turn execution reality into learning for future estimates.
As the manifesto states:
Construction does not lack expertise. It lacks durable memory.
To understand how Darwin works, learn the workflow first, then the core principles behind it.
The Request-to-Baseline Workflow
Section titled “The Request-to-Baseline Workflow”Darwin reflects how construction work usually begins: not as a perfect project record, but as a request, question, scope package, missing drawing, price concern, or change that needs clarification.
The workflow gives that work a clear path:
- Request — someone asks for work to be estimated, reviewed, changed, or approved.
- Clarify — the team adds drawings, files, comments, quantities, assumptions, and missing context.
- Estimate — the estimator turns the request into structured cost logic.
- Review — pricing, quantities, assumptions, and recommendations are challenged.
- Approve — the estimate becomes the committed baseline.
- Track — actual costs and invoices are recorded against the approved baseline.
- Learn — variance explains what changed and improves future estimating practice.
This is why Darwin should not be learned as a set of disconnected features. The value comes from how the workflow preserves context from the first request through execution feedback.
1. Projects Are the Center of Gravity
Section titled “1. Projects Are the Center of Gravity”Everything in Darwin happens inside a Project.
A project contains:
- work requests and clarification history
- IFC models and 2D drawings
- estimations and revisions
- modules and price lists
- documents and correspondence
- approvals, activity history, and tasks
- approved baselines and cost-control context
By bringing all of this into a single container, Darwin turns a project into a living record of how an estimate was produced.
Decisions gain context. Revisions gain lineage. Nothing gets lost in folders, spreadsheets, or email threads.
A project is not just storage — it is the foundation for reliable cost intelligence.
2. Modules Capture Construction Knowledge Once
Section titled “2. Modules Capture Construction Knowledge Once”Instead of writing line items from scratch every time, Darwin uses Modules — reusable building blocks that represent how something is constructed.
A module may include:
- materials and quantities
- labor and production rates
- expenses and overheads
- documentation
- classification (UniFormat, MasterFormat, IFC context)
Once validated, a module becomes part of your company’s Cost DNA.
Reusability ensures:
- faster estimating
- consistent assumptions
- easier onboarding
- fewer errors
Modules transform estimating from reinventing to applying knowledge.
3. Prices Change — Logic Shouldn’t
Section titled “3. Prices Change — Logic Shouldn’t”Markets move. Material costs fluctuate. Labor rates shift.
But the underlying construction logic stays the same.
Darwin separates these two worlds:
- Modules store construction logic
- Price Lists store economic conditions
This separation allows you to:
- recalculate a project instantly when prices change
- compare estimates across time or regions
- maintain consistency across teams
When the world changes, only the numbers evolve — not the knowledge behind them.
4. BIM and 2D QTO Are Fast Inputs, Not Final Truth
Section titled “4. BIM and 2D QTO Are Fast Inputs, Not Final Truth”Darwin integrates with IFC models and 2D drawings (PDF, JPG) to accelerate quantity takeoff and connect design with cost.
Importing a model or drawing allows you to:
- extract quantities
- group and classify elements
- map objects to modules
- visualize elements in 3D or annotate 2D drawings
But Darwin uses these inputs with a practical mindset:
- the model or drawing provides geometry and metadata
- Darwin provides the cost structure and traceability
The estimator’s judgment remains central.
BIM and 2D QTO are accelerators — not a replacement for cost logic.
Why This Matters
Section titled “Why This Matters”By organizing requests, estimating information, projects, modules, price lists, and imported data (IFC or 2D), Darwin creates a workflow where estimation becomes:
- reproducible — run the same logic and get the same results
- traceable — every decision has context and history
- collaborative — tasks, reviews, and documents live together
- adaptable — update prices or design inputs without rebuilding the estimate
Darwin also extends this logic beyond estimating alone.
As the platform evolves, the same structure can support:
- budget vs actual tracking
- invoice variance review
- system and subsystem cost control
- operational cost intelligence after the estimate is issued
Darwin brings structure and intelligence to construction cost decision-making, from estimate creation through cost control.