docs(problems): add trustworthiness evidence problem doc

[Benkapner]

Summary

• New problem document exploring what evidence organizations should require before granting agents increasing autonomy
• The roadmap identifies "trustworthiness evidence" as a gap area with thin tracking coverage
• Identifies five evidence types: configuration health (static analysis of agent configs), behavioral evaluation (functional testing), audit trail integrity (tamper-resistant logs), historical track record (success/revert rates), and configuration drift detection
• Explores how these evidence types compose into trust decisions, with three approaches and trade-offs
• Includes open questions on evidence freshness, portability, and gaming resistance

The autonomy spectrum defines when an agent can act independently, but not what evidence should be required before granting that autonomy. This doc addresses the gap between "we want to auto-merge" and "we have reason to believe auto-merge is safe."

Connects to several existing problem areas: testing-agents (behavioral evaluation is one evidence type), the audit log integrity work in #2010 (audit trails as evidence), MCP configuration drift in #2011 (drift detection as evidence), and the functional test framework in #1682 (behavioral thresholds).

Relates to #267 (agent attestations are one form of trustworthiness evidence).

[github-actions]

E2E tests did not run

E2E tests run automatically for org/repo members and collaborators on pull requests.

For other contributors, a maintainer must add the ok-to-test label after the latest push.

See E2E testing guide for details.

[qodo-code-review]

PR Summary by Qodo

Add trustworthiness evidence problem document

📝 Documentation 🕐 10-20 Minutes

AI Description

• Introduces a new problem doc defining what evidence should justify agent autonomy.
• Outlines key evidence categories (config, behavior, audit integrity, track record, drift).
• Discusses ways to compose evidence into tiered trust decisions and open questions.

Diagram

graph TD
  O(["Organization"]) --> P["Evidence portfolio"] --> D{"Trust decision"} --> T["Autonomy tier"]
  P --> C["Config assurance"]
  P --> B["Behavior tests"]
  P --> A["Audit integrity"]
  P --> R["Track record"]

  subgraph Legend
    direction LR
    _o(["Organization"]) ~~~ _e["Evidence"] ~~~ _d{"Decision"}
  end

Loading

High-Level Assessment

The following are alternative approaches to this PR:

1. Extend existing docs instead of a new problem doc

• ➕ Fewer conceptual entry points; reduces fragmentation across problem statements
• ➕ Keeps autonomy gating and evidence requirements co-located (e.g., in autonomy-spectrum/testing-agents)
• ➖ Cross-cuts multiple areas (security, observability, drift) and may bloat a single doc
• ➖ Harder to treat “evidence portfolio” as a first-class standalone gap on the roadmap

2. Add an explicit evidence rubric/template (matrix) alongside the narrative

• ➕ Makes the output actionable: teams can score evidence readiness per repo/path
• ➕ Easier to operationalize tiered requirements and audits
• ➖ Higher maintenance burden; rubric can become prematurely prescriptive
• ➖ May require agreeing on thresholds/weights earlier than desired

Recommendation: Keeping this as a standalone “problem” doc is a good choice because it unifies evidence concepts across multiple existing areas without overloading any single doc. Consider following up with a lightweight rubric/matrix (even as an appendix) once the narrative stabilizes, to make the evidence portfolio easier to apply in practice.

Files changed (1) +111 / -0

Documentation (1) +111 / -0

trustworthiness-evidence.mdAdd problem doc defining trustworthiness evidence for agent autonomy +111/-0

Add problem doc defining trustworthiness evidence for agent autonomy

• Introduces a new problem statement describing the gap between autonomy tiers and the evidence needed to safely grant them. Enumerates evidence categories (static config analysis, behavioral evaluation, audit integrity, track record, drift detection) and discusses composition models and open questions.

docs/problems/trustworthiness-evidence.md

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (1) 📎 Requirement gaps (0) 📜 Skill insights (0)

Context used

✅ Tickets: 🎫 Evaluate producing agent-commit attestations (refs.arewm.com/agent-commit/v0.1)

✅ Compliance rules (platform): 54 rules

✅ Skills: writing-user-docs, writing-adrs

1. No labeled trade-off sections 📘 Rule violation ⌂ Architecture

Description

The new problem doc lists multiple approaches for composing trustworthiness evidence, but it does
not provide clearly labeled trade-off subsections (e.g., Pros/Cons or Risks) for each option as
required. This weakens comparability and can read as informal preference rather than a structured
options analysis.

Code

docs/problems/trustworthiness-evidence.md[R89-94]

+**Threshold model.** Each evidence type has a minimum passing threshold. All thresholds must be met before autonomy is granted. Simple and auditable, but rigid: a strong track record cannot compensate for a failing security scan.
+
+**Weighted portfolio.** Each evidence type contributes a weighted score to an overall trust assessment. Allows trade-offs between categories, but introduces calibration complexity: what weights are correct?
+
+**Tiered requirements.** Different autonomy levels require different evidence portfolios. Auto-triaging issues (low risk) requires only static analysis and basic behavioral tests. Auto-merging code (high risk) requires all five evidence types with strict thresholds. This aligns with the autonomy spectrum's per-repo, per-path granularity.
+

Relevance

⭐ Low

Similar “add labeled options + trade-offs sections” suggestion was rejected in PR #2549; formatting
rigidity not enforced.

PR-#2549
PR-#2011

ⓘ Recommendations generated based on similar findings in past PRs

Evidence

PR Compliance ID 1062035 requires at least two distinct options with clearly labeled trade-off
subsections. In docs/problems/trustworthiness-evidence.md, the approaches are listed with brief
inline commentary, but there are no explicit Pros/Cons (or equivalent) subsections for each option.

Rule 1062035: Problem docs must present multiple options with trade-offs, not a single prescribed solution
docs/problems/trustworthiness-evidence.md[89-94]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The problem doc includes multiple approaches (threshold/weighted/tiered) but does not include clearly labeled trade-off subsections for each option (e.g., **Pros**, **Cons / Risks**), which is required for problem docs.

## Issue Context
This file is a new core problem doc under `docs/problems/`, so it must explicitly document at least two distinct options and include clearly labeled trade-offs for each.

## Fix Focus Areas
- docs/problems/trustworthiness-evidence.md[83-94]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

[github-actions]

Site preview

Preview: https://85ca2be6-site.fullsend-ai.workers.dev

Commit: 0190efb74ff10f30c9c699e003da62b0ae6babd5

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[ralphbean]

I love it - thank you!

[fullsend-ai-retro]

🤖 Finished Retro · ✅ Success · Started 4:13 PM UTC · Completed 4:26 PM UTC
Commit: 0190efb · View workflow run →

[fullsend-ai-retro]

PR #3058 added a well-written trustworthiness evidence problem document from external contributor Benkapner (fork PR). The fullsend review agent never ran pre-merge because the dispatch authorization gate requires repo-level write permission, which fork contributors lack. This is a known gap tracked in #2967, but this PR reveals a concrete regression: the same contributor received review agent coverage on their previous PR (#2009, June 8) before the dispatch auth was tightened in mid-June. The human review was a single-line approval; the reviewer pushed a second commit to improve cross-linking and partially address a Qodo finding. Document quality was high — all cross-references valid, README and autonomy-spectrum properly linked. One evidence proposal filed for #2967.

Proposals filed

• Evidence for #2967: same contributor lost review coverage between PRs due to mid-June auth tightening (in fullsend-ai/fullsend)