Skip to main content

Concept Overview

This page defines the current operating terms and marks which pieces are implemented in this release.

Project Lifecycle​

Ideal project lifecycle using nipact:

  1. init
  2. bootstrap/register source data
  3. validate
  4. run selected workflow steps
  5. audit outputs

In this release, the CLI implements init, validate, workflow inspection, and execution for the packaged synthetic demos (colors, fmri, dfc). The maintainer real-data fMRI and DFC workflows used to develop the tutorials still depend on private data and explicit bootstrap scripts.

Execution is where declarations become recorded artifacts; see the CLI reference for the planner fields and reuse rules.

Source Index​

sources.yaml maps named source bindings to registry/runtime-relative source paths such as data/color_source.json. In generated project config, nipact.yaml points to that file with sources.index. Source-import steps declare the binding names they consume with source_inputs; selected run-plan construction resolves those bindings to files under the runtime root. Source paths stored in registry rows stay as data/...; the resolved filesystem files live under runtime_root/data/....

Output Address​

An output address is the identity of a produced artifact. In the colors processing demo, Pattern A outputs such as color_local_transform.local_color are entity-addressed: one entity in, one entity-scoped output address out.

Dependency Scope​

Dependency scope is the bounded set of inputs that a result actually depends on. The colors processing demo makes this boundary visible. A Pattern A artifact depends on one entity, and a Pattern B fit depends on a cohort manifest.

Manifest​

A manifest is the named set that binds a workflow step to a population. In the colors processing demo, demo-40 binds the Pattern B fit cohort and init binds the analysis cohort used by the color_sector_analysis workflow step.

Pattern A, Pattern B, Pattern C​

  • Pattern A: entity-local transforms
  • Pattern B: fit on a manifest-scoped population, then apply or export
  • Pattern C: planned vocabulary for bounded relation outputs over an explicit enumeration

The Colors Processing Demo page uses Pattern A and Pattern B as tutorial examples. The fMRI demo adds a small multi-output registration-shaped step, and the DFC demo adds a small cohort-analysis step. The current CLI validates generated project/runtime structure, inspects declared workflows, and runs selected workflow steps through Snakemake. Pattern C is planned vocabulary and is not demonstrated by these demos.