Skip to main content
GoldenPipe is the orchestrator: it runs the other Golden Suite tools as pipeline stages. A PipelineConfig is a thin envelope over an ordered list of stages, and each stage delegates its real tuning to the suite tool it adapts. A stage reads and writes a shared PipeContext (the df plus an artifacts bag), so goldencheck.scan can leave a profile that goldenmatch.dedupe picks up downstream without re-profiling. This page is the stage catalog and the config-shape reference. For the exhaustive, generated knob matrix see Config matrix; for a narrative walkthrough see Overview.

Stage reference

Stages are packaging entry points discovered at runtime by StageRegistry (goldenpipe/engine/registry.py), so the set is open and extensible. load is a built-in registered unconditionally; the other seven come from the [project.entry-points."goldenpipe.stages"] table in goldenpipe/pyproject.toml. That makes 8 built-in stages. Each stage’s config block is a free-form dict passed straight through to the adapted tool, so the deep knobs for a stage live in that tool’s own config matrix (the “Deep config” column). The goldenmatch.* and goldenanalysis.report stages need their tool installed. pip install goldenpipe[golden-suite] pulls all of GoldenCheck, GoldenFlow, GoldenMatch, and GoldenAnalysis; the narrower extras ([check], [flow], [match], [analysis]) pull one each. A stage whose tool is missing fails loudly in validate() with the install hint, rather than silently no-opping.

Pipeline config shape

A pipeline is a PipelineConfig (goldenpipe/models/config.py): a name, optional default source/output, an ordered list of stages, and a decisions log. Each stage is a StageSpec: The config dict is deliberately opaque to GoldenPipe: it forwards it to the adapted tool untouched. That is why the deep knobs for goldenmatch.dedupe live in the GoldenMatch config matrix, not here.

Status enums

Every stage’s run() returns a StageResult carrying a StageStatus; the run as a whole ends in a PipeStatus (goldenpipe/models/context.py). A stage can also return a Decision (skip / abort / insert / reason) to route the rest of the pipeline, which is how the adaptive logic (skip transform when the scan is clean, route to identity resolution) is expressed.

Column context and types

Stages share more than the df: goldencheck.scan builds a ColumnContext per column (goldenpipe/models/column_context.py), goldenflow.transform enriches it with the transforms it applied, and goldenmatch consumes it to skip re-profiling. Each column carries an inferred ColumnType, a CardinalityBand, a null rate, and an is_identifier flag. Classification combines column-name heuristics, the GoldenCheck profile (null rate, cardinality, dtype), and an IQR cardinality band. Name, email, and phone are identifier types by default; date, numeric, and identifier are never identifiers. A transform record with date in its name (a GoldenFlow date fixer) confirms the column as a date and drops it as an identifier, so a cleaning fixer upstream can change how a column is matched downstream.

Example pipeline

A small end-to-end pipeline: scan, then transform, then dedupe, then report. The needs list wires the dependency graph; on_error: continue lets the report still run over whatever earlier stages produced.
Run it from the CLI or Python:
Each stage’s config block is the seam to the underlying tool. To go deeper on any one stage, follow its “Deep config” link in the table above, or see the full Config matrix for every PipelineConfig field and GOLDENPIPE_* runtime knob.