AAO Verified dashboard: surface compliance `notices` (deprecations, future-required advisories)

[bokelley]

Summary

The @adcp/sdk runner is gaining a structured notices field on ComplianceResult (PR adcp-client#1705, implementing adcp-client#1704). Notices are advisory signals — deprecations and future-required capabilities — decoupled from pass/fail. Two day-one notices ship:

• request_signing.required (future_required, effective_version: '4.0') — agent doesn't advertise request_signing.supported: true; signing becomes required for spend-committing operations in AdCP 4.0.
• webhook_signing.legacy_hmac_fallback.removed (deprecation, effective_version: '4.0') — agent advertises webhook_signing.legacy_hmac_fallback: true; the legacy HMAC path is removed in AdCP 4.0.

Both are spec-grounded: see compliance/cache/{version}/universal/signed-requests.yaml line 34 (the "runner SHOULD emit an informational notice" clause that's been silently unimplemented) and schemas/cache/{version}/protocol/get-adcp-capabilities-response.json lines 892 and 966.

The dashboard gap

The AAO Verified dashboard at adcontextprotocol.org renders agent compliance verdicts. It currently consumes the SDK's ComplianceResult for pass/fail/partial signals but does NOT surface the notices advisory payload. If we ship adcp-client#1705 without paired AAO-side rendering, the audience that most needs the signal (sellers reading their AAO Verified report) doesn't see it.

A 3.0 seller that legitimately passes compliance today but will fail at the 4.0 cut (the BidMachine-shaped case in adcp#4419) needs to see the forward-readiness signal now, on the same surface where they see their current verdict. Burying it in --json output of an SDK CLI defeats the point.

Proposed dashboard contract

When rendering an agent's Verified result, surface result.notices[] as a distinct visual section below the verdict. Per-notice rendering:

Field	Use
severity	Badge color/icon (info, deprecation, future_required)
code	Stable identifier — link to docs or filter routing
message	Primary human-readable text
effective_version	"Required in v4.0" sub-line — sets the urgency
capability_path	Tooltip showing the capability response field that triggered
docs_url	Click-through to remediation docs
storyboard_ids[]	Disclosed in expanded view: "fired on N storyboard(s): [list]"

Suggested copy patterns:

• Severity future_required: "Plan ahead: required in AdCP {effective_version}"
• Severity deprecation: "Deprecated: removed in AdCP {effective_version}"
• Severity info: "Informational"

What this enables

• Sellers see the forward-readiness signal at the same time they see today's verdict.
• AAO can ship a "4.0-ready" filter on the agent catalog: agents with zero future_required notices in the relevant categories.
• The unimplemented runner SHOULD emit an informational notice clause at signed-requests.yaml:34 finally has somewhere to land.

Coordination

• adcp-client#1704 — the SDK-side surface spec.
• adcp-client#1705 — the in-flight implementation PR; emits the two day-one notices.
• adcp#4418 — upstream spec issue proposing notices on runner-output-contract.yaml so this contract becomes formally normative across runners (not just @adcp/sdk).
• adcp#4419 — BidMachine's "63/128 stuck score" report; the lack of forward-readiness signal contributed to the diagnose-loop.

The SDK side ships independent of this issue — the wire field will exist in the result — but the user-facing value lands only when the dashboard renders it. Filing this here so the AAO Verified renderer's work is tracked alongside the SDK rollout.

Refs

• adcp-client#1705 (in-flight PR adding the runtime emission)
• adcp-client#1704 (the SDK-side issue defining the RunnerNotice shape)
• adcp#4418 (upstream contract proposal)