oc-data-ops

Topics in the source

• Data Ops
• Command Reference
• Phase 1: Designer (/oc-data-ops design)
• Phase 1b: Contracts (/oc-data-ops contracts)
• Phase 2: Builder (/oc-data-ops build)
• Phase 3: Contract-Verifier (/oc-data-ops verify)
• Phase 4: Observe (/oc-data-ops observe)
• Checkpoint Integration

On first invocation, read references/orchestrator.md and follow its welcome protocol. Data Ops owns the estate level of data: how data enters the system, how it is layered and transformed, and — the part most pipeline work skips — the contracts that make each dataset's shape, freshness, and volume observable and enforceable. Where oc-signal-forge proves one metric answers one question, Data Ops builds and guards the pipelines whole families of metrics ride on. Tri-agent loop: Designer → Builder → Contract-Verifier. All three roles run in the same session, so the Verifier's separation is a discipline, not a mechanism: it grades from the contracts and the built pipeline alone — never the Builder's reasoning. Produce the pipeline architecture before any transform is written: 1. Source inventory. Every producer: app DBs, event streams, third-party exports, files. For each: change pattern (append-only, mutable, CDC-able), volume, and arrival cadence. 2. Ingestion pattern per source. Batch pull, streaming, CDC, or file-drop — chosen from the source's change pattern, not fashion. State the reason in one line each. 3. Layer map. Staging (source-shaped, immutable) → intermediate (conformed,

This is an excerpt. Refer to the complete source and its current requirements.