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. Twindexers is the broader experiment; Metrolane AutoAccessories is the first enterprise twin I am using to work out whether the idea actually holds together.

Why make the first twin so broad?

Metrolane is deliberately trying to cover quite a lot. It manufactures some products and buys others. It sells wholesale and directly to consumers. It has owned stores and franchisees, e-commerce, warehousing and logistics, a manufacturing floor with MES, IoT telemetry, support operations, HR, documents, and both internal and outsourced IT.

There is no assumption that every future twin needs to look like this. For the first one, I wanted something broad enough to exercise many kinds of enterprise behaviour in one place. If the underlying approach works, later twins can become much more focused — deeper into a particular industry, operating model or problem.

The harder part is disagreement

The most interesting thing about enterprise data is not that there is a lot of it. It is that 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. An employee can leave while access somewhere else remains active.

Metrolane deliberately contains situations like these rather than cleaning them away. Twelve cross-system inconsistency scenarios are already named and seeded for exactly that reason.

If I eventually want to test enterprise grounding, reconciliation, assistants 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 so far 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 will use it. A future UI or AI tool must use it too.

Those command handlers enforce authorization, business rules, transactions, audit records, events and corrections. There are currently 311 implemented handlers across the ten systems.

That took considerably more work than generating data with SQL. But it means the synthetic company is not merely populated. It has rules about how things are allowed to happen.

From ten systems to one enterprise view

Above the source systems is a canonical layer that resolves different source records into shared enterprise entities while preserving lineage.

One distinction I particularly wanted to keep clear is that these are not the same thing:

• two systems operationally linking records,
• two records representing the same real-world entity,
• and two different real-world entities simply being related.

Metrolane keeps those concepts separate, and canonical values retain where they came from and which rule caused them to survive when sources disagreed.

There is already a read-only Explorer where I can move from a source record to its connector payload, canonical entity and field-level provenance.

Simulation is only one direction

Metrolane already has a deliberately constructed operating history, but it does not yet have 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 generating more rows. One purchase order might arrive short, another might fail quality, another might wait indefinitely for approval.

That makes simulation one obvious use of Twindexers. But it is not the only reason I am building it.

A place to test enterprise AI

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

Enterprise data grounding, knowledge assistants, cross-system reasoning, permission-aware Q&A, employee knowledge and action, financial-close experiments, and AI tools or agents that can eventually act through governed business operations all need something realistic to work against.

The project already has enterprise data grounding, employee knowledge and action, and financial close explicitly in view as downstream uses.

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 already being shaped so that an answer can point back to its source and respect what the person asking was allowed to see. That part is still ahead.

For now, Twindexers is an experiment in building the substrate first. Metrolane is the first twin, deliberately broad and still evolving. If it works, I want to see what kinds of synthetic enterprises — and what kinds of AI experiments — become possible next.