The purpose of a matched-workload pilot is narrow: compare the candidate engine against your current baseline on the same universe, constraints, timing protocol, and quality thresholds. Anything else becomes sales theater quickly.

Figure 1: Pilot evidence pack

InputsUniverse, risk model, lots, restrictions, and target portfolio.
BaselineCurrent solver timing, outputs, and known failure modes.
PRISM runCPU/GPU/refinement routing under the same workload.
DecisionLatency, quality gap, pass rate, audit fit, and integration cost.

Define representative workloads first

Pick a small set of cases that reflect production: a normal rebalance, a transition, a tax-aware scenario, and a stress case. Include data preparation, solve, verification, and output formatting in the timing window.

PRISM is strongest when the pilot is honest. Its GPU-native path should be compared on workloads where asset scale, scenario count, or account batch size actually matters. Smaller workflows can still benefit from the routed stack, but the evaluation should not hide the workload class.

Measure operational behavior

Runtime matters, but so do failure modes. The pilot should record solve failures, infeasible requests, constraint violations, quality gaps, audit artifacts, and replay behavior. Silent failure is more dangerous than a loud failed solve.

Figure 2: Acceptance criteria to agree before testing

LatencyMaximum p50 and p95 timing by workflow.
QualityAcceptable objective gap and constraint pass rate.
AuditReplayable run record and deterministic output fields.

Decide before seeing results

Before the pilot starts, write down the acceptance criteria: maximum runtime, acceptable quality gap, required constraint pass rate, integration requirements, and deployment boundaries. This prevents the evaluation from drifting after the numbers arrive.

Practical next step: turn one existing production rebalance into a pilot fixture with anonymized inputs, expected outputs, and baseline timings.