Why build a synthetic enterprise at all?
Most demo datasets are clean.
Real companies are not.
A real enterprise has customers, employees, products, invoices, documents, warehouses and business processes — but those facts are spread across many systems that do not always agree at the same moment.
Metrolane was built to model that reality.
A company is more than rows in a database
Metrolane contains a realistic business estate:
- people
- customers
- suppliers
- products
- retail
- e-commerce
- manufacturing
- orders
- deliveries
- invoices
- payroll
- warranty claims
- documents
But the important part is not the count of records.
The important part is how those records behave across systems.
- A salesperson may know a deal as:CRM Opportunity
- Finance may later know the same commercial story as:ERP Sales Order · Customer Invoice
- Logistics may know it as:Delivery · Shipment
- Support may eventually know it as:Warranty Claim
Those records are connected by business meaning, but they are not the same database row.
One company
- SalesCRM
- Finance / OperationsERP
- ManufacturingMES
- StoresPOS
- LogisticsShipping / receiving
- PeopleHR / Payroll
- KnowledgeDocuments
- Digital commerceE-commerce
Each system sees the company from a different operational angle.
Why not make one perfect database?
Because that would remove many of the problems enterprise systems actually need to solve.
A perfect database would hide:
- different source IDs
- different status values
- different update timing
- cross-system handoffs
- duplicate identities
- integration lag
- canonical lag
- document access
- lineage
Metrolane deliberately keeps those realities visible.
One commercial story
Use the completed CRM → ERP handoff:
business handoff
This is one business story represented in two operational systems.
Synthetic does not mean arbitrary
Metrolane is synthetic because the company and records are invented.
But the architecture is intentionally realistic.
The estate is designed so that:
- business relationships make sense
- systems preserve their own semantics
- cross-system links are explicit
- canonical data has provenance
- scenarios are intentional
- the reference estate is reproducible
The goal is not to imitate one real company.
The goal is to create a controllable enterprise that behaves plausibly enough to test enterprise data, retrieval, grounding and simulation.
What makes this useful?
A realistic synthetic enterprise can support questions such as:
- Can we trace a canonical fact back to its source?
- Can we keep source identity separate from enterprise identity?
- Can an assistant answer from canonical data without silently reading source tables?
- Can document retrieval respect enterprise access?
- Can a simulator move the company forward without changing the Day-0 reference?
- Can future AI actions use the same business rules as human/system actions?
Those questions require more than sample rows.
They require architecture.
Chapter takeaway
Metrolane is a realistic synthetic enterprise.
Its value comes from preserving real enterprise complexity: multiple systems, different identities, timing differences, business handoffs, documents, provenance, and controlled inconsistency.