Dataops
MicrosoftOfficialPublished by Microsoft
- Skill
- Guidelines
- Software development
- CC-BY-4.0
- Low risk
- Has scripts
AutoGineer summary
Written by AutoGineer from the skill’s own files, not by the author
The dataops skill provides a structured reference for designing and reviewing data pipelines and machine learning workflows. It synthesizes engineering best practices regarding data quality tiers (Bronze, Silver, Gold), the strategic placement of validation logic, and the importance of maintaining faithful source copies for pipeline replayability. The skill helps teams distinguish between data validation and drift detection, ensuring that data-heavy systems are robust, testable, and maintainable.
What it does
- Defines data tier semantics for Bronze, Silver, and Gold storage layers.
- Provides rules for placing validation at the Bronze-to-Silver boundary.
- Explains the rationale for maintaining immutable, faithful source copies in the Bronze tier.
- Offers guidance on distinguishing between data validation and drift detection.
- Provides a framework for testing data science and MLOps code.
- Includes a contract for synthetic data operations to ensure safe preflight validation.
When to use it
- When designing the architecture of a new data pipeline or lakehouse.
- When reviewing data transformation code or pipeline test suites.
- When deciding where to implement data validation checks.
- When troubleshooting pipeline failures that require data replay or recovery.
- When establishing testing strategies for machine learning models and data loading processes.
Advantages
- Ensures consistent application of data quality and pipeline invariants.
- Promotes robust recovery strategies through faithful data ingestion.
- Clarifies the distinction between validation and drift for better observability.
- Provides clear, attributed guidance based on established engineering playbooks.
- Prevents common pitfalls like premature validation before data landing.
Usage examples
- “Where should I place validation logic in my ETL pipeline?”
- The skill advises placing validation at the Bronze-to-Silver boundary, explaining that Bronze should remain a faithful, immutable copy of the source to support replayability and recovery.
- “What is the difference between data validation and drift detection?”
- The skill provides a breakdown distinguishing data validation (schema and invariant checks) from drift detection (monitoring changes in data or model signals over time).
Install
Download the skill as a ZIP:
https://mp-staging.autogineer.com/agent-skills/microsoft/dataops/downloadUnzip it into the cross-client skills folder of your project:
mkdir -p .agents/skills && unzip dataops.zip -d .agents/skills
Documentation by Microsoft
DataOps Reference Pack
Goal
Ground pipeline and test generation in the Microsoft CSE engineering playbook so that data tier semantics, validation placement, recovery invariants, and DS/MLOps test technique are applied consistently and attributed accurately.
Inputs
The pipeline, transformation, validation, or test work under discussion
The tier of each dataset involved, when the consuming workflow records one
Existing test layout, package structure, and data-access boundaries
A data classification produced elsewhere, when sensitivity matters
Reference index
Read only the reference that matches the active concern.
| Reference | Read this when |
|---|---|
| data-tiers-and-pipeline-invariants.md | Assigning tier meaning, placing validation, routing malformed records, or asserting replay, idempotency, testability, source-control, and configuration invariants |
| testing-data-science-and-mlops.md | Writing or reviewing tests for data loading, transformation, model load or predict, data validation, or model robustness |
| validation-drift-and-observability.md | Distinguishing data validation from drift detection, choosing remediation, or deciding which data and model signals matter |
| synthetic-data-operation-contract.md | Validating synthetic-data preflight authority, field lineage, conditional subgroup evidence, result linkage, or guarded local replacement |
| provenance.md | Confirming what is upstream guidance, what is HVE Core derivation, and where upstream is silent |
Success criteria
Tier language distinguishes the three upstream quality tiers from the additional storage areas.
Validation is placed at the Bronze-to-Silver boundary, and the faithful-copy rationale with both replay purposes travels with that placement whether or not the request challenges it.
Test guidance names the operation category, its technique, and where mocking stops.
Validation and drift keep their distinct definitions and their distinct remediation paths.
Every claim traces to an attributed upstream source or is labelled as HVE Core guidance.
Synthetic-data generation stops before source access or writes unless its applicable
SYNTHETIC_DATA_OPERATION_V1preflight passes deterministic validation.
Constraints
This skill generates code, assertions, and review guidance. It does not execute pipelines, transformation engines, or telemetry backends.
Reproduce only the minimum text necessary for a specific technical point, and paraphrase everything else. Attribute every reference and describe accurately what each reference reproduces.
Label HVE Core derivations as such. Do not present a derived consequence or a repository convention as upstream guidance.
Where upstream is silent, say so rather than inventing an upstream-sounding rule.
Ownership boundaries
This skill decides which data and model signals matter. It does not own the vocabulary, the classification, or the surrounding workflow.
| Concern | Owner |
|---|---|
| Metric names, instrument types, units, cardinality discipline, and the PII emission denylist | telemetry-foundations |
| Data sensitivity classification and DPIA thresholds | privacy-standards |
| Entity semantics, relationships, and which tier a dataset is recorded as | The calling workflow |
| Feasibility assessment and go/no-go recommendation | The calling workflow |
No repository artifact currently owns the last two rows. When the caller supplies neither, state the gap rather than deciding tier assignment or feasibility here.
This skill never decides what is sensitive. It reads a classification produced elsewhere.
For synthetic-data operations, read synthetic-data-operation-contract.md and validate records against synthetic-data-operation-v1.schema.json. The contract records qualified decisions by immutable reference; it does not store source values or replace the authority of data, privacy, Responsible AI, fairness, or domain owners.
Stop rules
Stop and route metric naming, units, and cardinality to
telemetry-foundations, the OpenTelemetry-aligned vocabulary and instrumentation skill. Route data sensitivity toprivacy-standards, the privacy classification and DPIA-threshold reference.Stop and state the gap when the request depends on guidance the playbook does not provide, such as a drift threshold or an alerting policy.
Stop and offer the correct placement when asked to validate before Bronze landing, rather than complying or refusing without an alternative.
Attribution
This pack declares CC-BY-4.0 because both bodies of content it holds carry that license.
Source pages are Microsoft CSE Code With Engineering Playbook documentation licensed CC BY 4.0. The upstream project applies MIT through a separate LICENSE-CODE file to code samples only, which this pack does not reproduce. The references derive from those documentation pages and have been changed: upstream guidance is paraphrased, and only identifiers and structural names are carried across as facts. THIRD-PARTY-NOTICES carries the attribution CC BY 4.0 requires and states that the content has been changed. Each reference cites its own upstream URL and states what it reproduces.
Content labelled as HVE Core derivation is repository-original material under CC BY 4.0. See provenance.md for the consolidated source map and derivation labels.
Files
- ATTRIBUTION.mdAdded by AutoGineer965 B
- LICENSEAdded by AutoGineer16.6 KiB
- SKILL.md7.6 KiB
- assets/synthetic-data-operation-v1.schema.json9.2 KiB
- pyproject.toml681 B
- references/data-tiers-and-pipeline-invariants.md10.2 KiB
- references/provenance.md10.8 KiB
- references/synthetic-data-operation-contract.md6.4 KiB
- references/testing-data-science-and-mlops.md8.8 KiB
- references/validation-drift-and-observability.md7.2 KiB
- scripts/synthetic_data_operation.pyScript21.2 KiB
- tests/corpus/0_empty0 B
- tests/corpus/1_empty_object2 B
- tests/corpus/2_non_object_json2 B
- tests/corpus/3_minimal_preflight27 B
- tests/fuzz_harness.pyScript1.2 KiB
- tests/test_synthetic_data_operation.pyScript23.9 KiB
- uv.lock101.9 KiB
references/provenance.md
title: dataops provenance and attribution description: Source map, reproduction scope, HVE Core derivation labels, and upstream silences for the dataops reference pack
Purpose
This file records where each part of dataops comes from, what may be reproduced, and what is not upstream guidance at all. Consult it before treating any statement in this pack as a playbook rule.
Licensing posture
Microsoft CSE Code With Engineering Playbook documentation is licensed CC BY 4.0, which permits reproduction in whole or in part provided the source is attributed and changes are indicated; THIRD-PARTY-NOTICES carries that attribution and states that the content has been changed. The upstream project applies MIT through a separate LICENSE-CODE file to code samples only, which this pack does not reproduce.
This repository's licensing posture is stricter than the license itself: it limits reproduction to the minimum text necessary for a specific technical point. This pack paraphrases upstream guidance and reproduces only identifiers and structural names as facts, which keeps it within that limit. The scope column below states what each area actually reproduces. Standards identifiers and structural names are facts rather than licensed prose and are preserved exactly.
Source map
| Content area | Upstream source | Reproduction scope |
|---|---|---|
| Tier names and definitions; additional storage areas | Data and DataOps Fundamentals, Data Tiering | Tier and storage-area names as identifiers; definitions paraphrased |
| Validation placement, malformed routing, replay rationale | Data and DataOps Fundamentals, Data Validation | Boundary and store names as identifiers; placement rule and replay rationale paraphrased |
| Replayability and idempotency | Data and DataOps Fundamentals, Idempotent Data Pipelines | Paraphrase only |
| Transformation and data-access separation; notebooks to packages | Data and DataOps Fundamentals, Testing | Paraphrase only |
| Source-control scope | Data and DataOps Fundamentals, CI/CD and Source Control | Artifact-class names as identifiers; the artifact list reproduces upstream scope |
| Secure configuration | Data and DataOps Fundamentals, Security and Configuration | Paraphrase only |
| Observability includes data; malformed store monitoring | Data and DataOps Fundamentals, Observability | Paraphrase only |
| Five testing categories, technique, and mocking boundaries | Testing Data Science and MLOps Code | Category names and pytest API identifiers as facts; category descriptions and mocking-boundary guidance paraphrased; the code examples described rather than copied |
| ML unit test scope guard | Testing Data Science and MLOps Code, Basic Unit Tests for ML Models | Scope guard paraphrased; no upstream sentence reproduced |
| Validation versus drift and remediation asymmetry | ML Model Production Checklist, How Will Incoming Data Quality be Monitored | Term names as identifiers; the distinction and the remediation pair paraphrased |
| ML observability lifecycle framing | Observability in Machine Learning | Paraphrase only |
Correction to a common misattribution
The validation-versus-drift distinction is frequently attributed to the DataOps or testing pages. It is not on either. It appears on the ML Model Production Checklist under "How Will Incoming Data Quality be Monitored?". Cite that page when using the distinction.
The upstream passage is prose, not a two-sentence rule. Any short rendering of it is a condensation and must be presented as attributed paraphrase, never formatted as a quotation.
Paraphrases where precision is fragile
These points lose technical meaning if compressed carelessly.
Bronze exists for two distinct replay purposes: replay to test validation logic, and replay to recover from a transformation-code bug. A single "replayability" summary removes the reason a team cannot simply re-ingest.
ML model tests deliberately leave some external calls unstubbed. Dropping that clause turns a deliberate upstream trade-off into an apparent inconsistency.
Validation and drift have different remediation. Validation triggers re-routing and rectification; drift triggers adaptation or retraining. Collapsing both into "investigate" destroys the distinction's usefulness.
Experiment reproducibility is not pipeline replayability. Upstream keeps them separate; the checklists supply the former and the DataOps page supplies the latter.
HVE Core derivations
The following are reasoned consequences authored for this repository. They are consistent with upstream definitions but are not stated upstream.
| Item | Upstream basis | What is derived |
|---|---|---|
| Per-tier permitted and forbidden behavior | Tier definitions and the single validation-placement rule | Upstream defines the tiers and one placement rule. It does not enumerate per-tier consequences. Only the Bronze validation refusal is directly upstream-backed. |
| Notebook-to-package extraction trigger | The invariant that transformation code moves out of notebooks into packages | Upstream states the invariant with no line threshold, duplication heuristic, or execution-count signal. Any threshold is a repository convention. |
| Treating malformed and sandbox as tier-like catalog values | Upstream names them as additional storage areas | Upstream's quality model has three tiers. Promoting two storage areas to catalog values is a design choice, and a third named area, libraries and binaries, is intentionally omitted. |
Upstream silences
Do not present guidance in these areas as playbook-backed.
No metric names, instrument types, units, thresholds, or dimensions are prescribed anywhere in the source set.
Observability in Machine Learning is silent on data validation entirely, on the validation-versus-drift comparison, and on drift thresholds, alerting, ownership, and automatic remediation.
Neither ML checklist names a data-tiering model or states a pipeline-replayability requirement.
Isolation levels and concurrency control are covered upstream but are peripheral to this pack; use them only when the engagement touches transactional stores.
Requirements and compatibility
Written for: GitHub Copilot, Claude Code
Works with: Claude Code, Claude apps, OpenAI Codex, GitHub Copilot, Cursor, Gemini CLI, Kiro, OpenCode, Goose, Amp, Roo Code, JetBrains Junie, Factory Droid, Devin (ex-Windsurf), Mistral Vibe, OpenHands, Letta
“Works with” means the tool reads the open Agent Skills format; a skill written for one tool may use features others lack.
Needs: Claude Code frontmatter, Needs Python
Security
What our scanner noticed· Low risk
- Scripts that your agent may run
This skill includes scripts that your agent may run. Read them before you use it.
A static scan is not a guarantee. Skills are third-party content: review a skill before you let an agent use it.
Attribution and licence
- Published by
- Microsoft
- Publisher
- Microsoft (Official)
- Source
- microsoft/hve-core · .github/skills/data-science-engineering/dataops · commit f425e94
- Licence
- Creative Commons Attribution 4.0 International (redistribution allowed)
- LICENSE (written by AutoGineer)
- ATTRIBUTION.md (written by AutoGineer)
- Synced
AutoGineer is not affiliated with or endorsed by Microsoft.
Download ZIP
The ZIP holds the skill’s files, its licence files and an ATTRIBUTION.md. Download dataops.zip