> ## Documentation Index
> Fetch the complete documentation index at: https://agenticintentprotocol.com/llms.txt
> Use this file to discover all available pages before exploring further.

# AIP Events

> How AIP tracks exposure_shown, interaction_started, delegation_started, delegation_activity, delegation_expired, and task_completed for auditable settlement.

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

### Recommend mode

```mermaid theme={null}
stateDiagram-v2
    [*] --> ParticipationShown
    ParticipationShown --> InteractionStarted: User engages
    InteractionStarted --> TaskCompleted: User completes action
    TaskCompleted --> [*]
```

### Delegate mode

```mermaid theme={null}
stateDiagram-v2
    [*] --> ParticipationShown
    ParticipationShown --> DelegationStarted: User consents to handoff
    DelegationStarted --> DelegationActive: Platform/Brand Agent activity
    DelegationActive --> DelegationActive: More activity
    DelegationActive --> DelegationExpired: Inactivity timeout
    DelegationStarted --> TaskCompleted: User completes task
    DelegationActive --> TaskCompleted: User completes task
    DelegationExpired --> [*]
    TaskCompleted --> [*]
```

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

```json theme={null}
{
  "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

```json theme={null}
{
  "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.

```json theme={null}
{
  "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.

```json theme={null}
{
  "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.

```json theme={null}
{
  "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

```json theme={null}
{
  "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

### 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.

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