Make ownership, stewardship, SLAs, certification, deprecation, and data-product contracts executable governance gates rather than labels that can be omitted without consequence.
Owners, Stewards, SLAs, Certification, Deprecation, and Data Product Contracts
Build an identity and access model for AtlasMart that separates humans from services, eliminates shared credentials, enforces environment boundaries, and proves least privilege with allow/deny evidence.
Learning outcomes
Separate technical ownership from business stewardship.
Treat SLAs/SLOs, certification, deprecation, and data-product contracts as explicit promises.
Block certification when required governance metadata is missing.
Design deprecation windows and consumer migration evidence.
Balance domain autonomy with enforceable enterprise contracts.
Chapter 23 begins from the governed and secured AtlasMart state produced by earlier chapters: 10 current paid lines, 8 orders, 12 units, 820 USD gross revenue, 495 USD cost, and 325 USD gross profit. The fact grain remains one current paid order line; the Chapter 20 metric contracts remain authoritative; Chapter 21 certified marts remain dependent on those contracts; and Chapter 22 security/privacy controls remain in force. Metadata and lineage describe, govern, and make change safer. They do not silently create a second business definition.
Runtime: Python 3.13.5 + SQLite 3.46.1. Mode: local, in-memory SQLite plus deterministic Python, no cloud account and no paid feature. Time: UTC. Currency: USD. Security: synthetic identities and non-secret metadata only; metadata can itself reveal sensitive topology, so production catalog access still requires policy. History: catalog entries and deprecation notices are versioned/effective-dated rather than overwritten without evidence. Non-guarantee: the lab proves graph/catalog logic for this fixture; it does not prove any vendor's automatic lineage completeness.
1. The realistic problem: a “certified” mart has no steward or SLA
AtlasMart's marketing team promotes
mart.shadow_sales by changing a label to
certified. It has a technical owner but no business
steward, no SLA, no registered consumer contract, and no
semantic conformance check. A colored badge is not governance.
An owner is accountable for operating/evolving
an asset. A steward is accountable for meaning,
quality expectations, policy, and business interpretation. An
SLA is an explicit service commitment; an
SLO is a measurable objective used to assess
service behavior.
2. Certification is a gate, not a compliment
| Gate | Question | Evidence |
|---|---|---|
| Identity | Does the asset have a stable ID/version? | Catalog key + version |
| Meaning | Is grain/metric/business definition explicit? | Dictionary/metric/glossary link |
| Ownership | Who operates and who stewards it? | Owner/steward matrix |
| Reliability | What freshness/availability/completeness is promised? | SLA/SLO metadata + measurements |
| Lineage | Can source and consumers be traversed? | Upstream/downstream edges |
| Security | Who may access which surfaces? | Chapter 22 policy classification |
| Consumers | Who depends on it? | Consumer inventory |
| Change | How is deprecation/version migration handled? | Deprecation notice + compatibility window |
Not every sandbox needs every certified-data obligation. Governance should be proportional: experiments can move quickly because they are explicitly labeled non-certified and cannot masquerade as permanent APIs.
3. Controlled failure and repair
OWNER_GATE_BEFORE[('mart.shadow_sales', 'certified', 'marketing-analytics', None, None)]REPAIRcertification: certified -> sandboxdefinition: Sandbox experiment; not a certified API and no SLA promised.OWNER_GATE_AFTER[]The repair does not invent a steward/SLA merely to make a test green. It corrects the lifecycle state: the asset was a sandbox. Later, if it needs certification, ownership, semantics, lineage, security, quality, SLA, and consumer evidence must be supplied deliberately.
4. Owners and stewards have different escalation paths
| Asset | Technical owner | Business steward | Why both matter |
|---|---|---|---|
src.erp.order_lines... |
commerce-platform | orders-steward | Producer uptime/schema versus order semantics |
fact_sales.line_amount_usd |
warehouse-platform | finance-data-steward | Pipeline/model operation versus financial meaning |
gross_revenue_usd.v1 |
finance-analytics | finance-data-steward | Metric implementation versus definition/approval |
report.finance_margin_daily |
finance-bi | finance-data-steward | Report delivery versus governed semantics |
One person/team can hold both roles in a small organization. The important mechanism is explicit accountability, not organizational ceremony.
5. Data-product contract: interface + semantics + service + policy
asset: mart.finance.daily_salesversion: 2certification: certifiedowner: finance-analyticssteward: finance-data-stewardinputs: - metric.gross_revenue_usd.v1 - metric.gross_profit_usd.v1grain: one UTC calendar day x governed reporting dimensionsfreshness_sla_minutes: 150security_classification: internal-financechange_policy: breaking_change: new major version + impact analysis deprecation_notice_required: true consumers_must_be_inventoried: trueThis contract is illustrative data, not a particular product syntax. Its job is to make promises machine-checkable/reviewable.
6. Deprecation instead of surprise deletion
The ERP field rename is registered on 2026-09-21, becomes
effective on 2026-10-01, and retains compatibility through
2026-10-15 in the fixture. The old field is marked
deprecated, not silently overwritten. A deprecation
notice names the replacement and reason. The compatibility
window is an explicit fixture decision, not a
universal recommended duration.
notice_id: DEP-ERP-2026-09-21asset: src.erp.order_lines.line_amount_usdannounced_at: 2026-09-21T00:00:00Zeffective_at: 2026-10-01T00:00:00Zcompatibility_until: 2026-10-15T00:00:00Zreplacement: src.erp.order_lines.gross_line_amount_usd7. SLA labels must connect to measurements
An SLA field such as 150 minutes is only a contract
value. Chapter 16's orchestration/observability concepts still
need to measure source availability, successful
load/certification time, freshness, and completeness. A catalog
should link the definition to observed service evidence rather
than claiming that storing a number makes the service reliable.
8. Production judgment
Governance overhead: apply stronger gates to certified/shared interfaces than to temporary sandboxes. Domain autonomy: teams may create domain products quickly if state and guarantees are explicit. Change propagation: impact analysis drives notification/migration. Idempotency: certification/deprecation updates should be versioned and replay-safe. Security/privacy: ownership does not imply unrestricted data access. Rollback: compatibility windows and versioned contracts allow old consumers to remain functional while migration is verified.
9. Bridge to Lesson 4
Many of the technical fields in these contracts can be generated from code. The business definition and decision context cannot be safely inferred from syntax alone. Lesson 4 defines where automation ends and human review begins.
Knowledge check
Acceptance questions
-
Why was demoting
shadow_salessafer than inventing an SLA? - How do owner and steward responsibilities differ?
- Why is a deprecation record part of governance?
- Does certification mean “perfect data”?
Review the answers
1. Its real lifecycle state was experimental; fabricated guarantees create false trust.
2. Owner handles operational/evolution accountability; steward handles meaning/policy/quality interpretation.
3. It makes replacement, timing, compatibility, and consumer migration explicit.
4. No; it means the asset meets declared governance/quality/service gates within known limitations.
Authoritative references
- OpenLineage — Lineage Dataset FacetCurrent specification for expressing dataset/job/field dependencies; useful for portable lineage concepts without making OpenLineage a prerequisite.
- OpenLineage — Column Level Lineage Dataset FacetShows fine-grained field dependencies and distinguishes identity, transformation, aggregation, join, filter, sort, window, and conditional influence.
- W3C — Data Catalog Vocabulary (DCAT) Version 3A standard vocabulary for describing cataloged datasets/data services and their metadata; referenced as an interoperability model, not as a required implementation.
- W3C — PROV-OStable provenance vocabulary for entities, activities, and agents; useful for reasoning about lineage/provenance boundaries.
- SQLite — WITH / recursive common-table expressionsThe local lab uses a recursive CTE to traverse downstream lineage deterministically.
- Python — hashlibUsed to fingerprint the deterministic metadata state after catalog repair and change registration.
10. Lab cleanup/reset
Rerun the deterministic catalog fixture. The certification failure should reappear before the repair and disappear only after the lifecycle state is corrected.