Evaluate an enterprise workflow
Define a baseline, compare candidate models on the same work and measure cost per accepted result before expanding an enterprise pilot.
An enterprise evaluation starts with the work your team needs to complete. A model benchmark helps form a shortlist. The adoption decision also depends on your data, integrations, review process and total cost.
Prepare an evaluation plan with the task, baseline, test sample, acceptance criteria and decision owner. Save an editable evaluation to continue later, download the complete team brief or carry the actual project requirements into a request you review before sending.
You can also download a blank evaluation brief. These are planning aids. Access, delivery, deployment and commercial terms are confirmed in writing.
Start from a project or workflow brief#
In Projects or a workflow example, draft the problem, volume, integrations and success criterion. Choose Prepare evaluation from this brief, or Prepare this evaluation on a workflow page, to use those answers in the planner.
Each workflow guide puts the pilot brief after its starting task. Expand Review inputs, outputs and owners for the proposed scope. The measures remain below the brief; expand Review criteria beside each measure for the reviewer’s checks. Agree these requirements and thresholds with your team before running a pilot.
The handoff preserves your public workflow and industry choices. Written requirements travel within the current browser visit and do not enter the URL. The planner identifies the brief and how many requirements were drafted. Review the carried entries and complete the baseline, test sample and decision owner. Unanswered fields and observed results remain empty.
Save the editable evaluation before leaving or refreshing the page. Following a shared planner link opens the public context and does not restore another person's written notes.
Continue an evaluation with your team#
Expand Save or reopen your evaluation, then use Save editable evaluation to keep the plan, selected catalog context, inference assumptions, baseline and pilot observations, and current stage in one file. Keep the downloaded .json file before leaving the page. The planner does not save these notes between visits automatically.
When you return, expand Save or reopen your evaluation and choose Open saved evaluation. Review the plan and observations before choosing Reopen this evaluation. Reopening replaces the draft on the page; save the current draft first to keep a separate copy. Keep current draft cancels the file review without replacing your work.
The page reads the file locally. It does not send the file to Forward or submit an inquiry. Contact details are entered separately in the reviewed contact form. Describe the process and measurement boundary rather than including original records or credentials in a planning file.
A saved file holds your entries. Calculations are recomputed when reopened, and incomplete or invalid observations still require review. Current catalog choices are checked again; unavailable choices or invalid inference assumptions are excluded and shown during file review. Saving a model choice does not confirm access or preserve a quoted price.
Use Download team brief for a readable Markdown document that combines the acceptance plan, observations, cost boundary and comparison. Unanswered items remain “To confirm.” The team brief is for reading and editing with your team; the editable .json file reopens the planner.
Define the task and baseline#
Name the people who use the result, the unit of work and the current process. Record volume, peaks and the cost or effort of doing the work today. Define what counts as an accepted result before comparing models.
| Workflow | Example unit | What to evaluate |
|---|---|---|
| Documents | A reviewed record | Required field accuracy, source traceability, exceptions and rework |
| Enterprise knowledge | An accepted answer | Correctness, authorized sources, useful references and review effort |
| Service | A completed task | Correct action, bounded access, exceptions and human handoff |
| Engineering | An accepted change | Relevant tests, correctness, review time and failed attempts |
These are scoping examples. The engagement defines integrations, controls and acceptance thresholds for your organization.
Prepare a representative evaluation set#
Include normal work, difficult cases and the exceptions that matter. Record expected outputs or a rubric so reviewers can apply the same standard. Confirm who can authorize use of the data and how access will be provided.
If you train a model, keep a held-out evaluation set separate from the training examples. Compare the baseline and trained artifact on that same set. Define how you will check both the target behavior and regressions in other required behavior.
Compare the same work#
Use the same inputs, output requirements, tool access and review rules for every candidate. Pin the model and configuration during the comparison. Record prompt/version, deployed limits, cache behavior and the rates in effect.
The model shortlist compares published capabilities and indicative token cost for the same workload. Your account's model list confirms access; the Grid deployment confirms context and modalities.
Measure quality, time and useful cost#
Record accepted results, rejected or retried results, exception rate and human rework. Measure completion time and response-time percentiles where they affect the workflow. For a tool-based task, include all calls and attempts needed to finish it.
Define the cost boundary explicitly:
cost per accepted result = total cost inside the agreed boundary / accepted results
That boundary may include model consumption, routing, tools, review effort, integration, recurring operation and reserved capacity. Separate one-time delivery costs from recurring costs. A token-only estimate measures model consumption, not the entire engagement.
When no results are accepted, report the failed evaluation rather than treating a division by zero as a useful cost. State the sample size and test period beside every result.
Review your pilot results alongside the baseline. Enter evaluated and accepted units, operating cost, human hours, cost per hour and one-time cost. The tool keeps recurring cost separate and calculates total cost per accepted result only when accepted results exist. It requires the task, sample, boundary, acceptance rule and confirmation of the same cases before showing a relative comparison.
These calculations use your observations. Pricing assumptions do not become measured results, and the test sample does not automatically become production volume. Switching between the plan and results retains your notes on the page. Save the editable evaluation before leaving to reopen both stages, or download the complete team brief for your reviewers.
Agree the next decision#
Name the owner who accepts the result. Agree the thresholds, the limited rollout scope, exception handling and the conditions for revisiting the decision. Record data, deployment, support and commercial responsibilities in the proposal.
Choose the relevant path:
- Grid for an application your team is building.
- Detection for AI-text review or prompt protection with separate operating criteria.
- Training for a model adaptation pilot.
- Connect for coding tools.
- Dedicated for a defined capacity requirement.
- Projects for a workflow we scope and deliver together.
The enterprise journey and trust review connect the evaluation with deployment and procurement requirements.