Limits

The engine’s operational caps and defaults: what each protects, and where to tune the ones you can.

The engine ships with a small set of hard caps and tunable defaults. The caps protect instances from runaway definitions; the defaults are createEngine options.

• Cascade cap: 100 hops per cascade. A hop runs the current stage’s triggers until nothing more fires, then commits at most one transition, and the cascade repeats from the destination until nothing moves. Triggers are structurally bounded (each fires at most once per stage visit), but the hops they unblock are not, so an instance that never stabilizes stops with an error instead of spinning. Not configurable: a workflow that hits it almost always has a transition loop that never settles.
• Subworkflow depth: 6. A spawn is rejected when the child would sit more than six ancestors deep. This is the backstop against dynamic recursion (a spawn that fires conditionally on subject state), which no static cycle check can catch.
• Effect claim lease: 5 minutes (effectLeaseMs on createEngine). A drainer’s claim protects a pending effect for the lease; a claim past its lease is presumed dead, and another drainer may take the effect over. Set it longer than your slowest handler. Delivery is at-least-once either way; Effects and runtimes covers the contract.
• Effect reports: at most 32 reports may wait in a dispatch queue, and at most 200 report entries may be accepted per dispatch. commitOps reports never coalesce; pending setProgress updates to the same field keep the newest value. Await reports to apply backpressure and surface failures promptly.
• Idempotency window: 24 hours (idempotencyTtlMs on createEngine). A commit verb retried with the same idempotencyKey replays instead of double-applying while the key is inside the window; ledger rows expire after it and later keyed commits prune them.
• Definitions are immutable. Deploy is create-only and content-addressed: any change mints the next version, an identical redeploy is a no-op, and an instance pins (and snapshots) the version it started on.
• The data model is pre-1.0. Workflow documents carry a model-version stamp and reader floor. An engine older than a document’s floor refuses it. See Reader-model acknowledgement for the contract and How the prerelease works for rollout policy.

These numbers can change before 1.0. A change ships in the package changelog like any other.

• How the prerelease works: the versioning and breaking-change policy these limits live under.
• Effects and runtimes: the delivery contract behind the claim lease.
• Reference: every construct spelled out exactly, each field, type, default, and option.