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

    Interface GovernanceDenied

    interface GovernanceDenied {
        approved: false;
        checkId: string;
        explanation: string;
        findings?: {
            category_id: string;
            policy_id?: string;
            source_plan_id?: string;
            severity: EscalationSeverity;
            explanation: string;
            details?: {};
            confidence?: number;
            uncertainty_reason?: string;
        }[];
        conditions?: { field: string; required_value?: unknown; reason: string }[];
    }
    Index

    Properties

    approved: false
    checkId: string
    explanation: string
    findings?: {
        category_id: string;
        policy_id?: string;
        source_plan_id?: string;
        severity: EscalationSeverity;
        explanation: string;
        details?: {};
        confidence?: number;
        uncertainty_reason?: string;
    }[]

    Type Declaration

    • category_id: string

      Validation category that flagged the issue (e.g., 'budget_compliance', 'regulatory_compliance', 'brand_safety'). This is an agent-internal taxonomy: the string is defined by the governance agent's own policy model and is not constrained to any protocol-level enum. Sellers and buyers MUST NOT pattern-match category_id values against a fixed list — treat them as opaque labels with human-readable significance for audit but no machine-level contract. See the Campaign Governance specification for how an agent composes internal specialist review behind one endpoint.

    • Optionalpolicy_id?: string

      ID of the policy that triggered this finding. May reference a registry policy (with source: registry) or a bespoke inline policy (with source: inline). Bespoke policy_ids are unique within their authoring container; use source_plan_id when findings aggregate across multiple plans (e.g., portfolio evaluations). When the violation traces to a producer-tagged surface (feature-requirement, creative-feature-result, or validation-result feature) carrying policy_id, governance agents SHOULD echo that policy_id here for end-to-end traceability, and MUST NOT invent a policy_id that wasn't present on the originating surface. See /docs/governance/policy-attribution.

    • Optionalsource_plan_id?: string

      For portfolio or aggregated evaluations where findings draw on bespoke policies from multiple member plans: identifies the plan whose policy triggered this finding. Omit when the finding's policy_id is unambiguous within the response context (e.g., single-plan check_governance).

    • severity: EscalationSeverity
    • explanation: string

      Human-readable description of the issue.

    • Optionaldetails?: {}

      Structured details for programmatic consumption.

    • Optionalconfidence?: number

      Confidence score (0-1) in this finding. Distinguishes 'this definitely violates the policy' (0.95) from 'this might violate depending on how audience segments resolve' (0.6). When absent, the finding is presented without a confidence qualifier.

      0

      1

    • Optionaluncertainty_reason?: string

      Explanation of why confidence is below 1.0 (e.g., 'Targeting includes regions that partially overlap jurisdiction boundaries'). Present when confidence is below a governance-agent-defined threshold.

    conditions?: { field: string; required_value?: unknown; reason: string }[]

    Type Declaration

    • field: string

      Dot-path to the field that needs adjustment (in payload for proposed, in planned_delivery for committed).

    • Optionalrequired_value?: unknown

      The value the field must have for approval. When present, the condition is machine-actionable. When absent, the condition is advisory.

    • reason: string

      Why this condition is required.