Operating interfaces

Modelsmith exposes operating interfaces so a customer team can start, supervise, review, and promote specialisation runs without turning the public docs into an implementation manual.

The important contract is the workflow state, not the local command used by an operator on a specific deployment.

Interface principles

Typed inputs

Run intake should identify the base model, benchmark version, target cluster, hardware boundary, and promotion threshold before work starts.

Structured outputs

Every run should produce machine-readable state that can also be reviewed by a human: phase, score movement, failure clusters, capacity state, and promotion readiness.

Customer-owned execution

Training and inference execute inside the approved customer boundary. Shared status should use summaries, scorecards, and review labels rather than raw logs, hostnames, filesystem paths, or opaque artefact identifiers.

Recorded decisions

Each loop transition should state why it happened. If a run continues, stalls, promotes, or rolls back, the reason belongs in the ledger.

Customer workflow

1. Select the benchmark and target model.
2. Start a governed run against the chosen cluster.
3. Monitor the iterate ledger for score movement and blocked states.
4. Review failure clusters and scenario coverage.
5. Approve promotion only when the evidence bundle and rollback posture are sufficient.