Classifying Task Uncertainty Across Requirements, Implementation, and Evidence

Welcome back. In the previous lesson, you reframed a broad request around a decision, affected users, an observable failure, and a solution-neutral outcome. That framing prevents a code agent from silently choosing the problem on your behalf.

The next step is to inspect what kind of uncertainty remains. “This task is unclear” is not actionable enough. A request can be clear about the intended outcome but technically risky; technically straightforward but supported by weak evidence; or uncertain in all three ways. Those cases demand different work, different reviewers, and different instructions to Claude Code.

By the end of this lesson, you will be able to describe a task as a profile of requirements uncertainty, implementation uncertainty, and evidence uncertainty, rather than treating ambiguity as one undifferentiated problem.

---

Uncertainty belongs to claims, not to tasks

Consider the request:

“Build an agent that produces account-research briefs for enterprise SDRs.”

Calling this “an uncertain task” hides the important distinctions. The request actually contains several claims:

• SDRs need account briefs before outreach.
• Faster preparation would improve a meaningful commercial outcome.
• A brief should contain certain information and sources.
• An agent is an appropriate intervention.
• The company’s CRM and external data sources can be accessed safely.
• The system can generate sufficiently accurate, traceable briefs within an acceptable time and cost.

Some of these claims define what should be achieved. Some concern whether it can be built and operated. Some concern whether the underlying story is actually supported by reality.

Use three dimensions.

Dimension	Core question	Typical uncertainty signal	Common bad response
Requirements	What must be true of the outcome for this work to count as useful and in scope?	“Make it better,” “make it useful,” “build an agent,” conflicting stakeholder expectations	Choosing an architecture before defining the outcome
Implementation	Can we build, integrate, operate, and support it under real constraints?	Unknown APIs, model behavior, latency, permissions, reliability, cost, team capability	Treating a successful local demo as production feasibility
Evidence	What justifies the claims used to choose the problem, requirements, or solution?	Anecdotes, unrepresentative samples, stale data, no ground truth, conflicting reports	Treating a coherent explanation or generated report as proof

These are independent dimensions. A task can have:

• Low requirements uncertainty, high implementation uncertainty: “Add SSO via the documented identity provider flow” may be clearly specified, but your authorization model or provider integration may still be risky.
• High requirements uncertainty, low implementation uncertainty: “Create a dashboard to improve retention” is easy to start coding, but unclear about audience, decision, metric, and desired action.
• High evidence uncertainty despite a polished specification: a detailed request for an LLM research workflow may still rest on an untested belief that research time, rather than data access or sales process, is the bottleneck.

A useful working rule is:

Do not classify the whole ticket once. Classify the important propositions inside it.

This shifts your thinking from “What should Claude Code implement?” to “Which claims would need to be true for implementation to be worth doing?”

---

Requirements uncertainty: uncertainty about “what good means”

Requirements are broader than a PRD or a list of UI elements. They include the target user, job, boundaries, constraints, and acceptance conditions. Requirements uncertainty exists when reasonable people could build materially different things while all believing they are fulfilling the request.

For an internal research agent, compare these statements:

Statement	What remains ambiguous?
“Build a research agent for sales.”	Which sales role? What research? What decision does it improve? What sources are allowed?
“Generate a profile for enterprise prospects.”	Which facts matter? How current must they be? Must every claim have a source? Is a profile for pre-outreach, qualification, or meeting preparation?
“Help SDRs prepare an evidence-backed account brief before first outreach.”	More focused, but still needs a definition of “evidence-backed,” useful content, acceptable effort, and expected business signal.

Requirements uncertainty often appears as apparently small wording choices:

• “Accurate” may mean factually correct, sufficiently current, properly cited, or aligned with a domain expert.
• “Fast” may mean a 30-second interactive response, a five-minute asynchronous job, or less analyst time overall.
• “Support all customers” may conceal segmentation, legal, language, plan, and data-access constraints.
• “Automate research” may mean suggest sources, produce a draft, or act without human review. These are fundamentally different operating models.

When requirements are uncertain, more code usually produces a more expensive misunderstanding. The appropriate output is a clarified decision, scope, non-goals, and observable acceptance conditions—not a larger prototype.

A compact requirements classification looks like this:

Requirements uncertainty: high. “Useful account brief” has no agreed content standard, source policy, or target workflow. Sales leadership and SDRs may mean different things by “research.”
What would reduce it: examples of real briefs, a target user segment, a defined pre-outreach workflow, and a reviewable description of success.

Notice that this does not yet claim that the proposed solution is impossible. It identifies what has not been decided.

---

Implementation uncertainty: uncertainty about “can it work here?”

Implementation uncertainty concerns technical feasibility in the actual environment, not feasibility in an abstract sense. A model provider may expose tool use; that does not prove the agent can safely use your tools, comply with your data policies, meet your latency budget, or be operated by your team.

For LLM systems, implementation uncertainty commonly includes:

• Model-task fit: Can the selected model perform the required reasoning, extraction, tool use, or structured generation reliably enough?
• Integration: Can it access the necessary systems with appropriate permissions, error handling, rate-limit behavior, and observability?
• Non-functional constraints: Can it meet latency, privacy, security, reliability, cost, and maintainability needs?
• Operational behavior: What happens when a source is unavailable, returns contradictory information, changes format, or contains prompt injection?
• Team capability: Can the team evaluate output quality, debug failures, and maintain the system after the prototype’s author moves on?

For example:

“Claude Code can build the retrieval pipeline” is not evidence that the pipeline is feasible for the intended product.

It may produce a working implementation that has never been tested against real permission boundaries, representative documents, concurrent load, data freshness, or cost constraints. The code can be correct relative to a local mock while the system remains infeasible in production.

The AWS guidance below is useful because it separates data readiness from technical feasibility. Treating the data as merely an implementation detail is a recurring failure mode in generative-AI work.

A good implementation classification names the concrete uncertainty rather than vaguely saying “technical risk”:

Implementation uncertainty: medium to high. It is unknown whether the agent can access CRM fields and approved external sources under existing permissions, preserve citations through synthesis, and meet the interactive latency and per-brief cost constraints.
What would reduce it: inspect access patterns and data contracts, then validate the core retrieval-and-citation path under representative conditions.

This language provides a much better prompt for an engineering spike or agent investigation than “research the architecture.”

---

Evidence uncertainty: uncertainty about “how we know”

Evidence uncertainty is often the most dangerous category in agent-assisted work because generated text can make weak evidence feel complete.

Evidence uncertainty is present when you cannot yet justify an important claim about:

• the user’s problem;
• the frequency or severity of a failure;
• the relationship between an intervention and an outcome;
• the quality of input data;
• the correctness or usefulness of a model output;
• the representativeness of an evaluation set.

The key distinction is this:

A claim can be plausible, widely repeated, and still weakly evidenced.

Suppose a sales lead says, “SDRs spend hours researching each account.” This is a useful reported claim, but it is not automatically a fact. You still need to know:

• Which SDRs and which account segment does this describe?
• Is the time spent mostly finding sources, reconciling CRM data, validating claims, or writing outreach?
• How variable is the process?
• Does research time constrain outreach volume or quality?
• Would an automated brief be trusted enough to change behavior?

For an LLM system, “the model gave good answers in our demos” is similarly weak evidence if the examples were selected by the builders, the references are missing, or the test cases do not represent real production inputs.

A concise evidence classification might be:

Evidence uncertainty: high. The team has reports that preparation is inconsistent, but no sampled workflow data or reviewed account briefs. There is no agreed ground-truth set defining which claims a good brief should contain and which sources are authoritative.
What would reduce it: collect a small, representative sample of existing briefs and workflows, validate target claims with domain reviewers, and retain the source and caveat for each finding.

The relevant question is not, “Do we have data?” It is, “Do we have data that is sufficiently trustworthy and representative for this decision?”

---

Connect the three dimensions to product risk

The product-risk model is a helpful complement to the requirements–implementation–evidence classification. It asks four important questions: whether users value the solution, can use it, whether the team can build it, and whether it works for the business.

The two frameworks answer different questions:

Product risk	Where it usually appears in the uncertainty classification
Value — do users care enough to choose it?	Requirements uncertainty when the problem or desired outcome is unclear; evidence uncertainty when the claimed pain or impact is unverified
Usability — can people understand and use it?	Requirements uncertainty about the workflow and interaction; evidence uncertainty until representative users try a realistic version
Feasibility — can we build and support it?	Primarily implementation uncertainty
Business viability — does it work within commercial, legal, policy, and operational constraints?	Requirements uncertainty about hard constraints, plus evidence uncertainty about costs, contracts, compliance, and business effects

Do not force a one-to-one mapping. “Will SDRs trust a generated brief?” has a requirements aspect because trust may be a success condition; an evidence aspect because it must be observed with representative users; and possibly an implementation aspect if traceable citations or review controls are needed to earn that trust.

This is why one risk label is rarely enough.

---

A worked classification: the account-research agent

Return to the decision-centered statement from the previous lesson:

Decide whether to invest in reducing trustworthy account-research time for SDRs working on enterprise prospects, based on evidence that the current process delays or weakens outreach and that improvement would change a business-relevant outcome.

Now classify the task before you ask for an implementation plan.

Proposition or decision	Dimension	Assessment	Why
Which SDR segment and workflow should be improved?	Requirements	High	“Enterprise SDR” may include different account sizes, territories, source access, and preparation practices.
What must a trustworthy brief contain?	Requirements	High	The request has no agreed claim types, source policy, freshness threshold, or human-review expectation.
Can the system access CRM data and external sources within approved permissions?	Implementation	Medium	This can often be inspected and tested, but must account for credentials, source restrictions, and data handling.
Can the system produce traceable briefs at acceptable latency and cost?	Implementation	Medium to high	Depends on retrieval design, model behavior, source quality, load, and expected review effort.
Is manual research truly the primary bottleneck?	Evidence	High	Leadership reports may be correct, but the causal story has not been observed or measured.
Will better briefs change outreach quality or productivity?	Evidence	High	This is a business-outcome claim, not something code can establish by itself.
Which sources are reliable enough to serve as references?	Evidence	High	Source authority, freshness, coverage, and contradictions determine whether “citation” means anything.

The result is not “do not build.” It is a more honest project state:

R: high, I: medium to high, E: high.
We have a plausible opportunity, but the content standard and target workflow are unresolved; technical feasibility depends on integration and citation quality; and the main business rationale lacks direct evidence.

This classification changes how you use Claude Code. It can help inspect the repository, map existing integrations, draft an evaluation harness, or generate a narrow prototype. It should not be treated as an authority on whether SDR research is the business bottleneck or whether the resulting workflow will be trusted.

---

Record uncertainty in a form that resists narrative drift

A lightweight knowledge board helps keep questions, assumptions, research, and established facts separate rather than allowing them to blur into a single design document.

For your own task, create short cards with these fields:

Field	Example
Claim or question	“Every material claim in an account brief needs a visible primary source.”
Dimension	Requirements and implementation
Status	Assumption
Support	Sales lead request; no existing standard or policy located
What would change the classification	Review five current briefs and agree on a source policy with the intended users
Consequence if wrong	The agent may optimize for citations that users do not need, or omit evidence they require

The status labels from the previous lesson remain useful:

• Observed: directly seen in a workflow, system, or measurement.
• Reported: stated by a stakeholder or user.
• Inferred: a conclusion drawn from observations or reports.
• Unknown: no reliable basis yet.

A stakeholder statement is not useless because it is “reported.” It is a lead. The classification simply stops it from becoming a fact through repetition.

You can also give an agent a constrained inventory task before it writes code:

From the request, linked notes, and repository evidence, create a claim inventory.

For each claim:
1. quote the supporting evidence or state that no evidence was provided;
2. classify it as requirements, implementation, evidence, or multiple;
3. label it observed, reported, inferred, or unknown;
4. identify contradictions or missing acceptance conditions.

Do not propose an architecture or resolve missing information by assumption.

This use of an agent is valuable because it externalizes ambiguities quickly. Your responsibility is to inspect its classifications and source references, especially where it upgrades an inference into an apparent fact.

---

A practical classification routine

For a new ambiguous task, spend roughly ten minutes before planning implementation:

1. Restate the decision and intended outcome.
   If you cannot state this without naming a framework or model, requirements uncertainty is probably already high.

2. Extract the important claims.
   Write claims about users, desired behavior, constraints, data, expected outcomes, and technical capabilities.

3. Tag each claim by uncertainty dimension.
   A claim may receive more than one tag. Avoid forcing it into a single bucket.

4. Assign a plain-language level.
   Use low, medium, or high. High means that plausible alternative answers would materially change the work or decision.

5. Name the smallest missing piece of knowledge.
   For requirements, this may be an agreed success condition. For implementation, an integration check or bounded test. For evidence, a representative sample, validated reference, or direct observation.

6. Keep the dimensions visible in the task brief.
   Do not collapse them into a single “risk: high” label or average them into a score. A task with low technical uncertainty can still be a poor investment if evidence uncertainty is high.

This is a judgment practice, not bureaucracy. It gives you a reason to stop when an agent produces an attractive answer to the wrong kind of question.

---

Key takeaways

An ambiguous request usually contains several distinct uncertainties:

• Requirements uncertainty concerns what outcome, scope, user workflow, constraints, and acceptance conditions actually matter.
• Implementation uncertainty concerns whether the system can be built, integrated, operated, and supported in its real environment.
• Evidence uncertainty concerns whether the claims guiding the work are sufficiently supported by representative, trustworthy information.

Classify claims rather than giving the whole task one vague label. A single proposition may belong to several dimensions, and each dimension calls for a different way of learning.

Next, you will turn this classification into an assumption map: a structured separation of facts, hypotheses, questions, and the evidence attached to each.