@adcp/sdk API Reference - v10.0.1
    Preparing search index...

    Interface ReportPlanOutcomeResponse

    Response from reporting an action outcome. Only returned to the orchestrator (buyer-side agent) that manages the plan. Sellers report delivery data via check_governance with phase 'delivery', not via this task.

    interface ReportPlanOutcomeResponse {
        adcp_version?: string;
        adcp_major_version?: number;
        outcome_id: string;
        outcome_state: "accepted" | "findings";
        committed_budget?: number;
        findings?: {
            category_id: string;
            severity: EscalationSeverity;
            explanation: string;
            details?: {};
        }[];
        plan_summary?: { total_committed?: number; budget_remaining?: number };
        replayed?: boolean;
        context?: ContextObject;
        ext?: ExtensionObject;
    }
    Index

    Properties

    adcp_version? adcp_major_version? outcome_id outcome_state committed_budget? findings? plan_summary? replayed? context? ext?

    Properties

    adcp_version?: string

    Release-precision AdCP version (VERSION.RELEASE, e.g. "3.0", "3.1", "3.1-beta"). On a request: the buyer's release pin — the seller validates against its supported_versions and returns VERSION_UNSUPPORTED on cross-major mismatch, or downshifts to the highest supported release within the same major. On a response: the release the seller actually served — clients SHOULD validate the response against that release's schema, not against their pin. Patches are not negotiated; surface them as build_version on capabilities for operational visibility. When omitted, falls back to adcp_major_version (deprecated) or server default. Buyers SHOULD emit both adcp_version and adcp_major_version through 3.x to remain compatible with sellers that only read the legacy field. NORMALIZATION: SDKs that read full-semver values from bundle metadata (e.g. ComplianceIndex.published_version = "3.1.0-beta.1") MUST normalize to release-precision ("3.1-beta.1") before emitting on the wire — meta-field values are NOT valid wire values.

    adcp_major_version?: number

    DEPRECATED in favor of adcp_version (release-precision string). Servers MUST continue to honor this field through 3.x. Removed in 4.0. Original semantics: the AdCP major version the buyer's payloads conform to. Sellers validate against their supported major_versions and return VERSION_UNSUPPORTED if unsupported. When omitted, the seller assumes its highest supported version.

    outcome_id: string

    Unique identifier for this outcome record.

    outcome_state: "accepted" | "findings"

    Outcome state. 'accepted' means state updated with no issues. 'findings' means issues were detected. Renamed from status in 3.1 to free the top-level status key for the envelope task-status (TaskStatus) under MCP flat-on-the-wire serialization.

    committed_budget?: number

    Budget committed from this outcome. Present for 'completed' and 'failed' outcomes.

    findings?: {
        category_id: string;
        severity: EscalationSeverity;
        explanation: string;
        details?: {};
    }[]

    Issues detected. Present only when outcome_state is 'findings'.

    Type Declaration

    • category_id: string

      Which validation category flagged the issue.

    • severity: EscalationSeverity
    • explanation: string

      Human-readable description of the issue.

    • Optionaldetails?: {}

      Structured details for programmatic consumption.

    plan_summary?: { total_committed?: number; budget_remaining?: number }

    Updated plan budget state. Present for 'completed' and 'failed' outcomes.

    Type Declaration

    • Optionaltotal_committed?: number

      Total budget committed across all campaigns in the plan.

    • Optionalbudget_remaining?: number

      Authorized budget minus total committed.

    replayed?: boolean

    Set to true when this response was returned from the idempotency cache rather than from a fresh execution. Set to false (or omitted) when the request was executed fresh. Buyers use this to distinguish cached replays from new executions — matters for billing reconciliation, audit logs, state-machine routing (cached state-tracking fields are historical snapshots, not current state — re-read via the resource's read endpoint), and any downstream system that assumes exactly-once event semantics. From 3.1 onward, replayed MAY appear on responses to any request that resolved via the idempotency cache, including read tools — universal idempotency_key (see security.mdx §Idempotency) means the cache holds read responses too.

    context?: ContextObject
    ext?: ExtensionObject

    Settings

    Member Visibility

    On This Page

    Properties