You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When every accepted_verifiers[] entry errors or times out on get_creative_features, the spec doesn't say what the seller does:
Hold the creative pending retry?
Reject with a new error code?
Allow and emit a structured warning?
Allow-and-log silently?
Inconsistent supply chain behavior here is a real risk. A buyer's orchestrator can't reason about expected seller behavior if it's per-seller policy with no protocol guidance. Same creative, two sellers, different outcomes depending on which one's verifier was up that minute.
Proposed fallback states
Codify three documented seller-policy modes the seller declares on creative_policy.provenance_requirements:
hold (recommended default): seller responds to sync_creatives with action: 'pending' + new error code PROVENANCE_VERIFICATION_UNAVAILABLE and recovery: 'retry-later'. Idempotent retry expected.
reject: seller responds with action: 'failed' + PROVENANCE_VERIFICATION_UNAVAILABLE and recovery: 'correctable'. Buyer must resubmit, presumably to a seller whose verifier is up — or wait. Hard-stop mode for risk-averse sellers.
allow_with_warning: seller approves the creative but stamps the artifact with a structured governance_observations entry indicating verification was attempted and unavailable. Audit trail records the gap. Permissive mode for high-volume sellers willing to accept buyer-claim as the evidence floor when their own verifier infra is unreachable.
Default behavior if unspecified: hold. Safest default — neither blocks supply nor allows unverified claims through.
Distinct from inconclusive: an inconclusive verifier result is "I called the verifier and got a low-confidence response." This is "I could not call the verifier at all." Mirror the structure (recovery: retry-later for hold), but the error code distinguishes the root cause so a buyer's orchestrator can pick the right retry strategy.
Scope
Spec edit, not a wire change:
New paragraph in docs/governance/creative/provenance-verification.mdx documenting the three policy modes and the hold default.
New optional field verification_unavailable_policy on creative-policy.jsonprovenance_requirements object.
Conformance scenario at static/compliance/source/protocols/media-buy/scenarios/ covering each of the three modes.
Out of scope
Retry policy / backoff semantics. That's idempotency-key territory and lives in existing spec surfaces.
Defining what "unavailable" means in seconds. Seller-side policy. A seller may decide "30s timeout = unavailable"; the protocol cares about the outcome, not the threshold.
Memory: error-code.json dual surfaces — new code needs entries in both enumDescriptions and enumMetadata
Memory: KMS eager-init at boot kills deploys — analogous "verifier unreachable" failure mode at adjacent layer
Priority
Anytime. Low-risk, additive, closes a small gap pre-GA. Realistic candidate for a small docs+schema PR that could land soon after the bigger pre-GA work (signed claims, served-disclosure receipt) gets scoped.
Problem
When every
accepted_verifiers[]entry errors or times out onget_creative_features, the spec doesn't say what the seller does:Inconsistent supply chain behavior here is a real risk. A buyer's orchestrator can't reason about expected seller behavior if it's per-seller policy with no protocol guidance. Same creative, two sellers, different outcomes depending on which one's verifier was up that minute.
Proposed fallback states
Codify three documented seller-policy modes the seller declares on
creative_policy.provenance_requirements:{ "provenance_requirements": { "require_digital_source_type": true, "require_disclosure_metadata": true, "verification_unavailable_policy": "hold" } }Enum values:
hold(recommended default): seller responds tosync_creativeswithaction: 'pending'+ new error codePROVENANCE_VERIFICATION_UNAVAILABLEandrecovery: 'retry-later'. Idempotent retry expected.reject: seller responds withaction: 'failed'+PROVENANCE_VERIFICATION_UNAVAILABLEandrecovery: 'correctable'. Buyer must resubmit, presumably to a seller whose verifier is up — or wait. Hard-stop mode for risk-averse sellers.allow_with_warning: seller approves the creative but stamps the artifact with a structuredgovernance_observationsentry indicating verification was attempted and unavailable. Audit trail records the gap. Permissive mode for high-volume sellers willing to accept buyer-claim as the evidence floor when their own verifier infra is unreachable.Default behavior if unspecified:
hold. Safest default — neither blocks supply nor allows unverified claims through.Distinct from
inconclusive: aninconclusiveverifier result is "I called the verifier and got a low-confidence response." This is "I could not call the verifier at all." Mirror the structure (recovery: retry-later forhold), but the error code distinguishes the root cause so a buyer's orchestrator can pick the right retry strategy.Scope
Spec edit, not a wire change:
docs/governance/creative/provenance-verification.mdxdocumenting the three policy modes and theholddefault.verification_unavailable_policyoncreative-policy.jsonprovenance_requirementsobject.PROVENANCE_VERIFICATION_UNAVAILABLEonerror-code.json(and matching entry inenumMetadataper the dual-surface pattern from PR feat(schema): manifest.json + structured enumMetadata (closes #3725) #3738).static/compliance/source/protocols/media-buy/scenarios/covering each of the three modes.Out of scope
Refs
Priority
Anytime. Low-risk, additive, closes a small gap pre-GA. Realistic candidate for a small docs+schema PR that could land soon after the bigger pre-GA work (signed claims, served-disclosure receipt) gets scoped.