There is a version of the custom systems story where someone looks at a founder's workflow, sees that it is manual, and says: let's automate it. The automation gets built. Some things improve. And some things — things that were working precisely because they were manual, because they required human judgment that no automation can replicate — stop working the way they should.
The Diagnosis exists to prevent this. It is the step between seeing the workflow and deciding what to do about it. And the decisions it makes are more nuanced than 'automate' or 'don't automate.'
What the Diagnosis actually determines
The Audit shows what is happening. The Diagnosis interprets what it means — and specifically, what should change and in what direction.
For each workflow area the Audit surfaces, the Diagnosis asks five questions:
- Should this be automated? Some handoffs are simple, stable, and repeated in exactly the same way. Those are strong automation candidates.
- Should this be replaced? Some tools are creating more friction than they solve. The answer is not to automate the friction — it is to replace the tool with something better fitted.
- Should this be protected? Some manual steps exist because they require genuine contextual judgment. Automating them would remove the judgment. Those should stay human.
- Should this be connected? Some workflows just need a better bridge between existing tools — not a full rebuild, not a new tool, just a defined integration.
- Should this be kept exactly as it is? Not every friction point is worth addressing. Sometimes the cost of changing something exceeds the cost of continuing to do it manually.
“The Diagnosis is what prevents building the right system in the wrong place.”
Why the Diagnosis is embedded, not standalone
The Diagnosis is embedded inside every paid Prymetheus engagement — the Knowledge Pack and every Custom Build. It is never sold as a standalone assessment because an assessment without a path forward is not useful. The Diagnosis only produces value when it leads somewhere.
In a Knowledge Pack engagement, the Diagnosis determines what knowledge needs to be structured and in what form. In a Custom Build engagement, the Diagnosis determines the exact scope of the build — which workflow to rebuild, what should be inside the scope, and what should explicitly remain outside it.
What the Diagnosis protects against
The most common failure mode in custom systems work is building the right thing in the wrong workflow area, or building the wrong thing in the right workflow area. A founder who feels friction in client communication might assume the fix is an automated response system. The Diagnosis might reveal that the real friction is in the project setup that happens before communication, and that the communication friction would resolve on its own once the upstream problem is addressed.
This is the kind of finding that prevents expensive misdirection. And it is why the Audit — where the Diagnosis begins — always comes first. You cannot diagnose a workflow you have not seen.