Simulations

# Simulations

Simulations are part of the onboarding and operating story.

They should not be treated as a detached pricing widget that sits beside the
real product.

## Why Simulations Matter

At launch, simulations give operators a safe way to:

- size the initial program shape
- save an artifact that can be shared internally
- rehearse the business consequences of events, claims, and payouts
- prove first value in sandbox before switching a workspace to live

## Current Role In The Launch Flow

The intended sequence is:

```text
sandbox key
  -> webhook capture
  -> simulation artifact
  -> lifecycle proof
  -> explicit live activation
```

That means the simulation surface should feel guided and operational, not
abstract.

## What A Saved Simulation Should Do

A saved simulation should provide:

- a named scenario for the workspace
- a preserved artifact that can be revisited or exported
- a clear summary of protected notional, expected claims, payout posture, and
  automation shape
- a bridge into the wider lifecycle rather than a dead-end calculator

## Relationship To Public API Concepts

Simulations are not the same thing as the canonical Auk runtime entities.

They sit beside them as rehearsal and planning infrastructure:

- [Events](/api/events/) define what happened
- [Policies](/api/policies/) define the protected contract posture
- [Claims and Payouts](/api/claims-and-payouts/) define the runtime outcome
- simulations help operators prepare for those outcomes before the live path is
  activated

## Public Boundary

The simulation concept should stay public and explainable without exposing
private planning logic, internal commercial experiments, or unreleased
control-plane mechanics.