Proposal: Standardized Rendering Context Fields for Creative Formats

[pkras]

Problem Statement

Creative agents need to generate assets that work within specific rendering constraints, but the current AdCP creative format schema doesn't provide a way for sales agents to declare these constraints. This creates a disconnect between what creatives are generated and what environments can actually render them.

Proposal

Add standardized rendering_context fields to the creative format schema that sales agents can use to declare technical constraints and capabilities of their rendering environments.

Suggested Schema Addition (to be discussed)

{
"rendering_context": {
"sandbox_level": "iframe|safeframe|fencedframe|native",
"javascript_enabled": boolean,
"external_resources_allowed": boolean,
"max_file_size_kb": number,
"allowed_domains": ["domain1.com", "domain2.com"],
"viewport_constraints": {
"min_width": number,
"max_width": number,
"min_height": number,
"max_height": number,
"aspect_ratio": "16:9|4:3|1:1|flexible"
}
}
}

[bokelley]

@pkras I think the schema addition got cut off at the bottom?
On allowed domains is that allowed 3p domains that can get called?

[pkras]

apologies, fixed - was discussing too many things and streamlined this i think it's beneficial to add as the current schema focuses on what the creative format produces (dimensions, assets, renders), what i'd additionally address is how and where the format can be rendered (execution environment, security context, resource loading).

I guess sales agent can say "I accept 300x250 display ads" but can't say "...and they must work in a SafeFrame sandbox with no external JS." This could help creative agents generate appropriately for the rendering environment.

[bokelley]

Counter-proposal: Typed Asset Requirements

After discussing this internally, we agree the problem is real but propose a different solution.

Key Insight

The rendering context constraints (SafeFrame, external JS, etc.) aren't format-level concerns - they're HTML asset characteristics. Just as an image has width and height, HTML has sandbox compatibility and external resource constraints. These are intrinsic properties of the asset itself, not the container.

Approach

Instead of a top-level rendering_context on formats, we've implemented typed requirement schemas per asset type. The format's assets[].requirements object is now strongly typed based on asset_type:

For HTML assets:

{
  "asset_type": "html",
  "requirements": {
    "max_file_size_kb": 150,
    "sandbox": "safeframe",
    "external_resources_allowed": false,
    "allowed_domains": ["cdn.example.com"]
  }
}

For images, videos, text, URLs, etc. - each gets its own typed requirements schema with fields appropriate to that asset type.

Benefits

1. No schema overlap - viewport_constraints in the original proposal duplicated renders.dimensions
2. Scoped correctly - HTML constraints only apply to HTML assets, not to the whole format
3. Validates properly - Explicit schemas with additionalProperties: false instead of open objects
4. Clear naming - Standard formats become self-documenting: display_300x250_html_safeframe vs display_300x250_html_native

Implementation

Draft PR coming with:

• /schemas/core/requirements/html-asset-requirements.json (and others)
• Updated format.json to use typed requirements
• Documentation with SafeFrame, native, and fenced frame format examples

cc @pkras - thoughts?