manifest.json

manifest.json makes an IDS discoverable: it is what lets a user find the right artifact in the Tetra Catalog (a TetraScience internal-only feature for now) by vendor, instrument type, instrument model, software, file format, and acquisition technique.

As an IDS designer you fill in two things (introduced in the artifact overview):

• Identity — the type/namespace/slug/version that name the artifact.

• Applicability — a requirements block declaring the instrument models, acquisition modes, software, and source file formats the IDS is designed to handle.

The applicability values are keys into the Tetra Catalog (TetraScience’s controlled vocabulary), not free text. You declare only the instrument model and software (plus modes and file formats); the platform derives the remaining facets — vendor and instrument type — by following each key’s links in the catalog, so do not repeat them in the manifest. Because the values are catalog keys, a wrong or missing key means the artifact is mis-categorized or cannot be easily found.

Note

The catalog vocabulary — which term each key maps to, and how to add a term that doesn’t exist yet — lives in the catalog itself. See the ts-tetra-catalog README.

Structure

A minimal IDS manifest with a single applicability path:

{
  "type": "ids",
  "namespace": "common",
  "slug": "plate-reader-bmg-labtech",
  "version": "v5.0.0",
  "name": "Plate Reader BMG Labtech IDS",
  "description": "IDS for BMG Labtech plate readers across multiple models and modalities.",
  "requirements": [
    {
      "instruments": [
        {
          "instrument_model": "bmg-clariostar",
          "instrument_modes": ["flu-int", "luminescence", "abs-uv-spec"]
        }
      ],
      "software": { "name": "bmg-labtech-reader-control", "min_version": "v5.50" },
      "file_formats": ["csv", "txt"],
      "ts_integration": { "repo_name": "ts-agent-file-log" }
    }
  ]
}

Add one requirements entry per software / ingestion path. The same instrument can be onboarded through more than one path — for example, its data may be ingested directly via an SDK-based integration, or exported as a file and converted to IDS via a file-based integration. Give each path its own entry.

Field reference

Identity

Field	Required	Notes
type	yes	Always "ids" for an IDS artifact.
namespace	yes	Must equal the schema’s @idsNamespace (usually common).
slug	yes	Must equal @idsType and the ts-ids-<name> repo name (see artifact naming).
version	yes	Must equal @idsVersion, in vX.Y.Z form.
name	recommended	Human-readable title.
description	recommended	One or two sentences on what the IDS covers.

Applicability (requirements[])

Each entry describes one instrument-plus-software combination the IDS supports.

Field	Catalog term?	Notes
instruments[].instrument_model	yes — an instrument_key	The instrument the data comes from.
instruments[].instrument_modes	yes — instrument_technique_key values	The acquisition modes / techniques the IDS models for that instrument. May be [] when mode is not a meaningful discriminator.
software.name	yes — a software_key	The software that produced the file.
software.min_version / max_version	no	Optional free-text version bounds.
file_formats	yes — file_format_key values	The source file extensions this path covers.
ts_integration.repo_name	no	The agent/connector repo that ingests the files (e.g. ts-agent-file-log, a ts-connector-*).

When you need it

manifest.json is not required for self-service artifacts published with ts-cli, but any TetraScience-maintained IDS released from GitHub must have a complete, catalog-valid manifest. The GitHub release pipeline validates every applicability key against the Tetra Catalog and fails the build if a term isn’t registered — which is why a term you need must be added to the catalog first. Self-service ts-cli publish does not run this check, but using real catalog terms is still strongly recommended so the artifact is discoverable.

Empty requirements: the catalog_keys exception

If an IDS is not associated with any instrument vendor, you may have nothing to put in requirements — but the validator requires requirements to be non-empty. Set catalog_keys: ["any"] to bypass that check. This is the only situation where you need catalog_keys.