Design: Consume trust signals in posture and audit workflows

[jpower432]

Design Question

How should studio surface trust signals when complytime-core replaces the binary certified flag with queryable per-check trust signals?

Context

Core Epic #72 (Certification Pipeline & Trust Signals) is replacing the opaque certified: true/false with layered, queryable trust signals:

trust_signals:
  - layer: identity, check: schema, result: pass
  - layer: identity, check: provenance, result: pass
  - layer: attestation, check: witness-verified, result: pass

Phase 3 adds query APIs:

• GET /api/evidence?trust_layer=identity&trust_check=schema&trust_result=pass
• GET /api/evidence/{id}/trust-signals
• GET /api/evidence/{id}/chain

This affects studio in three places:

1. query_evidence tool (agents/assistant/tools.py) — the assistant queries evidence but has no way to filter or display trust signals today
2. /workbench/posture endpoint (workbench/app.py) — aggregates pass/fail counts from evidence; needs to surface trust signal summaries
3. Audit production workflow (prompt.md) — classifications (Strength/Finding/Gap/Observation) should consider trust signal status, not just eval_result

Options Considered

• Option A: Add a query_trust_signals gateway tool so the LLM can query signals directly and reason about them in audit/posture workflows
• Option B: Fold trust signal summaries into the existing query_evidence response (core enriches the payload) and update the posture aggregation to group by signal status
• Option C: Both — tool for agent-level reasoning, aggregation for dashboard views

Related

• complytime-core#72 — Epic: Certification Pipeline & Trust Signals
• complytime-core#49 — Epic: Stratified Trust Layers Architecture
• workbench/app.py:posture_summary — current aggregation logic
• agents/assistant/tools.py:query_evidence — current evidence tool