Overview
A PlatformRequest is the canonical envelope that an AI platform sends to an AIP operator to initiate intent-based monetization. It is operator-agnostic: any conforming operator can process it. The schema is designed around five principles:- Consent is first-class. Every request carries an explicit consent envelope. No consent, no processing.
- Classification has two modes. The platform either sends the interaction and the operator classifies it (operator-derived), or the platform sends pre-computed signals and the operator validates them (platform-derived).
- Policy is auditable. The operator produces a structured policy decision with thresholds, basis, and sensitivity — separate from classification and monetization.
- Monetization is not just auction. The
monetizationblock supports auction as one mechanism, not the only one. - Identity is quarantined by default. Platform-internal fields live in
identity.quarantinedand must never be forwarded downstream.
Top-Level Fields
| Field | Type | Required | Description |
|---|---|---|---|
spec_version | string | Yes | "1.0" |
message_id | string | Yes | Canonical per-message identifier used for auction identity, replay, dedupe, and downstream traceability |
timestamp | string | Yes | RFC 3339 timestamp when the platform generated the request |
platform | object | Yes | The AI platform producing the request |
identity | object | Yes | Anonymous or pseudonymous subject identity |
consent | object | Yes | Effective consent state for this request |
classification_input | object | Yes | Interaction data or pre-computed signals — exactly one mode |
policy_hints | object | No | Non-binding hints from the platform |
signal_validation | object | No | Operator validation metadata (platform-derived mode only) |
policy | object | No | Auditable policy decision |
monetization | object | No | Monetization configuration and runtime controls |
Identifier Model
AIP uses one top-level identifier onPlatformRequest:
message_id: canonical conversation-turn identifier used for auction identity, replay, dedupe, and downstream traceability
messageId, treat it as a client alias that maps to canonical message_id at the API boundary.
platform
| Field | Type | Required | Description |
|---|---|---|---|
platform_id | string | Yes | Platform identifier |
role | string | Yes | Must be "platform" |
software.name | string | Yes | Software name (e.g. "assistant_app") |
software.version | string | Yes | Software version (e.g. "1.2.0") |
identity
| Field | Type | Required | Description |
|---|---|---|---|
namespace | string | Yes | Identity namespace (e.g. "platform_user") |
value_hash | string | Yes | Hashed or pseudonymous identity value |
confidence | number | No | Identity confidence (0.0–1.0) |
quarantined | object | No | Platform-internal fields that must never be forwarded downstream |
consent
Every request must carry an explicit consent envelope. The operator must not process a request where consent is denied or unknown without a policy basis for doing so.
| Field | Type | Required | Description |
|---|---|---|---|
status | string | Yes | "granted", "denied", "unknown", "not_required" |
source | string | No | Source of consent: "platform_ui", "account_setting", "jurisdiction_default" |
scope | object | Yes | What is consented to (see below) |
constraints | object | Yes | What may be forwarded downstream (see below) |
captured_at | string | No | RFC 3339 timestamp of consent capture |
proof_ref | string | No | Reference to consent proof record |
consent.scope
| Field | Type | Required | Description |
|---|---|---|---|
intent_based_monetization | boolean | Yes | Whether the current intent moment may be monetized |
agent_participation | boolean | Yes | Whether external brands, agents, tools, or buyers may participate |
measurement | boolean | Yes | Whether monetization outcome measurement is permitted |
consent.constraints
| Field | Type | Required | Description |
|---|---|---|---|
allow_identity_downstream | boolean | Yes | Whether identity information may be forwarded |
classification_input
A PlatformRequest MUST include exactly one classification input form.
| Field | Type | Required | Description |
|---|---|---|---|
type | string | Yes | "interaction" (operator-derived) or "provided_signals" (platform-derived) |
interaction | object | Conditional | Required when type is "interaction" |
signals | object | Conditional | Required when type is "provided_signals" |
If
classification_input.type is "interaction", the request is operator-derived. The platform provides the interaction data and the operator derives classification outputs from that interaction.If classification_input.type is "provided_signals", the request is platform-derived. The platform provides structured classification signals and the operator validates, normalizes, and governs those signals before using them for policy or monetization decisions.Platform-derived signals MUST NOT be treated as trusted by default. The operator remains the authoritative decision-maker for validation, policy, monetization eligibility, and downstream participation.Mode 1: Operator-Derived (type: "interaction")
Use this mode when the platform sends the interaction data and the operator performs classification.
The platform provides the user interaction, surface metadata, consent, and identity envelope. The operator then classifies intent, maps taxonomy, evaluates policy, determines monetization eligibility, and optionally runs monetization logic.
When to use:
- The platform does not run its own intent classifier
- The platform wants the operator to be the source of truth for classification
- The platform wants simpler integration
- The operator needs consistent classification across all platforms
classification_input.interaction
| Field | Type | Required | Description |
|---|---|---|---|
session | object | No | Session context |
surface | object | Yes | Surface and device metadata |
input | object | Yes | The user query and optional message history |
interaction.session
| Field | Type | Required | Description |
|---|---|---|---|
id | string | No | Session identifier |
turn_index | integer | No | Zero-based turn index in the conversation |
interaction.surface
| Field | Type | Required | Description |
|---|---|---|---|
channel | string | Yes | "conversation", "search_result", "assistant_panel", "embedded_assistant", "voice_assistant" |
interaction_mode | string | Yes | "text", "voice", "multimodal" |
platform | string | Yes | "web", "mobile", "desktop_app", "browser_extension", "api", "other" |
form_factor | string | No | "mobile", "desktop", "tablet", "speaker", "other" |
os | string | No | Operating system (e.g. "macOS", "iOS", "Android") |
app_id | string | No | Platform app or client identifier |
app_version | string | No | App version |
device_type | string | No | "phone", "laptop", "desktop", "tablet", "speaker", "tv", "other" |
browser | string | No | Browser name |
browser_version | string | No | Browser version |
locale | string | No | User locale |
country | string | No | ISO 3166-1 alpha-2 country code. Pattern: ^[A-Z]{2}$ |
interaction.input
| Field | Type | Required | Description |
|---|---|---|---|
query_text | string | Yes | The user’s raw query text |
messages | array | No | Short conversation history. Each item: { role, content } |
interaction.input.messages[]
| Field | Type | Required | Description |
|---|---|---|---|
role | string | Yes | "user", "assistant", "system", "tool" |
content | string | Yes | Message content |
Operator-derived example
Mode 2: Platform-Derived (type: "provided_signals")
Use this mode when the platform has already generated structured intent signals and sends those signals to the operator.
The platform provides structured intent output, signal provenance, optional taxonomy and inferred context. The operator then validates the provided signals, normalizes scores if needed, applies trust rules, evaluates policy, and determines monetization eligibility.
The operator MUST NOT assume that platform-provided signals are trusted by default.
When to use:
- The platform runs its own classifier
- The platform runs a certified shared classifier locally
- The platform wants lower latency or less raw interaction sharing
- The operator supports signal validation for upstream classification
classification_input.signals
| Field | Type | Required | Description |
|---|---|---|---|
source | object | Yes | Signal provenance and trust metadata |
intent | object | Yes | Structured intent classification |
iab_content | object | No | IAB Content Taxonomy mapping |
context | object | No | Inferred entities and constraints |
signals.source
| Field | Type | Required | Description |
|---|---|---|---|
type | string | Yes | "platform_model", "operator_model", "third_party" |
name | string | Yes | Model or classifier name |
version | string | Yes | Model version |
calibration_version | string | No | Calibration profile version |
trust_tier | string | No | "unverified", "self_attested", "certified", "operator_verified", "operator_hosted" |
signals.intent
| Field | Type | Required | Description |
|---|---|---|---|
type | string | Yes | "commercial", "transactional", "informational", "navigational", "support", "unsafe", "unknown" |
subtype | string | No | Interaction pattern (e.g. "comparison", "product_discovery") |
decision_phase | string | Yes | "awareness", "research", "consideration", "decision", "action", "post_purchase", "support" |
confidence | number | No | 0.0–1.0 |
commercial_score | number | No | 0.0–1.0 |
signals.iab_content
| Field | Type | Description |
|---|---|---|
taxonomy | string | Taxonomy name (e.g. "IAB Content Taxonomy") |
taxonomy_version | string | Version (e.g. "3.1") |
tier1 | string | Top-level category |
tier2 | string | Second-level category |
tier3 | string | Third-level category |
signals.context
| Field | Type | Description |
|---|---|---|
entities | string[] | Named entities from the query |
constraints | object | Decision-relevant constraints |
Platform-derived example
Normative Difference Between Modes
| Operator-Derived | Platform-Derived | |
|---|---|---|
| Input source | Interaction data | Platform-generated signals |
| Classifier owner | Operator | Platform |
| Classification authority | Operator | Platform initially; operator controls trust, policy, and eligibility |
| Best for | Consistency and auditability | Advanced integrations and lower raw data sharing |
policy_hints
Non-binding hints from the platform. The operator may use or ignore them.
| Field | Type | Description |
|---|---|---|
latency_budget_ms | integer | Requested latency budget in milliseconds |
preferred_pricing_model | string | "CPX", "CPC", "CPA" |
signal_validation
Present only when classification_input.type is "provided_signals". Contains the operator’s validation and normalization metadata for platform-derived signals.
| Field | Type | Description |
|---|---|---|
status | string | "accepted", "accepted_with_normalization", "rejected", "not_applicable" |
trust_tier_applied | string | Trust tier the operator applied to the signals |
normalized_scores.confidence | number | Operator-normalized confidence (0.0–1.0) |
normalized_scores.commercial_score | number | Operator-normalized commercial score (0.0–1.0) |
drift_risk | string | "low", "medium", "high", "unknown" |
reason | string | Human-readable explanation |
- Provenance is missing
- Trust tier is insufficient
- Calibration is unknown
- Signals fail validation
- The request falls into a restricted policy class
policy
Auditable policy decision produced after consent, classification, validation, and operator rules are applied.
| Field | Type | Description |
|---|---|---|
consent_eligibility | string | "allowed", "restricted", "not_allowed" |
monetization_eligibility | string | "allowed", "allowed_with_caution", "restricted", "not_allowed" |
decision_basis | string | See enum below |
reason | string | Human-readable explanation |
applied_thresholds | object | { confidence_min, commercial_score_min } |
sensitivity | string | "low", "medium", "high", "prohibited" |
regulated_vertical | boolean | Whether regulated-vertical controls apply |
opportunity | object | Monetization opportunity type and strength |
decision_basis values:
interaction_classification · provided_signal · normalized_signal · score_threshold · policy_override · regulated_vertical_control · manual_override · consent_denied · consent_unknown · fallback
policy.opportunity
| Field | Type | Description |
|---|---|---|
type | string | "none", "soft_recommendation", "comparison_slot", "decision_moment", "transaction_trigger" |
strength | string | "low", "medium", "high" |
monetization
Monetization configuration and runtime controls. Auction is one monetization mechanism, not the only one.
| Field | Type | Description |
|---|---|---|
enabled | boolean | Whether monetization is enabled for this request |
pricing_model | string | "CPX", "CPC", "CPA" |
auction.enabled | boolean | Whether auction is enabled |
auction.floor.amount | number | Floor price amount |
auction.floor.currency | string | ISO 4217 currency code |
Processing Expectations
For operator-derived requests
The operator SHOULD:- Derive intent from the interaction
- Produce classification outputs internally
- Use those outputs as the basis for policy and monetization decisions
For platform-derived requests
The operator SHOULD:- Inspect signal provenance
- Validate or normalize the provided signals
- Apply trust-tier logic
- Use validated or normalized signals as the basis for policy and monetization decisions
Full Example: Operator-Derived
Full Example: Platform-Derived
Validation Rules
spec_versionmust be"1.0".message_idmust be a non-empty string.timestampmust be RFC 3339.platform.rolemust be"platform".consentmust containstatus,scope, andconstraints.classification_inputmust contain exactly one ofinteractionorsignalsbased ontype.- When
typeis"interaction",interaction.input.query_textandinteraction.surfaceare required. - When
typeis"provided_signals",signals.sourceandsignals.intentare required. signals.intentmust containtypeanddecision_phase.identity.quarantinedmust never be forwarded downstream.consent.constraints.allow_identity_downstreammust be respected when forwarding identity-related data.- Raw query text and message history must never be forwarded downstream to brand agents in v1.0.