---
name: create-mts
description: Create or revise a Modeling Technical Specification (MTS) that implements an approved Model Requirements Specification for a biological or computational model. Use when defining architecture, methods, interfaces, verification, reproducibility, delivery, Biosimulant fit, and operations; do not use to invent or weaken MRS acceptance requirements.
metadata:
  version: "2026.08.28"
---

# Create MTS

Translate an approved MRS into a traceable implementation contract. The MTS explains how the requirements will be satisfied; it does not replace, reinterpret, or weaken them.

## Gate and ground the work

1. Locate the MRS and verify its identifier, version, `Approved` status, approvals, and mandatory requirements. A full MTS requires an approved, versioned MRS. If the MRS is Draft, In review, missing, or materially inconsistent, produce only a gap analysis or clearly non-authoritative skeleton and stop before calling it a completed MTS.
2. Read [references/suite-lifecycle.md](references/suite-lifecycle.md) and [references/mts-suite-guidance.md](references/mts-suite-guidance.md).
3. Inspect relevant code, manifests, environments, model artifacts, data/partition manifests, tests, operational constraints, and native scientific runtimes before choosing the architecture.
4. Classify every component by model job. Read only the matching example reference(s):
   - predictive or ML: [references/examples/predictive-ml.md](references/examples/predictive-ml.md)
   - mechanistic: [references/examples/mechanistic.md](references/examples/mechanistic.md)
   - generative: [references/examples/generative.md](references/examples/generative.md)
   - optimization: [references/examples/optimization.md](references/examples/optimization.md)
   - simulation or digital twin: [references/examples/digital-twin.md](references/examples/digital-twin.md)
   - statistical estimation: [references/examples/statistical-estimation.md](references/examples/statistical-estimation.md)
   Read every applicable example for a hybrid model, without carrying over illustrative thresholds or claims.
5. Read [references/biosimulant-runtime.md](references/biosimulant-runtime.md) before making a Biosimulant fit decision or specifying a Biosimulant implementation. When the referenced repository is available, inspect it and treat the current code as authoritative over the snapshot.

Prefer evidence over questions. Ask only about design decisions, operational constraints, or ownership that cannot be derived from the approved MRS and project artifacts. Never invent scientific evidence, approvals, parity tolerances, resource budgets, or validation results.

## Create or revise

For a new MTS, run:

```bash
python3 <skill-dir>/scripts/start_mts.py "<Model or Project Name>" --root <project-root>
```

Resolve `<skill-dir>` to the folder containing this `SKILL.md`. The command copies the protected template to `specifications/<model-slug>/mts.md` and refuses to overwrite an existing file. Edit only the working copy.

For a revision, preserve the MTS identifier lineage, update version/date/revision history, record the decision and alternatives, assess MRS impact and revalidation impact, and keep prior evidence traceable. If the intended use or any MRS-controlled requirement changes, return the issue to the MRS owner instead of changing it in the MTS.

## Build the traceable design

- Include every mandatory MRS identifier in the traceability matrix. Map it to a component or design decision, test or validation protocol, evidence artifact, accountable owner, and the original acceptance criterion.
- Use stable `MTS-*`, component, data, and test identifiers. Derived technical requirements must name their source MRS requirement.
- Preserve scientific meaning, units, ranges, time bases, coordinate systems, uncertainty, and failure semantics across every boundary.
- Separate authoritative scientific artifacts from adapters, packages, and presentation layers. Lock data, preprocessing, equations/architecture, parameters/weights, thresholds, environments, schemas, adapters, validation protocols, and analysis plans before locked validation.
- Define invalid input, out-of-domain, nonidentifiable, infeasible, abstention, and execution-failure behavior with machine-readable status and safe user interpretation.
- Include unit, interface, data/leakage, scientific-behavior, numerical, regression, integration, robustness, performance, reproducibility, and acceptance tests as applicable.
- Distinguish verification evidence from scientific validation evidence. A package that validates and runs may still fail the MRS.

## Decide Biosimulant fit

Choose exactly one outcome and justify it with evidence:

- **Native fit:** typed, time-aware, stateful composition materially benefits the model. Retain the Biosimulant realization section.
- **Adapter fit:** the native scientific artifact remains authoritative while a frozen wrapper adds composition, inspection, packaging, or delivery value. Retain realization and specify native-runtime parity tests.
- **External boundary:** the core belongs in another runtime, with only a versioned exchange/import/export/scoring boundary if useful. Retain external delivery and do not wrap the core for uniformity.
- **Not suitable:** another stack is clearer and safer for the standalone work. Retain external delivery, reproducibility controls, and a reassessment trigger.

Only native and adapter fits require `BioModule`, `BioSignal`, `BioWorld`, model/Lab manifests, packaging, and Biosimulant execution details. Delete the conditional section that does not apply.

## Validate

Run:

```bash
python3 <skill-dir>/scripts/validate_mts.py specifications/<model-slug>/mts.md --mrs specifications/<model-slug>/mrs.md
```

An Approved MTS must pass with no errors. Then perform the required semantic review: compare every mapped acceptance criterion with the MRS, confirm that grouped mappings genuinely apply to every requirement, and verify that no technical choice changes the supported domain or evidentiary threshold.