Operating Model

Darwin’s workflow is:

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

The workflow explains the journey. The operating model explains how teams keep that journey reliable.

Operating Principles

Start from a work request when the reason for the work matters.
Keep project context complete enough that another user can understand what happened.
Treat tasks as action prompts, not as approval or audit records.
Keep estimate logic, prices, quantities, files, comments, and decisions traceable.
Do not treat an estimate as committed until it has an approved baseline.
Track actual costs only against the active approved baseline.
Use variance to improve future estimating logic, not only to explain overruns.

Standard Handoffs

Stage	Primary owner	Ready to hand off when
Request	Requester	Scope intent, files, requested outcome, and assignee are clear.
Clarification	Estimator	Missing information is documented in comments or files.
Project generation and estimation	Estimator	The project has been generated from clear request information, and the estimate has modules, quantities, price context, assumptions, and source files.
Review	Reviewer	Issues are resolved or converted into governed requests.
Approval	Approver	The decision is recorded and an approved baseline exists.
Cost tracking	Cost controller	Actual costs are entered, reviewed, and tied to source evidence.
Learning	Project lead or catalog owner	Variance findings are clear enough to improve modules, prices, or assumptions.

Daily Loop

At the start of a working session, check:

assigned tasks
assigned, blocked, and pending work requests
active project summaries for owned work
comments, files, activity, and approval decisions before editing estimates
cost-control projects with pending actual costs or variance review

At the end of a working session, confirm:

request status reflects current workflow state
unresolved questions are captured in comments
source files are attached to the object they explain
tasks point to the next action
major estimate changes have an activity trail, request, or review note

Quality Gates

Before estimation:

request type and status are correct
client or project context is known
required drawings or files are attached or explicitly missing
assignee and next action are clear
project generation has preserved the originating work-request context

Before review:

major scope has modules or cost items
quantities have source context
price list and rate assumptions are visible
known gaps are documented

Before approval:

review findings are resolved or explicitly accepted
selected estimation revision is clear
approval request has decision context
summaries or reports are available for approver review

Before cost tracking:

approval decision is approved
approved baseline exists
cost groups are available
cost controller can identify the active baseline

Before variance conclusions:

actual costs are reviewed
invoices or source records are attached or noted
variance is compared against the active approved baseline
follow-up actions are recorded for material findings

Object Rules

A work request explains intent: what needs to be created, clarified, reviewed, refreshed, changed, or approved.

A task tells a specific user that an action needs attention. Completing a task does not approve a project, complete a review, or create a baseline by itself.

An approval request asks someone to decide. An approval decision records approve or reject history.

An approved baseline exists only after approval. Cost tracking and variance should use the active approved baseline, not an arbitrary estimate or approval-related task.

Exception Rules

If files are missing, mark the request as waiting for information or blocked, then name the missing source in a comment.
If a request has the wrong type, correct it early or create the right request type and explain the correction.
If a task exists but the business state is wrong, update the underlying request, project, estimation, approval, or cost entry.
If an estimate is rejected, preserve the decision history and create the required revision or follow-up request.
If an approved project does not appear in cost control, confirm the decision, project approval baseline, and active baseline reference.
If an actual cost has no source evidence, keep it pending until evidence is attached or the risk is explicitly accepted.