Skip to content
Merulan

Models and sandboxes

Models retain objectives, versions, and reviewed releases; Sandboxes retain bounded scenario revisions without changing live Records.

Models and sandboxes support different choices in Labs & Modeling. A Model holds a goal, versions, and releases. A Sandbox holds a separate view of data for a study.

Ownership

A Model objective names the task and its contract in the Workspace. Its versions and tests pin that meaning. A release binds one exact version to a staging or production alias. Labs & Modeling owns model meaning even when code uses the predictiveModels prefix.

A Sandbox belongs to Laboratory. Its purpose is bound at creation. Its baseline comes from an authorized Company Schema view, and its changes remain in Sandbox revisions.

In the Console, /labs/models lists Models and /labs/models/[modelId] opens one. /labs/models/new creates an objective. /labs/models/installed/[installedCapabilityId] opens installed model work. /labs/sandboxes opens the separate scenario lifecycle.

Lifecycle

A Model release request starts pending. A distinct reviewer approves or rejects it. Approval moves the alias and keeps release history. A candidate or pending request does not move the alias. Request a Model release owns the exact release contract.

A Sandbox starts active. Each edit creates a revision. A branch can diverge from an earlier revision. Archive blocks further edits. Archive does not erase evidence: retention and legal hold still govern when it can be removed.

Boundaries

A Model release is separate from an Experiment's result. A passing Evaluation supports review but does not grant a candidate live use. Consumers follow the approved alias, while retained evidence still names its exact version.

A Sandbox does not relax permission checks or write its scenario back to live Records. Declared transforms bound its edits. Its metadata shows references and evidence labels. Those labels cannot bypass data access rules.

Failures

A Model release can be rejected, and a stale request cannot overwrite a decision that has moved. Inspect the exact version and review evidence before proposing another release.

A Sandbox edit can fail with REVISION_CONFLICT when its branch head changed. A rebase can return REBASE_CONFLICT when changes cannot be replayed. A held Sandbox can archive and keep its evidence. The hold requires that evidence to stay.

Recovery

A Model recovery starts with the release decision and its affected consumers. Use those facts to choose a corrected candidate or a reviewed rollback. Inspect the objective and exact version before requesting the change.

A Sandbox recovery rereads the branch head and compares revisions before another edit. Keep the conflict evidence instead of forcing an overwrite. Read a Sandbox confirms its current state and retained references after repair or archive.