How it works — Neopiq finds the setting behind the problem, and shows its evidence

What you get back: a finding, not an opinion

A finding is one problem, on one named object, with the evidence attached and an owner to send it to. Nothing is ever reported without the reasoning that produced it — if we cannot show the working, it does not go in the report.

Every finding tells you

What is wrong — in one sentence, in planning language
Which objects — the item, the vendor, the site
The evidence — configured value, observed value, sample size, threshold crossed
What it costs you — the business consequence, stated plainly
The likely cause — why a setting usually ends up like this
What to change — the action, not a suggestion to “investigate”
Who owns it — the planner or buyer on record
Where it came from — the D365 tables and the files that were read
How sure we are — and why, with the arithmetic shown

Worked example · sample data

“Configured lead time is materially shorter than actual receipt behaviour, and there is no safety stock to absorb the difference”

Objects: item ITM-X123, vendor VEN-045. Owner: PLN-02.
Configured lead time 30 days; observed 69.88 days across 8 receipts; ratio 2.33 against a 1.40 threshold; safety stock 0.
Impact: master planning proposes supply too late by design, and nothing stands between the gap and the customer. Expect recurring shortages, expediting cost and service failures that look like supplier problems.
Action: move the item lead time towards observed receipt behaviour and add a temporary buffer until supplier performance is stable.
Confidence 0.83 — and the finding shows how that number was built.

From the synthetic sample data shipped with the free check, not from a customer. One click in the tool reproduces it exactly.

How it decides something is wrong

Three kinds of question, in increasing order of how much thinking stands between the data and the claim. The first two are facts. The third is where the money is.

1. Is it filled in?

An active planning item with no lead time, no supplier, no planner, no site, no item group, no coverage group. Directly observed, so there is nothing to argue with — only to fix.

2. Do the records agree with each other?

An item lead time that contradicts the vendor record. A coverage group or reduction key that points at something which no longer exists. A manufactured item with no route, a purchased item carrying one. An obsolete item still being forecast, and still holding stock.

3. Does the setting match reality?

Configured lead time against actual receipts. Safety stock against demand volatility and your service target. MOQ against real consumption. Forecast against real order intake. On-time delivery this half-year against last. This is the layer that explains the shortages nobody can account for.

Where we are honest with you, because you will find out anyway

Findings are hypotheses, not verdicts. A rule does not know that your coverage group means something unusual on purpose. It shows its evidence so a human can overrule it in ten seconds.
Thresholds are starting points, not truths. “At least 40% longer than configured, and at least 10 days” is a defensible default, not a fact about your business. The thresholds sit in plain rule files precisely so you can argue with them and change them.
The confidence number is judgement, not a measured probability. 0.83 does not mean 83% of such findings turn out to be real — nobody has that data yet. It is a consistent, explainable ordering of how much inference stands behind a claim.
A check we cannot run is reported, not hidden. If your export is missing the columns a rule needs, it says so. “Your extract cannot answer three of these questions” is itself useful.
Nothing is written back to D365. The whole product is read-only today, on purpose.

Where your data is while the work happens

Your item master and your vendor lead times are commercially sensitive. That is exactly why the first useful answer must not require anybody to sign anything.

The free check, today

It never leaves the machine you run it on

The check is a web page that reads your CSV files locally. There is no upload, no account, no login, no cookie, no analytics, no error reporting and no server to send anything to. Nothing is stored between runs — closing the tab is the delete button.

You do not have to believe any of that. Open your browser's network tab while it runs and watch nothing happen, or disconnect from the network before you start. The tool is built so it has no way to reach out even if it wanted to.

What IT has to approve: nothing. There is no data transfer to review.

Why we built the free thing this way

A tool that reads business data normally has to clear a security review, a procurement step and an integration project before it is allowed to say anything at all. By then the question has moved on and the shortage has already happened.

So we inverted the order. The cheapest, safest form of the analysis comes first, because nothing moves and there is nothing to approve. Only if that proves useful does anything heavier make sense — and every step after it is designed to keep as much of that property as possible.

Run it and check the network tab

How far it goes: what ships today, and where it is heading

The product is built in three steps, and they differ in one thing above all: where your data is when the work happens. Only the first step exists today. The other two are the direction of travel, described here so you can judge whether it is a direction you want to be on — not because you can buy them.

Level 0 · available today

The local check — rules and arithmetic, on your machine

Runs in the browser, on the machine you open it on. Reads your extracts, applies the rule library, produces findings with evidence. Rules and arithmetic only: no model, no guessing, no network. Same input, same output, every time.

Why it exists: to be useful to you before you owe us anything.

What it covers today

26 checks across the three layers above, over 11 D365-shaped extracts
7 kinds of comparison: missing values, missing owners, cross-table conflicts, outliers against peers, configuration against history, service KPIs getting worse, and behaviour drifting from its own past
Findings written for a planner, with impact, cause, action, owner and sources

Your data: stays where it is. Nothing is transmitted.

Open the free check

Level 1 · in development

Explanation and reporting — the local check, written up

The intended next step. The reading, the aggregation and the rule work would stay local, exactly as they are today. A cloud service would take the results — summary numbers and risk signals — and turn them into a written report, a prioritised story of what is going wrong and why, and a pattern library that improves as more organisations use it.

This does not exist yet. Nothing described here is available to buy or to try, and the boundary below is a design commitment, not a running service.

Would stay with you

Everything that identifies your business.

The extracts themselves
Item, customer, vendor and site identities
Quantities, prices and order history
All the reading and the rule work

Would be sent

Results, not records.

Summary numbers
Risk signals and scores
Which patterns fired, and how strongly

Never: your business records.

What IT would have to approve: one outbound service that receives results and no records — the questions an IT reviewer will ask about it are listed as unanswered further down this page.

Level 2 · planned

The heavy work, inside your own Azure

The long-term direction. Optimisation, simulation, process mining and supervised repair at full data volume are intended to run inside your own Azure subscription, under your own identity and access controls, with the compute billed to you by Microsoft on your existing agreement. We would orchestrate; you would own the environment the data sits in.

This is a roadmap position, not a product. No deployment, no template and no permission model exists today, and any change to your system would come after the read-only diagnosis, never instead of it.

Your data: would not move at all — the compute would come to the data.

Levels are the product. Tiers are how you buy it.

The three pricing tiers map one-to-one onto these three levels: the Free tier unlocks Level 0, the Trial tier unlocks Level 1, and the Enterprise tier unlocks Level 2. Each tier includes everything in the tier below it. Because only Level 0 exists today, only the Free tier is open today — the pricing page says exactly what that means.

The table to take into your IT review

Where the work runs, what crosses the boundary, and who carries the risk — step by step. The second and third rows describe intent, because those steps are not built.

Data movement and risk, by step. Only Level 0 exists today; the other rows state design intent for capabilities that are not built.
Step	Status	What leaves your environment	Where the work runs	What it means for you
Level 0 — the local check	Available today	Nothing	Your browser, or a small local program	Nothing to approve, nothing to sign, nothing to transfer
Level 1 — explanation and reporting	In development	Intended: summary numbers and risk signals only — never your records	Reading and rules stay local; the write-up would happen in our cloud service	One outbound service to review, with no business records in it
Level 2 — execution in your Azure	Planned	Intended: nothing — the compute comes to the data	Inside your own Azure subscription	Your identity model, your controls, your Microsoft bill for the compute

Placeholder — owner input required

[PLACEHOLDER: the concrete commitments an IT reviewer will ask for once Level 1 exists — data-processing agreement, sub-processor list, hosting region, retention period for the signals that are sent, and the exact Azure permissions Level 2 would request. None of this is decided, so none of it is claimed here.]

No certification, audit, standard or compliance badge is claimed anywhere on this site. Do not add one until it actually exists.

Getting better without pooling anybody's data

The planned learning model, in one line: we want the checks to get sharper because many organisations use them, without any organisation's records being part of what makes that happen. It is not running today, because Level 1 is not built.

What we would learn from

Which checks fire, and how often
Summary numbers and risk signals
Which findings people act on, and which they dismiss

What we would never collect

Your business records
Sensitive fields
Anything that identifies your items, customers or suppliers

What that would buy you

Thresholds tuned on evidence instead of on judgement
Fewer findings you have to dismiss
New checks for failure patterns somebody else hit first