Skip to content
TCAFTask-Contract AI Development Framework
TCAF 0.3.3

Outcome labels

Use PASS, READY FOR CHECK, PARTIAL, BLOCKED and FAIL to describe the current evidence and next developer action honestly.

Content: completeWorkflow: verified

TCAF responses begin with an outcome label so the developer can understand the current state before reading detail.

The label describes evidence and completion state. It is not a confidence score and it is not a marketing claim.

PASS

Use PASS when:

  • the authorized implementation is complete;
  • required checks that can determine completion have passed;
  • no required manual verification remains;
  • no unresolved deviation prevents acceptance.

Example:

PASS — The requested validation behaviour is implemented.

Changed: email-validator.ts, email-validator.test.ts
Checks: focused test PASS; typecheck PASS
Deviation: none
Next: review the diff and decide whether to commit.

PASS does not mean the developer has already accepted or committed the work. It means the agent has completed the contract with the declared evidence.

READY FOR CHECK

Use READY FOR CHECK when implementation is complete but a required manual or external verification remains.

Typical reasons:

  • browser interaction is required;
  • credentials or a real service are needed;
  • the agent cannot run commands in the current tool;
  • visual or usability judgement belongs to the developer;
  • a hardware or environment-specific check is necessary.

Example:

READY FOR CHECK — Implementation complete.

Automatic checks: typecheck PASS
Manual check: submit the invalid form and confirm the inline error
Next: run the manual check and report the result.

Do not use PASS simply because the code appears correct.

PARTIAL

Use PARTIAL when only part of the approved contract has been completed.

The response must state:

  • completed criteria;
  • incomplete criteria;
  • why the remaining work was not completed;
  • whether completed work is safe to keep;
  • next decision or action.

Example:

PARTIAL — API validation completed; UI integration not implemented.

Completed: AC-1, AC-2
Remaining: AC-3
Reason: the referenced form component is absent from the target branch
Next: confirm the intended component or split the UI work into a new task.

PARTIAL is not a softer version of success. It means the contract is not fully satisfied.

BLOCKED

Use BLOCKED when work cannot continue safely without a developer decision, missing prerequisite or external condition.

Examples:

  • two canonical sources contradict each other;
  • a required API or dependency is absent;
  • credentials or environment access are unavailable;
  • the task requires a destructive operation that was not authorized;
  • new evidence makes the approved scope invalid;
  • a product or architectural decision is needed.

A useful blocked response identifies the exact decision rather than describing a vague problem.

BLOCKED — The contract assumes an endpoint that is not present.

Evidence: no password-reset endpoint exists in the API or documented roadmap
Decision required: add the endpoint to this task, select another integration or postpone the feature
Unauthorised changes: none

FAIL

Use FAIL when a required check fails or the implementation is known not to satisfy the contract.

Examples:

  • a focused test fails;
  • typecheck fails because of the change;
  • a manual acceptance scenario produces the wrong behaviour;
  • the implementation violates an exclusion or preserved interface;
  • structural validation reports errors.

The response should include:

  • failed check or criterion;
  • concise failure evidence;
  • affected files or behaviour;
  • whether changes were reverted or remain present;
  • next action.

Do not hide a failure behind READY FOR CHECK or PARTIAL when the evidence already shows the result is incorrect.

Outcome and workflow status are different

Outcome labels describe one execution result. Workflow status describes how well a documented procedure has been validated across TCAF usage.

For example:

  • a framework-aligned workflow can produce PASS in one test;
  • a verified workflow can produce BLOCKED for a particular project;
  • an adapter verified with limitations can still complete a task successfully.

Keep these dimensions separate.

Write the label first

The first line should be understandable without scrolling. Then include only the information needed for the next decision.

Routine successful output can be short. Expand the response for:

  • failure;
  • blockers;
  • partial completion;
  • deviations;
  • amendments;
  • ambiguous evidence;
  • destructive operations;
  • decisions with meaningful alternatives.

Never upgrade the outcome for presentation

A polished response does not improve the underlying result.

Do not:

  • call an unexecuted command successful;
  • omit a required manual check to claim PASS;
  • hide incomplete criteria;
  • downgrade a failing check to a warning without authorization;
  • treat generated files as accepted merely because they exist.

The value of the label is its reliability. A truthful READY FOR CHECK or BLOCKED is more useful than an unjustified PASS.