"The capability works and the budget is approved. Nobody has checked whether we hold the data it needs, or whether any of it is still an advantage in three years."
Per case: which fields, at what granularity, over how much history, refreshed how often. Then whether you hold it, whether it joins, whether the lineage is traceable, and whether you are permitted to use it for this purpose. Each case gets a verdict rather than a score: ready, ready after specified work, or not viable as scoped.
Unit economics at real volume rather than at pilot scale, including the cost of clearing whatever the data check turned up. Then run it forward on the assumption the capability becomes ordinary, because margin built on a capability gap behaves differently from margin built on switching costs or proprietary data.
A stated view on how long the advantage holds and what erodes it, with the assumptions written down so they can be argued with. Then what would extend it. That is normally a data or workflow position, not a model one, and it comes with a cost.
The common finding is that the advantage is real and shorter-lived than assumed, and that the largest line in the business case is getting the data into shape. It is a less exciting answer than the market rewards, and worth having before an investor asks it for you. This is the analysis behind a no-go I recommended on a pre-IPO round, where the price assumed a lead unlikely to last the hold.
A view on whether the case holds, with the economics behind it, in a form that survives challenge from someone who would prefer a different answer.
The model stays with you and can be re-run as costs move. Inference pricing and capability both move quickly, so last year's answer will not hold.
In scope: what each use case requires and whether you hold it, the economics at real volume, how long the advantage holds, and what would extend it.
Out of scope: building the pipelines, technical audit of the models, and selecting tooling. This tells you whether to commit and at what cost; the build sits with your engineering or a vendor.
Fixed price, not a day rate. The scope is agreed up front and the price does not move with it. If the work takes longer than expected, that is my problem rather than yours, which is the right way round.
Quoted after a short call, once I understand what you are actually dealing with. Invoiced half on start and half on delivery.
Timing is agreed on the call. It depends on scope, and I would rather set it against the date you are working to than quote a standard length. There is no discovery phase, so the first useful output comes early.
Most engagements end at delivery. Some clients keep me on a light retainer afterwards to keep the model current and to be available when the board asks something new. That is agreed at the end, not the start.
Where AI does part of the work, I say which part. Some of the analysis and model building uses AI tooling. The judgement, the method and the conclusions are mine, and I will tell you which is which if you ask.