Skip to main content
GoldenAnalysis is the suite’s read-only metrics and reporting layer. It never transforms data, mutates a store, or makes a pipeline decision. It consumes the typed artifacts another package already produced and emits one unified, comparable, exportable AnalysisReport. The flagship surface is the analyzer catalog. Each analyzer takes a typed input (a raw frame, a GoldenMatch result, a GoldenPipe run) and computes a set of dotted, stable Metric keys plus optional embeddable tables. An analyze run resolves the requested analyzers, runs each one, and merges their metrics and tables into a single report.

Analyzer reference

Every analyzer degrades gracefully: it emits the metrics its present artifacts support and simply omits the rest. match.rates with no certificate skips the recall metrics; quality.rollup with only a manifest skips the quality.* keys and keeps the flow.* keys. Requested names that are not discoverable are recorded in report.source["unavailable"] rather than raising, so the report says what it could and could not compute.

An open, extensible registry

The four analyzers above are the built-in set, but the catalog is not closed. Analyzers are discovered through the goldenanalysis.analyzers entry-point group, so a third-party package can register its own analyzer by declaring an entry point, with no edit to GoldenAnalysis itself. The registry unions the entry-point table with a hard-coded fallback map that mirrors it (editable installs sometimes cannot see their own entry points), so discovery stays reliable either way.
An analyzer is anything with an info descriptor (its name, what it consumes, what it produces) and a run(inp) method that returns metrics and tables. That protocol is the whole contract a new analyzer implements.

Configuring a run

Every analyze path funnels through one internal assembler, so the same four options mean the same thing everywhere: Three entry points cover the common shapes:
  • analyze(df, analyzers=None, ...) is the generic frame path. It works on any Polars DataFrame with zero suite dependencies installed. analyzers=None runs every frame-compatible analyzer (currently frame.summary); pass an explicit list to narrow it.
  • analyze_match(result, ...) analyzes a GoldenMatch DedupeResult, running match.rates + cluster.distribution. Pass certificate= to feed the recall metrics; omit it and they are dropped.
  • analyze_pipeline(result, ...) analyzes a whole GoldenPipe PipeResult, fanning out to every analyzer whose consumed artifacts are actually present in the run.

The metrics model

Every analyzer emits a list of Metric records. A metric is a dotted, stable key, a value, an optional unit, and a direction. Keys are the cross-run contract: renaming one breaks comparability across a history, so a rename is a schema_version bump on the report. The direction is what makes a metric gateable. It tells the regression layer which way is “worse”:

Regression gating

Metrics become gates when you compare a report against a baseline with a regression policy. The full mechanics live in cross-run analysis; the two knobs are: Baseline picks what “the last run” means: RegressionPolicy sets how much movement counts. default_pct is the percent change from the baseline that flags any metric; per_metric overrides it per key for the metrics you care about most. The policy always respects each metric’s direction, so a lower_better metric flags only on an increase and a higher_better metric only on a decrease.

Reading the report

Every entry point returns one AnalysisReport. Run it, then read the merged metrics and tables:
AnalysisReport and Metric are snake_case wire types on every surface, so a report crosses the JSON wire between Python and TypeScript without remapping.

More

  • Overview — where GoldenAnalysis sits in the suite and how it differs from GoldenCheck.
  • Config matrix — the full option surface across the analyze entry points.
  • Cross-run analysis — trend metrics over a run history and detect regressions vs a baseline.