OPS-VIEW-10
Developer handover
Everything a developer needs to implement the acquisition operations layer for real: where each definition lives in this build, what it already states, and exactly which fields are still outstanding.
OverviewSource & signal monitorFlow runs & deliveryQuality & readinessLogs, traces & changesIncident registerAlert rules & scenariosPerformance & capacityReportsMetric contractDeveloper handover
As of 2026-09-23T06:00Z (virtual scenario clock)Window trailing 720 minTimezone Asia/Kolkata (UTC+05:30), displayed in UTCDataset ops-seed-0.7.0 · run SR-0007-baselineenvironmentMode: simulation
Simulated acquisition operations. These artifacts describe studio definitions. They do not constitute a production integration, and nothing here qualifies a native adapter in an environment.
Handover artifacts
| Artifact | Where it lives | In-app view | Outstanding | |
|---|---|---|---|---|
| HO-1 Metric & event contract | src/lib/ops/metrics.ts + src/lib/ops/model.ts | open | Reconcile the fifteen proposed identifiers with official Optimon 9 metric names; confirm the freshness rule per source family with the platform team. | |
| HO-2 Structured diagnostic schema | src/lib/ops/model.ts (DiagnosticEvent) | open | Vendor code mapping table per connector family is still empty; only the neutral code set is defined. | |
| HO-3 Alert rule pack | src/lib/ops/alerts.ts (ALERT_RULES) | open | Service class thresholds per site have not been agreed; current values are illustrative defaults. | |
| HO-4 Incident model & runbooks | src/lib/ops/alerts.ts (INCIDENT_STATES, RUNBOOKS) | open | Escalation ownership beyond the Operations Lead is not defined; no on-call roster exists in the studio. | |
| HO-5 Report definitions | src/lib/ops/reports.ts | open | Retention and distribution policy for generated reports is undecided; nothing is scheduled or delivered. | |
| HO-6 Acceptance scenario pack | src/lib/ops/scenarios.ts | open | Scenarios assert studio behaviour on synthetic inputs. They are not native adapter qualification. | |
| HO-7 Dataset provenance | src/lib/ops/events.ts | open | Real event volumes and cardinalities are unknown; the simulated fleet is not a capacity estimate. | |
| HO-8 Outstanding decisions | this page | open | Tracked as an open list below; each item names who must decide it. |
Open decisions this workspace cannot settle by itself
| Decision | Question | Owner | Impact |
|---|---|---|---|
| OPS-DEC-01 | Which freshness rule applies per source family, and who owns it? | Platform + operations | Changes OPS-M-07 and alert rule OPS-AR-01 directly. |
| OPS-DEC-02 | Can a source declare an expected-member denominator for polled APIs and event pushes? | Integration engineering | Without it, completeness stays not measurable for those families rather than assumed complete. |
| OPS-DEC-03 | Are the proposed OPS-M / OPS-AR identifiers acceptable, or must they map onto existing O9 names? | Optimon 9 platform team | The studio never invents official identifiers; these stay in the studio namespace until reconciled. |
| OPS-DEC-04 | What retention applies to intake payloads, and does it allow reprocess under a new mapping version? | Governance | Determines whether reprocess is available as a recovery operation at all. |
| OPS-DEC-05 | Who may authorise recovery that reads a historical window from a live source? | Operations + security | Backfill reads a source; replay does not. The authority model differs. |
| OPS-DEC-06 | Which consumer contracts define delivery due times used by OPS-M-10 and OPS-AR-02? | Delivery + consumers | Currently derived from the simulated obligations, not from agreed service classes. |
Studio readiness vs production integration
Studio readinessDefined, interactive and scenario-tested for this layer. Tracked on the readiness ledgers.
Production integrationunassessed — no source confirmed, no runtime implemented, no environment qualified
Datasetops-seed-0.7.0 · scenario run SR-0007-baseline
Definition packacquisition operations pack v0.7