Continuous Monitoring Station Operations: From Sensor Selection to Defensible Data

Create one row per channel with intended use, station and depth, method, logging interval, acceptance rule source, maintenance burden, review state, and decision owner.

Does every collected channel have a named use, controlled method, acceptance rule, and owner, or an explicit reason for retention?

Build a sensor acceptance matrix that includes method fit, interferences, preparation, standards, service evidence, spares, and review labor rather than only purchase specifications.

Are calibration, fouling, consumables, replacement, configuration, and data-validation effort included in the selection?

Draw the station with datum, sensor depths, protected water masses, mooring loads, power, communications, access route, retrieval sequence, hazards, and failure modes.

Can the station be serviced safely without unintentionally changing the represented water mass or losing the depth reference?

Trace one observation and its timestamps through the full chain, then simulate a buffered backfill, repeated payload, clock offset, communications outage, and maintenance annotation.

Can users distinguish observation, receipt, display, missing, delayed, provisional, accepted, and released states?

Write the predeployment and field-service sequence for one station from method and manufacturer documents: identify, preserve configuration, as found, pre-clean check, clean, calibrate or verify, as left, and affected-interval handoff.

Are standards, criteria, environmental conditions, failures, raw observations, adjustments, and post-adjustment verification retained without invented limits?

Build a responsibility and state-transition table with primary and backup owners, permitted actions, entry evidence, user-facing behavior, exit rules, spares, outage response, and seasonal review triggers.

Can the program survive a missed visit, power failure, communications loss, sensor replacement, firmware change, or staff turnover without losing authority or lineage?

Complete a tabletop service event with one as-found failure, one cleaning effect, one configuration decision, an affected raw-data interval, a bounded return disposition, and an unresolved reviewer action.

Does the record prevent cleaning or adjustment from erasing as-found evidence and prevent operational return from approving the data?

Run a tabletop alarm through maintenance suppression, raw-value review, QC and companion context, confirmation, field escalation, public-authority boundary, reset, and retained event record.

Can the workflow distinguish a service artifact, telemetry failure, plausible environmental change, and confirmed authority-managed event?

Build a practice release package that preserves original logger and telemetry records, retains real-time flags, documents any derived correction, names the reviewed use, and issues a new version rather than silently editing history.

Are operational return, automated screening, human acceptance, correction, alert confirmation, and public release represented as separate attributable events?