Request-to-Baseline Workflow

Darwin’s golden path is:

request → clarify → estimate → review → approve → track → learn

This is the simplest way to understand the platform. Darwin does not only help teams create estimates. It governs how a request becomes an estimate, how an estimate becomes a baseline, and how real project costs improve future work.

1. Request

Work starts when someone asks for something to be estimated, clarified, changed, priced, reviewed, or approved.

In Darwin, this intent is captured as a work request.

A good request includes:

the desired outcome
scope context
files or drawings when available
requester and assignee
comments or missing questions

2. Clarify

Construction work rarely starts with perfect information.

Clarification is where the team adds:

drawings
scope notes
owner expectations
quantity assumptions
comments
attachments

The goal is to make the request actionable before it becomes structured estimating work.

3. Generate the Project and Estimate

Once the work request is clear, Darwin can generate a project automatically from the request information. The estimator then turns that project context into a structured estimate.

The generated project preserves the request as the origin of the work, including the scope context, files, comments, requester, assignee, and activity history that made the request actionable.

This is where Darwin brings together:

modules
materials
labor
expenses
price context
IFC/BIM or 2D QTO quantity inputs
manual quantities when needed

The estimate is not just a number. It is structured cost logic with context.

4. Review

Before commitment, the estimate should be challenged.

Review may include:

price review
quantity review
assumption review
revision comparison
estimation analysis
change requests

Review protects the team from turning incomplete or unchallenged assumptions into a baseline.

5. Approve

Approval is the moment an estimate becomes a committed cost-control baseline.

An approval decision should answer:

is this estimate accepted
who made the decision
what was approved or rejected
which estimate became the baseline
whether rework is required

A rejected decision does not create a baseline. It sends the estimate back for revision.

6. Track

Once a baseline is active, Darwin can track actual costs against it.

Cost tracking captures:

invoices
suppliers
transaction amounts
dates
notes
source links
review status

Actual costs are execution evidence connected back to the approved plan.

7. Learn

Variance explains the difference between the approved baseline and execution reality.

Variance can reveal:

price movement
quantity differences
scope changes
execution behavior
estimate logic that needs improvement
assumptions that should be reviewed next time

This is how Darwin turns completed work into organizational memory.

Key Idea

A task tells someone to act. A work request explains why work is moving. An approval commits the baseline. Variance turns real cost into learning.

Operating Discipline

The workflow is reliable only when each stage has enough evidence to move forward:

request context should explain the requested outcome, scope, files, owner, and next action before project generation
clarification should keep missing information in comments, files, or request status
generated projects should preserve their originating request, files, comments, and activity
estimation should preserve module, price, quantity, and assumption context
review issues should be resolved or converted into governed requests
approval should identify the exact estimate revision that becomes the baseline
actual costs should include source evidence such as invoices, supplier notes, or links
variance conclusions should reference the active approved baseline