Skip to main content

Data Product Manifest

The Data Product Manifest is the file that contains both Spine build input and data product metadata for a repository. By convention the on-disk name is dataspine.json at the project root (or the filename your toolchain documents). It is the only place a single file carries information that is relevant to both the Spine language build (namespaces, layout, extra libraries) and the data product as a platform object (naming, documentation, identifiers the control plane uses). For how dataspine.json fits next to spine-src/, tests, and build output, see Filesystem layout.

You can think of it as the data-product analogue of a tsconfig.json: you need it to interpret and compile sources, and it also records project-level choices that are not part of the language grammar.

What it is for​

  • Build / DSL alignment — fields such as the root namespace that must match the Spine namespace prefix for the repository layout, and library references (--lib and bundled dataspine core) the compiler merges with your sources.
  • Data product metadata — fields the control plane or build pipeline use to name, describe, and publish the product, including human-facing documentation that does not belong in a .spine file.
  • Operational and integration hooks (where your org enables them) — anything that is source-of-truth in Git but is not a Spine construct (for example default regions, or links to other manifests).

What is not in the Data Product Manifest​

  • The Spine language itself: ingests, outlets, types, and flow are defined in *.spine, not in JSON.
  • Runtime configuration for applications (endpoints, tokens) usually lives in client config and secret stores, not in dataspine.json.

What to do next​

  • Validate and compile your project with the Dataspine CLI; the CLI is the source of truth for supported fields in the Data Product Manifest for your current toolchain.
  • If you are building platform automation, pair this conceptual guide with the Admin API and product UI docs for the specific operations (create product, new version, access policies, replay, and so on). Those entry points are expected to link to the same concepts described in Data products and Spine.

A machine-readable schema and example snippets can be added here or linked from the CLI reference when the team publishes a stable, versioned document.