Twindexers: Building a Synthetic Enterprise Before Asking AI to Understand It

A lot of enterprise AI experiments start somewhere in the middle. We take a few tables, some documents, perhaps a CRM export, and then ask an LLM to search, summarize, reason or act over them.

I wanted to try the opposite direction. What if I first built the enterprise itself — synthetically — and then used that as the environment for everything that comes after?

That is the idea behind Twindexers. Metrolane AutoAccessories is the first enterprise twin. V1 is now built and publicly explorable through its Day-0 site, while I continue to extend the twin and the ideas around it.

Why make the first twin so broad?

Metrolane deliberately covers quite a lot. It manufactures some products and buys others; sells wholesale and directly to consumers; has owned stores and franchisees; and includes e-commerce, warehousing, logistics, MES, IoT, support, HR, documents, and internal as well as outsourced IT.

There is no assumption that every future twin needs to look like this. For the first one, I wanted enough variety to exercise many enterprise patterns together. Later twins can become much more focused — deeper into a particular industry, operating model or problem.

The harder part is disagreement

The interesting thing about enterprise data is not only that there is a lot of it. The systems disagree. A customer can exist twice in CRM. HR and ERP can be out of sync. A franchise store can send sales late and then resend them. Goods can move before finance catches up.

Metrolane deliberately contains situations like these rather than cleaning them away. Twelve cross-system inconsistency scenarios are seeded for that reason. If I want to test grounding, reconciliation or AI-driven action, a perfectly tidy synthetic company would actually be a poor test environment.

One command layer underneath it

The biggest implementation decision was to avoid generating plausible-looking rows directly. Every business write goes through the same command layer. The seed uses it. Tests use it. The future simulator uses it. A UI or AI tool has to use it too.

The handlers enforce authorization, business rules, transactions, audit records, events and corrections. There are currently 311 implemented handlers across the ten systems. That took much more work than generating data with SQL, but the synthetic company is not merely populated. It has rules about how things are allowed to happen.

From ten systems to a public enterprise view

Above the source systems is a canonical layer that resolves different source records into shared enterprise entities while preserving lineage. Operational links, identity resolution and relationships between different canonical entities remain separate concepts rather than being collapsed into one.

The first public slice is now the Metrolane Day-0 Explorer. It lets someone inspect the frozen enterprise rather than just read about the architecture. A public Guide sits alongside it to explain how the company, canonical layer, retrieval ideas and future simulation fit together.

Simulation is the next layer

Day-0 gives Metrolane a deliberately constructed operating state and history, but not yet an ongoing life. The next major step is a simulator that moves the company forward by calling the same business handlers on a clock, rather than manufacturing more rows.

One purchase order might arrive short, another might fail quality, another might wait for an approval that never comes. The point is not simply more data; it is causal variety over time.

Then the enterprise becomes an AI test bed

Once a synthetic organization has systems, people, transactions, inconsistencies, permissions, lineage and history, it becomes a useful place to test newer enterprise AI ideas.

Enterprise data grounding, knowledge assistants, cross-system reasoning, permission-aware Q&A, employee knowledge and action, financial-close experiments, and eventually governed AI actions all have something realistic to work against instead of a tidy demo dataset.

The first of those is already under way: Twindexers EKA, an Enterprise Knowledge Assistant that reasons across Metrolane's systems, documents, evidence and access rules.

Eventually, I want to ask the company questions

Why is this invoice blocked? Which customers were affected by that delayed shipment? What happened before this machine started showing a predictive-failure flag?

And when an answer comes back, I want to be able to ask: Where did you get that from? The architecture is being shaped so an answer can point back to its source and respect what the person asking was allowed to see.

That is still being built, but the first twin is no longer only an internal experiment. Metrolane V1 is live; Twindexers is operational and continuing to evolve.

The first version now works well enough to explore publicly. The interesting question is what happens as the twin begins to move — and as richer AI experiments are layered on top.