Site, API, Auth & Admin

Darwin’s four main pillars each have a different responsibility.

They should be understood by what they do for the request-to-baseline workflow, not only by their repository names.

Darwin.Site

The operational workspace where users move work forward.

Users use Darwin.Site to:

• create and clarify work requests
• generate projects automatically from accepted work-request information
• build estimations from modules, prices, and quantities
• import or measure IFC and 2D QTO inputs
• manage files, comments, tasks, and activity history
• request price review, change, alternate, or approval workflows
• record approval or rejection decisions
• track actual costs and review variance against the active approved baseline

Darwin.API

The backend domain engine that preserves Darwin’s business logic and records.

It owns the business state for:

• projects and estimations
• work requests and tasks
• modules, price lists, and provenance
• approval decisions and project approval baselines
• active baseline selection
• actual costs, invoices, and variance data

This separation is important because a task is only an action signal, a work request is intent, an approval decision records approve or reject history, and an approved baseline is the committed reference for cost control.

Darwin.Auth

The identity service that manages authentication, invitations, password recovery, and instance-aware access.

Darwin.Auth makes sure users enter the right tenant context before they reach operational work.

Darwin.Admin

The governance console for users, instances, assignments, invitations, and instance-owner operations.

Darwin.Admin does not create estimates directly. It protects the operating conditions that make requests, approvals, cost-control actions, and audit history trustworthy.

Why The Separation Matters

This separation allows Darwin to scale as a platform:

• product workflows stay distinct from platform governance
• tenant access stays explicit
• domain logic stays centralized
• education and onboarding can evolve separately

For users, the practical meaning is simple: do the work in Darwin.Site, trust Darwin.API as the record of business state, enter through Darwin.Auth, and administer access and instance governance through Darwin.Admin.