Locus imports need channel-level control totals

Give every channel a bounded control envelope

The direct answer is that an import needs a control envelope defined for the channel before records begin arriving. Locus's official site names API connectors, uploads, mobile devices, smart meters, and laboratory imports. A bounded file may declare rows and bytes, an API pull may have pages and cursors, and a continuous feed may require a time window, partition, expected device roster, interval count, and watermark. Calling each one a completed import without those boundaries hides different failure modes.

Retain the channel and source-system identifiers, batch or window ID, sender and receiver endpoints, schema version, extraction cutoff, expected record count, expected byte or page count where available, sequence or cursor range, first and last event times, transfer start and finish, file or payload digest, initiating identity, and retry relationship. For a stream, state when the window is provisionally closed and when it becomes final. An empty batch must be an explicit zero-record assertion, not an absent transfer that happens to produce no rows.

Balance every sent record to one ingestion outcome

For each closed file or pull, reconcile the sender's count to mutually exclusive receiver outcomes: accepted, rejected, duplicate, quarantined, or otherwise explicitly unresolved. Preserve item-level keys linking every outcome to the original batch. A parse failure, schema mismatch, unauthorized source, truncated page, or validation exception should increment a visible category and enter a queue; it should not disappear between a successful transport status and the accepted-row count. Control totals should balance both in aggregate and by any partition used for restart.

Duplicate handling needs its own declared identity rule. A byte-identical replay, repeated source event ID, same device and interval, and two legitimately separate observations with equal values are not equivalent. Retain the candidate records, matching rule and version, first-seen batch, replay batch, disposition, reviewer where required, and whether the accepted population changed. An upsert that overwrites an earlier record can make the destination row count look correct while concealing that two arrivals were never independently reconciled.

Keep missing and late arrivals open across retries

A count can balance and still be incomplete if the expected source population was wrong. Compare each window with its declared device, laboratory, mobile-user, file, or API-partition roster and expected cadence. Missing intervals, absent files, skipped pages, and silent sources need an exception with first detection, owner, source inquiry, next retry, aging, and closure basis. Keep source-declared zero activity distinct from no response and from a transport failure. The system should show which expectation generated each missing-record claim.

Late arrivals and retries should extend the history without rewriting it. Record the original window, watermark, allowed-lateness rule, arrival time, linked delta or replacement batch, records added or displaced, duplicates created, and new reconciliation result. A failed batch that restarts after page three needs evidence that pages one through three were not doubled and pages four onward were not skipped. If a source republishes a corrected file, retain both digests and reconcile whether the second file supplements or replaces the first.

Test one population through every intake channel

Use a controlled set of observations and send designated subsets through an API, an upload, a mobile workflow, a meter feed, and a laboratory interface. Include a zero-record file, truncated API page, schema rejection, duplicate replay, out-of-order event, missing device interval, late laboratory batch, interrupted restart, and corrected replacement. Verify that each channel forms a bounded envelope, all sender totals reconcile to receiver outcomes, missing and late queues remain visible, retries are linked, and the final accepted population can be reproduced without silently discarding or multiplying an arrival.

Locus's official site supports the attributed provider statements about platform scope, configurable applications, and the named intake channels. It does not establish a buyer's batch design, expected population, connector behavior, schema compatibility, identity key, duplicate logic, watermark, retry safety, exception handling, control-total balance, or ingestion completeness. Those are buyer-side evaluation requirements. Environmental-data, EHS, laboratory, field-operations, integration, data-engineering, security, quality, and audit owners retain their respective decisions.

Enterprise buyer test

Translate this change into the exact population, record type, workflow stage, decision owner, effective date, and evidence that could be affected. Ask current or prospective providers to demonstrate the named workflow with representative data and an exception—not a polished feature tour. Record what official documentation establishes, what a provider states, what the team observes, and what remains unresolved.

A defensible review also identifies the dependency outside the product. Authority interpretation, policy configuration, data quality, integrations, human judgment, approval rights, release governance, training, and retained evidence may remain customer or service responsibilities. The evaluation should preserve those boundaries instead of treating a technology claim as the complete operating model.

What we will watch next

Safety Operations Standard will watch the named source and affected market records for later evidence that changes status, scope, availability, implementation timing, workflow consequence, or the limits of the initial report. A later announcement does not silently overwrite this dated account; the change ledger preserves the sequence.