Assayer works in a space that does not have a settled name yet, so most first conversations start with the same handful of questions. Here they are, answered directly.
Assayer tests reported progress against the evidence in your own systems of record.
It reads the signals your systems already produce, builds a live model of how work, dependencies, decisions, ownership, and outcomes actually connect in your company, and keeps learning as they change. Then it does the part nobody else does: it checks whether the status you were told is actually supported by that evidence.
You see reported next to supported, how strongly the evidence holds, and the reasons why.
Reported is what was entered. A milestone marked complete. A green status. A date typed into a plan.
Supported is what the evidence across your systems actually backs up.
Assayer does not take a reported status at face value. It looks for corroborating and contradicting evidence in the systems that would have to agree if the status were true. When they agree, you get confirmation you can defend. When they do not, you get the gap and the reasons for it, before it reaches a decision.
Most tools show you the report. Assayer cross-examines it.
No. They answer a different question.
Dashboards, project management tools, BI layers, and the AI assistants now sitting on top of them all display what was entered. They aggregate it, visualize it, and summarize it faster than any person could. None of them checks whether what was entered holds up.
Assayer sits above those tools and does exactly that. It is not a system of record and has no interest in replacing the ones your teams already use.
Because your reporting answers a different question.
Everything in your reporting stack takes the data in your systems as given. If the underlying status is wrong, it will present the wrong status beautifully, and an AI assistant will summarize it confidently.
Assayer does not start from the data. It starts from the signals: a date that moved twice, an approval that came in late, an assignment quietly changed, a dependency nobody re-confirmed. Signals carry context that a field value does not, and not all of them count the same. A system of record and a status update are not equal witnesses, and Assayer does not treat them as if they were. What comes out is how strongly the evidence supports each reported status, with the reasons.
The failure that costs you money is not that the report was slow or hard to read. It is that the report was believed. Assayer is the layer that checks whether it should have been.
No. Assayer sits above whatever you already run. There is no migration, no standardization program, and nothing to rip out.
This is deliberate. The problem is not that you picked the wrong systems. It is that no layer above them reconciles what they are collectively telling you. Replacing the stack would recreate the same blind spot on newer tools.
Read access to the systems that carry execution evidence. Typically that means your ERP, MES, PLM, and the project and planning tools your teams work in day to day.
The exact list gets scoped before anything is connected, and it is usually narrower than people expect. We are looking for the signals that show whether a reported status is supported, not a full copy of your enterprise.
Assayer reads. It does not write back into your systems and it does not change records in them.
Access is also a genuine constraint rather than a formality. Assayer always shows you how much of the picture it can see alongside what it found in it, so a source that security, ownership, or an API limit keeps out shows up as a gap you can name, not as silence that looks like good news. We would rather establish that during scoping than discover it later.
That is the normal case, and it is the case Assayer is built for.
When two sources disagree, Assayer does not quietly pick one. It shows the disagreement, the evidence on each side, and who needs to resolve it. When a source is missing or stale, that shows up as a gap, and the gap counts against how strongly the reported status is supported. A missing signal stays unknown; it does not silently become green.
Nothing in Assayer requires your data to be clean or centralized first. Waiting for that usually delays the work without fixing the problem, and the inconsistencies themselves are part of what you are trying to see.
That is the point, and it is worth being direct about what it means in practice.
Assayer is not built to grade people. A gap between reported and supported is almost never anyone acting in bad faith. Far more often it is the predictable result of a large organization where a status was accurate in one system, on one day, at one level, and nothing above it reconciled that against everything else. Locally correct, globally wrong.
So the output is not a list of who got it wrong. It is the gap, the evidence behind it, and the reason it opened, routed to the people who can act on it before it reaches a decision.
It is equally important what Assayer does not do. It does not declare a status false and it does not make the call. It shows what is supported, what is not, and why. A person decides. Human judgment stays in charge.
It fits organizations running execution across three or more systems of record, where work crosses functions that do not share a view of it, and where no single person owns the whole picture. The sponsor is an operator: a COO, a VP of Operations, a head of PMO, a transformation leader. Our initial focus is manufacturers with engineered products, because that is where we have run execution ourselves. The problem is not unique to manufacturing, and we will say so when we have earned the right to.
It is a poor fit if you run execution in a single system, if what you actually want is a better dashboard, or if you are hoping AI will resolve an organizational problem on its own. It also will not work without an executive sponsor, because the findings cross functional boundaries and need someone with the authority to act on them.
Every engagement starts with an Execution Architecture Assessment: a fixed-fee engagement scoped around one consequential decision you have to make. It produces a structured view of how execution actually works across your systems of record, where reported and supported diverge, and what to do about it. It stands on its own whether or not you ever deploy the platform.
The platform that follows is an annual subscription. Its scope and price come out of what the assessment finds, so we will give you a number once we understand your environment rather than publish a range that fits nobody.