Workflows

Two workflows, and an honest note about one of them.

A workflow here is a fixed sequence of permitted operations with a declared expected output hash. If a replay produces a different hash, either the dataset moved or the code did — and both are supposed to be visible.

Registry

Workflow	Operations	Replayable from the release	Output sha256
`prime-distribution-baseline`	4	no	—
`stable-baseline`	7	yes	`5b93e5f26256…`

Why the shipped one cannot be replayed

The v1.0 package contains the promoted dataset under stable_data/shards/. It does not contain the data lake's index (lake_state/lake_index.sqlite) or the generation-1 lake shards (lake_data/primary/shards/) — those shipped in the v0.8 and v0.9 packages only. The baseline workflow addresses the lake by shard index, so from the released package it addresses nothing.

Running it against the release used to produce three unhandled exceptions and, worse, one confident answer: family_counts returned status: OK, decision: ALLOW and a full set of zero counts, having opened zero files. A missing index read exactly like a range that genuinely contains no primes.

That is repaired. An empty shard selection now raises rather than returning an empty aggregate, and the CLI reports it as status: NO_DATA with exit code 2. All four operations now refuse in the same, legible way:

shell

$ python lake/mmrf_lake_cli.py query \
    --request query_examples/family_counts.json
{
  "status": "NO_DATA",
  "reason": "No shards registered for index range [0, 20)."
}
exit 2

The replacement

The stable-shard baseline computes the same four aggregates — plus a gap histogram, the mod-6 and mod-210 residue distributions, and the magnitude bands — directly from the promoted shards, with no index and no network.

shell

python workflows/stable_baseline.py --project-root . \
    --output results_v10/stable_baseline_output.json

workflow_id: stable-baseline
workflow_version: 1.0.0
workflow sha256: 36f765220749b287cde604bbff48b2c1b31e1c212855afeac3c10498bfd22569
dataset_manifest_sha256: a5caea22a57efaac915c00dd92c655b1126e0b6d9b2b93790e48bc167733e0d1
expected output sha256: 5b93e5f26256e16f6290cea957df45aaf78de672ca0e80bf17ef2419b4d50ac3
resource estimate: under a second; ~2 MB read
safety classification: L0_PUBLIC_MATH, aggregate-only

Preconditions it enforces

The stable manifest must hash to its own recorded value.
The shard count on disk must match the manifest.
The prime count across the shards must match the manifest.
Every bit set in the family-flag column must map to a named family; an unnamed bit stops the run rather than being silently under-counted.

Each is a condition that could have failed silently, and each one is the sort of check the earlier defect got past. The results are on the research page.