Skip to main content
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. Once a higher event (like task_completed) is verified, lower-tier events are not billed again.

4. Event lifecycle

Recommend mode

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

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

Example: Interaction started event

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.

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.

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.

Example: Task completed event

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: 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

Recommend mode

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

Delegate mode

  1. Platform shows delegation offer → exposure_shown logged
  2. User consents, the Operator confirms brand-agent availability and initiates the delegated session → delegation_started verified
  3. Platform and Brand Agent emit delegation_activity while the session remains active
  4. If the inactivity timeout elapses, the Operator records delegation_expired
  5. If the user completes signup through the brand agent before expiry → task_completed confirmed
  6. 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. 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.