AIP Events

Every measurable action in AIP is recorded as an Event. AIP measures the lifecycle of a decision, not just isolated interactions.

1. TL;DR

Events track and verify each stage of the decision lifecycle: participation, interaction, delegation, and outcome.

2. Why it matters

Traditional systems rely on opaque tracking pixels and fragmented attribution. AIP replaces those with signed, timestamped events tied to a single serve_token that can be independently verified by all participants. This means:

No duplicate billing
No fabricated interactions
Transparent proof of every settled action
Full lifecycle visibility from participation to outcome

3. Decision lifecycle events

AIP defines four progressive event stages - each building on the last. Only the highest-value event in a lifecycle is billable per serve_token.

Event	Type	Trigger	Settlement Unit	Mode
Exposure shown	`exposure_shown`	Commercial response surfaced to user	CPX	Both
Interaction started	`interaction_started`	User engaged with recommendation	CPE or CPC	Both
Delegation started	`delegation_started`	Session handoff initiated	-	Delegate only
Delegation activity	`delegation_activity`	Platform or Brand Agent proves the delegated session is still active	-	Delegate only
Delegation expired	`delegation_expired`	Operator marks the delegated session inactive or closed before completion	-	Delegate only
Task completed	`task_completed`	User completed a signup, purchase, or action	CPA	Both

Once a higher event (like task_completed) is verified, lower-tier events are not billed again.

Metric	Meaning
`CPX`	Cost per Exposure
`CPE`	Cost per Engagement
`CPC`	Cost per Click
`CPA`	Cost per Action

4. Event lifecycle

Delegate mode

Each transition is verified and timestamped. If no further event occurs, the lifecycle ends at the last verified state.

5. EventPacket schema

All events share common required fields that link them back to the selection and enable verification.

Common required fields

Field	Type	Description
`event_type`	string	Event type identifier (`exposure_shown`, `interaction_started`, `delegation_started`, `delegation_activity`, `delegation_expired`, or `task_completed`)
`serve_token`	string	Serve token from the `PlatformResponse` - links event to original selection
`ts`	string	ISO 8601 timestamp of when the event occurred

Event-specific fields

At the protocol level, events require event_type, serve_token, and ts. Each event type has additional required and optional fields that are implementation-specific.

Example: Exposure shown event

{
  "event_type": "exposure_shown",
  "serve_token": "stk_abcxyz123",
  "session_id": "s_001",
  "platform_id": "pf_chatapp",
  "agent_id": "ag_123",
  "wallet_id": "w_890",
  "settlement": {
    "unit": "CPX",
    "amount_micros": 34000,
    "currency": "USD"
  },
  "ts": "2025-11-11T18:00:00Z"
}

Example: Interaction started event

{
  "event_type": "interaction_started",
  "serve_token": "stk_abcxyz123",
  "session_id": "sess_789",
  "platform_id": "pf_chatapp",
  "agent_id": "ag_123",
  "wallet_id": "w_890",
  "settlement": {
    "unit": "CPC",
    "amount_micros": 450000,
    "currency": "USD"
  },
  "interaction_metadata": {
    "source": "button",
    "position": 1
  },
  "ts": "2025-11-11T18:00:30Z"
}

Example: Delegation started event

This event is emitted by the Operator after the Platform has collected user consent and the Operator has confirmed that the selected Brand Agent can accept the delegated session. It proves that the delegated session was authorized and initiated. It does not mean the Operator transports or inspects every subsequent turn in the live delegated session.

{
  "event_type": "delegation_started",
  "serve_token": "stk_abcxyz123",
  "session_id": "sess_789",
  "platform_id": "pf_chatapp",
  "agent_id": "ag_123",
  "delegation_session_id": "del_sess_001",
  "ts": "2025-11-11T18:01:00Z"
}

Example: Delegation activity event

This non-billable event is emitted by either the Platform or the Brand Agent while the delegated session remains active. Each verified delegation_activity resets the inactivity timer for the delegated session.

{
  "event_type": "delegation_activity",
  "serve_token": "stk_abcxyz123",
  "session_id": "sess_789",
  "platform_id": "pf_chatapp",
  "agent_id": "ag_123",
  "delegation_session_id": "del_sess_001",
  "actor_role": "platform",
  "activity_type": "user_turn",
  "activity_metadata": {
    "turn_index": 2
  },
  "ts": "2025-11-11T18:05:00Z"
}

Example: Delegation expired event

This non-billable event is recorded by the Operator when the delegated session expires before task completion, usually because the inactivity timeout elapsed.

{
  "event_type": "delegation_expired",
  "serve_token": "stk_abcxyz123",
  "session_id": "sess_789",
  "platform_id": "pf_chatapp",
  "agent_id": "ag_123",
  "delegation_session_id": "del_sess_001",
  "reason": "inactivity_timeout",
  "ts": "2025-11-11T18:20:00Z"
}

Example: Task completed event

{
  "event_type": "task_completed",
  "serve_token": "stk_abcxyz123",
  "session_id": "sess_789",
  "platform_id": "pf_chatapp",
  "agent_id": "ag_123",
  "wallet_id": "w_890",
  "outcome_type": "signup",
  "outcome_value_micros": 0,
  "settlement": {
    "unit": "CPA",
    "amount_micros": 10000000,
    "currency": "USD"
  },
  "ts": "2025-11-11T18:30:00Z"
}

The serve_token links each event back to the original selection and selected agent.

6. Verification process

Operators define their own verification logic for each event type. Acceptable signal sources include:

Event Type	Signal Sources (Informational)
Exposure shown	Platform display logs, visibility events, viewability metrics
Interaction started	Platform interaction logs, user engagement events, timestamp validation
Delegation started	Operator session records, brand agent session confirmation
Delegation activity	Platform session activity, brand agent turn logs, liveness heartbeats
Delegation expired	Operator inactivity timer, max-turn enforcement, operator session controls
Task completed	Brand agent callbacks, server-side API confirmations, outcome tracking

Every event is digitally signed and validated against the original serve_token. Operators implement their own verification and reconciliation logic to ensure event integrity. In delegated flows, operators verify session start, track liveness from activity events sent by both the Platform and Brand Agent, and record expiry or outcomes even when the live task turns after session initiation are direct between the Platform and Brand Agent.

7. Example flow

Platform renders a commercial recommendation → exposure_shown logged
User clicks the recommendation → interaction_started verified
User signs up on brand’s site → task_completed confirmed
Lower events (exposure_shown, interaction_started) are marked as verified but not billed

Delegate mode

Platform shows delegation offer → exposure_shown logged
User consents, the Operator confirms brand-agent availability and initiates the delegated session → delegation_started verified
Platform and Brand Agent emit delegation_activity while the session remains active
If the inactivity timeout elapses, the Operator records delegation_expired
If the user completes signup through the brand agent before expiry → task_completed confirmed
Only task_completed (CPA) is billed

8. Settlement implications

Operators determine settlement based on verified events according to the event lifecycle: Settlement rule: Only the highest-value event in a lifecycle is billable.

Highest verified event	What is billed
`task_completed`	CPA
`interaction_started`	CPE or CPC
`delegation_started`	Operator-defined
`exposure_shown`	CPX

delegation_activity and delegation_expired are non-billable lifecycle control events. Settlement terms, revenue sharing, and payout schedules are defined by each operator’s policies and agreements with platforms and brand agents.

9. Guarantees

Each event is uniquely linked to a serve token
Events cannot be duplicated or retroactively modified
Signatures are auditable by any party in the chain
Settlement data is mathematically verifiable
Only the highest-value event per lifecycle is billable

Summary

Events are the backbone of AIP - they turn user decisions into verified, auditable, and settled outcomes across the full participation lifecycle.

Welcome

Get Started

AI Platforms

Publisher Access Governance (PAG)

Common

1. TL;DR

2. Why it matters

3. Decision lifecycle events

4. Event lifecycle

Delegate mode

5. EventPacket schema

Common required fields

Event-specific fields

Example: Exposure shown event

Example: Interaction started event

Example: Delegation started event

Example: Delegation activity event

Example: Delegation expired event

Example: Task completed event

6. Verification process

7. Example flow

Delegate mode

8. Settlement implications

9. Guarantees

Summary

Welcome

Get Started

AI Platforms

Publisher Access Governance (PAG)

Common

​1. TL;DR

​2. Why it matters

​3. Decision lifecycle events

​4. Event lifecycle

​Recommend mode

​Delegate mode

​5. EventPacket schema

​Common required fields

​Event-specific fields

​Example: Exposure shown event

​Example: Interaction started event

​Example: Delegation started event

​Example: Delegation activity event

​Example: Delegation expired event

​Example: Task completed event

​6. Verification process

​7. Example flow

​Recommend mode

​Delegate mode

​8. Settlement implications

​9. Guarantees

​Summary

1. TL;DR

2. Why it matters

3. Decision lifecycle events

4. Event lifecycle

Recommend mode

Delegate mode

5. EventPacket schema

Common required fields

Event-specific fields

Example: Exposure shown event

Example: Interaction started event

Example: Delegation started event

Example: Delegation activity event

Example: Delegation expired event

Example: Task completed event

6. Verification process

7. Example flow

Recommend mode

Delegate mode

8. Settlement implications

9. Guarantees

Summary