One task. Two credible paths.
Define a completed task and the policy for accepting it. Record a dated production setup and a reasonably optimised API alternative. Document prompting, caching, retrieval and routing checks. Keep model versions, prompt revisions, retrieval configuration, evaluation dates, pricing dates and p95 latency with the record.
Protect the test before the experiment.
Separate training, validation and protected holdout. Choose source-group and temporal rules for the claim you need to evaluate. Holdout control belongs to the buyer or an independent evaluator. Metadata checks can identify exact overlaps; they cannot establish semantic independence, legal rights or overall label quality.
Measure the whole task.
Extraction acceptance is not average field accuracy. Support resolution must include unsupported and unsafe response checks. Inspect meaningful customer slices and rejected cases. For actual observations, report sample sizes and justified uncertainty tied to the sampling design. This demo’s plotted data is synthetic, so confidence intervals would imply evidence that does not exist.
Count accepted completions once.
Recurring cost per accepted task equals all monthly recurring costs divided by final accepted completed tasks. Retries add inference expense but do not increase the task denominator. Reviewed tasks count once under the final policy. The calculator uses either direct billed inference or token-derived inference, never both. Direct bills must include retries.
Investment is kept separate. Cash payback is derived from cumulative monthly savings, with growth and peak-month assumptions. Hosting is a simplified capacity-step model using entered utilisation. Hybrid volume branches are disjoint and shared capacity remains included. Financing, discounting, taxes and cross-branch escalation are excluded; add these to a bespoke financial review when relevant.
Separate the intervention from its owner.
The decision guide tests baseline maturity, dominant failures and freshness before assigning a delivery route. Fresh information suggests a retrieval experiment; stable format failures may support adaptation after a prompt baseline; expensive exceptions may support routing. Adequate quality and cost can justify retaining the API.
| route | scoring |
|---|---|
| Tool | 2 standard deployment + 2 managed fit + 1 funded urgency |
| Build | 3 dedicated ML capacity + 2 deployment competence + 2 named maintenance owner |
| Expert | 2 capacity gap + 2 private deployment + 2 independent evaluation need + 1 funded urgency |
These scores are heuristics. Ties remain alternatives. No data rights, no accountable owner or no evaluation plan blocks commissioning regardless of score. The proposal scorecard uses user-entered evidence weights; unresolved hard gates exclude a candidate from a positive selection.
Evidence labels
| label | meaning |
|---|---|
| User-supplied | Entered by the visitor; not independently checked. |
| Document-backed | A source reference is supplied; its contents still require validation. |
| Assumed | A planning input or synthetic fixture, not observation. |
| Inferred | A deterministic calculation or rule output from the supplied inputs. |
| Unknown | Evidence is missing. Never substituted with zero. |
Published research and our interpretation
The flagship analysis synthesises seven selected primary studies. Each study entry identifies the authors, date, source version, experimental setting, reported finding and limits. Published results are attributed to their authors; Frontier Development has not independently rerun those experiments.
Our synthesis, proposed experiments and decision guides are labelled as interpretation or frameworks. Tool defaults remain synthetic examples. A source supports the specific claim next to it, not every recommendation on the page.
The reading set is bounded, not a systematic review or a current model ranking. No named external technical reviewer is recorded for this edition. Edition 1.0 was published on 16 October 2026; the existing decision guides were updated to edition 1.1 with claim-level source notes.
Inspect the evidence register →Sources and review boundary
Primary references accessed 16 October 2026. They support general evaluation and documentation concepts; no source endorses Frontier Development. Product scope and prices must be checked at the time of procurement.
- Model optimisation — OpenAI ↗
- Optimising LLM accuracy — OpenAI ↗
- Cross-validation and grouped splits — scikit-learn ↗
- Evaluation best practices — OpenAI ↗
- Model cards — Hugging Face ↗
- AI Risk Management Framework — NIST ↗
Corrections
Use the local contact-request preview to describe the page, claim, supporting source and proposed correction. This demo does not send that request; a real contact destination must be connected before launch.
Prepare a correction request →