@adcp/sdk 8.1.0-beta.7 → 8.1.0-beta.8

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
Files changed (56) hide show
  1. package/README.md +12 -0
  2. package/dist/lib/schemas-data/v2.5/_provenance.json +1 -1
  3. package/dist/lib/types/activate-signal.d.ts +647 -0
  4. package/dist/lib/types/build-creative.d.ts +2105 -0
  5. package/dist/lib/types/calibrate-content.d.ts +675 -0
  6. package/dist/lib/types/check-governance.d.ts +619 -0
  7. package/dist/lib/types/comply-test-controller.d.ts +8428 -0
  8. package/dist/lib/types/create-collection-list.d.ts +693 -0
  9. package/dist/lib/types/create-content-standards.d.ts +830 -0
  10. package/dist/lib/types/create-media-buy.d.ts +3374 -0
  11. package/dist/lib/types/create-property-list.d.ts +836 -0
  12. package/dist/lib/types/delete-collection-list.d.ts +497 -0
  13. package/dist/lib/types/delete-property-list.d.ts +497 -0
  14. package/dist/lib/types/get-account-financials.d.ts +624 -0
  15. package/dist/lib/types/get-adcp-capabilities.d.ts +2863 -0
  16. package/dist/lib/types/get-collection-list.d.ts +763 -0
  17. package/dist/lib/types/get-content-standards.d.ts +919 -0
  18. package/dist/lib/types/get-creative-delivery.d.ts +2219 -0
  19. package/dist/lib/types/get-creative-features.d.ts +1736 -0
  20. package/dist/lib/types/get-media-buy-artifacts.d.ts +864 -0
  21. package/dist/lib/types/get-media-buys.d.ts +1670 -0
  22. package/dist/lib/types/get-plan-audit-logs.d.ts +455 -0
  23. package/dist/lib/types/get-products.d.ts +4935 -0
  24. package/dist/lib/types/get-property-list.d.ts +874 -0
  25. package/dist/lib/types/get-signals.d.ts +986 -0
  26. package/dist/lib/types/list-accounts.d.ts +851 -0
  27. package/dist/lib/types/list-content-standards.d.ts +975 -0
  28. package/dist/lib/types/list-creative-formats.d.ts +3132 -0
  29. package/dist/lib/types/list-creatives.d.ts +2390 -0
  30. package/dist/lib/types/list-property-lists.d.ts +855 -0
  31. package/dist/lib/types/log-event.d.ts +373 -0
  32. package/dist/lib/types/per-tool-index.json +391 -0
  33. package/dist/lib/types/preview-creative.d.ts +1981 -0
  34. package/dist/lib/types/provide-performance-feedback.d.ts +218 -0
  35. package/dist/lib/types/report-plan-outcome.d.ts +433 -0
  36. package/dist/lib/types/report-usage.d.ts +579 -0
  37. package/dist/lib/types/si-get-offering.d.ts +259 -0
  38. package/dist/lib/types/si-initiate-session.d.ts +372 -0
  39. package/dist/lib/types/si-send-message.d.ts +300 -0
  40. package/dist/lib/types/si-terminate-session.d.ts +213 -0
  41. package/dist/lib/types/sync-accounts.d.ts +856 -0
  42. package/dist/lib/types/sync-audiences.d.ts +707 -0
  43. package/dist/lib/types/sync-catalogs.d.ts +766 -0
  44. package/dist/lib/types/sync-creatives.d.ts +2134 -0
  45. package/dist/lib/types/sync-event-sources.d.ts +665 -0
  46. package/dist/lib/types/sync-governance.d.ts +558 -0
  47. package/dist/lib/types/sync-plans.d.ts +979 -0
  48. package/dist/lib/types/update-collection-list.d.ts +697 -0
  49. package/dist/lib/types/update-content-standards.d.ts +847 -0
  50. package/dist/lib/types/update-media-buy.d.ts +3047 -0
  51. package/dist/lib/types/update-property-list.d.ts +840 -0
  52. package/dist/lib/types/validate-content-delivery.d.ts +722 -0
  53. package/dist/lib/types/validate-input.d.ts +1683 -0
  54. package/dist/lib/version.d.ts +3 -3
  55. package/dist/lib/version.js +3 -3
  56. package/package.json +9 -2
@@ -0,0 +1,979 @@
1
+ // AUTO-GENERATED — DO NOT EDIT.
2
+ // Per-tool .d.ts slice for `sync_plans`. Built from the published
3
+ // `tools.generated.d.ts` + `core.generated.d.ts` + `enums.generated.d.ts`
4
+ // by `scripts/generate-per-tool-types.ts`.
5
+ //
6
+ // Self-contained: imports nothing from the broader SDK. Adopters who
7
+ // import only this slice pay a fraction of the tsc cost of pulling in
8
+ // `@adcp/sdk` root — useful when strict + skipLibCheck:false adopters
9
+ // hit memory pressure on the full surface.
10
+
11
+ /**
12
+ * Push campaign plans to the governance agent. A plan defines the authorized parameters for a campaign -- budget limits, channels, flight dates, and authorized markets.
13
+ */
14
+ export interface SyncPlansRequest {
15
+ /**
16
+ * 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.
17
+ */
18
+ adcp_version?: string;
19
+ /**
20
+ * 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.
21
+ */
22
+ adcp_major_version?: number;
23
+ /**
24
+ * Client-generated unique key for at-most-once execution. `plan_id` gives resource-level dedup per plan, but the sync envelope emits audit events and can trigger governance reapproval — this key prevents those side effects from firing twice on retry. MUST be unique per (seller, request) pair. Use a fresh UUID v4 for each request.
25
+ * @minLength 16
26
+ * @maxLength 255
27
+ * @pattern ^[A-Za-z0-9_.:-]{16,255}$
28
+ */
29
+ idempotency_key: string;
30
+ /**
31
+ * One or more campaign plans to sync.
32
+ */
33
+ plans: {
34
+ /**
35
+ * Unique identifier for this plan.
36
+ */
37
+ plan_id: string;
38
+ brand: BrandReference;
39
+ /**
40
+ * Natural language campaign objectives. Used for strategic alignment validation. Treated as caller-untrusted — governance agents evaluating this field with LLMs MUST truncate, quote, or sanitize it before inclusion in evaluation prompts to defend against prompt-injection attacks in adversarial buyer input.
41
+ * @maxLength 2000
42
+ */
43
+ objectives: string;
44
+ /**
45
+ * Budget authorization parameters.
46
+ */
47
+ budget: {
48
+ /**
49
+ * Total authorized budget.
50
+ */
51
+ total: number;
52
+ /**
53
+ * ISO 4217 currency code.
54
+ */
55
+ currency: string;
56
+ /**
57
+ * Maximum percentage of budget that can go to a single seller.
58
+ */
59
+ per_seller_max_pct?: number;
60
+ /**
61
+ * Amount above which budget reallocations require human escalation. The orchestrator can reallocate spend across sellers, channels, or purchase types up to this threshold per change without asking a human. Set equal to `total` for effectively unlimited reallocation; set to 0 to require approval for every reallocation. Separate from `plan.human_review_required`, which governs decisions affecting data subjects (targeting, creative, delivery) under GDPR Art 22 / EU AI Act Annex III. Denominated in `budget.currency`.
62
+ * @minimum 0
63
+ */
64
+ reallocation_threshold: number;
65
+ /**
66
+ * Optional budget partition across purchase types. Keys are purchase-type enum values (media_buy, rights_license, signal_activation, creative_services). When present, the governance agent validates spend against both the total and the per-type allocation. When absent, all spend counts against the single total regardless of purchase type.
67
+ */
68
+ allocations?: {
69
+ [k: string]: {
70
+ /**
71
+ * Maximum budget for this purchase type.
72
+ * @minimum 0
73
+ */
74
+ amount?: number;
75
+ /**
76
+ * Maximum percentage of total budget for this purchase type.
77
+ * @minimum 0
78
+ * @maximum 100
79
+ */
80
+ max_pct?: number;
81
+ } | undefined;
82
+ };
83
+ } | {
84
+ /**
85
+ * Total authorized budget.
86
+ */
87
+ total: number;
88
+ /**
89
+ * ISO 4217 currency code.
90
+ */
91
+ currency: string;
92
+ /**
93
+ * Maximum percentage of budget that can go to a single seller.
94
+ */
95
+ per_seller_max_pct?: number;
96
+ reallocation_unlimited: true;
97
+ /**
98
+ * Optional budget partition across purchase types. Keys are purchase-type enum values (media_buy, rights_license, signal_activation, creative_services). When present, the governance agent validates spend against both the total and the per-type allocation. When absent, all spend counts against the single total regardless of purchase type.
99
+ */
100
+ allocations?: {
101
+ [k: string]: {
102
+ /**
103
+ * Maximum budget for this purchase type.
104
+ * @minimum 0
105
+ */
106
+ amount?: number;
107
+ /**
108
+ * Maximum percentage of total budget for this purchase type.
109
+ * @minimum 0
110
+ * @maximum 100
111
+ */
112
+ max_pct?: number;
113
+ } | undefined;
114
+ };
115
+ };
116
+ /**
117
+ * Channel constraints. If omitted, all channels are allowed.
118
+ */
119
+ channels?: {
120
+ /**
121
+ * Channels that must be included in the media mix.
122
+ */
123
+ required?: MediaChannel[];
124
+ /**
125
+ * Channels the orchestrator may use.
126
+ */
127
+ allowed?: MediaChannel[];
128
+ /**
129
+ * Target allocation ranges per channel, keyed by channel ID.
130
+ */
131
+ mix_targets?: {
132
+ [k: string]: {
133
+ min_pct?: number;
134
+ max_pct?: number;
135
+ } | undefined;
136
+ };
137
+ };
138
+ /**
139
+ * Authorized flight dates. Governed actions with dates outside this window are rejected.
140
+ */
141
+ flight: {
142
+ /**
143
+ * Flight start (ISO 8601).
144
+ * @format date-time
145
+ */
146
+ start: string;
147
+ /**
148
+ * Flight end (ISO 8601).
149
+ * @format date-time
150
+ */
151
+ end: string;
152
+ };
153
+ /**
154
+ * ISO 3166-1 alpha-2 country codes for authorized markets (e.g., ['US', 'GB']). The governance agent rejects governed actions targeting outside these countries and resolves applicable policies by matching against policy jurisdictions.
155
+ */
156
+ countries?: string[];
157
+ /**
158
+ * ISO 3166-2 subdivision codes for authorized sub-national markets (e.g., ['US-MA', 'US-CA']). When present, the governance agent restricts governed actions to these specific regions rather than the full country. Use for plans limited to specific states or provinces (e.g., cannabis in legal states). Policy resolution matches against both the subdivision and its parent country.
159
+ */
160
+ regions?: string[];
161
+ /**
162
+ * Registry policy IDs to enforce for this plan. The governance agent resolves full policy definitions from the registry and evaluates actions against them. Intersected with the plan's countries/regions to activate only geographically relevant policies.
163
+ */
164
+ policy_ids?: string[];
165
+ /**
166
+ * Regulatory categories that apply to this campaign. Determines which policy regimes the governance agent enforces (e.g., 'children_directed' activates COPPA/AADC, 'political_advertising' activates disclosure requirements). The governance agent resolves categories to specific policies based on the plan's jurisdictions. When omitted, governance agents MAY infer categories from the brand's industries and the plan's objectives. Values are registry-defined category IDs (intentionally freeform strings, not an enum — new categories are added as regulations evolve).
167
+ */
168
+ policy_categories?: string[];
169
+ audience?: AudienceConstraints;
170
+ /**
171
+ * Personal data categories that must not be used for targeting in this campaign. Applies horizontally across all audience criteria. Used for EU DSA Article 26 compliance (prohibits targeting on GDPR Article 9 special categories) and similar regulations. The governance agent flags any audience targeting that references these attributes.
172
+ */
173
+ restricted_attributes?: RestrictedAttribute[];
174
+ /**
175
+ * Additional restricted attributes not covered by the restricted-attribute enum. Freeform strings for jurisdiction-specific or brand-specific restrictions beyond GDPR Article 9 categories (e.g., 'financial_status', 'immigration_status'). Governance agents use semantic matching for these.
176
+ */
177
+ restricted_attributes_custom?: string[];
178
+ /**
179
+ * Minimum audience segment size. Prevents micro-targeting by ensuring segments meet a k-anonymity threshold. Applies to the estimated combined (intersection) audience when multiple criteria are used, not just individual criterion sizes. The governance agent validates this by querying signal catalog metadata or seller-reported segment sizes. When segment size data is unavailable, the governance agent SHOULD produce a finding with reduced confidence rather than silently passing.
180
+ * @minimum 1
181
+ */
182
+ min_audience_size?: number;
183
+ /**
184
+ * When true, the governance agent MUST escalate any action on this plan for human review before execution — regardless of budget. Required by regulations that prohibit solely automated decisions affecting data subjects (GDPR Art 22, EU AI Act Annex III): credit, insurance pricing, recruitment, housing allocation. Governance agents MUST set this to true automatically when any resolved policy or policy_category has requires_human_review: true. Distinct from budget.reallocation_threshold, which only governs budget reallocation autonomy — human_review_required covers decisions affecting individuals (targeting, creative, delivery).
185
+ */
186
+ human_review_required?: boolean;
187
+ /**
188
+ * Bespoke policies specific to this campaign, using the same shape as registry entries. Each policy has a policy_id, enforcement (must|should), and natural-language policy text. Governance findings reference policy_id to identify which policy triggered. For quick authoring, omit version/name/category — servers default them.
189
+ */
190
+ custom_policies?: PolicyEntry[];
191
+ /**
192
+ * List of approved seller agent URLs. null means any seller.
193
+ */
194
+ approved_sellers?: string[] | null;
195
+ /**
196
+ * Agents authorized to execute against this plan. Each delegation scopes an agent's authority by budget, markets, and expiration. The governance agent validates that the requesting agent matches a delegation before approving actions.
197
+ */
198
+ delegations?: {
199
+ /**
200
+ * URL of the delegated agent.
201
+ */
202
+ agent_url: string;
203
+ authority: DelegationAuthority;
204
+ /**
205
+ * Maximum budget this agent can commit. When omitted, the agent can commit up to the plan's total budget.
206
+ */
207
+ budget_limit?: {
208
+ amount: number;
209
+ currency: string;
210
+ };
211
+ /**
212
+ * ISO 3166-1/3166-2 codes this agent is authorized for. When omitted, the agent can operate in all plan markets.
213
+ */
214
+ markets?: string[];
215
+ /**
216
+ * When this delegation expires. After expiration, the governance agent denies actions from this agent.
217
+ * @format date-time
218
+ */
219
+ expires_at?: string;
220
+ }[];
221
+ /**
222
+ * Portfolio-level governance constraints. When present, this plan acts as a portfolio plan that governs member plans. Portfolio plans define cross-brand constraints that no individual brand plan can override.
223
+ */
224
+ portfolio?: {
225
+ /**
226
+ * Plan IDs governed by this portfolio plan. The governance agent validates member plan actions against portfolio constraints.
227
+ */
228
+ member_plan_ids: string[];
229
+ /**
230
+ * Maximum aggregate budget across all member plans.
231
+ */
232
+ total_budget_cap?: {
233
+ amount: number;
234
+ currency: string;
235
+ };
236
+ /**
237
+ * Registry policy IDs enforced across all member plans, regardless of individual brand configuration.
238
+ */
239
+ shared_policy_ids?: string[];
240
+ /**
241
+ * Bespoke exclusion policies applied across all member plans, using the same shape as registry entries. Authored typically as enforcement: must policies with exclusion language in the policy text (e.g., 'No advertising on properties owned by competitor holding companies').
242
+ */
243
+ shared_exclusions?: PolicyEntry[];
244
+ };
245
+ ext?: ExtensionObject;
246
+ }[];
247
+ context?: ContextObject;
248
+ ext?: ExtensionObject;
249
+ }
250
+
251
+ /**
252
+ * Response from syncing campaign plans. Returns status and active validation categories for each plan.
253
+ */
254
+ export interface SyncPlansResponse {
255
+ /**
256
+ * Session/conversation identifier for tracking related operations across multiple task invocations. Managed by the protocol layer to maintain conversational context. Distinct from `context` (per-request opaque echo, see below).
257
+ */
258
+ context_id?: string;
259
+ context?: ContextObject;
260
+ /**
261
+ * Unique identifier for tracking asynchronous operations. Present when a task requires extended processing time. Used to query task status and retrieve results when complete.
262
+ */
263
+ task_id?: string;
264
+ status: TaskStatus;
265
+ /**
266
+ * Human-readable summary of the task result. Provides natural language explanation of what happened, suitable for display to end users or for AI agent comprehension. Generated by the protocol layer based on the task response.
267
+ */
268
+ message?: string;
269
+ /**
270
+ * ISO 8601 timestamp when the response was generated. Useful for debugging, logging, cache validation, and tracking async operation progress.
271
+ */
272
+ timestamp?: string;
273
+ /**
274
+ * 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.
275
+ */
276
+ replayed?: boolean;
277
+ adcp_error?: Error;
278
+ push_notification_config?: PushNotificationConfig;
279
+ /**
280
+ * Governance context token issued by the account's governance agent during check_governance. Buyers attach it to governed purchase requests (media buys, rights acquisitions, signal activations, creative services); sellers persist it and include it on all subsequent governance calls for that action's lifecycle. An account binds to one governance agent (see sync_governance); governance is phased across `purchase` / `modification` / `delivery`, not partitioned across specialist agents, so the envelope carries a single token for the full lifecycle.
281
+ *
282
+ * Value format: governance agents MUST emit a compact JWS per the AdCP JWS profile (see Security — Signed Governance Context). Sellers MAY verify; sellers that do not verify MUST persist and forward the token unchanged. In 3.1 all sellers MUST verify. Non-JWS values from pre-3.0 governance agents are deprecated.
283
+ *
284
+ * This is the primary correlation key for audit and reporting across the governance lifecycle.
285
+ */
286
+ governance_context?: string;
287
+ /**
288
+ * Conceptual grouping for the task-specific response data defined by individual task response schemas (e.g., get-products-response.json, create-media-buy-response.json). `payload` is a documentary construct — it is NOT a required wire field, and its on-the-wire shape depends on transport (see Transport serialization below). Task response schemas declare body fields without wrapping them in a `payload` object; the wire representation places those body fields per transport convention. On MCP the body fields appear as siblings of envelope fields at the root of the tool response; on A2A they appear inside `task.artifacts[0].parts[].DataPart`; on REST they appear at the root of the JSON body.
289
+ */
290
+ payload?: {};
291
+ /**
292
+ * 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.
293
+ */
294
+ adcp_version?: string;
295
+ /**
296
+ * 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.
297
+ */
298
+ adcp_major_version?: number;
299
+ /**
300
+ * Status for each synced plan.
301
+ */
302
+ plans: {
303
+ /**
304
+ * Plan identifier.
305
+ */
306
+ plan_id: string;
307
+ /**
308
+ * Sync result status. 'active' means sync succeeded; 'error' means sync failed.
309
+ */
310
+ status: 'active' | 'error';
311
+ /**
312
+ * Plan version (increments on each sync).
313
+ */
314
+ version: number;
315
+ /**
316
+ * Validation categories active for this plan.
317
+ */
318
+ categories?: {
319
+ /**
320
+ * Validation category identifier.
321
+ */
322
+ category_id: string;
323
+ /**
324
+ * Whether this category is active for this plan.
325
+ */
326
+ status: 'active' | 'inactive';
327
+ }[];
328
+ /**
329
+ * Policies the governance agent will enforce for this plan. Includes explicitly referenced policies from the brand compliance configuration and auto-applied policies matched by jurisdiction or policy category. Present when the governance agent supports policy resolution.
330
+ */
331
+ resolved_policies?: {
332
+ /**
333
+ * Registry policy ID.
334
+ */
335
+ policy_id: string;
336
+ /**
337
+ * How this policy was included. 'explicit': referenced in the brand compliance configuration. 'auto_applied': matched automatically by jurisdiction or policy category.
338
+ */
339
+ source: 'explicit' | 'auto_applied';
340
+ enforcement: PolicyEnforcementLevel;
341
+ /**
342
+ * Why this policy was included (e.g., 'Matched jurisdiction US and policy category pharmaceutical_advertising').
343
+ */
344
+ reason?: string;
345
+ }[];
346
+ }[];
347
+ ext?: ExtensionObject;
348
+ }
349
+
350
+ /**
351
+ * Audience targeting constraints. Defines who the campaign should reach (include) and must not reach (exclude). The governance agent evaluates seller targeting against these constraints.
352
+ */
353
+ export interface AudienceConstraints {
354
+ /**
355
+ * Desired audience criteria. The seller's targeting should align with these. Each criterion is evaluated independently — the combined targeting should satisfy at least one inclusion criterion.
356
+ */
357
+ include?: AudienceSelector[];
358
+ /**
359
+ * Excluded audience criteria. The seller's targeting must not overlap with these. Exclusions take precedence over inclusions. Used for protected groups, vulnerable communities, regulatory restrictions, or brand safety.
360
+ */
361
+ exclude?: AudienceSelector[];
362
+ }
363
+
364
+ /**
365
+ * Selects an audience by signal reference or natural language description. Uses 'type' as the primary discriminator (signal vs description). Signal selectors additionally use 'value_type' to determine the targeting expression format (matching signal-targeting.json variants).
366
+ */
367
+ export type AudienceSelector = {
368
+ /**
369
+ * Discriminator for signal-based selectors
370
+ */
371
+ type: 'signal';
372
+ signal_id: SignalID;
373
+ /**
374
+ * Discriminator for binary signals
375
+ */
376
+ value_type: 'binary';
377
+ /**
378
+ * Whether to include (true) or exclude (false) users matching this signal
379
+ */
380
+ value: boolean;
381
+ } | {
382
+ /**
383
+ * Discriminator for signal-based selectors
384
+ */
385
+ type: 'signal';
386
+ signal_id: SignalID;
387
+ /**
388
+ * Discriminator for categorical signals
389
+ */
390
+ value_type: 'categorical';
391
+ /**
392
+ * Values to target. Users with any of these values will be included.
393
+ */
394
+ values: string[];
395
+ } | {
396
+ /**
397
+ * Discriminator for signal-based selectors
398
+ */
399
+ type: 'signal';
400
+ signal_id: SignalID;
401
+ /**
402
+ * Discriminator for numeric signals
403
+ */
404
+ value_type: 'numeric';
405
+ /**
406
+ * Minimum value (inclusive). Omit for no minimum. Must be <= max_value when both are provided.
407
+ */
408
+ min_value?: number;
409
+ /**
410
+ * Maximum value (inclusive). Omit for no maximum. Must be >= min_value when both are provided.
411
+ */
412
+ max_value?: number;
413
+ } | {
414
+ /**
415
+ * Discriminator for description-based selectors
416
+ */
417
+ type: 'description';
418
+ /**
419
+ * Natural language description of the audience (e.g., 'likely EV buyers', 'high net worth individuals', 'vulnerable communities')
420
+ * @minLength 1
421
+ * @maxLength 2000
422
+ */
423
+ description: string;
424
+ /**
425
+ * Optional grouping hint for the governance agent (e.g., 'demographic', 'behavioral', 'contextual', 'financial')
426
+ */
427
+ category?: string;
428
+ };
429
+
430
+ /**
431
+ * Legacy authentication schemes for the webhook auth block. Bearer: token sent in Authorization header. HMAC-SHA256: legacy shared-secret signing. Both are deprecated; new integrations SHOULD omit the authentication block and use the RFC 9421 webhook signing profile (applicable on schemas where authentication is optional). Removed in AdCP 4.0.
432
+ */
433
+ export type AuthenticationScheme = 'Bearer' | 'HMAC-SHA256';
434
+
435
+ /**
436
+ * Brand identifier within the house portfolio. Optional for single-brand domains.
437
+ */
438
+ export type BrandID = string;
439
+
440
+ /**
441
+ * Brand reference for product discovery context. Resolved to full brand identity at execution time.
442
+ */
443
+ export interface BrandReference {
444
+ /**
445
+ * Domain where /.well-known/brand.json is hosted, or the brand's operating domain
446
+ * @pattern ^[a-z0-9]([a-z0-9-]*[a-z0-9])?(\.[a-z0-9]([a-z0-9-]*[a-z0-9])?)*$
447
+ */
448
+ domain: string;
449
+ brand_id?: BrandID;
450
+ /**
451
+ * Inline override for the brand's industries. Useful when the caller cannot modify the brand's canonical brand.json but needs to declare industries for governance (e.g., Annex III vertical detection). brand.json remains the canonical source; when omitted here, governance agents SHOULD resolve from brand.json.
452
+ */
453
+ industries?: string[];
454
+ /**
455
+ * Inline override for the brand's contestation contact point. Useful when the operator does not control brand.json but needs to discharge Art 22(3) for this plan. brand.json is canonical; when omitted, governance agents resolve brand → house → missing.
456
+ */
457
+ data_subject_contestation?: {
458
+ [k: string]: unknown | undefined;
459
+ };
460
+ /**
461
+ * Inline override for brand-kit fields normally resolved from `/.well-known/brand.json` on `domain` (logo, colors, voice, tagline). Use when brand.json is missing, stale, or inappropriate for this specific call — e.g., a campaign-scoped tagline, a co-branded creative, a freshly-rebranded color palette the brand.json hasn't shipped yet. Same inline-override pattern as `industries` and `data_subject_contestation` above: brand.json is canonical, the override is per-call. Adopters needing to override fields outside this subset (`voice_attributes`, `prohibited_terms`, etc.) MUST publish a different brand.json and reference it via a different `domain` — the inline override is intentionally narrow to a small high-traffic subset.
462
+ *
463
+ * **Merge semantics (normative).** The merge is **field-level**, not whole-object replacement. Each field within `brand_kit_override` (`logo`, `colors`, `voice`, `tagline`) is evaluated independently — when a field is present on the override the override value applies; when a field is absent the brand.json value applies (or is absent if brand.json doesn't carry one either). For composite fields (`colors.primary`, `colors.secondary`, `colors.accent`), the merge is one level deeper: each color slot is evaluated independently — a producer can override `colors.primary` while still inheriting `colors.secondary` from brand.json. SDKs MUST NOT treat a present `brand_kit_override.colors` as wiping the brand.json `colors` block entirely; only the per-slot fields present in the override take precedence. Without this rule, a partial-override semantics would diverge across SDKs and produce inconsistent rendering for the same payload.
464
+ */
465
+ brand_kit_override?: {
466
+ logo?: ImageAsset;
467
+ /**
468
+ * Override brand colors (hex strings).
469
+ */
470
+ colors?: {
471
+ /**
472
+ * @pattern ^#[0-9a-fA-F]{6}$
473
+ */
474
+ primary?: string;
475
+ /**
476
+ * @pattern ^#[0-9a-fA-F]{6}$
477
+ */
478
+ secondary?: string;
479
+ /**
480
+ * @pattern ^#[0-9a-fA-F]{6}$
481
+ */
482
+ accent?: string;
483
+ };
484
+ /**
485
+ * Override brand-voice description for surface-composed text/audio output.
486
+ */
487
+ voice?: string;
488
+ /**
489
+ * Override tagline.
490
+ */
491
+ tagline?: string;
492
+ };
493
+ }
494
+
495
+ /**
496
+ * C2PA action classification for this watermark
497
+ */
498
+ export type C2PAWatermarkAction = 'c2pa.watermarked.bound' | 'c2pa.watermarked.unbound';
499
+
500
+ /**
501
+ * Opaque correlation data that is echoed unchanged in responses. Used for internal tracking, UI session IDs, trace IDs, and other caller-specific identifiers that don't affect protocol behavior. Context data is never parsed by AdCP agents - it's simply preserved and returned.
502
+ */
503
+ export interface ContextObject {
504
+ }
505
+
506
+ /**
507
+ * Authority level granted to this agent.
508
+ */
509
+ export type DelegationAuthority = 'full' | 'execute_only' | 'propose_only';
510
+
511
+ /**
512
+ * IPTC-aligned classification of AI involvement in producing this content
513
+ */
514
+ export type DigitalSourceType = 'digital_capture' | 'digital_creation' | 'trained_algorithmic_media' | 'composite_with_trained_algorithmic_media' | 'algorithmic_media' | 'composite_capture' | 'composite_synthetic' | 'human_edits' | 'data_driven_media';
515
+
516
+ /**
517
+ * How long the disclosure must persist during content playback or display
518
+ */
519
+ export type DisclosurePersistence = 'continuous' | 'initial' | 'flexible';
520
+
521
+ /**
522
+ * Where a required disclosure should appear within a creative. Used by creative briefs to specify disclosure placement and by formats to declare which positions they can render.
523
+ */
524
+ export type DisclosurePosition = 'prominent' | 'footer' | 'audio' | 'subtitle' | 'overlay' | 'end_card' | 'pre_roll' | 'companion';
525
+
526
+ /**
527
+ * How provenance data is carried within the content
528
+ */
529
+ export type EmbeddedProvenanceMethod = 'manifest_wrapper' | 'provenance_markers';
530
+
531
+ export interface Exemplar {
532
+ /**
533
+ * A concrete scenario describing an advertising action or configuration.
534
+ */
535
+ scenario: string;
536
+ /**
537
+ * Why this scenario passes or fails the policy.
538
+ */
539
+ explanation: string;
540
+ }
541
+
542
+ /**
543
+ * Extension object for platform-specific, vendor-namespaced parameters. Extensions are always optional and must be namespaced under a vendor/platform key (e.g., ext.gam, ext.roku). Used for custom capabilities, partner-specific configuration, and features being proposed for standardization.
544
+ */
545
+ export interface ExtensionObject {
546
+ }
547
+
548
+ /**
549
+ * Governance sub-domains that a registry policy applies to. Used to indicate which types of governance agents can evaluate this policy.
550
+ */
551
+ export type GovernanceDomain = 'campaign' | 'property' | 'creative' | 'content_standards';
552
+
553
+ /**
554
+ * Override logo asset.
555
+ */
556
+ export interface ImageAsset {
557
+ /**
558
+ * Discriminator identifying this as an image asset. See /schemas/creative/asset-types for the registry.
559
+ */
560
+ asset_type: 'image';
561
+ /**
562
+ * URL to the image asset
563
+ */
564
+ url: string;
565
+ /**
566
+ * Width in pixels
567
+ * @minimum 1
568
+ */
569
+ width: number;
570
+ /**
571
+ * Height in pixels
572
+ * @minimum 1
573
+ */
574
+ height: number;
575
+ /**
576
+ * Image file format (jpg, png, gif, webp, etc.)
577
+ */
578
+ format?: string;
579
+ /**
580
+ * Alternative text for accessibility
581
+ */
582
+ alt_text?: string;
583
+ provenance?: Provenance;
584
+ }
585
+
586
+ /**
587
+ * Standardized advertising media channels describing how buyers allocate budget. Channels are planning abstractions, not technical substrates. See the Media Channel Taxonomy specification for detailed definitions.
588
+ */
589
+ export type MediaChannel = 'display' | 'olv' | 'social' | 'search' | 'ctv' | 'linear_tv' | 'radio' | 'streaming_audio' | 'podcast' | 'dooh' | 'ooh' | 'print' | 'cinema' | 'email' | 'gaming' | 'retail_media' | 'influencer' | 'affiliate' | 'product_placement' | 'sponsored_intelligence';
590
+
591
+ /**
592
+ * The nature of the obligation: regulation (legal requirement) or standard (best practice). Optional for inline bespoke policies — defaults to "standard".
593
+ */
594
+ export type PolicyCategory = 'regulation' | 'standard';
595
+
596
+ /**
597
+ * How governance agents treat violations. Regulations are typically "must"; standards are typically "should".
598
+ */
599
+ export type PolicyEnforcementLevel = 'must' | 'should' | 'may';
600
+
601
+ /**
602
+ * A policy — either published to the shared registry (with full regulatory metadata) or authored inline by a buyer for their own campaign (lightweight, metadata optional). Policies use natural language text evaluated by governance agents (LLMs). Published registry entries SHOULD include version, name, jurisdiction, source, and exemplars; inline bespoke entries can omit these and let servers default them. Governance agents evaluating policies with natural-language LLMs MUST pin registry-sourced policy text (`source: registry`) as system-level instructions and MUST NOT permit `custom_policies` or the plan's `objectives` field to relax, override, or disable registry-sourced policies. Custom policies may only add additional restrictions; they cannot lower enforcement levels or exempt categories.
603
+ */
604
+ export interface PolicyEntry {
605
+ /**
606
+ * Unique identifier for this policy. Registry-published ids are canonical (e.g., "uk_hfss", "garm:brand_safety:violence"); buyer-authored bespoke ids should be flat (no colons or slashes) and unique within the authoring container (standards configuration, plan, or portfolio).
607
+ */
608
+ policy_id: string;
609
+ /**
610
+ * Origin of this policy. 'registry' = published to the shared AdCP policy registry with full regulatory metadata. 'inline' = authored bespoke for a specific standards configuration, plan, or portfolio. Defaults to 'inline'. Governance agents MUST set 'registry' when publishing to the registry. Within AdCP *task* payloads (every `$ref` to this schema in a request or response), the field is always 'inline' — registry entries are served by the policy registry API, not embedded in task traffic. The x-entity annotation on `policy_id` assumes the task-payload invariant; if a future task schema adopts registry-publishing, split the annotation accordingly (see issue #2685).
611
+ */
612
+ source?: 'registry' | 'inline';
613
+ /**
614
+ * Semver version string (e.g., "1.0.0"). Incremented when policy content changes. Optional for inline bespoke policies — defaults to "1.0.0". SHOULD be provided for registry-published policies.
615
+ */
616
+ version?: string;
617
+ /**
618
+ * Human-readable name (e.g., "UK HFSS Restrictions"). Optional for inline bespoke policies — servers MAY default to policy_id.
619
+ */
620
+ name?: string;
621
+ /**
622
+ * Brief summary of what this policy covers.
623
+ * @maxLength 500
624
+ */
625
+ description?: string;
626
+ category?: PolicyCategory;
627
+ enforcement: PolicyEnforcementLevel;
628
+ /**
629
+ * When true, plans subject to this policy MUST set plan.human_review_required = true. Use for policies that mandate human oversight of decisions affecting data subjects — e.g., GDPR Article 22 (solely automated decisions with legal or similarly significant effects) and EU AI Act Annex III high-risk categories (credit, insurance pricing, recruitment, housing allocation). Governance agents MUST escalate any plan action whose resolved policies include requires_human_review: true. Unlike `enforcement`, this flag applies as soon as the policy is resolved — it is NOT gated by `effective_date`. Art 22 GDPR and similar foundational obligations may predate an AI-Act-specific effective date; the human-review requirement fires regardless.
630
+ */
631
+ requires_human_review?: boolean;
632
+ /**
633
+ * ISO 3166-1 alpha-2 country codes where this policy applies. Empty array means the policy is not jurisdiction-specific.
634
+ */
635
+ jurisdictions?: string[];
636
+ /**
637
+ * Named groups of jurisdictions for convenience (e.g., {"EU": ["AT","BE","BG",...]}). Governance agents expand aliases when matching against a plan's target jurisdictions.
638
+ */
639
+ region_aliases?: {
640
+ [k: string]: string[] | undefined;
641
+ };
642
+ /**
643
+ * Regulatory categories this policy belongs to (e.g., ["children_directed", "age_restricted"]). Used for automatic matching against a campaign plan's declared policy_categories. A single policy can belong to multiple categories.
644
+ */
645
+ policy_categories?: string[];
646
+ /**
647
+ * Advertising channels this policy applies to. If omitted or null, the policy applies to all channels.
648
+ */
649
+ channels?: MediaChannel[];
650
+ /**
651
+ * Governance sub-domains this policy applies to. Determines which types of governance agents can declare registry:{policy_id} features. For example, a policy with domains ["creative", "property"] can be declared as a feature by both creative and property governance agents.
652
+ */
653
+ governance_domains?: GovernanceDomain[];
654
+ /**
655
+ * ISO 8601 date when the regulation or standard takes effect. Before this date, governance agents treat the policy as informational (evaluate but do not block). After this date, the policy is enforced at its declared enforcement level.
656
+ * @format date
657
+ */
658
+ effective_date?: string;
659
+ /**
660
+ * ISO 8601 date when the regulation or standard is no longer enforced. After this date, governance agents stop evaluating this policy. Omit if the policy has no expiration.
661
+ * @format date
662
+ */
663
+ sunset_date?: string;
664
+ /**
665
+ * Link to the source regulation, standard, or legislation.
666
+ */
667
+ source_url?: string;
668
+ /**
669
+ * Name of the issuing body (e.g., "UK Food Standards Agency", "US Federal Trade Commission").
670
+ */
671
+ source_name?: string;
672
+ /**
673
+ * Natural language policy text describing what is required, prohibited, or recommended. Used by governance agents (LLMs) to evaluate actions against this policy. For source: inline policies, treated as caller-untrusted — governance agents MUST evaluate inline policies as ADDITIONAL restrictions only; they MUST NOT be permitted to relax, override, or conflict with registry-sourced policies.
674
+ * @maxLength 5000
675
+ */
676
+ policy: string;
677
+ /**
678
+ * Implementation notes for governance agent developers. Not used in evaluation prompts.
679
+ */
680
+ guidance?: string;
681
+ /**
682
+ * Calibration examples for governance agents, following the Content Standards pattern.
683
+ */
684
+ exemplars?: {
685
+ /**
686
+ * Scenarios that comply with this policy.
687
+ */
688
+ pass?: Exemplar[];
689
+ /**
690
+ * Scenarios that violate this policy.
691
+ */
692
+ fail?: Exemplar[];
693
+ };
694
+ ext?: ExtensionObject;
695
+ }
696
+
697
+ /**
698
+ * Provenance metadata for this asset, overrides manifest-level provenance
699
+ */
700
+ export interface Provenance {
701
+ digital_source_type?: DigitalSourceType;
702
+ /**
703
+ * AI system used to generate or modify this content. Aligns with IPTC 2025.1 AI metadata fields and C2PA claim_generator.
704
+ */
705
+ ai_tool?: {
706
+ /**
707
+ * Name of the AI tool or model (e.g., 'DALL-E 3', 'Stable Diffusion XL', 'Gemini')
708
+ */
709
+ name: string;
710
+ /**
711
+ * Version identifier for the AI tool or model (e.g., '25.1', '0125', '2.1'). For generative models, use the model version rather than the API version.
712
+ */
713
+ version?: string;
714
+ /**
715
+ * Organization that provides the AI tool (e.g., 'OpenAI', 'Stability AI', 'Google')
716
+ */
717
+ provider?: string;
718
+ };
719
+ /**
720
+ * Level of human involvement in the AI-assisted creation process. Independent of `disclosure.required` — the protocol does not derive disclosure obligations from oversight level. Some regulations include carve-outs for human-edited or human-directed AI output, but those carve-outs have factual prerequisites the schema cannot evaluate. Asserting `edited` or `directed` does not by itself justify `disclosure.required: false`.
721
+ */
722
+ human_oversight?: 'none' | 'prompt_only' | 'selected' | 'edited' | 'directed';
723
+ /**
724
+ * Party declaring this provenance. Identifies who attached the provenance claim, enabling receiving parties to assess trust.
725
+ */
726
+ declared_by?: {
727
+ /**
728
+ * URL of the agent or service that declared this provenance
729
+ */
730
+ agent_url?: string;
731
+ /**
732
+ * Role of the declaring party in the supply chain
733
+ */
734
+ role: 'creator' | 'advertiser' | 'agency' | 'platform' | 'tool';
735
+ };
736
+ /**
737
+ * When this provenance claim was made (ISO 8601). Distinct from created_time, which records when the content itself was produced. A provenance claim may be attached well after content creation, for example when retroactively declaring AI involvement for regulatory compliance.
738
+ * @format date-time
739
+ */
740
+ declared_at?: string;
741
+ /**
742
+ * When this content was created or generated (ISO 8601)
743
+ * @format date-time
744
+ */
745
+ created_time?: string;
746
+ /**
747
+ * C2PA sidecar manifest reference. Links to a detached cryptographic provenance manifest for this content. Note: file-level C2PA bindings break when ad servers transcode, resize, or re-encode assets. For pipelines with intermediaries, consider embedded_provenance as the primary provenance mechanism.
748
+ */
749
+ c2pa?: {
750
+ /**
751
+ * URL to the C2PA manifest store for this content
752
+ */
753
+ manifest_url: string;
754
+ };
755
+ /**
756
+ * Provenance metadata embedded within the content stream. Each entry declares one embedding layer: structured provenance data carried inside the content itself, as distinct from sidecar references (c2pa.manifest_url). Embedded provenance survives operations that break sidecar and file-level bindings: ad-server transcoding, CMS ingestion, copy-paste, reformatting, and CDN re-encoding. For ad-tech pipelines where content passes through multiple intermediaries, embedded provenance is the reliable path for provenance that persists from declaration through delivery. This is a declaration by the embedding party. The receiving party (the seller) is the verifier-of-record: it confirms the claim by calling a governance agent it trusts (typically one published in `creative_policy.accepted_verifiers`).
757
+ */
758
+ embedded_provenance?: {
759
+ method: EmbeddedProvenanceMethod;
760
+ /**
761
+ * Standard the embedding conforms to, if any (e.g., 'c2pa' for C2PA Section A.7 text manifest embedding)
762
+ */
763
+ standard?: string;
764
+ /**
765
+ * Organization that performed the embedding (e.g., 'Encypher', 'Digimarc'). Display label and audit context — not a wire identifier.
766
+ */
767
+ provider: string;
768
+ /**
769
+ * Buyer's representation that this embedding can be verified by a governance agent on the seller's `creative_policy.accepted_verifiers` list. The `agent_url` MUST match (canonicalized) one of the seller's published `accepted_verifiers[].agent_url` entries; sellers reject `sync_creatives` submissions whose `verify_agent.agent_url` is off-list with `PROVENANCE_VERIFIER_NOT_ACCEPTED`. This is buyer-supplied evidence, not buyer-driven routing — the seller is the verifier-of-record and the seller controls which agent it actually calls (the seller MAY use a different on-list agent if it determines this is more appropriate; the seller does not call buyer-asserted endpoints outside its allowlist). MAY be omitted for self-verifiable embeddings (e.g., a C2PA text manifest with a public key the seller already trusts).
770
+ */
771
+ verify_agent?: {
772
+ /**
773
+ * URL of the governance agent the buyer represents was used to embed/verify this layer. MUST use the `https://` scheme and MUST appear in the seller's `creative_policy.accepted_verifiers[].agent_url` list (canonicalized per /docs/reference/url-canonicalization: lowercase scheme and host, strip default port, normalize path dot-segments). Sellers MUST NOT call this URL until the canonicalized match is confirmed.
774
+ * @pattern ^https:\/\/
775
+ */
776
+ agent_url: string;
777
+ /**
778
+ * Optional `feature_id` the buyer represents the seller should request via `get_creative_features` (e.g., `encypher.markers_present_v2`). SHOULD match the `feature_id` declared on the matching `accepted_verifiers[]` entry, or be omitted to defer the selector to the seller. When the seller's entry pins a `feature_id`, that value wins; when neither side pins, the seller selects from the agent's `governance.creative_features` catalog.
779
+ */
780
+ feature_id?: string;
781
+ };
782
+ /**
783
+ * When the provenance data was embedded (ISO 8601)
784
+ * @format date-time
785
+ */
786
+ embedded_at?: string;
787
+ }[];
788
+ /**
789
+ * Content watermarks applied to this asset. Each entry declares one watermarking layer: a content modification that encodes an identifier or fingerprint within the asset. Watermarks differ from embedded provenance: a watermark encodes an identifier (who generated it, who owns it), while embedded provenance carries or references a structured provenance record (the full chain of custody). A single asset may carry both. Aligns with C2PA action taxonomy: c2pa.watermarked.bound (watermark linked to a C2PA manifest) and c2pa.watermarked.unbound (watermark independent of any manifest). This is a declaration by the watermarking party. The receiving party (the seller) is the verifier-of-record: it confirms the claim by calling a governance agent it trusts (typically one published in `creative_policy.accepted_verifiers`).
790
+ */
791
+ watermarks?: {
792
+ media_type: WatermarkMediaType;
793
+ /**
794
+ * Organization that applied the watermark (e.g., 'Imatag', 'Steg.AI', 'Encypher'). Display label and audit context — not a wire identifier.
795
+ */
796
+ provider: string;
797
+ /**
798
+ * Buyer's representation that this watermark can be detected by a governance agent on the seller's `creative_policy.accepted_verifiers` list. The `agent_url` MUST match (canonicalized) one of the seller's published `accepted_verifiers[].agent_url` entries; sellers reject `sync_creatives` submissions whose `verify_agent.agent_url` is off-list with `PROVENANCE_VERIFIER_NOT_ACCEPTED`. This is buyer-supplied evidence, not buyer-driven routing — the seller is the verifier-of-record and the seller controls which agent it actually calls (the seller MAY use a different on-list agent if it determines this is more appropriate; the seller does not call buyer-asserted endpoints outside its allowlist).
799
+ */
800
+ verify_agent?: {
801
+ /**
802
+ * URL of the governance agent the buyer represents was used to apply/detect this watermark. MUST use the `https://` scheme and MUST appear in the seller's `creative_policy.accepted_verifiers[].agent_url` list (canonicalized per /docs/reference/url-canonicalization: lowercase scheme and host, strip default port, normalize path dot-segments). Sellers MUST NOT call this URL until the canonicalized match is confirmed.
803
+ * @pattern ^https:\/\/
804
+ */
805
+ agent_url: string;
806
+ /**
807
+ * Optional `feature_id` the buyer represents the seller should request via `get_creative_features` (e.g., `imatag.watermark_detected`). SHOULD match the `feature_id` declared on the matching `accepted_verifiers[]` entry, or be omitted to defer the selector to the seller. When the seller's entry pins a `feature_id`, that value wins; when neither side pins, the seller selects from the agent's `governance.creative_features` catalog.
808
+ */
809
+ feature_id?: string;
810
+ };
811
+ c2pa_action?: C2PAWatermarkAction;
812
+ /**
813
+ * When the watermark was applied (ISO 8601)
814
+ * @format date-time
815
+ */
816
+ embedded_at?: string;
817
+ }[];
818
+ /**
819
+ * Regulatory disclosure requirements for this content. Indicates whether AI disclosure is required and under which jurisdictions.
820
+ */
821
+ disclosure?: {
822
+ /**
823
+ * The declaring party's claim that AI disclosure is required for this content under applicable regulations. This is a declared signal carried through the supply chain — useful as a routing and audit input — not a regulatory determination made by the protocol. Receiving parties remain responsible for their own jurisdictional analysis and should not treat `required: false` as compliance cover.
824
+ */
825
+ required: boolean;
826
+ /**
827
+ * Jurisdictions where disclosure obligations apply
828
+ */
829
+ jurisdictions?: {
830
+ /**
831
+ * ISO 3166-1 alpha-2 country code (e.g., 'US', 'DE', 'CN')
832
+ */
833
+ country: string;
834
+ /**
835
+ * Sub-national region code (e.g., 'CA' for California, 'BY' for Bavaria)
836
+ */
837
+ region?: string;
838
+ /**
839
+ * Regulation identifier (e.g., 'eu_ai_act_article_50', 'ca_sb_942', 'cn_deep_synthesis')
840
+ */
841
+ regulation: string;
842
+ /**
843
+ * Required disclosure label text for this jurisdiction, in the local language
844
+ */
845
+ label_text?: string;
846
+ /**
847
+ * How the disclosure should be rendered for this jurisdiction. Expresses the declaring party's intent for persistence and position based on regulatory requirements. Publishers control actual rendering but governance agents can audit whether guidance was followed.
848
+ */
849
+ render_guidance?: {
850
+ persistence?: DisclosurePersistence;
851
+ /**
852
+ * Minimum display duration in milliseconds for initial persistence. Recommended when persistence is initial — without it, the duration is at the publisher's discretion. At serve time the publisher reads this from provenance since the brief is not available.
853
+ * @minimum 1
854
+ */
855
+ min_duration_ms?: number;
856
+ /**
857
+ * Preferred disclosure positions in priority order. The first position a format supports should be used.
858
+ */
859
+ positions?: DisclosurePosition[];
860
+ ext?: ExtensionObject;
861
+ };
862
+ }[];
863
+ };
864
+ /**
865
+ * Third-party verification or detection results for this content. Multiple services may independently evaluate the same content. Provenance is a claim — verification results attached by the declaring party are supplementary. The enforcing party (e.g., seller/publisher) should run its own verification via get_creative_features or calibrate_content.
866
+ */
867
+ verification?: {
868
+ /**
869
+ * Name of the verification service (e.g., 'DoubleVerify', 'Hive Moderation', 'Reality Defender')
870
+ */
871
+ verified_by: string;
872
+ /**
873
+ * When the verification was performed (ISO 8601)
874
+ * @format date-time
875
+ */
876
+ verified_time?: string;
877
+ /**
878
+ * Verification outcome
879
+ */
880
+ result: 'authentic' | 'ai_generated' | 'ai_modified' | 'inconclusive';
881
+ /**
882
+ * Confidence score of the verification result (0.0 to 1.0)
883
+ * @minimum 0
884
+ * @maximum 1
885
+ */
886
+ confidence?: number;
887
+ /**
888
+ * URL to the full verification report
889
+ */
890
+ details_url?: string;
891
+ }[];
892
+ ext?: ExtensionObject;
893
+ }
894
+
895
+ /**
896
+ * Push notification configuration for async task updates (A2A and REST protocols). Echoed from the request to confirm webhook settings. Specifies URL, authentication scheme (Bearer or HMAC-SHA256), and credentials. MCP uses progress notifications instead of webhooks.
897
+ */
898
+ export interface PushNotificationConfig {
899
+ /**
900
+ * Webhook endpoint URL for task status notifications. The wire contract is unconstrained beyond `format: "uri"` — in particular, publishers SHOULD NOT enforce a destination-port allowlist by default, since buyers legitimately host receivers on non-standard TLS ports (`:9443`, `:4443`, path-routed multi-tenant gateways). The SSRF guard the protocol relies on is the IP-range check + DNS-rebinding-resistant connect pin defined in [Webhook URL validation (SSRF)](/docs/building/by-layer/L1/security#webhook-url-validation-ssrf), not port filtering. Operators who want a hardened destination-port allowlist as defense-in-depth (e.g., locked-down enterprise egress) opt in explicitly — see [Destination port: permissive by default](/docs/building/by-layer/L1/security#destination-port-permissive-by-default).
901
+ */
902
+ url: string;
903
+ /**
904
+ * Buyer-supplied correlation identifier for the operation that will produce webhooks against this registration. The seller MUST echo this value verbatim into every webhook payload's `operation_id` field (see [`mcp-webhook-payload.json`](/schemas/core/mcp-webhook-payload.json) and [Webhooks — Operation IDs](/docs/building/by-layer/L3/webhooks#operation-ids-and-url-templates)). Buyers SHOULD generate a unique value per task invocation (UUID recommended). This field is the canonical registration channel for `operation_id`; buyers MAY additionally embed the same value in the URL path or query as a routing aid for their own HTTP server, but the URL is opaque to the seller and the wire-level source of truth is this field. Sellers MUST NOT parse the URL to recover `operation_id`. Sellers that receive a webhook registration without `operation_id` MAY reject the task with `INVALID_REQUEST`.
905
+ * @minLength 1
906
+ * @maxLength 255
907
+ * @pattern ^[A-Za-z0-9_.:-]{1,255}$
908
+ */
909
+ operation_id?: string;
910
+ /**
911
+ * Optional client-provided token for webhook validation. The seller MUST echo this value verbatim in every webhook payload's `token` field (see [`mcp-webhook-payload.json`](/schemas/core/mcp-webhook-payload.json) for the receiver-side validation obligation). Length bounds give receivers a defensive range check on the echoed value; senders SHOULD generate tokens with at least 128 bits of entropy (≥22 base64url characters). This is a complementary authenticity mechanism that can layer on top of the RFC 9421 webhook signature — unlike the `authentication` block below, it is not on the 4.0 removal track. Receivers that registered both a signing key (RFC 9421) and a `token` MUST NOT treat a valid token echo as authorization to skip signature verification; both checks remain independent obligations.
912
+ * @minLength 16
913
+ * @maxLength 4096
914
+ */
915
+ token?: string;
916
+ /**
917
+ * Legacy authentication configuration (A2A-compatible). Opts the seller into Bearer or HMAC-SHA256 signing instead of the default RFC 9421 webhook profile. Deprecated; removed in AdCP 4.0. **Precedence is a switch, not a fallback:** presence of this block selects the legacy scheme; absence selects 9421. A seller MUST NOT sign the same webhook both ways, and a buyer MUST NOT attempt 'try 9421 first, fall back to HMAC' verification — signature mode is determined solely by whether this block was present at registration time. The seller's baseline 9421 webhook-signing key published at its brand.json `agents[]` `jwks_uri` does not override this selector; it is always discoverable but only used when `authentication` is omitted. See docs/building/implementation/security.mdx#webhook-callbacks for the full precedence and downgrade-resistance rules (including the `webhook_mode_mismatch` rejection a buyer MUST apply when a received webhook's signing mode does not match the registered mode).
918
+ */
919
+ authentication?: {
920
+ /**
921
+ * Array of authentication schemes. Supported: ['Bearer'] for simple token auth, ['HMAC-SHA256'] for legacy shared-secret signing. Both are deprecated; new integrations SHOULD omit `authentication` and use the RFC 9421 webhook profile.
922
+ */
923
+ schemes: AuthenticationScheme[];
924
+ /**
925
+ * Credentials for the legacy scheme. For Bearer: token sent in Authorization header. For HMAC-SHA256: shared secret used to generate signature. Minimum 32 characters. Exchanged out-of-band during onboarding.
926
+ * @minLength 32
927
+ */
928
+ credentials: string;
929
+ };
930
+ }
931
+
932
+ /**
933
+ * Personal data categories that may be restricted from use in audience targeting. Combines GDPR Article 9 special categories with US civil-rights protected classes (FHA familial_status, ADEA age). Used in two places: (1) on campaign plans via restricted_attributes to declare which categories are prohibited, and (2) on signal-definition.json via restricted_attributes to declare which categories a signal touches. Governance agents match plan restrictions against signal declarations for structural validation.
934
+ */
935
+ export type RestrictedAttribute = 'racial_ethnic_origin' | 'political_opinions' | 'religious_beliefs' | 'trade_union_membership' | 'health_data' | 'sex_life_sexual_orientation' | 'genetic_data' | 'biometric_data' | 'age' | 'familial_status';
936
+
937
+ /**
938
+ * The signal to target
939
+ */
940
+ export type SignalID = {
941
+ /**
942
+ * Discriminator indicating this signal is from a data provider's published catalog
943
+ */
944
+ source: 'catalog';
945
+ /**
946
+ * Domain of the data provider that owns this signal (e.g., 'polk.com', 'experian.com'). The signal definition is published at this domain's /.well-known/adagents.json
947
+ * @pattern ^[a-z0-9]([a-z0-9-]*[a-z0-9])?(\.[a-z0-9]([a-z0-9-]*[a-z0-9])?)*$
948
+ */
949
+ data_provider_domain: string;
950
+ /**
951
+ * Signal identifier within the data provider's catalog (e.g., 'likely_tesla_buyers', 'income_100k_plus')
952
+ * @pattern ^[a-zA-Z0-9_-]+$
953
+ */
954
+ id: string;
955
+ } | {
956
+ /**
957
+ * Discriminator indicating this signal is native to the agent (not from a data provider catalog)
958
+ */
959
+ source: 'agent';
960
+ /**
961
+ * URL of the signals agent that provides this signal (e.g., 'https://liveramp.com/.well-known/adcp/signals')
962
+ */
963
+ agent_url: string;
964
+ /**
965
+ * Signal identifier within the agent's signal set (e.g., 'custom_auto_intenders')
966
+ * @pattern ^[a-zA-Z0-9_-]+$
967
+ */
968
+ id: string;
969
+ };
970
+
971
+ /**
972
+ * Current task execution state. Indicates whether the task is completed, in progress (working), submitted for async processing, failed, or requires user input. REQUIRED on every task response envelope. Synchronous tasks (including read-only metadata calls like `get_adcp_capabilities`) MUST emit `status: "completed"`; async tasks emit `submitted`, `working`, `input-required`, etc. per their lifecycle. Agents MUST NOT emit the legacy task_status or response_status fields alongside this field — the status field is the single authoritative task state.
973
+ */
974
+ export type TaskStatus = 'submitted' | 'working' | 'input-required' | 'completed' | 'canceled' | 'failed' | 'rejected' | 'auth-required' | 'unknown';
975
+
976
+ /**
977
+ * Media category of the watermarked content
978
+ */
979
+ export type WatermarkMediaType = 'audio' | 'image' | 'video' | 'text';