Why we deprecated the Accuracy Engine

In PRISM v1.0, we attempted to build an "Accuracy Simulation Engine". The premise was that we could mathematically simulate retrieval quality without making live API calls to an embedding model or vector database.

We were wrong. You cannot calculate ground-truth accuracy dynamically without executing the data payload.

The Honest Product Constraint

PRISM's core value proposition is that it is a *simulator*. It projects costs using deterministic token math, and it projects latency using rigorous Monte Carlo simulations against empirical benchmarks. When we tried to apply this same methodology to accuracy, the confidence intervals were too wide to be useful.

We had a choice: either break our fundamental architecture by introducing live API execution into the simulation loop (which destroys the safety and cost-free nature of the tool), or admit what PRISM does not know.

Enter Configuration Intelligence

Instead of hallucinating numeric accuracy scores, we built Configuration Intelligence. PRISM now scans your 9 structural node primitives and evaluates your configuration against published MTEB leaderboards and domain-specific research.

If you route financial documents into a `text-embedding-3-small` node, PRISM will flag the sub-optimal configuration, cite the latest retrieval benchmarks for the financial domain, and quantify the exact cost and latency tradeoffs of upgrading to `voyage-3` or `embed-english-v3.0`.

It provides data. The engineering team decides what to optimize.