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
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.
Antonio has spent more than three decades doing this work inside manufacturing, including aerospace production. ERP and MES implementations across machine shops and production facilities, often without documentation and with the people who run the floor as the only reliable source of what the rules actually are.
Engagement boundary
A defined Manufacturing Execution System (MES), Enterprise Resource Planning (ERP), Customer Relationship Management (CRM), a CNC machining or production cell, a custom operational application, a database, or a closely related set of sources. This includes aerospace and defense manufacturing operations, where traceability, qualification, and revision control carry real weight. Not "everything we have."
A bounded area such as yield, quality, downtime, WIP, inventory, fulfillment, or customer operations: something you can actually finish.
A specific question, investigation, reporting problem, or proposed AI use case. If you can't name it, we won't start.
A typical diagnostic runs about two weeks for one system and one decision, and is fixed-fee for that written scope. Discovery is read-only where that is feasible, and there is no control path to your machines or robots during it. Larger environments can be split into more phases. A focused diagnostic is not an enterprise-wide data audit, and that limit is intentional.
Pricing is not published here. It depends on the system, the evidence access, and the scope we agree, so we put the number in writing after a first conversation rather than quoting a figure that does not match your situation.
What we clarify
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
What you actually have: the databases, tables, views, stored procedures, reports, and interfaces in scope, and who owns each one. Ends the argument about which screen is authoritative.
How the important things actually connect, including the joins that exist in application code but never in the schema. This is usually where the surprises are.
Each field in plain language: what it means, where it comes from, who owns it, and what is still unresolved. Written so an engineer and a manager read the same definition.
The rules that live in people's heads and in code nobody wants to touch: calculations, report logic, workarounds, exceptions, and the practice that makes them work.
What can be reached, what must stay restricted, who has to validate an answer, and which decisions still need a named owner before anything proceeds.
What to fix first, what can wait, and what is not worth doing at all. Sometimes the answer is that the problem is smaller than the tooling would be.
Final outputs are confirmed in a written agreement, and not every engagement needs every item on this list.
A worked example
Synthetic example, published so the shape of the work is inspectable before anyone signs anything. No real facility or machine is described here. The point is not the geometry. It is that every claim carries a confidence level and every gap is written down.
The gaps are the deliverable as much as the findings are. A record that cannot say what it does not know is not one you can govern.
This record format comes from our own cell-level work. It is the same structure we would use on your first cell, whether or not a spatial view is ever part of it.
How the work moves
Scope is written after the first conversation, not before.
Confirm the decision, scope, stakeholders, constraints, evidence, and what "useful" looks like. If that isn't written, we stop.
Review metadata, documentation, reports, logic, and relationships. Client-approved access only.
Put the schema next to how the floor actually talks, using interviews, evidence, and the places two people disagree.
Write down uncertainties, access needs, validation paths, restrictions, and whether you're ready for anything next.
Share findings, the decisions still required, and a practical next-step roadmap. Sometimes the recommendation is to wait.
Fit
A real operational system, a meaningful question, an identified owner, available experts, and a willingness to examine context before building. A single machine or production cell with real downtime or quality exposure is enough. You do not need an MES, an ERP, or a data team to start. A shop running on paper travelers, a spreadsheet, and one CAM system is a legitimate starting point.
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.
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.