The Data-Fracture Diagnostic

This is a seven-task prompt you paste into whatever AI assistant you already use — pointed at your own files, on your own machine. We never see any of it. It exists because the most expensive mistake in this area is buying a system to fix a problem nobody has measured.

The prompt

Replace the bracketed placeholders with your real folders and systems before running it. A generic run against nothing produces nothing.

You are running a data-fracture diagnostic on [COMPANY NAME]'s own systems, for [COMPANY
NAME]'s own use. You have file/folder access to: [LIST THE LOCAL FOLDERS / DRIVES / EXPORTS YOU CAN
POINT IT AT — e.g. a knowledge folder, a OneDrive or Google Drive, an accounting or ERP export, a
local file share].

Ground rules before you start:
- Measure, never estimate. Every finding must cite a real file path, a real file date, a real file
  count, or a real reconciled value — not a plausible-sounding guess.
- Where you cannot verify something (access denied, file unreadable, ambiguous naming), say so
  explicitly as a gap, not as a finding.
- This diagnostic is genuinely open — if the data turns out to be well-structured and current, say
  that. Do not manufacture a fracture that isn't there.

Run these seven tasks, in order, and report each one separately before moving to the next:

TASK 1 — THE JOIN TEST
Pick one real business number that should exist in more than one place (total inventory value, one
month's revenue, headcount by branch). Try to pull that same number from at least two different
systems/folders/exports. Do the two numbers match? If not, quantify the gap and identify exactly
which two sources disagree and by how much. If they cannot be compared at all (different units,
different periods, no shared key), state that as the finding — an unjoinable pair is itself the
result.

TASK 2 — THE STALENESS AUDIT
For every major data folder/source you have access to, find the single newest file's date and
compute how many days old it is as of today. Produce one table: folder/source name, newest file
date, days stale. Cover both operational categories (sales, finance, pricing) and administrative
ones (reports, meeting notes, stock counts). Flag the largest gaps — and note honestly where a gap
might reflect a normal reporting cadence rather than a broken pipeline.

TASK 3 — FORMAT/INTERVAL INVENTORY
For each department or business line that produces regular reports: what format do they send
(Excel, PDF, PowerPoint, a chat message, a form)? On what interval? Is there one standard format
company-wide, or does each department choose its own? Report as a table — department, format,
interval, standardized yes/no.

TASK 4 — MONTHLY-DECK DECOMPOSITION
If there is a large recurring report (a monthly review deck, a board pack), open the most recent
one and decompose it: how many pages? How many genuinely distinct data fields does it contain once
repeats and re-formats of the same number are collapsed? What percentage is duplicated or derived
data that did not need to be manually re-entered? This measures the assembly cost of the current
process — the human effort spent joining data that already exists, repeated every cycle.

TASK 5 — KEY-FIELD RECONCILIATION
Identify the single most-used identifying code across systems — a product/SKU code, a customer ID,
a branch code, whatever is the primary join key. Check whether it is represented identically across
every system that uses it: same format, same values, no duplicates, no drift. This is the cheapest
thing to check on this list and the most expensive thing to discover after signing a systems
contract — a mismatched key field breaks every downstream integration a vendor might build,
regardless of how good their software is.

TASK 6 — THE UNANSWERABLE-QUESTIONS LIST
List 5–10 real, ordinary business questions someone running this company should be able to answer
quickly ("what is our total parts inventory value right now, across every branch?", "which branch's
service backlog is oldest?", "what was last month's profit by business line?"). Actually try to
answer each from the data available. Report which you could answer directly, which took manual
cross-referencing, and which you genuinely could not answer at all — and why not: data does not
exist, data exists but is not joinable, or data is stale.

TASK 7 — THE VENDOR-PROPOSAL OVERLAY
If there is a vendor proposal on the table, take its stated scope — which systems and functions it
covers, which it explicitly excludes — and overlay it against everything found above. Which of the
problems you actually found would this proposal fix? Which would it leave untouched? Which of its
promised benefits depend on something you found to be broken or missing? Be genuinely even-handed:
if the proposal addresses the real constraint, say so plainly.

What to expect

Most businesses at any real scale have real fracture, and finding it precisely is more useful than a vague sense that something somewhere is disorganised. A clean result is a valid outcome too — it is just less common.

What the instrument cannot tell you is which of the fractures it finds actually matter, and which are simply how a working business looks. That judgment is the part a prompt cannot do. If you get a result and want a second opinion on it, that is a conversation we are happy to have — and it costs nothing.