DataMosaic

Mosaic · How it works

How Mosaic finds the reason.

A comparison stops at two numbers that differ. Mosaic keeps going: it lines your systems up every night, follows each difference back to the reason, and fixes what you have already taught it to fix.

  1. 01Connect
  2. 02Understand
  3. 03Check
  4. 04Run
  5. 05Why
  6. 06Act
  7. 07Nine o'clock

01 · Connect

Connect the systems you already run.

A data source is one question put to one system: a SQL query against the tills, a REST call to the ERP, the file the warehouse drops at 02:00. Mosaic reads them where they are, from inside your network, and a data source never writes back.

Data sources

TillsOracle · receipts by store and day 48 store servers
ERPSQL Server · sales journal 1 server
WebshopREST API · orders REST
WarehouseCSV · dropped at 02:00 File
Four systems, one of them on every store's own server.

One query, every store. Where each shop runs its own till database, the query is written once and Mosaic runs it on every server — from a list, or from the hostnames on your business locations — with each row labelled by the store it came from. Open a shop in Mosaic and every check reads it.

Describe the rows, get the query. Say what you want — net sales per store and day — and Mosaic finds the tables, looks at the real values before it filters on them, writes the query and runs it. Every query it ran is listed under the answer.

Read-only, enforced. A statement that isn't a read is refused as it's typed and again on the server, and each run asks the database for a read-only session.

In the docs: Data sources · Running across many machines · A read-only login

02 · Understand

Teach it what your columns really mean.

The hard part is rarely the comparison. It is that two systems disagree about what a value means — S014 on one side and 014 on the other, or a field that was repurposed ten years ago and never renamed.

Normalise

Tills S014 014 Drop first characters · 1
Webshop 1240000 12,400.00 Multiply by · 0.01

What the column means

CUST_GENDERcustomer gender
  • RETAIL
  • WEB
  • PARTNER
  • OUTLET

MeansSales channel — read from its values, not its name

Two transforms, and one column whose name has been wrong for a decade.

Normalise makes two systems read the same way before anything is compared: trim a prefix, pad a code, turn cents into units, move a clock an hour. It changes how a value is read, never the system it came from.

Meanings. Mosaic reads every table and column it can see and proposes what each one means — from its values, not just its name. Nothing counts until somebody agrees. Once agreed, every check built afterwards uses it.

That is the knowledge that usually lives in one person's head. After a few months, Mosaic knows how your business is wired.

In the docs: Normalise

03 · Check

Build a check: what to match, what to compare.

Choose what identifies a row — store and business date — and what gets added up — net sales, receipts, tax. Mosaic groups each side the same way, lines them up, and shows every row that differs, by how much, and which side is missing it.

A check called Daily sales, POS to ERP, after its run. Five stores: ST-004, ST-011 and ST-037 match; ST-014 has 12,400 at the tills and 11,920 in the ERP, a difference of 480; ST-022 has 6,410.75 at the tills and is missing in the ERP. The footer says 2 of 2 rules failed. A check called Daily sales, POS to ERP, after its run. Five stores: ST-004, ST-011 and ST-037 match; ST-014 has 12,400 at the tills and 11,920 in the ERP, a difference of 480; ST-022 has 6,410.75 at the tills and is missing in the ERP. The footer says 2 of 2 rules failed.
Five stores. Three agree; ST-014 is 480 short in the ERP, and ST-022's day never reached it.

Rules decide whether tonight passed.

A check with no rules shows the differences. Rules let it judge them, so that at 03:00 a run can fail without anybody reading it. Each rule is four fields and nothing more.

Add Rows compared, at least 1 as well: a query that quietly returns nothing has no differences, and would pass every other rule.

What is countedMust beThresholdOn breach
Rows that differat most0Fail the run
Rows missing from a sourceat most0Fail the run

Last night, 00:452 of 2 rules failed

The two rules behind that footer.

In the docs: Aggregations · Rules · Your first check

04 · Run

Run it every night, on every store.

A trigger runs the check on a schedule, in your workspace's own time zone, and sends the result where it needs to go. Nobody has to remember to look.

Every night at 04:00 After the ERP's import has landed. Daily, weekly, monthly or every few minutes; a slot missed while the server was off runs once when it is back, not once per slot.
Only when it matters Email the result only when something differs, write an XLSX or a PDF to a share, or publish a page people can read without a login.
One problem, not five A difference that survives a run becomes an exception with an owner and a history. Out by 3 on Monday and by 3,000 on Friday is one problem getting worse.
  • Open
  • Investigating
  • Expected
  • Resolved
  • Ignored

In the docs: Triggers and schedules · Outputs · Exceptions

05 · Why

Follow a difference to its reason.

This is the step a comparison cannot take. An investigation is the runbook somebody would follow at seven in the morning, written down once: each step asks a system what it saw, a question splits the path on the answer, and it ends on a conclusion.

480

short in the ERP for ST-014

212

receipts rang at the tills

212

reached the integration layer — the whole day was delivered

2

refused by the ERP

→

A line with no tax codeT-014-0475  T-014-0480  · 480.00 between them

Steps query a system, run another check, or hand the row to a model that reads your systems with read-only queries. Questions and switches route on the answer. A conclusion ends it: answered, ruled out, or inconclusive.

On every disagreeing row. Switch it on and the investigation runs as part of the check, writing where it ended into a column at the end of the table — so the morning starts with the reason, not the difference.

Evidence, not guesses. Every answer shows the queries behind it. When the data cannot tell, the conclusion says so instead of inventing a cause.

An investigation called Why is this store short?, run on ST-014. Did the whole day reach the ERP? Delivered. Did the ERP refuse anything? It has four ways out: nothing refused, no tax code, period closed, another error. The no-tax-code branch is lit and ends on the conclusion A line with no tax code, answered. An investigation called Why is this store short?, run on ST-014. Did the whole day reach the ERP? Delivered. Did the ERP refuse anything? It has four ways out: nothing refused, no tax code, period closed, another error. The no-tax-code branch is lit and ends on the conclusion A line with no tax code, answered.
The runbook behind ST-014: delivered, refused, and the branch that lit up.

Not every row needs a runbook. A drilldown opens the records behind any row — matching or not — with one query bound to it: the receipts behind a store's total, the lines behind a receipt.

In the docs: Investigations · Agents

06 · Act

Then do something about it, before anybody has to.

A workflow is a chain of steps on a canvas. It starts when a check finishes, when somebody sends it rows from a result, on a schedule, from a webhook or a call to the API — and then does what a person would have done at nine. You build every step; it does those and nothing else, and no AI decides what changes.

A workflow called Price batch missed a store, switched on. When the price list and the tills differ, it sends the price batch again by HTTP request, runs the check again, asks Still different?, and on true emails the store manager. A workflow called Price batch missed a store, switched on. When the price list and the tills differ, it sends the price batch again by HTTP request, runs the check again, asks Still different?, and on true emails the store manager.
Send the price batch again, run the check again, and email the store manager only if it still differs.
  • Query a system
  • Run a check
  • HTTP request
  • If and switch
  • Filter, sort, sum
  • Send an email
  • Post to a channel
  • Ask a model

Every execution is kept, step by step, with what went in and what came out. On your own server a workflow can also run a script or work with files — off until whoever runs the server switches it on.

07 · Nine o'clock

At nine, the answer is waiting.

The Overview is what you open first: how many checks agree, which rows are still out, and how last night's runs went against the fortnight before. It counts what disagrees; it doesn't chart your sales.

The Overview for the last 14 days: 7 of 9 checks agreeing, 92.8% of rows matched, 6 rows out of agreement (4 differ, 2 missing, unchanged since the previous run), 98.4% of runs passed, and a chart of runs per day with two failures. The Overview for the last 14 days: 7 of 9 checks agreeing, 92.8% of rows matched, 6 rows out of agreement (4 differ, 2 missing, unchanged since the previous run), 98.4% of runs passed, and a chart of runs per day with two failures.
Seven of nine checks agree. Six rows are out, the same six as the run before.

Your board. Each workspace arranges its own tiles — a check, a workflow, a monitor, or one figure set against the period before.

Monitors answer the question before the question: is each store's server answering at all? A workflow reads the hostnames from your business locations, knocks on each one, and the monitor shows who answered.

Store servers

ST-011pos-st011.stores.internal Online
ST-014pos-st014.stores.internal Online
ST-022pos-st022.stores.internal Offline
ST-022's day never reached the ERP. Its server isn't answering either.

Build one check and see what it finds.

Every feature is free while DataMosaic is in beta.

Get started Or book a demo →