Retirement Conductor technical dossier / 0.2.0
ENGINEERING SCOPE COMPLETE · phases 00–08 Evidence snapshot: f8f533d · adoption study: NOT_RUN

The safe answer to “can we delete this column?”

Retirement Conductor turns a risky schema change into a verified campaign: it finds known consumers through DataHub, changes only an explicitly authorized Git/dbt target, validates with dbt, reconciles fresh evidence, and refuses the producer action until the declared evidence closes.

Retirement Conductor never interprets “nothing was returned” as “nothing depends on it.” If evidence is missing, stale, partial, ambiguous, contradictory, or natively unvalidated, retirement is refused.

01 / THE PRODUCT

From blast-radius report to enforceable change operation.

DataHub knows the cross-system graph. Git knows the source. dbt knows whether the changed model works. Retirement Conductor makes those authorities satisfy one continuously reconciled completion criterion.

Impact analysis stops at “these things may break.”

It can identify downstream assets, but it does not bind exact native identities, perform authorized changes, capture native validation, discover again, or stop the producer action.

Retirement Conductor owns the operational loop.

It freezes evidence scope, changes a reviewable target, accepts only valid receipts, reopens on drift, and returns a machine-enforceable decision from one canonical manifest.

A catalog deprecation flag records intent.

Flags, tickets, scores, acknowledgments, and successful API calls are context. None independently proves that a migrated consumer still behaves correctly.

The campaign records changed and validated state.

Every consumer is closed by a native validation receipt, verified removal, or proved non-applicability—or remains visibly blocking.

02 / CAMPAIGN LOOP

One field replacement. Seven controlled transitions.

The first supported vertical deliberately stays narrow: one warehouse column, one compatible replacement, one Git repository, native dbt validation, and DataHub as the context and reconciliation surface.

  1. 01Declare the exact legacy and replacement fields
  2. 02Resolve identities and inventory within a named envelope
  3. 03Freeze scope, fingerprints, policy, and target set
  4. 04Apply only the reviewed Git/dbt change
  5. 05Run dbt-native parse, build, and semantic tests
  6. 06Reconcile against fresh graph and source evidence
  7. 07Publish, verify, and permit or refuse the producer action
The result is bounded, not universal.

READY_TO_RETIRE means every consumer observed through the recorded sources has an acceptable disposition inside that fresh, completely paged evidence envelope. It never claims that invisible consumers cannot exist.

03 / ARCHITECTURE

A small deterministic control plane around existing authorities.

The system does not replace DataHub, Git, dbt, or the warehouse. It owns orchestration, durable campaign history, evidence contracts, refusal policy, and the final gate.

Evidence authorities

  • DataHub Core graph, schemas, ownership, lineage, and campaign document
  • Git commit, path, branch, and content fingerprints
  • dbt manifest, compiled model, build, and semantic tests
  • Native data-time and source-quality observations

Campaign engine

  • Pure deterministic four-way policy
  • Append-oriented SQLite event store
  • Versioned manifests, envelopes, receipts, and refusal codes
  • Exact authorization and source-precondition binding
  • Fresh reconciliation and one-time producer plan

Shared outputs

  • Canonical private campaign manifest
  • CLI inspect and explain views
  • Structurally redacted HTML report
  • Stable DataHub summary with verified read-back
  • Non-zero CI gate unless policy permits retirement

Authority stays where it belongs

DataHub remains the graph and shared-context system. Git remains authoritative for repository content. dbt remains authoritative for native validation. SQLite is the single-writer campaign transaction store. The producer workflow retains the destructive credential.

The model proposes; deterministic code decides

Model assistance may explain consumers or propose a minimal patch. It cannot decide identity uniqueness, authorization, preconditions, state transitions, receipt acceptance, or retirement readiness.

04 / POLICY

Refusal is a successful product outcome.

The policy produces exactly four decisions. Operator views, the DataHub summary, the HTML report, and the producer gate all consume the same canonical manifest instead of recomputing policy independently.

READY_TO_RETIRE

All required evidence is fresh and complete within scope, every consumer is acceptably closed, and reconciliation found no new consumer.

REVIEW_REQUIRED

Technical checks are sufficient, but a declared semantic or authority judgment still requires a responsible person.

BLOCKED

A required source, permission, identity, approval, validator, freshness bound, or pagination proof is unavailable or inconclusive.

UNSAFE

A known active, failed, stale, newly discovered, unresolved, or otherwise unacceptable consumer remains.

The gate exits zero only for READY_TO_RETIRE.

It rereads current state, validates provenance and digests, checks source and publication bindings, consumes one short-lived issued producer plan, and refuses replay. A prior green report or manifest is never reusable authorization.

05 / SUPPORTED SCOPE

Automation is intentionally narrow. Safety is not.

Git/dbt is the sole automated native mutation boundary. DataHub may reveal dashboards, notebooks, pipelines, charts, or models elsewhere; those consumers stay exact blockers until independent evidence closes them.

Inside the supported release

  • One field replaced by a compatible field in the same table
  • DataHub Core inventory, aspect reread, reconciliation, and publication
  • One explicit Git/dbt identity and reviewable one-file branch change
  • dbt parse, seed, build, tests, and source-level semantic parity
  • Single-writer SQLite state, deterministic replay, backup, and restore
  • CLI, public-safe report, durable summary, and producer refusal gate

Explicitly outside the claim

  • No Looker instance, adapter, schema, recipe, fixture, or release dependency
  • No automatic mutation of opaque non-repository consumers
  • No custom metadata graph, custom dbt compiler, or generic coding agent
  • No hosted multi-writer service or distributed scheduler
  • No production warehouse deletion during development acceptance
  • No universal safety, adoption, or customer-value claim from fixtures
06 / OBSERVED EVIDENCE

The pitch is backed by inspected runtime evidence.

The current engineering goal is complete. Evidence remains carefully typed as live local, fixture, replay, or analysis; an official dataset is still fixture data, and a local integration is not production coverage.

14/14oracle scenarios matched the real policy boundary
0false-ready outcomes across the adversarial suite
183tests in the final repository validation
1 / 12producer gate: executed once, refused twelve times
PHASE 00
COMPLETE · FIXTURE

Strict schemas, valid and refusal fixtures, package smoke test, and fixture evidence forced to remain BLOCKED.

PHASE 01
COMPLETE · FIXTURE

Append-only campaign events, deterministic replay, interruption recovery, approval and receipt binding, four-way policy, clock and integrity refusals.

PHASE 02
COMPLETE · LIVE LOCAL

Live Core resolved the exact fields, paged 31 consumers across seven pages, expanded one repository reference by at least 30 consumers, and verified one stable DataHub document without lifecycle mutation.

PHASE 03
COMPLETE · LIVE LOCAL

One exact DataHub-to-dbt identity, one-file review branches, bounded apply, dbt-native validation, compensation, idempotent reapply, and sandbox containment.

PHASE 04
COMPLETE · LIVE LOCAL

Fresh reconciliation, verified publication, one ready sentinel, late-consumer reopening, rich-graph refusal, and one-time producer-plan enforcement.

PHASE 05
COMPLETE · LIVE + FIXTURE

Canonical CLI and HTML for all four decisions, exact plan confirmation, structural redaction, responsive browser proof, 15 keyboard targets, and zero axe violations.

PHASE 06
COMPLETE · LIVE + FIXTURE

Four checksum-pinned official datasets, deterministic synthetic truth, direct DataHub aspect reread, 14/14 oracle matches, exact Git/dbt apply, and zero false readiness.

PHASE 07
COMPLETE · HARDENED

53 security, 47 fault, and 40 recovery tests; plan/apply separation; copied-store refusal; verified backup/restore; dependency, secret, and public-artifact scans.

PHASE 08
ENGINEERING COMPLETE

Reproducible 0.2.0 package, clean Python 3.11–3.14 installs, installed-wheel live reference, upgrade/rollback, confirmed state removal, and explicit independent-operator boundary.

07 / DATA QUALITY

Official DataHub data, plus synthetic truth that can fail for the right reason.

The benchmark uses official public inputs where they add realistic structure, then derives a deterministic field-retirement corpus with an independent oracle. Large databases stay in an ignored, content-addressed cache—not in the package or Git history.

Official assetQuality roleLicenseObserved and verified input
fiction-retailClean relational control and field-replacement baseCC0-1.0150,000 orders; zero observed foreign-key orphans; 9f95373e…55754
healthcareSelective downstream impact from deterministic quality defectsCC0-1.01,215 negative billing, 555 null names, 832 invalid ages, 277 date swaps; 287a47c5…ec488
nyc-taxi cleanNative freshness controlNYC public domainChecksum-pinned clean control; fef53dcc…6537d
nyc-taxi staleFresh catalog metadata over stale underlying dataNYC public domainObserved nine-day native gap; zero zero-trip mart rows; 35573de0…c9871

Pinned acquisition

All four assets come from datahub-project/static-assets at commit a6479c691dd2a40dd89563396d9c8b2b28bee83c. The registry fixes URL, revision, license evidence, byte size, SHA-256, format, and allowed archive members. First acquisition verified 312,086,528 bytes; later runs can verify strictly offline.

Observed bytes outrank prose

The pinned NYC stale database did not match its README’s three-day and empty-load description. The benchmark preserved the discrepancy and used the queried nine-day gap rather than adjusting data to make documentation appear correct.

Synthetic generation standard

Generator 1.1.0, seed 20260802, medium scale: 2,500 orders joined across ten tables with stable ordering, zero clean-control integrity failures, documented distributions, byte-identical twin generation, exact fault provenance, and an oracle that does not import campaign policy.

Truth scenarioExpected decisionRequired refusal signal
Clean isolated replacementREADY_TO_RETIRENo refusal; one verified dbt consumer
Ambiguous native/DataHub identityBLOCKEDIDENTITY_AMBIGUOUS
Incomplete lineage pageBLOCKEDEVIDENCE_PAGINATION_FAILED
Stale native data, fresh metadataBLOCKEDEVIDENCE_REQUIRED_SOURCE_INCOMPLETE
Incompatible replacement typeUNSAFESPEC_REPLACEMENT_INCOMPATIBLE
Late consumer after first reconciliationUNSAFERECONCILIATION_NEW_CONSUMER
Null inflationUNSAFEVALIDATION_RECEIPT_FAILED
Valid-category semantic driftUNSAFEVALIDATION_RECEIPT_FAILED
Unmapped categoryUNSAFEVALIDATION_RECEIPT_FAILED
Healthcare branch-selective failureUNSAFEPOLICY_CONSUMER_FAILED
Table-only lineageUNSAFEPOLICY_CONSUMER_OPAQUE
Ownership context without native validationUNSAFEPOLICY_CONSUMER_OPAQUE
Disappearing edge without closure receiptUNSAFEPOLICY_CONSUMER_STALE
Rich graph with opaque consumersUNSAFEPOLICY_CONSUMER_OPAQUE
08 / SAFETY MODEL

Every authority is narrower than the campaign.

Read, plan, apply, validate, reconcile, publish, and producer action are distinct capabilities. Authentication alone grants no mutation authority, and the campaign process never receives the producer’s destructive credential.

Before mutation

Resolve one exact native identity. Bind repository, branch, commit, file, content fingerprint, DataHub URN, dbt manifest node, policy, validator, target allowlist, approval, and expiry.

During validation

Copy the dbt project into bubblewrap with no host home, source checkout, or network namespace; constrain environment and resources; treat macros, hooks, packages, and generated content as untrusted.

At the producer gate

Reread sources and publication, verify canonical bindings, record intent before action, consume one issued plan, and refuse replay, drift, unavailable evidence, untrusted context, or a non-ready decision.

Campaign durability

Append-oriented SQLite events are authoritative over materialized cache. The store binds one resolved path and writer identity, refuses copied state and known shared filesystems, validates canonical replay before backup, and restores only to the original authority path.

Evidence hygiene

Secrets never enter specs, command arguments, manifests, public artifacts, or support packets. Raw source rows stay ignored. Public rendering structurally replaces sensitive identities before HTML generation rather than post-processing private output.

09 / EXECUTE THE PROOF

Copyable, credential-independent end-to-end verification.

Run these commands from the repository root on the supported Linux boundary. They operate only on repository-owned disposable resources and public or generated fixtures. They do not connect to production systems or provision paid services.

Safety precondition

Use a clean worktree. Do not substitute production endpoints, credentials, repositories, warehouses, or state paths. The positive producer proof writes a harmless local sentinel; it never deletes a warehouse field.

  1. Bootstrap
  2. Full repository check
  3. Data-quality benchmark
  4. Live campaign loop
  5. Installed release
  6. Inspect evidence

1. Bootstrap the pinned development environment

git status --short
uv sync --all-groups
uv run retirement-conductor --version
uv run retirement-conductor validate-spec fixtures/specs/valid.yaml
uv run retirement-conductor fixture run fixtures/specs/valid.yaml

Expected fixture decision: BLOCKED with EVIDENCE_MODE_NOT_LIVE. A positive fixture must not authorize retirement.

2. Run the repository-wide verification gate

make check
git diff --check

The recorded final run passed Ruff, formatting, strict mypy, 183 tests, repository and link validation, a 302-file secret scan, a 56-file public-artifact review, and reproducible source/wheel builds.

3. Reproduce official inputs, synthetic truth, and all 14 scenarios

# Acquires four checksum-pinned public SQLite assets on first run.
make phase06-data

# Starts only the isolated loopback Core composition.
make datahub-core-up
make phase06-benchmark
make phase06-evidence

# Re-run to prove stable semantic output and promotion.
make phase06-benchmark
make phase06-evidence

uv run python scripts/check_public_artifacts.py
uv run python scripts/check_secrets.py
git diff --check

# Stop services without deleting the isolated volumes.
make datahub-core-down

Inspect for 14/14 expected decisions, zero false readiness, 100% controlled-graph recall, exact one-file apply, three native fault failures, one ready sentinel, and late/rich refusal.

4. Execute the complete live-local campaign and producer gate

make datahub-core-up
make git-dbt-tool
make test-end-to-end
make phase04-evidence
make check
git diff --check
make datahub-core-down

The runner creates a unique ignored store, repository, campaign, writer, trusted run, artifact tree, and sentinel root. Expected outcomes: one READY_TO_RETIRE action, replay refusal, late-consumer reopening, and rich-graph refusal.

5. Verify the packaged and installed 0.2.0 release

make package
make test-install
make test-upgrade
make test-reference-campaign
make phase08-evidence
make check
git diff --check

This exercises reproducible archives, Python 3.11–3.14 clean installs, actionable preflight, installed-wheel operations, upgrade and backup-based rollback, copied-store refusal, confirmed state removal, and package uninstall.

6. Inspect the promoted public-safe evidence

jq . artifacts/public/phase06/phase06-evidence.json
jq . artifacts/public/phase06/oracle-evidence.json
jq . artifacts/public/phase06/refusal-matrix.json
jq . artifacts/public/phase07/phase07-evidence.json
jq . artifacts/public/phase08/phase08-preacceptance-evidence.json
jq . artifacts/public/phase08/operator-boundary.json

sha256sum artifacts/public/phase06/*.json
sha256sum artifacts/public/phase07/*.json
sha256sum artifacts/public/phase08/*.json

Public artifacts contain aggregates and digests—not source rows, planted row IDs, credentials, cache paths, private host paths, or raw native output.

10 / FAILURE CONTRACT

Stable refusals make missing proof actionable.

Expected failures are domain results, not unexpected exceptions. The prefix identifies the failed authority and each result retains a safe next action without leaking sensitive content.

SPEC_Invalid or unsupported retirement intent
Identical fields, incompatible replacement type, unsupported cross-table mapping, or schema-invalid configuration refuses before any source mutation.
EVIDENCE_Unavailable, partial, stale, or unverifiable evidence
Incomplete lineage paging, missing required source, fixture-only proof, stale source time, or publication mismatch prevents readiness.
IDENTITY_Missing, ambiguous, or inconsistent native identity
Display names and aliases can assist discovery, but only one exact DataHub-to-native mapping can authorize apply.
AUTH_ / SCOPE_Mutation was not explicitly and exactly authorized
Plan mode, missing approval, missing or wrong plan confirmation, expired authority, a moved source, or any target expansion refuses before mutation.
VALIDATION_Source-native validation failed or was inconclusive
A successful apply or API response never closes a consumer. Only a passed native receipt bound to the exact target and artifacts can support VALIDATED.
RECONCILIATION_ / POLICY_Fresh evidence reopened or prevented closure
A late consumer, stale receipt, table-only edge, opaque external consumer, or disappearing edge without a valid closure remains visible and non-ready.
INTEGRITY_ / RUNTIME_State, provenance, or single-writer authority is not trustworthy
Digest mismatch, corrupt event chain, copied store, wrong writer, unsupported shared filesystem, unavailable trusted clock, or missing campaign state refuses rather than repairing itself into readiness.
GATE_The producer action cannot safely execute
Wrong run provenance, drifted state, unavailable DataHub, missing verified publication, expired or replayed plan, source change, or any non-ready decision exits non-zero without another action.
11 / AGENT HANDOFF

How another agent should reason about this repository.

The repository is evidence-driven. Status changes only after commands run and artifacts are inspected; no implementation should weaken a refusal merely to obtain a positive result.

Read in this order

  1. AGENTS.md
  2. GOAL.md
  3. STATUS.md
  4. README.md and docs/PRODUCT.md
  5. PLAN.md and the relevant phase contract
  6. docs/REQUIREMENTS_TRACEABILITY.md
  7. Architecture, contracts, risks, decisions, and evidence ledger

Do not collapse these distinctions

  • Complete within an envelope ≠ globally complete
  • Metadata freshness ≠ native data freshness
  • HTTP success ≠ validated migration
  • Digest identity ≠ authorship
  • Owner acknowledgment ≠ native validation
  • Disappearing lineage ≠ consumer closure
  • Fixture proof ≠ production or customer evidence
  • Model proposal ≠ authorization or policy

Minimal agent verification loop

git status --short
uv sync --all-groups
make check
make phase06-data
make datahub-core-up
make phase06-benchmark
make phase06-evidence
make phase07-evidence
make phase08-evidence
uv run python scripts/check_secrets.py
uv run python scripts/check_public_artifacts.py
git diff --check
make datahub-core-down

Inspect artifacts after every generator. Never promote from exit status alone, never treat an implementation failure as external access, and never convert fixture output into live evidence.

12 / HONEST LIMITS

What remains unproven.

The engineering vertical is complete. Adoption and production claims are deliberately not inferred from repository work.

Independent operation

RC-018 remains NOT_RUN. No independent prospective operator has yet established whether the workflow is operable without the author, recurrent, valuable, adoptable, or fundable.

Deployment boundary

Executed on Linux x86_64 with Python 3.11–3.14, local single-writer SQLite, DataHub Core 1.6.0, MCP 0.6.0, Git, dbt/DuckDB, Docker, and bubblewrap. macOS, Windows, musl, shared or multi-writer state, a product container, and DataHub Cloud remain unexecuted.

Evidence boundary

Official and generated data are still fixtures. Live-local integration proves the mechanics against disposable sources, not production graph completeness, production identity behavior, warehouse deletion, broad market demand, or universal safety.

Release provenance

The wheel and source archive reproduce byte-for-byte and carry checksums plus a runtime SBOM, but remain unsigned. SHA-256 detects changed content; it does not prove who produced the artifact.

Residual race

The producer plan is short-lived, one-time, and checked immediately before the local sentinel. A real separately privileged warehouse transaction still owns the final external race and must call the same gate inside its trusted invocation.