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:

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 define what happened
• Policies define the protected contract posture
• 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.