System
A defined Manufacturing Execution System (MES), Enterprise Resource Planning (ERP), Customer Relationship Management (CRM), custom operational application, database, or a closely related set of sources. Not "everything we have."
Prime Diagnostics
Write the system down before you build on it.
The boundary is deliberate: one system, one domain, and one decision. Once the context is written, AI and analytics have something people can actually inspect and challenge.
Why it exists
A roadmap is hard to trust if nobody agrees what the reports mean.
Most teams already know their data is messy. What's missing is a shared written view: which sources matter, how metrics get calculated, where exceptions live, who owns the definitions.
Prime Diagnostics turns those unknowns into findings, open questions, and decisions before a larger build starts, not after you've already bought the model.
- Sources Systems, reports, and interfaces behind one decision, including the ones that don't agree
- Meaning Rules, exceptions, and definitions, written down rather than assumed
- Ownership Who validates answers, and what stays restricted until review
Engagement boundary
One system. One domain. One decision.
Domain
A bounded area such as yield, quality, downtime, WIP, inventory, fulfillment, or customer operations: something you can actually finish.
Decision
A specific question, investigation, reporting problem, or proposed AI use case. If you can't name it, we won't start.
Larger environments can be split into more phases. A focused diagnostic is not an enterprise-wide data audit, and that limit is intentional.
What we clarify
Questions we won't leave fuzzy
Six anchors under one written scope, with no guessing what "done" looks like.
Which systems and data objects actually matter for this decision?
Where do the important relationships, calculations, and exceptions hide?
Which definitions look settled, and which still need an owner?
Which data surfaces look appropriate for further evaluation?
What should stay restricted until legal, privacy, security, or owner review?
What would a credible pilot or next phase actually require?
Possible outputs
Working materials you can use, not a generic strategy deck.
System inventory
In-scope databases, tables, views, procedures, reports, interfaces, and who owns what.
Priority relationship map
How the important entities, data flows, and boundaries actually connect, including the links that aren't formal foreign keys.
Operational data dictionary
Business meaning, source, ownership, sensitivity, relationships, and the questions still sitting open.
Business-logic register
Calculations, report rules, application quirks, and the expert practices documented during the work.
Readiness findings
Access paths, validation duties, restrictions, assumptions, and decisions that still need an owner.
Prioritized roadmap
What to resolve first, what can move, and what should wait, including when waiting is the right call.
Final outputs are confirmed in a written agreement, and not every engagement needs every item on this list.
How the work moves
How the weeks usually feel.
Scope is written after the first conversation, not before.
-
Align
Confirm the decision, scope, stakeholders, constraints, evidence, and what "useful" looks like. If that isn't written, we stop.
-
Examine
Review metadata, documentation, reports, logic, and relationships. Client-approved access only.
-
Interpret
Put the schema next to how the floor actually talks, using interviews, evidence, and the places two people disagree.
-
Assess
Write down uncertainties, access needs, validation paths, restrictions, and whether you're ready for anything next.
-
Recommend
Share findings, the decisions still required, and a practical next-step roadmap. Sometimes the recommendation is to wait.
Fit
Who this is for, and who it isn't.
Strong fit
A real operational system, a meaningful question, an identified owner, available experts, and a willingness to examine context before building.
Probably not a fit
A generic marketing chatbot, a consumer app, a rapid demo without access controls, or work with no system owner and no operational question. We'll say no.
Our recommendations do not replace review by the client’s legal, privacy, security, compliance, data-owner, system-owner, or executive functions. Final access and deployment decisions remain with the client.
Bring us the system and the question.
A short first conversation usually tells us three things: whether a focused diagnostic fits, what information we'd need, and whether we're the right partner for it.