Docs: add auditable task output receipt guidance

[aDragon0707]

Summary

Adds a docs-only section to the Tasks guide about auditable task output receipts.

The section shows how safety-sensitive crew tasks can return a compact receipt that separates:

• task completion claims
• supporting evidence
• unsupported claims
• next owner
• human approval boundaries

Motivation

A task result can sound complete even when important evidence is missing. For example, Done. All tests passed. Ready to publish. contains completion, verification, and external-action claims that may require different evidence and approvals.

The receipt pattern complements expected_output: expected_output describes what success should look like, while the receipt summarizes whether the final task output is actually supported by evidence.

Notes

• Docs-only change.
• No CrewAI behavior change.
• No runtime dependency.
• Safety-oriented guidance for reviewing task outputs.

Summary by CodeRabbit

• Documentation
  • Added guidance on "Auditable Task Output Receipts" for safety-sensitive workflows: describes producing a machine-readable receipt alongside user-facing output that summarizes overall verification status, per-claim support and evidence, required fixes for unsupported items, step ownership, and human approval needs; includes practical examples illustrating supported and unsupported claim scenarios.

[coderabbitai]

📝 Walkthrough

Walkthrough

Adds an “Auditable Task Output Receipts” documentation section that defines a Pydantic receipt schema and workflow for emitting machine-validated receipts alongside task outputs, with YAML examples showing supported and unsupported claims, evidence attachments, required fixes, and ownership/human-approval fields.

Changes

Auditable Task Output Receipts Documentation

Layer / File(s)	Summary
Introduction and workflow docs/en/concepts/tasks.mdx	Adds the new section explaining receipts as machine-validated summaries that should not be treated as proof of claims in safety-sensitive contexts.
Pydantic schema and verification Task docs/en/concepts/tasks.mdx	Introduces Claim and TaskReceipt Pydantic models and a Task configured with output_pydantic=TaskReceipt to emit verification status, per-claim support, evidence, required fixes, and ownership fields.
YAML examples and receipt boundaries docs/en/concepts/tasks.mdx	Includes two YAML receipt examples (one verified with evidence, one missing evidence/unverified) and explains next_owner, receipt boundaries, and how the receipt complements expected_output.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~8 minutes

Poem

"A rabbit stamps a receipt with care,
Claims checked, evidence laid bare.
When humans need proof, not just a say,
This tiny slip shows the verified way. 🐇📜"

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title accurately and concisely describes the main change: adding documentation guidance about auditable task output receipts. It is specific, clear, and directly reflects the core purpose of this docs-only pull request.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 2

🧹 Nitpick comments (1)

docs/en/concepts/tasks.mdx (1)

1121-1121: ⚡ Quick win

Define "ProducingAgent" or use a clearer example.

The term ProducingAgent appears without definition. Is this a specific CrewAI concept, a placeholder, or example agent name? Consider using a more descriptive example (e.g., research_agent, verification_agent) or defining this terminology if it's meant to be standard.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@docs/en/concepts/tasks.mdx` at line 1121, The term "ProducingAgent" used as
the value for next_owner is undefined and could be ambiguous; either define
"ProducingAgent" in this document's concepts section (explaining it's a
role/agent type responsible for producing task outputs) or replace it with a
clearer example like "research_agent" or "verification_agent" and add a short
inline note explaining the field (e.g., next_owner specifies the role or agent
responsible for the next step). Ensure the symbol ProducingAgent and the
metadata key next_owner are updated consistently and that a brief definition or
example is added nearby for readers.

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Inline comments:
In `@docs/en/concepts/tasks.mdx`:
- Around line 1108-1123: The docs example lacks implementation guidance and a
populated evidence example; add a new subsection "Implementing Receipt-Based
Tasks" that shows using a Pydantic model (e.g., Claim and TaskReceipt) and how
to wire it into Task definitions via the output_pydantic parameter (reference
symbols: Claim, TaskReceipt, Task, output_pydantic, verification_task) and
explain whether the receipt is returned as the primary expected_output or
returned alongside the main answer (recommend returning it as the structured
expected_output for programmatic verification). Show a concrete populated
evidence example (tool outputs, file paths, log excerpts like "test_output.log:
All 47 tests passed in 12.3s" and "pytest exit code: 0"), and briefly note
integration points with guardrails and callbacks (how to emit the receipt from
the agent, validate via output_pydantic, and surface to callbacks) so readers
can implement end-to-end verification.
- Line 1109: Replace the HTTP-specific field "status_code: 412" in the task
receipt with a domain-specific status scheme (for example use "status:
incomplete" or "verification_status: missing_evidence") and update any
surrounding copy to reflect the new key; alternatively, if you intend to keep
HTTP codes, add a short explanatory note next to "status_code: 412" clarifying
that HTTP semantics are being reused intentionally for interoperability and why
412 (Precondition Failed) maps to the task state. Ensure the change references
the existing "status_code: 412" token so the update is made in the same receipt
example and keep downstream examples/usage consistent with the chosen
representation.

---

Nitpick comments:
In `@docs/en/concepts/tasks.mdx`:
- Line 1121: The term "ProducingAgent" used as the value for next_owner is
undefined and could be ambiguous; either define "ProducingAgent" in this
document's concepts section (explaining it's a role/agent type responsible for
producing task outputs) or replace it with a clearer example like
"research_agent" or "verification_agent" and add a short inline note explaining
the field (e.g., next_owner specifies the role or agent responsible for the next
step). Ensure the symbol ProducingAgent and the metadata key next_owner are
updated consistently and that a brief definition or example is added nearby for
readers.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 2256e998-c545-4a59-bcff-64688d8e2fb5

📥 Commits

Reviewing files that changed from the base of the PR and between a95d267 and 7c05e4b.

📒 Files selected for processing (1)

• docs/en/concepts/tasks.mdx

[coderabbitai]

🧹 Nitpick comments (1)

docs/en/concepts/tasks.mdx (1)

1087-1088: ⚡ Quick win

Move this section before the Conclusion.

The "Conclusion" section (lines 1081-1086) should remain the final section of the document. Placing new content after it breaks standard document flow and may cause readers to miss this guidance.

Consider moving this section to appear before "Conclusion", perhaps after "Creating Directories when Saving Files" or grouped with the "Task Guardrails" section since both relate to validation patterns.

🤖 Prompt for AI Agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

In `@docs/en/concepts/tasks.mdx` around lines 1087 - 1088, Move the "Auditable
Task Output Receipts" section so it appears before the "Conclusion" section;
locate the heading "Auditable Task Output Receipts" and cut/paste it to a
position prior to the "Conclusion" heading (for example immediately after the
"Creating Directories when Saving Files" section or grouped near the "Task
Guardrails" section) to preserve correct document flow and keep "Conclusion" as
the final section.

🤖 Prompt for all review comments with AI agents

Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.

Nitpick comments:
In `@docs/en/concepts/tasks.mdx`:
- Around line 1087-1088: Move the "Auditable Task Output Receipts" section so it
appears before the "Conclusion" section; locate the heading "Auditable Task
Output Receipts" and cut/paste it to a position prior to the "Conclusion"
heading (for example immediately after the "Creating Directories when Saving
Files" section or grouped near the "Task Guardrails" section) to preserve
correct document flow and keep "Conclusion" as the final section.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 275a0ec9-0157-4e27-92b2-64c39cd84580

📥 Commits

Reviewing files that changed from the base of the PR and between 7c05e4b and 9e95daa.

📒 Files selected for processing (1)

• docs/en/concepts/tasks.mdx