Outcome lifecycle

Outcomes are state machines. Understanding settlement tells you exactly when events are accepted and when an outcome resolves.

States

An outcome is always in one of four states:

State	Description
`OPEN`	Accepting events. The success condition has not become true yet.
`PENDING`	The success condition became true at least once. The current result is provisional until settlement.
`CONFIRMED`	The outcome was confirmed. Terminal state.
`FAILED`	The outcome failed. Terminal state.

All transitions happen in one of two ways:

Event submission. When you call POST /v1/events with a new key, the first event creates the outcome and snapshots the agent contract. Every accepted event is appended to the event log, the condition is re-evaluated, and the settlement timer resets to now plus the agent's settlement_period.
Settlement. A scheduled job runs every minute and settles outcomes whose timer has expired: OPEN becomes FAILED, PENDING becomes CONFIRMED or FAILED based on whether the condition is currently true.

The settlement window is controlled by settlement_period on the agent contract (default: 72 hours). Every event pushes the window forward.

{ "settlement_period": 259200 }

Field	Unit	Default	Min	Max
`settlement_period`	seconds	259,200 (72 h)	1	15,552,000 (180 days)

If an event includes properties.settles_at, that timestamp is used as the window close time instead.

OPEN and PENDING outcomes both accept events.
Events for CONFIRMED or FAILED outcomes return 202 and are discarded. The outcome is not reopened.
For condition evaluation, the latest properties.value for each action is used. Earlier events remain in the log and can still affect billing through attribution_method.
The condition is re-evaluated from scratch on every submission against the full event log.