← All articles

Your business data is a scrambled cube: how to prepare it for AI

October 19, 2026

Ask an AI tool which customers are about to churn and it will usually answer. The answer is often wrong in a way that is hard to spot. Your CRM has "Acme Inc", your billing system has "ACME", and the AI counts them as two customers: one healthy, one gone quiet.

Nothing was missing. Every fact the AI needed was in your tools. The facts were in the wrong places relative to each other, the way every sticker on a scrambled Rubik's cube is present and none of them line up.

TL;DR: Preparing business data for AI is not about giving a model more to read. It is about solving the cube once: matching the same customer across tools, measuring which joins actually hold, and building one connected schema that every AI tool reads. Algorithms can do most of that work, a person should approve the result, and who sees which face should be decided per person.

Animation: a scrambled Rubik's cube is solved one layer turn at a time while, beside it, coloured dots that sit on the crossings of three families of rings slide along a highlighted blue ring with each turn, until every colour is grouped together; the labels turn from "Your tools, scrambled" and "The same data, as a graph" to "One connected schema" and "Every join measured" Each turn of the cube slides one ring of stickers on the graph, until every colour sits together. Credit: The Math Flow, "Solving a Rubik's Cube with graph theory".

Why can't AI make sense of my business data?

A scrambled cube has 54 stickers and loses none of them when you twist it. Business data behaves the same way. Customers, deals, invoices, tickets and bugs all exist, spread across HubSpot, Stripe, Google Sheets, Linear and the rest. Each tool is one face: tidy on its own, with no idea what the other faces say.

The problem is not a lack of data. It is that nothing records how the pieces relate: that this HubSpot company is that Stripe customer, that this bug was reported by that account, that a column called cust_ref in one tool holds the same thing as an email domain in another. Without those relationships the model has to guess, and it guesses with confidence.

More connectors and bigger context windows show more faces, not a solved cube

The two common fixes are reasonable. Connect each tool to your AI assistant so it can look things up. Or export everything and paste it into a large context window so it can see it all at once.

Both help. A connector shows the AI one face clearly. A big context window shows it every face at once. Neither solves the cube. The AI still has to work out, on every question, which records across tools refer to the same thing, and it works that out again next time, possibly differently. That is how two AI tools end up giving two different answers to the same question about the same month, and why a bigger context window doesn't replace a data layer.

Solvers don't stare at the cube. They change the representation

A Rubik's cube has about 43 quintillion possible arrangements. Nobody solves it by looking harder. Mathematicians treat it as a graph: every arrangement is a node, every twist is an edge, and solving means finding a short path back to the solved node. Framed that way, a computer can reason about it exhaustively. In 2010, Tomas Rokicki, Herbert Kociemba, Morley Davidson and John Dethridge used this approach to prove that every position can be solved in 20 moves or fewer.

The lesson carries over. The breakthrough was not a sharper observer; it was the right representation. For a business, that representation is a schema with relationships: which tables exist, which records are the same entity, and which columns connect one tool to another.

What a solved state looks like for business data

Three algorithms do the solving, and each has a job you can define in one sentence.

Schema inference reads the structure of each source and proposes one unified set of tables, resolving naming clashes, type mismatches and duplicates. Entity matching recognises that "Acme Inc" in the CRM and "ACME" in billing are one customer, using signals the tools share such as email, domain and IDs. Join measurement tests every proposed relationship against the actual rows and reports its match rate: the share of rows on one side that find a partner on the other.

The last one matters most. A join that matches only a small fraction of rows will still produce an answer if the AI is allowed to use it, and that answer will be confident and wrong. Measuring each join is how you know which twists move you toward solved.

Three source records (a HubSpot company, a Stripe customer and a Linear issue) joined into one customers table, with domain and email-domain joins marked as strong matches and a name join at 4% marked as kept out One customer, three tools. Strong joins are used; a weak one is measured and kept out. Illustrative example, not customer data.

This is the wedge we built Synquil on. Synquil connects to the tools a team already uses with read-only access, drafts one connected schema across them, detects how tables join across sources and measures each join's match rate. Weak joins are flagged and kept out of what the query model is told. Scheduled syncs keep the solved state current, and Claude, ChatGPT, Cursor and Windsurf all read the same layer, so the same question gets the same answer whichever tool asks it. Connecting a source and getting a live schema takes about ten minutes.

A solved cube still needs locks on its faces

Solving the data creates a new risk. Once the business is one connected picture, anyone with AI access can ask across all of it. A sales rep's AI should not reach salaries just because salaries now join neatly to everything else.

So control has to come with the context. In Synquil, an admin grants each person a whole source, specific tables or specific columns, and everything else is denied by default. Ungranted data is invisible rather than refused: a person's AI only ever receives their slice of the schema, so it cannot name or infer what it was not given. Here is how the access model works. AI needs context. Businesses need control.

Where the analogy breaks

A Rubik's cube has exactly one solved state. A business has several reasonable ones. Does a trial account count as a customer? Is a refunded invoice revenue? Algorithms can propose a schema and measure the joins, but those are judgement calls about how your business works. That is why, in Synquil, the schema is a draft an admin reviews and applies, never something applied behind their back.

Some data doesn't need solving at all. If you have one spreadsheet and one person asking about it, paste it into the chat. The cube only matters once the business lives across several tools and several people want answers from it.

Three stages left to right: a scrambled cube, a state graph with a highlighted route, and a solved cube connected to Claude, ChatGPT, Cursor and Windsurf Solve it once, and every AI tool reads the result instead of re-solving the scramble on each question.

Every new AI tool and agent your team adopts will face the same scrambled cube. Solve it once, measure every join, decide who sees which face, and each new tool starts from the solved state instead of guessing.

See how Synquil builds the schema and measures relationships at synquil.com/technical.