Skip to content

dpone ops operational controls

dpone ops is the self-service operational toolbox for local, CI, staging, and production-like runs. It is not a separate runtime mode. The same commands are safe to use before a local smoke test, in manual certification, or during an incident review.

Command map

Capability Command Purpose
Artifact index dpone ops artifact-index Index .dpone/ and test_artifacts/ ops artifacts for GitHub Pages and CI.
Run registry dpone ops run-registry Record dpone run results and attached evidence as immutable checksumed run entries.
OpenLineage export dpone ops lineage-export Export a run registry entry as an OpenLineage-compatible event.
dbt lineage dpone ops dbt-lineage Export dbt artifacts as graph and OpenLineage-compatible transformation lineage evidence.
Native certification harness dpone ops certification-run Run selected source -> sink matrix contracts and write evidence artifacts.
Certification suite dpone ops certification-suite Aggregate matrix, benchmark, lineage, dbt, strategy, and evidence artifacts into one release gate.
Connector certification pack dpone ops certification-pack Aggregate certification, observability, reconciliation, staging, and lineage artifacts into one connector certification 2.0 pack.
Live certification plan dpone ops live-certification-plan Plan local-live, real-local, or vendor-live certification with services, commands, artifacts, and credential boundaries.
Benchmark and SLO gate dpone ops benchmark-slo-gate Evaluate performance baseline regression and operational SLO objectives as one release evidence artifact.
Performance certification dpone ops performance-certification Build release-grade throughput, duration, memory, and failure-rate evidence.
Live state/reconciliation dpone ops live-state-reconciliation Aggregate state backend, XMin/Kafka/CDC state, and physical-delete reconciliation evidence.
Release evidence pack dpone ops release-evidence-pack Build the final go/no-go evidence pack for minor and major releases.
Pre-release checklist dpone ops pre-release-checklist Record CLI, run, Python API, lineage, matrix, contracts, docs, and package checks before minor/major release.
Runtime recovery plan dpone ops recovery-plan Detect failed/resumable jobs, active locks, and uncommitted load packages.
Reconciliation 2.0 dpone ops reconcile Compute source-target counts, checksums, delete reconciliation, and repair actions.
Observability pack dpone ops observability-pack Generate Grafana dashboard and Prometheus alert templates.
Deployment profile rendering dpone ops deploy-render Render Docker Compose, Kubernetes CronJob, Airflow DAG, or Dagster asset handoff templates.
Object-storage staging evidence dpone ops staging-evidence Validate object-storage staging manifests and render target-native load hints.
Catalog publication dpone ops catalog-publish Build OpenLineage, dbt sources, and DataHub-compatible publication artifacts.
Release summary dpone ops release-summary Combine replay, source -> sink matrix, and connector certification evidence into one final go/no-go report.
Certification history dpone ops certification-history Record release history, badge status, fixed cases, and certification regressions.
Connector badges dpone ops connector-badges Generate README/GitHub Pages connector badge matrix artifacts.
Data contracts and drift guard dpone ops contract-check Evaluate required columns, nullability, uniqueness, row count, and null-ratio contracts.
Quarantine and replay dpone ops quarantine-export, dpone ops quarantine-replay Inspect and replay rejected rows from append-only quarantine files.
Load package lifecycle dpone ops package-start, dpone ops package-commit Create load IDs and enforce state commit only after load commit.
Rollback and restore dpone ops rollback-plan, dpone ops rollback-apply, dpone ops rollback-execute Build, preview, and apply explicit target-native rollback plans.
Connector marketplace dpone ops marketplace Render connector certification status, capabilities, badges, and docs links.
Evidence bundle dpone ops evidence-bundle Collect certification, data-contract, and marketplace evidence with checksums.
Evidence chain dpone ops evidence-chain Append a tamper-evident release evidence chain entry.
Go-live gate dpone ops go-live-gate Evaluate required evidence and return go/no-go blockers.
Policy-as-code dpone ops policy-evaluate Enforce JSON release policies against an evidence bundle.
Reconciliation diff dpone ops diff Compare bounded source/target rows and emit missing, extra, and mismatch samples.
Security audit dpone ops security-audit Detect inline secrets, unsafe connection types, and unredacted log tokens.
SLO evaluation dpone ops slo-evaluate Evaluate freshness, throughput, latency, failure-rate, and retry-budget objectives.
Benchmark baseline dpone ops benchmark-baseline Detect throughput/latency regressions against committed benchmark profiles.
Incident pack dpone ops incident-pack Bundle evidence, policy, SLO, security, diff, and rollback artifacts for review.
Release gate dpone ops release-gate Aggregate ops artifacts into one release readiness decision.
Production maturity gate dpone ops production-maturity Aggregate certification, CDC, performance, security, supply-chain, governance, and docs evidence into one GA readiness decision.
Release orchestrator dpone ops release-orchestrator Run artifact index, evidence chain, release gate, docs pack, and runbook pack as one release pipeline.
Release promotion dpone ops release-promote Record immutable environment promotion evidence for dev/staging/production handoff.
Environment drift dpone ops env-drift Compare environment manifests/configs and block unapproved drift before promotion.
Change request dpone ops change-request Build a machine-readable release approval artifact with risk, approvers, and evidence.
Approval record dpone ops approval-record Record actual approval/rejection decisions and evaluate quorum before promotion.
Deployment record dpone ops deployment-record Record factual deployment outcome, post-deploy checks, and rollback pointer.
Post-deploy verification dpone ops post-deploy-verify Aggregate final deployment, SLO, diff, security, and contract checks into close-or-rollback gate.
Release close dpone ops release-close Write final immutable release closure or rollback-required evidence.
Docs publish pack dpone ops docs-publish-pack Build README and GitHub Pages snippets from ops artifacts.
Manifest bundle dpone ops manifest-bundle Create a redacted portable support/release bundle with checksums.
Runbook pack dpone ops runbook-pack Generate an operator go-live/rollback/incident runbook from ops artifacts.
Performance planning dpone perf advise Recommend native bulk paths, partitioning, and throughput improvements.

Design rules

  • There is no production namespace or production mode.
  • Operational services live under dpone.ops.*.
  • CLI adapters are thin; business rules stay in focused services.
  • Destructive operations require explicit --yes.
  • Every command supports JSON output for automation where relevant.
  • Artifacts should be saved under .dpone/ for local runs and under test_artifacts/ for tests/certification.
  • Minor and major releases require a green dpone ops release-evidence-pack produced from real_local evidence before tagging or publishing.

Artifact index

Use dpone ops artifact-index to publish a searchable list of generated ops artifacts for GitHub Pages, CI summaries, release notes, and incident review.

dpone ops artifact-index \
  --output-dir .dpone/artifact-index \
  --root .dpone \
  --root test_artifacts \
  --release v0.7.1 \
  --format json

Artifacts written:

artifact_index.json
artifact_index.md

Indexed metadata:

Field Meaning
artifact_type Type inferred from artifact filename such as release_gate or ops_evidence_bundle.
sha256 Content checksum for audit and tamper detection.
size_bytes File size for storage and artifact growth reviews.
modified_at UTC file modification timestamp.
release, run_id, passed Extracted from JSON artifacts when present.

Runbook when the index is red:

  1. Find rows with passed=false.
  2. Open the referenced artifact path.
  3. Fix the underlying gate, SLO, security, diff, or certification issue.
  4. Regenerate the artifact and re-run artifact-index.

Run registry

Use dpone ops run-registry after dpone run to create an auditable run entry. The registry stores the canonical run result, attached quality/state/reconciliation artifacts, SHA-256 checksums, and an append/update run_registry_index.json.

dpone run manifests/orders.yml \
  --selector daily_orders \
  --format json > .dpone/runs/daily_orders/run_result.json

dpone ops run-registry \
  --output-dir .dpone/run-registry \
  --run-result .dpone/runs/daily_orders/run_result.json \
  --artifact quality=.dpone/runs/daily_orders/quality.json \
  --artifact state=.dpone/runs/daily_orders/state_transition.json \
  --format json

Artifacts written:

<run_id>__run_registry.json
<run_id>__run_registry.md
run_registry_index.json

Registry fields:

Field Meaning
run_id Run identifier from dpone run, or unknown_run when the result is invalid.
process Manifest process selector/name.
status, passed, blockers Final run health and blocking diagnostics.
run_result_sha256 SHA-256 checksum of the canonical dpone run --format json output.
artifacts Attached quality, state, diff, SLO, release, or support artifacts with checksums.
index_path Location of the registry index for docs, CI summaries, or incident review.

Operational model:

flowchart LR
    Run["dpone run --format json"] --> Result["run_result.json"]
    Quality["quality/state/diff artifacts"] --> Registry["dpone ops run-registry"]
    Result --> Registry
    Registry --> Entry["<run_id>__run_registry.json"]
    Registry --> Markdown["<run_id>__run_registry.md"]
    Registry --> Index["run_registry_index.json"]

Runbook when registry is red:

  1. Open blockers in <run_id>__run_registry.json.
  2. If run_result.missing or run_result.invalid_json, re-run dpone run --format json.
  3. If run_result.not_passed, fix the runtime failure before promoting state/release evidence.
  4. If an attached artifact is red, open that artifact and follow its dedicated runbook.
  5. Treat checksum drift in run_registry_index.json as an audit event.

OpenLineage export

Use dpone ops lineage-export after run-registry to publish a portable lineage event. The detailed model and runbook live in OpenLineage and run history.

dpone ops lineage-export \
  --output-dir .dpone/lineage/daily_orders \
  --run-registry-entry .dpone/run-registry/<run_id>__run_registry.json \
  --namespace dpone.local \
  --input postgres=public.orders \
  --output mssql=landing.orders \
  --format json

Artifacts written:

<run_id>__openlineage.json
<run_id>__openlineage.md

Runbook when lineage export is red:

  1. If run_registry.missing, regenerate the run registry entry.
  2. If run_registry.not_passed, fix the original dpone run before publishing lineage.
  3. Re-export with explicit --input and --output when catalog datasets are missing.
  4. Keep the generated JSON as immutable evidence even when the collector is temporarily unavailable.

dbt lineage

Use dpone ops dbt-lineage after dbt build to attach transformation lineage to dpone run evidence. Detailed artifact semantics, CI examples, and runbooks live in dbt integration.

dbt build --project-dir analytics --profiles-dir analytics

dpone ops dbt-lineage \
  --output-dir .dpone/dbt-lineage/orders \
  --manifest analytics/target/manifest.json \
  --run-results analytics/target/run_results.json \
  --run-registry-entry .dpone/run-registry/<run_id>__run_registry.json \
  --namespace dbt.local \
  --format json

Artifacts written:

dbt_lineage.json
dbt_lineage.md
dbt_openlineage.json

Runbook when dbt lineage is red:

  1. If dbt_manifest.missing, run dbt build and verify the target/ path.
  2. If dbt_results.not_passed, fix failed dbt models/tests before release promotion.
  3. If run_registry.not_passed, fix the dpone load before publishing transformation lineage.
  4. Publish dbt_openlineage.json to the same collector as dpone run lineage.

Evidence chain

Use dpone ops evidence-chain after artifact-index to append a tamper-evident release entry. Each entry stores:

Field Meaning
artifact_index_hash SHA-256 checksum of the release artifact index.
previous_chain_hash Prior release chain hash, or genesis for the first entry.
chain_hash SHA-256 hash of release id, artifact checksum, previous hash, and timestamp. 
dpone ops evidence-chain \
  --chain-dir .dpone/evidence-chain \
  --release v0.7.1 \
  --artifact-index .dpone/artifact-index/artifact_index.json \
  --format json

dpone ops evidence-chain-verify \
  --chain-dir .dpone/evidence-chain \
  --format json

Artifacts written:

<release>__evidence_chain.json
<release>__evidence_chain.md
evidence_chain_index.json

Operational model:

flowchart LR
    Index["artifact_index.json"] --> Hash["artifact_index_hash"]
    Previous["previous release chain_hash"] --> Entry["evidence chain entry"]
    Hash --> Entry
    Entry --> Current["current chain_hash"]
    Current --> Next["next release previous_chain_hash"]

Runbook when verification fails:

  1. Recompute the artifact index with dpone ops artifact-index.
  2. Compare the current artifact checksum with artifact_index_hash.
  3. Compare previous_chain_hash with the prior release chain_hash.
  4. If a file changed unexpectedly, treat it as a release-blocking audit event.
  5. Regenerate the evidence chain only after the artifact diff is reviewed.
  6. Use dpone ops evidence-chain-verify in CI; an empty chain returns a non-zero exit code.

Certification harness

Run one focused case:

dpone ops certification-run \
  --source postgres \
  --sink mssql \
  --strategy snapshot_diff \
  --row-count 10000 \
  --artifact-dir test_artifacts/certification/postgres_mssql_snapshot_diff \
  --format json

Run the default mock-contract profile:

dpone ops certification-run \
  --artifact-dir test_artifacts/certification/mock_contract_latest

Artifacts:

certification_report.json
certification_report.md
<case_id>__behavior.json

Runbook when a case fails:

  1. Open certification_report.json and identify the failing case_id.
  2. Open <case_id>__behavior.json.
  3. Compare expected_row_count and actual_row_count.
  4. Compare expected_checksum and actual_checksum.
  5. Re-run a focused case with the same row count.
  6. If the contract is wrong, update dpone.integration_matrix.
  7. If runtime behavior is wrong, add a sink/source regression test before changing code.

Certification suite

Use dpone ops certification-suite to combine matrix certification, benchmark, lineage, dbt lineage, strategy certification, and evidence artifacts into one manual/scheduled CI gate. The full guide lives in Certification suite automation.

dpone ops certification-suite \
  --output-dir test_artifacts/certification/suite \
  --suite-id manual_matrix_2026_06_05 \
  --certification-report test_artifacts/certification/current/certification_report.json \
  --benchmark-baseline test_artifacts/benchmarks/current/benchmark_baseline.json \
  --lineage-report .dpone/lineage/orders/run_01__openlineage_report.json \
  --dbt-lineage-report .dpone/dbt-lineage/orders/dbt_lineage.json \
  --strategy-certification-bundle test_artifacts/strategy_certification/matrix/strategy_certification_bundle.json \
  --evidence-bundle test_artifacts/ops/evidence/ops_evidence_bundle.json \
  --require-benchmark \
  --require-lineage \
  --require-dbt-lineage \
  --require-strategy-certification \
  --require-evidence \
  --format json

Artifacts:

certification_suite.json
certification_suite.md
certification_suite_index.json

Integration matrix report

Use dpone ops integration-matrix-report after the manual matrix pytest run to convert per-case artifacts into a certification_report.json that can feed dpone ops certification-suite.

DPONE_MATRIX_ARTIFACT_DIR=test_artifacts/integration_matrix \
uv run pytest -m integration_matrix tests/integration/matrix -q

dpone ops integration-matrix-report \
  --artifact-dir test_artifacts/integration_matrix \
  --output-dir test_artifacts/integration_matrix \
  --format json

Artifacts:

certification_report.json
certification_report.md

Runbook:

  1. If matrix_behavior.missing:<case_id> appears, re-run that case with DPONE_MATRIX_CASE_ID=<case_id>.
  2. If matrix_rows.mismatch:<case_id> appears, open <case_id>__behavior.json and compare expected/actual checksums.
  3. If the report is red in CI, download both source-sink-integration-matrix and source-sink-certification-suite artifacts.

Runbook when suite is red:

  1. Open certification_suite.json and inspect blockers.
  2. Fix red matrix cases before publishing connector badges.
  3. Re-run benchmark on the same profile before changing baselines.
  4. Regenerate lineage/dbt evidence after runtime or transformation changes.
  5. Attach the suite artifact to release evidence before go-live.

Certification history

Record a release certification snapshot and compare it with the previous snapshot:

dpone ops certification-history \
  --history-dir test_artifacts/certification/history \
  --release v0.7.1 \
  --current-report test_artifacts/certification/current/certification_report.json \
  --previous-report test_artifacts/certification/previous/certification_report.json \
  --format json

Artifacts:

<release>__certification_history.json
<release>__certification_history.md
certification_history_index.json

Status values:

Status Meaning
passing Current report is green and has no new failures.
regression At least one previously passing case failed now.
failing No new failures, but old failures remain.
incomplete The report is not fully green and has no previous failure context.

Runbook when status is regression:

  1. Open new_failures.
  2. Re-run each focused case_id.
  3. Fix runtime behavior or update the certification contract with review.
  4. Re-record certification history before publishing badges or release notes.

Connector badges

Generate connector status artifacts for README snippets, GitHub Pages, and release notes:

dpone ops connector-badges \
  --output-dir test_artifacts/certification/badges \
  --history-index test_artifacts/certification/history/certification_history_index.json \
  --format json

Artifacts:

connector_badges.json
connector_badges.md

Badge rules:

Input Badge behavior
Marketplace status only Use connector marketplace badge such as certified or beta.
New or unchanged failed case Mark both source and sink connectors as regression.
Fixed failed case Add a strategy row with status fixed, but do not downgrade connector badge.

Runbook when connector badge is regression:

  1. Open strategy_rows.
  2. Re-run the listed source -> sink strategy case.
  3. Fix runtime or certification contract.
  4. Regenerate certification-history.
  5. Regenerate connector-badges.

Data contract guard

dpone ops contract-check \
  --rows-json '[{"id": 1, "email": null}]' \
  --contract-json '{"required_columns":["id","email"],"not_null":["email"],"unique":["id"],"min_rows":1}' \
  --format json

Supported checks:

Check Contract key Failure action
Required columns required_columns Add source column, schema evolution, or contract migration.
Not null not_null Fix upstream nulls or relax the contract.
Unique unique Fix duplicate keys or configure a composite key.
Minimum rows min_rows Check credentials, filters, pagination, and state.
Null ratio max_null_ratio Investigate sparsity drift or adjust threshold.

Use --mode warn when introducing a new contract. Use --mode fail for release gates.

Quarantine and replay

Export bad rows:

dpone ops quarantine-export \
  --dir .dpone/quarantine \
  --run-id 01J00000000000000000000000 \
  --format json

Preview replay:

dpone ops quarantine-replay \
  --dir .dpone/quarantine \
  --run-id 01J00000000000000000000000

Apply replay:

dpone ops quarantine-replay \
  --dir .dpone/quarantine \
  --run-id 01J00000000000000000000000 \
  --yes

Runbook:

  1. Export rows and group by reason.
  2. Fix mapping, schema evolution, or source data.
  3. Replay only after the fix is deployed.
  4. Keep original quarantine artifacts immutable for audit.

Load package lifecycle

Start a package:

dpone ops package-start \
  --dir .dpone/load-packages \
  --run-id 01JRUN00000000000000000000 \
  --target landing.orders \
  --chunk-id business_date=2026-06-01 \
  --format json

Commit a package:

dpone ops package-commit \
  --dir .dpone/load-packages \
  --load-id 01JLOAD0000000000000000000 \
  --rows-loaded 10000 \
  --state-after-json '{"xmin":"845221"}'

State advancement is valid only after package status is committed.

Rollback

Plan rollback:

dpone ops rollback-plan \
  --sink mssql \
  --target landing.orders \
  --load-id 01JLOAD0000000000000000000 \
  --strategy shadow_swap \
  --format json

Apply rollback after external review:

dpone ops rollback-apply \
  --plan-json rollback-plan.json \
  --yes

Safely preview or apply through the guarded executor:

dpone ops rollback-execute \
  --sink mssql \
  --target landing.orders \
  --load-id 01JLOAD0000000000000000000 \
  --strategy shadow_swap \
  --require-backup \
  --format json

Apply mode still requires explicit --yes:

dpone ops rollback-execute \
  --sink mssql \
  --target landing.orders \
  --load-id 01JLOAD0000000000000000000 \
  --strategy shadow_swap \
  --require-backup \
  --yes

Runbook:

  1. Generate a rollback plan.
  2. Review all SQL actions manually.
  3. Verify backup/shadow objects exist.
  4. Stop writers to the target table.
  5. Apply with --yes.
  6. Run reconciliation and data contracts.
  7. Decide whether to replay or cancel downstream state.

Connector marketplace

dpone ops marketplace --format json
dpone ops marketplace --format md

The marketplace is a capability catalog, not a SaaS registry. It helps users decide whether a connector is certified, beta, experimental, or community-owned and points to the relevant docs/runbooks.

Evidence bundle

Build one audit artifact for a release candidate, connector certification run, or controlled go-live:

dpone ops evidence-bundle \
  --artifact-dir test_artifacts/ops/evidence/postgres_mssql_snapshot_diff \
  --run-id 01JOPS00000000000000000000 \
  --source postgres \
  --sink mssql \
  --strategy snapshot_diff \
  --row-count 10000 \
  --rows-json '[{"id": 1, "email": "a@example.com"}]' \
  --contract-json '{"required_columns":["id","email"],"not_null":["id"]}' \
  --format json

Artifacts:

certification_report.json
certification_report.md
data_contract_report.json
data_contract_report.md
connector_marketplace.json
connector_marketplace.md
ops_evidence_bundle.json
ops_evidence_bundle.md

The bundle stores a SHA-256 checksum for every required evidence file. Treat ops_evidence_bundle.json as the automation input and ops_evidence_bundle.md as the review artifact for PRs, incidents, and release notes.

Evidence chain

Use dpone ops evidence-chain after artifact-index to create a tamper-evident release chain entry.

dpone ops evidence-chain \
  --chain-dir .dpone/evidence-chain \
  --release v0.7.1 \
  --artifact-index .dpone/artifact-index/artifact_index.json \
  --previous-entry .dpone/evidence-chain/v0.7.1__evidence_chain.json \
  --format json

dpone ops evidence-chain-verify \
  --chain-dir .dpone/evidence-chain \
  --format json

Artifacts:

<release>__evidence_chain.json
<release>__evidence_chain.md
evidence_chain_index.json

The chain hash includes:

Field Purpose
release Release identifier.
artifact_index_hash SHA-256 of the release artifact index.
previous_chain_hash Hash from the previous release entry.
created_at UTC creation timestamp for this entry.

Runbook:

  1. Generate artifact-index.
  2. Append a new evidence chain entry.
  3. Store the generated JSON and Markdown with release artifacts.
  4. If a previous entry is present, pass it with --previous-entry.
  5. Treat changed chain hashes as tamper evidence and regenerate/review artifacts.

Go-live gate

Evaluate a previously generated evidence bundle:

dpone ops go-live-gate \
  --bundle-json test_artifacts/ops/evidence/postgres_mssql_snapshot_diff/ops_evidence_bundle.json \
  --format json

Exit codes:

Exit code Meaning
0 All required evidence passed.
1 One or more required evidence items failed.

Runbook when the gate is red:

  1. Open the bundle JSON and identify items[*].passed = false.
  2. Open the referenced evidence artifact by path.
  3. Fix the underlying runtime, contract, docs, or connector capability issue.
  4. Re-run dpone ops evidence-bundle.
  5. Re-run dpone ops go-live-gate.

Policy-as-code

Use policy evaluation when a CI job, release manager, or connector owner needs a repeatable rule set instead of manual evidence review.

dpone ops policy-evaluate \
  --bundle-json test_artifacts/ops/evidence/postgres_mssql_snapshot_diff/ops_evidence_bundle.json \
  --policy-json '{"required_evidence":["certification","data_contract","marketplace"],"require_bundle_passed":true,"require_artifacts_exist":true}' \
  --format json

Supported policy keys:

Policy key Default Meaning
required_evidence [] Evidence names that must be present in the bundle.
require_bundle_passed true Fail if the bundle-level status is false.
require_artifacts_exist false Fail if referenced local artifact files are missing.

Runbook when policy is red:

  1. Read violations.
  2. Follow the matching actions.
  3. Regenerate the evidence bundle after the fix.
  4. Re-run policy-evaluate in CI and locally.

Reconciliation diff

Use dpone ops diff when a load, certification run, or incident review needs a small but precise source-target comparison artifact.

dpone ops diff \
  --source-rows-json '[{"id": 1, "amount": 100}, {"id": 2, "amount": 200}]' \
  --target-rows-json '[{"id": 1, "amount": 100}, {"id": 2, "amount": 250}]' \
  --key id \
  --compare-columns amount \
  --format json

The service reports:

Signal Meaning
missing_in_target_count Source rows absent from target.
extra_in_target_count Target rows absent from source.
mismatch_count Matching keys with different compared columns.
duplicate_source_key_count Source has duplicate business keys.
duplicate_target_key_count Target has duplicate business keys.

Runbook when diff is red:

  1. Check duplicate keys first; fix the unique_key contract if duplicates are valid.
  2. Inspect missing and extra samples.
  3. Inspect mismatch columns and decide whether the target needs replay, rollback, or reconciliation.
  4. Do not advance state until the diff is green or an explicit exception is approved.

Security audit

Use dpone ops security-audit before committing manifests, publishing support bundles, or storing CI logs as artifacts.

dpone ops security-audit \
  --manifest-json '{"source":{"connection_type":"vault","credentials":{"password":"${DPONE_SOURCE_PASSWORD}"}}}' \
  --log-text 'password=[REDACTED] token=[REDACTED]' \
  --format json

The audit checks:

Check What it catches
Inline manifest secrets Literal values under password, token, api_key, secret, private_key, and related fields.
Connection type policy Unsupported connection_type values outside env, airflow, vault, and params.
Log redaction Raw GitHub/PyPI/AWS-like tokens, credential URLs, and password=value style leaks.

Safe secret references:

${DPONE_PASSWORD}
env:DPONE_PASSWORD
vault:secret/data/dpone/source#password
airflow:conn_id:postgres_oltp
[REDACTED]

Runbook when security audit is red:

  1. Remove literal secrets from manifests and logs.
  2. Move credentials into env, Vault, Airflow, or another external provider.
  3. Re-run security-audit.
  4. Rotate any credential that was written to a repo, CI log, or support bundle.

SLO evaluation

Use dpone ops slo-evaluate to enforce run-level or release-level objectives from a run report, benchmark, certification artifact, or CI job.

dpone ops slo-evaluate \
  --metrics-json '{"freshness_lag_seconds":120,"throughput_rows_per_second":2500,"failure_rate":0.001}' \
  --objectives-json '{"freshness_lag_seconds":{"max":300},"throughput_rows_per_second":{"min":1000},"failure_rate":{"max":0.01}}' \
  --format json

Recommended objective families:

Metric Rule Typical action when red
freshness_lag_seconds max Reduce schedule interval, inspect state lag, or fix upstream delays.
throughput_rows_per_second min Tune partitioning, native bulk path, batch size, or retry policy.
p95_latency_seconds max Inspect slow stages, target locks, API backoff, and finalization.
failure_rate max Investigate connector errors and target throttling.
retry_budget_used_ratio max Reduce transient failures or adjust retry/backoff policy.

Runbook when SLO is red:

  1. Identify failed metrics in results.
  2. Apply the recommended action for each failed metric.
  3. Re-run the same workload or benchmark.
  4. Attach the SLO report to release/certification evidence.

Benchmark baseline gate

Use dpone ops benchmark-baseline for long-running stress and matrix gates. Unlike SLOs, benchmark baselines answer: "did this release regress compared to the same tested profile?"

dpone ops benchmark-baseline \
  --output-dir test_artifacts/benchmarks/postgres_mssql_10k \
  --metrics-json '{"throughput_rows_per_second":95000,"p95_latency_seconds":32}' \
  --baseline-json '{"throughput_rows_per_second":{"value":100000,"direction":"higher"},"p95_latency_seconds":{"value":30,"direction":"lower"}}' \
  --allowed-regression-ratio 0.10 \
  --format json

Baseline directions:

Direction Pass rule Example metrics
higher Actual must stay above baseline * (1 - allowed_regression_ratio). Throughput, loaded rows, parallel worker utilization.
lower Actual must stay below baseline * (1 + allowed_regression_ratio). Latency, runtime, error rate, retry budget burn.

Artifacts written:

benchmark_baseline.json
benchmark_baseline.md

Runbook when benchmark baseline is red:

  1. Re-run the same benchmark profile before changing the baseline.
  2. Confirm row count, source/sink versions, hardware profile, and bulk path are unchanged.
  3. Tune partitioning, native bulk mode, batch size, target finalizer policy, or target capacity.
  4. Update baseline only after a reviewed intentional performance change.

Incident pack

Use dpone ops incident-pack to create one auditable bundle for a release review, go-live gate, failed certification, or incident handoff.

dpone ops incident-pack \
  --artifact-dir .dpone/incidents/01JINC00000000000000000000 \
  --incident-id 01JINC00000000000000000000 \
  --title "Postgres to MSSQL release gate" \
  --severity release \
  --artifact evidence=test_artifacts/ops/evidence/latest/ops_evidence_bundle.json \
  --artifact policy=test_artifacts/ops/evidence/latest/policy_decision.json \
  --artifact slo=test_artifacts/ops/evidence/latest/slo_report.json \
  --artifact security=test_artifacts/ops/evidence/latest/security_audit.json \
  --format json

Artifacts written:

ops_incident_pack.json
ops_incident_pack.md

Runbook when incident pack is red:

  1. Open ops_incident_pack.json.
  2. Review every item with passed=false.
  3. Open the referenced artifact path and fix the underlying issue.
  4. Regenerate the failed artifact.
  5. Re-run incident-pack before closing the incident or approving go-live.

Release gate

Use dpone ops release-gate as the final CI or release-manager gate after generating evidence, policy, SLO, security, diff, connector badge, and incident artifacts.

dpone ops release-gate \
  --artifact-dir .dpone/releases/v0.7.1 \
  --release v0.7.1 \
  --artifact evidence=test_artifacts/ops/evidence/latest/ops_evidence_bundle.json \
  --artifact policy=test_artifacts/ops/evidence/latest/policy_decision.json \
  --artifact security=test_artifacts/ops/evidence/latest/security_audit.json \
  --artifact slo=test_artifacts/ops/evidence/latest/slo_report.json \
  --artifact connector_badges=test_artifacts/certification/badges/connector_badges.json \
  --format json

Artifacts written:

release_gate.json
release_gate.md

Runbook when release gate is red:

  1. Open release_gate.json.
  2. Inspect blockers.
  3. Open each referenced artifact path.
  4. Fix the underlying issue and regenerate that artifact.
  5. Re-run release-gate.
  6. Publish only when passed=true.

Release orchestrator

Use dpone ops release-orchestrator when a release manager wants the standard ops evidence pipeline in one command. The orchestrator does not replace the underlying focused commands; it calls them in order and writes a top-level summary.

dpone ops release-orchestrator \
  --output-dir .dpone/releases/v0.7.1 \
  --release v0.7.1 \
  --root .dpone \
  --root test_artifacts \
  --artifact security=test_artifacts/ops/evidence/latest/security_audit.json \
  --artifact slo=test_artifacts/ops/evidence/latest/slo_report.json \
  --format json

Pipeline:

flowchart LR
    Roots["artifact roots"] --> Index["artifact-index"]
    Index --> Chain["evidence-chain"]
    Chain --> Gate["release-gate"]
    Gate --> Docs["docs-publish-pack"]
    Docs --> Runbook["runbook-pack"]
    Runbook --> Summary["release_orchestration.json"]

Artifacts written:

release_orchestration.json
release_orchestration.md
artifact-index/artifact_index.json
evidence-chain/<release>__evidence_chain.json
release-gate/release_gate.json
docs-publish-pack/docs_publish_pack.json
runbook-pack/runbook_pack.json
runbook-pack/OPERATOR_RUNBOOK.md

Runbook when orchestration is red:

  1. Open release_orchestration.json.
  2. Inspect blockers to find the failed pipeline step.
  3. Open the step artifact path from steps.
  4. Fix the underlying focused command failure.
  5. Re-run release-orchestrator.
  6. Publish only when every step has passed=true.

Release promotion

Use dpone ops release-promote after a green release orchestration when the same release is promoted between environments. The promotion manifest is an audit artifact: it records source environment, target environment, artifact checksums, and promotion blockers.

dpone ops release-promote \
  --output-dir .dpone/promotions/v0.7.1-staging-production \
  --release v0.7.1 \
  --from-env staging \
  --to-env production \
  --artifact release_orchestration=.dpone/releases/v0.7.1/release_orchestration.json \
  --artifact runbook=.dpone/releases/v0.7.1/runbook-pack/runbook_pack.json \
  --artifact rollback=.dpone/releases/v0.7.1/rollback_execute.json \
  --format json

Promotion model:

flowchart LR
    Source["from environment"] --> Evidence["promotion evidence"]
    Artifacts["release artifacts"] --> Evidence
    Evidence --> Decision{"passed?"}
    Decision -->|yes| Target["to environment"]
    Decision -->|no| Blocked["blocked promotion"]

Artifacts written:

promotion_manifest.json
promotion_manifest.md

Runbook when promotion is blocked:

  1. Open promotion_manifest.json.
  2. Inspect blockers.
  3. Open every failed artifact path.
  4. Fix or regenerate the failed focused artifact.
  5. Re-run release-promote.
  6. Promote only when passed=true.

Environment drift

Use dpone ops env-drift before promotion to compare staging/production manifests, rendered configs, or release artifact metadata. Expected environment-specific values can be allowlisted by exact flattened path, while all other differences become blockers.

dpone ops env-drift \
  --output-dir .dpone/env-drift/v0.7.1-staging-production \
  --source-env staging \
  --target-env production \
  --source .dpone/rendered/staging.json \
  --target .dpone/rendered/production.json \
  --allowlist-path connection.host \
  --allowlist-path connection.database \
  --format json

Drift model:

flowchart LR
    Source["source environment config"] --> Flatten["flatten paths"]
    Target["target environment config"] --> Flatten
    Flatten --> Diff["compare values"]
    Diff --> Allowlist["apply allowlist"]
    Allowlist --> Decision{"blocking drift?"}
    Decision -->|no| Promote["promotion can continue"]
    Decision -->|yes| Block["promotion blocked"]

Artifacts written:

env_drift.json
env_drift.md

Runbook when drift is blocked:

  1. Open env_drift.json.
  2. Review blockers.
  3. Fix accidental config drift in the target environment.
  4. Add allowlist entries only for stable environment-specific fields.
  5. Re-run env-drift.
  6. Attach env_drift.json to release-promote.

Change request

Use dpone ops change-request to create a machine-readable approval artifact for release governance. It should be generated after release orchestration, environment drift, promotion evidence, and rollback/runbook artifacts are available.

dpone ops change-request \
  --output-dir .dpone/change-requests/CR-2026-0001 \
  --change-id CR-2026-0001 \
  --release v0.7.1 \
  --target-env production \
  --risk-level medium \
  --requested-by release-manager@example.com \
  --approver data-architect@example.com \
  --approver platform-owner@example.com \
  --artifact release_orchestration=.dpone/releases/v0.7.1/release_orchestration.json \
  --artifact env_drift=.dpone/env-drift/v0.7.1-staging-production/env_drift.json \
  --artifact promotion=.dpone/promotions/v0.7.1-staging-production/promotion_manifest.json \
  --format json

Approval model:

flowchart LR
    Evidence["release evidence"] --> Request["change request"]
    Risk["risk level"] --> Request
    Approvers["approvers"] --> Request
    Request --> Decision{"passed?"}
    Decision -->|yes| Approval["approval workflow"]
    Decision -->|no| Blocked["blocked change"]

Artifacts written:

change_request.json
change_request.md

Runbook when change request is blocked:

  1. Open change_request.json.
  2. Review blockers.
  3. Add required approvers if approval.approvers_missing is present.
  4. Fix or regenerate failed evidence artifacts.
  5. Re-run change-request.
  6. Attach change_request.json to the approval system.

Approval record

Use dpone ops approval-record to record real approval or rejection decisions against a generated change_request.json. This keeps the release approval state machine machine-readable and auditable.

dpone ops approval-record \
  --output-dir .dpone/approvals/CR-2026-0001 \
  --change-request .dpone/change-requests/CR-2026-0001/change_request.json \
  --actor data-architect@example.com \
  --decision approved \
  --comment "Release evidence reviewed." \
  --quorum-required 1 \
  --format json

Approval model:

flowchart LR
    Request["change_request.json"] --> Decision["approval decision"]
    Decision --> Checks["actor, expiry, rejection, quorum checks"]
    Checks --> Approved{"approved?"}
    Approved -->|yes| Promote["promotion can continue"]
    Approved -->|no| Blocked["promotion blocked"]

Artifacts written:

approval_record.json
approval_record.md

Runbook when approval is blocked:

  1. Open approval_record.json.
  2. Review blockers.
  3. Confirm the actor is listed in the change request approvers.
  4. Confirm expires_at has not passed.
  5. Resolve rejected decisions through a new change request.
  6. Continue promotion only when quorum is met and passed=true.

Deployment record

Use dpone ops deployment-record after a release is actually applied to an environment. It links the deployment to the approved change request, records post-deploy checks, and keeps rollback evidence discoverable.

dpone ops deployment-record \
  --output-dir .dpone/deployments/DEP-2026-0001 \
  --deployment-id DEP-2026-0001 \
  --environment production \
  --actor release-manager@example.com \
  --approval-record .dpone/approvals/CR-2026-0001/approval_record.json \
  --status succeeded \
  --post-check smoke=true \
  --post-check quality=true \
  --rollback-artifact .dpone/rollback/DEP-2026-0001/rollback_execute.json \
  --format json

Deployment model:

flowchart LR
    Approval["approval_record.json"] --> Deploy["deployment execution"]
    Deploy --> Checks["post-deploy checks"]
    Checks --> Record["deployment_record.json"]
    Record --> Decision{"passed?"}
    Decision -->|yes| Complete["deployment complete"]
    Decision -->|no| Rollback["rollback/runbook required"]

Artifacts written:

deployment_record.json
deployment_record.md

Runbook when deployment is blocked:

  1. Open deployment_record.json.
  2. Review blockers and failed post checks.
  3. Attach rollback evidence when status is failed or partial.
  4. Re-run post-deploy checks after remediation.
  5. Keep the original deployment record immutable for audit.

Post-deploy verification

Use dpone ops post-deploy-verify after deployment to aggregate deployment record, SLO, reconciliation, security, and data-contract artifacts into a final release close gate.

dpone ops post-deploy-verify \
  --output-dir .dpone/post-deploy/DEP-2026-0001 \
  --deployment-record .dpone/deployments/DEP-2026-0001/deployment_record.json \
  --artifact slo=.dpone/slo/DEP-2026-0001/slo_report.json \
  --artifact diff=.dpone/diff/DEP-2026-0001/diff.json \
  --artifact security=.dpone/security/DEP-2026-0001/security_audit.json \
  --format json

Verification model:

flowchart LR
    Deployment["deployment_record.json"] --> Verify["post-deploy verify"]
    SLO["SLO report"] --> Verify
    Diff["reconciliation diff"] --> Verify
    Security["security audit"] --> Verify
    Contracts["data contracts"] --> Verify
    Verify --> Decision{"all green?"}
    Decision -->|yes| Closed["release_closed"]
    Decision -->|no| Rollback["rollback_required"]

Artifacts written:

post_deploy_verify.json
post_deploy_verify.md

Runbook when verification requires rollback:

  1. Open post_deploy_verify.json.
  2. Review blockers.
  3. Open the referenced failed check artifact.
  4. If deployment record is red, attach rollback evidence and incident pack.
  5. Re-run failed checks after remediation.
  6. Close the release only when status=release_closed and passed=true.

Release close

Use dpone ops release-close as the final release lifecycle artifact after a green post-deploy verification gate.

dpone ops release-close \
  --output-dir .dpone/release-close/v0.7.1 \
  --release v0.7.1 \
  --closed-by release-manager@example.com \
  --post-deploy-verify .dpone/post-deploy/DEP-2026-0001/post_deploy_verify.json \
  --notes "Release closed after green post-deploy checks." \
  --format json

Closure model:

flowchart LR
    Verify["post_deploy_verify.json"] --> Close["release-close"]
    Close --> Decision{"post-deploy passed?"}
    Decision -->|yes| Closed["closed"]
    Decision -->|no| Rollback["rollback_required"]

Artifacts written:

release_close.json
release_close.md

Runbook when release close is blocked:

  1. Open release_close.json.
  2. Confirm post_deploy_verify.json exists and has passed=true.
  3. If post-deploy status is red, attach rollback and incident artifacts.
  4. Do not close the release until post-deploy verification is green.
  5. Keep release_close.json immutable as the final audit record.

Docs publish pack

Use dpone ops docs-publish-pack after release artifacts are green to generate copy/paste-ready README snippets and a GitHub Pages operational index.

dpone ops docs-publish-pack \
  --output-dir .dpone/docs-publish/v0.7.1 \
  --release v0.7.1 \
  --artifact artifact_index=.dpone/artifact-index/artifact_index.json \
  --artifact connector_badges=test_artifacts/certification/badges/connector_badges.json \
  --artifact release_gate=.dpone/releases/v0.7.1/release_gate.json \
  --artifact certification_history=test_artifacts/certification/history/certification_history_index.json \
  --format json

Artifacts written:

docs_publish_pack.json
docs_publish_pack.md
README_SNIPPET.md
PAGES_INDEX.md

Runbook:

  1. Generate artifact-index, connector-badges, and release-gate.
  2. Run docs-publish-pack.
  3. Review README_SNIPPET.md and PAGES_INDEX.md.
  4. Copy snippets into docs only when passed=true.
  5. Re-run mkdocs build --strict after publishing snippets.

Manifest bundle

Use dpone ops manifest-bundle when support, release review, or incident handoff needs a portable archive directory with redacted inputs and checksums.

dpone ops manifest-bundle \
  --output-dir .dpone/manifest-bundles/01JBUNDLE000000000000000000 \
  --bundle-id 01JBUNDLE000000000000000000 \
  --file manifest=examples/postgres_to_mssql/manifest.yml \
  --file release_gate=.dpone/releases/v0.7.1/release_gate.json \
  --redact \
  --format json

Artifacts written:

files/
manifest_bundle.json
manifest_bundle.md

Runbook:

  1. Always use --redact before sharing bundles outside your machine.
  2. Inspect manifest_bundle.md.
  3. Confirm every item has a SHA-256 checksum.
  4. If passed=false, fix missing files and rebuild the bundle.
  5. Rotate any credential that existed in a non-redacted source file.

Runbook pack

Use dpone ops runbook-pack to generate one operator-facing Markdown runbook for go-live, rollback, or incident handoff.

dpone ops runbook-pack \
  --output-dir .dpone/runbooks/v0.7.1 \
  --runbook-id 01JRUNBOOK0000000000000000 \
  --title "v0.7.1 go-live" \
  --artifact release_gate=.dpone/releases/v0.7.1/release_gate.json \
  --artifact rollback=.dpone/rollback/rollback_execute.json \
  --artifact security=test_artifacts/ops/evidence/latest/security_audit.json \
  --artifact diff=test_artifacts/ops/evidence/latest/diff_report.json \
  --format json

Artifacts written:

runbook_pack.json
runbook_pack.md
OPERATOR_RUNBOOK.md

Runbook sections:

Section Purpose
Current status Compact table of attached artifact statuses.
Go-live checklist Release readiness actions and blocker follow-up.
Rollback checklist Safe preview/apply sequence and post-rollback checks.
Incident handoff checklist What to attach and what owners must follow up.

Runbook:

  1. Generate release gate, security, SLO, diff, rollback and manifest bundle artifacts.
  2. Run runbook-pack.
  3. Review OPERATOR_RUNBOOK.md.
  4. Attach the generated runbook to release/incident review.
  5. Close only when passed=true or an explicit exception is approved.

Developer extension points

Service Module
Artifact index dpone.ops.artifact_index
Certification harness dpone.ops.certification
Certification history dpone.ops.certification_history
Connector badges dpone.ops.connector_badges
Data contract guard dpone.ops.contracts
Quarantine store dpone.ops.quarantine
Load package lifecycle dpone.ops.packages
Rollback planner dpone.ops.rollback
Rollback executor dpone.ops.rollback_execute
Connector marketplace dpone.ops.marketplace
Evidence bundle dpone.ops.evidence
Evidence chain dpone.ops.evidence_chain
Go-live gate dpone.ops.gate
Policy-as-code dpone.ops.policy
Reconciliation diff dpone.ops.diff
Security audit dpone.ops.security
SLO evaluation dpone.ops.slo
Incident pack dpone.ops.incident
Release gate dpone.ops.release_gate
Release orchestrator dpone.ops.release_orchestrator
Release promotion dpone.ops.release_promote
Environment drift dpone.ops.env_drift
Change request dpone.ops.change_request
Approval record dpone.ops.approval_record
Deployment record dpone.ops.deployment_record
Post-deploy verification dpone.ops.post_deploy_verify
Release close dpone.ops.release_close
Docs publish pack dpone.ops.docs_publish_pack
Manifest bundle dpone.ops.manifest_bundle
Runbook pack dpone.ops.runbook_pack

When adding a new operational capability:

  1. Add a focused service module.
  2. Add a thin command adapter in dpone.commands.
  3. Add contract tests first.
  4. Add docs and a runbook.
  5. Add generated artifacts only under .dpone/ or test_artifacts/.

Release summary

dpone ops release-summary is the final promotion gate after the manual replay, source -> sink matrix, and connector certification workflows have published their artifacts. It verifies all evidence chains and reads both certification suites before writing release_summary.json / release_summary.md.

dpone ops release-summary \
  --output-dir test_artifacts/certification/release-summary \
  --release-id v0.7.1 \
  --replay-chain-dir test_artifacts/replay-evidence-chain \
  --matrix-suite test_artifacts/source-sink-certification-suite/certification_suite.json \
  --matrix-chain-dir test_artifacts/source-sink-evidence-chain \
  --connector-suite test_artifacts/connector-certification-suite/certification_suite.json \
  --connector-chain-dir test_artifacts/connector-evidence-chain \
  --format md

Exit code 1 means a chain is missing, a chain cannot be verified, or a suite is red. The generated Markdown report includes the short release-blocking runbook.

Certification automation plan

dpone ops certification-automation-plan renders the expected full certification sequence and required artifacts before a scheduled/manual workflow runs.

dpone ops certification-automation-plan \
  --output-dir test_artifacts/full_certification/automation \
  --profile mock_contract \
  --row-count 10000 \
  --format md

Use this command when onboarding a new certification profile or reviewing .github/workflows/full-certification.yml. The command does not run tests; it documents the required order and artifacts so automation, docs, and runbooks stay aligned.

Workflow: .github/workflows/full-certification.yml.

Production maturity gate

dpone ops production-maturity aggregates certification, CDC, performance, security, supply-chain, governance, and docs evidence into one release-readiness report.

uv run dpone ops production-maturity \
  --release v0.7.1-rc1 \
  --output-dir test_artifacts/production_maturity/report \
  --artifact certification=test_artifacts/connectors/latest/certification.json \
  --artifact cdc=test_artifacts/replay/latest/replay.json \
  --artifact performance=test_artifacts/benchmarks/latest/baseline.json \
  --artifact security=test_artifacts/security/latest/security.json \
  --artifact supply_chain=test_artifacts/supply_chain/latest/evidence.json \
  --artifact governance=test_artifacts/governance/latest/policy.json \
  --artifact docs=test_artifacts/docs/latest/docs.json

Outputs:

File Description
production_maturity.json Automation-friendly status, domain checksums, blockers, score, and level.
production_maturity.md Release-review summary for humans.

The scheduled/manual workflow is .github/workflows/production-maturity.yml; it uploads production-maturity-report.

Runbook: if a domain is missing, produce the specialized artifact first; if a domain is not_passed, fix the failing specialized gate before rerunning the aggregator.

Industrial readiness gate

dpone ops industrial-readiness aggregates local matrix, correctness, reliability, performance lab, UX, and governance evidence into one industrial release-readiness report.

uv run dpone ops industrial-readiness \
  --release v0.7.1-rc1 \
  --output-dir test_artifacts/industrial_readiness/report \
  --artifact local_matrix=test_artifacts/integration_matrix/latest/matrix.json \
  --artifact correctness=test_artifacts/correctness/latest/correctness.json \
  --artifact reliability=test_artifacts/reliability/latest/reliability.json \
  --artifact performance_lab=test_artifacts/benchmarks/latest/performance_lab.json \
  --artifact ux=test_artifacts/ux/latest/ux.json \
  --artifact governance=test_artifacts/governance/latest/governance.json \
  --case postgres:mssql:incremental_merge

The scheduled/manual workflow is .github/workflows/industrial-readiness.yml; it uploads industrial-readiness-report.

Schema DDL governance commands

Approve a schema change ledger artifact:

dpone schema approve --ledger .dpone/schema_changes/schema_change.json --approver data-architect --format json

Generate an expand-contract migration plan:

dpone schema expand-contract --source source-columns.json --target target-columns.json --table landing.orders --dialect postgres --format json