Data product delivery¶
Trigger¶
A business area needs a trusted dataset, metric or report.
Intended outcome¶
A governed, documented, monitored data product with an owner.
Workflow steps and gates¶
| Step | Accountable role | Activity | Handover | Gate |
|---|---|---|---|---|
| 1 | Data Governance Lead | confirms the critical data elements, owners and tolerances | governed element definitions | Owner, steward, definition and quality tolerance exist |
| 2 | Data Protection Officer | advises on lawful basis and minimisation | privacy position and DPIA where required | DPIA completed before processing begins |
| 3 | Data Architect | designs the structures and the flows, including trust boundaries | data model and flow design | Every flow crossing a trust or jurisdiction boundary has a control |
| 4 | Data Engineer | builds the pipelines with declared quality expectations | pipelines with freshness and completeness checks | Checks fail loudly rather than degrading silently |
| 5 | Analytics Engineer | models and tests the consumable datasets | tested, documented models with lineage | Uniqueness, referential integrity and freshness tested |
| 6 | Data Quality Analyst | measures fitness against the stated purpose | quality measurement against tolerance | No bare percentage without a fitness-for-purpose statement |
| 7 | Business Intelligence Analyst | publishes the reporting product on agreed definitions | dashboards on a single agreed metric definition | Two dashboards may not disagree silently |
| 8 | Data Steward | runs it day to day and arbitrates definition disputes | stewardship decisions and issue log | Competing definitions escalated, not averaged |
Running this workflow: operator and implementer boundary¶
In Claude Code or Codex CLI, use the prompt in the next section (or adapt it to your programme): it is a provider conversation request, not a shell program named after this workflow. You supply the source materials, actual owners, gate acceptance and any authorisation for changing real systems. The provider agent interprets the registered workflow stages and role contracts, calls supported tools if allowed, and returns explicit evidence and blockers. Stage completion in the diagram or metadata is not proof of a successful external tool call, an approved exception or a released system.
For consequential decisions explicitly start /layered (Claude) or $workflow-layered (Codex); this version does not force every direct/natural-language workflow invocation into Fabric. Human L0 authority remains separate, with Codex requiring the actual human to run any protected authority command in a trusted terminal. See the interaction model, layered engagement and human authority.
How to use this workflow¶
A practical prompt pattern is:
Apply the
data-product-deliveryworkflow to this situation. For each step, identify the current state, accountable role, required evidence, hand-over artefact, gate status and unresolved blocker. Do not skip a gate merely because the implementation is technically complete.
Operational interpretation¶
The workflow is most useful when the team keeps each hand-over explicit. The system can help generate or review the artefacts, but the accountable role and approval decision remain organisational responsibilities.