Concepts
Schema Vs Executor Support
How to understand features that are modeled in schemas but not fully executable in the current local engine.
isplay intentionally models more of the replay and experiment domain than the local engine fully executes today. This is useful because adapters, managed runtimes, and future executors need a stable vocabulary, but documentation must be honest about the difference.
Three Support Levels
| Level | Meaning | Example |
|---|---|---|
| Schema-supported | The value or record shape exists in @isplay/core. | live-explicit tool policy. |
| API-supported | The server accepts, stores, or returns the shape. | Experiment trial plans include concurrency. |
| Executor-supported | Runtime code actually performs the behavior. | Recorded model replay and pause-for-fixture tool replay. |
Important Current Boundaries
| Area | Current local behavior |
|---|---|
| Live model replay | Schema exists; local engine errors without an explicit model executor. |
| Live tool replay | Schema exists; local engine errors without an explicit tool executor. |
| Experiment concurrency | Parsed but current runner is serial. |
maxReplays and stopRule | Parsed but not fully enforced by the current runner. |
RunExperiment.wait and CLI --no-wait | Implemented for replay and experiment jobs through Graphile Worker. |
| Worker jobs | Replay and experiment jobs execute durably; diff/metric/export jobs are not separate tasks yet. |
| Redaction encryption | Not a capture policy action in v0.3; use explicit storage/encryption outside capture policy. |
How To Read Docs And Results
If a page says "schema-supported," treat it as a contract shape, not a runtime promise. If a page says "supported by the current local engine," the repository code implements it without an external executor.
For final reports, name the runtime support level:
This experiment used schema-supported `live-readonly` policy, but no live tool executor was configured, so the replay did not execute the live branch.