What Evidence Should Founders Request Before Funding AI?

The demo is usually the easiest part of an AI workflow to show. A founder needs evidence about the work around it: what happens on representative inputs, where people still intervene, what a completed task costs, and what happens when the system is wrong.

The useful question is not “did the model produce a good answer?” It is “does this bounded workflow improve a defined outcome enough to justify its cost and risk?”

Start with a packet that ends in a decision

Ask for one evidence packet that connects the current process, the proposed workflow, its failure modes, and a predeclared funding call. A slide deck of model examples is not enough. The packet should let another reviewer trace each important claim back to an input, output, calculation, or control.

This is the reusable decision artifact in this article:

Packet block	What the owner must show	What the founder decides
Baseline	The business-as-usual process, outcome, time, and material constraints	Is there a real problem to fund?
Representative task set	Versioned cases that cover ordinary work and known exceptions	Does the evaluation resemble the work that matters?
End-to-end outcome	The workflow result, not only a model score or isolated step	Does the proposed system complete the job?
Human work and cost	Review, correction, escalation, tool, model, and operating costs	Does the economics survive contact with real operations?
Safeguards and fallback	Permissions, privacy, failure handling, abstention, and human ownership	Can a failure stay bounded?
Thresholded decision	Pass conditions, vetoes, unknowns, owner, and next stage	Fund, revise, pilot, or stop?

NIST describes the AI Risk Management Framework as a way to incorporate trustworthiness into the design, development, use, and evaluation of AI systems. Its TEVV-Athlon draft likewise frames evaluation as evidence that a system meets organizational goals while minimizing negative impacts. Those sources support the shape of the packet. They do not supply evidence about your workflow. (NIST AI RMF, NIST TEVV-Athlon)

Define the baseline and the outcome before testing

Write down what happens without the AI workflow before interpreting any improvement. The baseline can be a business-as-usual process, a justified proxy, or a comparison group. It cannot be an unexamined assumption that “manual is slow” or that the demo is better.

For the baseline, request:

• the unit of work, trigger, input, output, and owner;
• the current completion rule, including what counts as rework;
• the time, cost, quality, and escalation measures that matter for this decision;
• the period and conditions represented by the observation;
• the constraints that make the current process difficult to compare with the proposed one.

The target outcome must use the same unit of work. If the workflow drafts a support response, measure the completed support task, not only the draft’s language quality. If it extracts fields, measure usable records after review and correction. If it recommends an action, measure the human decision and its consequences.

The UK government’s guidance on evaluating AI interventions says a baseline describes the situation before rollout and that business-as-usual should be documented precisely when it is the comparison. It also calls for attention to unintended outcomes, variation across groups, efficiency, accuracy, quality, and value for money. (GOV.UK impact evaluation guidance)

The exception is a genuinely new workflow with no historical process. In that case, request a justified proxy and mark the uncertainty in the decision. A proxy can justify a bounded learning stage. It should not be presented as proof of production value.

Test representative tasks from trigger to completion

Request a versioned task set and the complete workflow trace for each case. A few polished examples can show that the happy path exists. They cannot show how often the system needs correction, whether a tool call changes the result, or whether an exception escapes the review boundary.

Each task record should include:

1. The input and its provenance, with sensitive data handled appropriately.
2. The task version, workflow version, model or configuration, and test date.
3. The expected completion condition and the reviewer rubric.
4. The raw output, tool results, retries, abstentions, and human edits.
5. The final workflow outcome and failure classification.

Keep ordinary cases, boundary cases, and cases where the correct action is to ask for help or abstain. The task set does not need to be large by default. It needs to be defensible for the decision: a founder should know why these cases represent the work and what they leave out.

NIST’s TEVV-Athlon description emphasizes assessments customized to organizational objectives and built from events, tools, and measurement blocks. That maps well to a workflow trace: the input event, tool actions, output, human intervention, and outcome should remain connected. (NIST TEVV-Athlon)

Do not let a high model score hide an incomplete workflow. A classifier can label a case correctly while the integration writes to the wrong record. A drafting step can look accurate while review takes longer than the original work. The funding unit is the completed job.

Include human work in the economics

Ask for total cost per completed unit, including the work the model does not remove. The calculation should separate measured inputs from assumptions:

total unit cost = model and tool usage
                + storage and infrastructure
                + human review and correction
                + escalation and exception handling
                + monitoring and maintenance

Use actual usage or clearly marked estimates for each term. Record the unit of work, billing period, volume assumption, reviewer time, correction time, and escalation rate. If a vendor price or model version can change, include the date and source of the assumption.

This is where a workflow can look attractive and still fail the funding test. If every output needs a careful rewrite, the system may have changed the location of work rather than removed it. If an agent needs a person to approve every external action, that approval is part of the operating design and cost.

For a deeper economics worksheet, compare this packet with how to calculate ROI for an AI agent. The two jobs are related but different: ROI frames value, while this packet checks whether the workflow evidence is strong enough to trust the inputs to that calculation.

Latency also belongs in the packet when the workflow is interactive or time-sensitive. AWS recommends release criteria that cover expected benefits and potential harms, with factors such as usability performance, latency, uptime, safety, controllability, security, privacy, reliability, fairness, veracity, explainability, and transparency where relevant. (AWS Responsible AI release criteria)

The exception is a discovery stage where the purpose is learning, not claiming operating savings. Label that stage honestly. A discovery budget can be approved because it answers a valuable question. It is not evidence that the finished workflow has acceptable unit economics.

Treat permissions and fallback as veto conditions

Request a risk and control section that states what the workflow may do, what it may never do, and who owns the decision when it cannot proceed safely. Review the workflow’s permissions, data exposure, external actions, audit trail, human approval points, fallback behavior, and recovery path.

Make the following checks explicit:

Check	Pass condition	Veto or revision trigger
Permissions	Every tool and data access matches the smallest necessary scope	The workflow can take an unapproved external action
Sensitive data	Collection, retention, and access have named owners and controls	The packet cannot explain where sensitive data goes
Uncertainty	The workflow can abstain or escalate when evidence is insufficient	It presents a guess as a completed decision
Failure recovery	A failed step is visible, bounded, and recoverable	A retry can duplicate or conceal a material action
Human ownership	A named person owns approval for consequential actions	Nobody owns the final decision

AWS defines a release criterion as a binary test with a quantitative assessment and a decision threshold, then treats the release decision as an aggregation of those individual criteria. The exact thresholds depend on the workflow. The useful discipline is to write them before the funding call, record the measurement, and preserve the result. (AWS release criteria)

NIST’s AI RMF is voluntary guidance, not a substitute for a product-specific control review. Use it to ask what trustworthiness concerns belong in the packet, then assign owners and evidence for the concerns that matter in this workflow. (NIST AI RMF)

Apply the worked funding table

Use this table as a worked logic example. The statuses are deliberately evidence states, not results from a real workflow. Replace them with the packet’s observed records and predeclared thresholds.

Packet state	Decision effect	Funding call
Baseline and target are defined; representative tasks and end-to-end traces are attached	The question is testable	Continue review
Human effort or unit cost is missing	The value claim cannot be checked	Revise the packet; do not fund rollout
A critical permission, privacy, or external-action veto fails	The downside is not bounded	Stop or redesign before funding
Outcomes meet the target; economics meet the agreed budget; controls pass; remaining unknowns are named	The bounded next stage has evidence and a controlled risk profile	Fund the next stage, with a review date
Evidence is incomplete but the learning question is narrow and reversible	The case is for learning, not rollout	Fund a time-boxed pilot only

The table produces four useful calls:

• Fund: the target outcome, economics, controls, and decision thresholds pass.
• Revise: a material evidence block is incomplete, so the next action is to close that gap.
• Pilot: the question is worth answering, but the workflow is still bounded, reversible, or uncertain.
• Stop: a veto fails, the comparison is invalid, or the proposed outcome does not justify the cost and risk.

Do not average away a veto. A strong quality result does not compensate for an unapproved permission. A low operating cost does not compensate for an unowned consequential decision. The table is useful because it keeps those failure types visible instead of hiding them inside one score.

Use a seven-step funding procedure

Run the packet through this procedure before asking for a larger budget:

1. Name one investment decision. State the workflow, the next stage, the target outcome, and the owner of the call.
2. Write the baseline. Describe the current process and define the unit of work, completion, quality, time, and cost.
3. Lock the task set. Version representative ordinary, boundary, and abstention cases before reviewing the outputs.
4. Trace the whole workflow. Preserve raw inputs, outputs, tool actions, retries, human edits, escalations, and final outcomes.
5. Calculate total unit cost. Separate measured usage, human effort, infrastructure, maintenance, and assumptions.
6. Set thresholds and vetoes. Decide what must pass, what can remain unknown for a pilot, and what stops the investment.
7. Record the call and limits. Choose fund, revise, pilot, or stop. Name the evidence that could change the decision and set the next review date.

If the team cannot complete step two, it has not defined the problem. If it cannot complete step four, it has not evaluated the workflow. If it cannot complete step six, it has not decided what “good enough” means. Those are different gaps and need different budgets.

OpenAI’s API reference documents graders and evaluation runs as separate resources. That can help a team build evaluation tooling, but a tool record is not automatically evidence of business value. The packet still needs a baseline, representative work, end-to-end outcomes, human effort, cost, and controls. (OpenAI graders reference)

For the broader technical context, start with the AI evaluation pillar and then read how to evaluate an AI agent. Those pages cover evaluation practice; this article adds the commercial gate that turns evidence into a funding decision.

When a team has a real workflow but cannot turn its traces into a defensible packet, Marius Manolachi’s AI consulting and tutoring work is aimed at making existing people capable of building and evaluating AI products on their own work. The article is complete without that next step: the packet and the veto rule come first.