1. Assign one authority for each record
Name the owning system for sample and worklist identity, plate and instrument source, method and analysis configuration, calculated result, review or release decision, report, and downstream status. A consumer may retain a copy without becoming the authority.
Carry stable run, plate, sample, method, analysis, result, and report identifiers across every handoff. File names and mutable display labels are not sufficient transaction identities.
2. Define one complete versioned transaction
Specify fields, types, required and optional status, units, controlled vocabularies, time-zone convention, format version, source and configuration fingerprints, exclusions, report identity, and machine-readable errors. Keep scientific observations separate from human review or release status.
Define what acceptance means. A transport success means bytes arrived; a business acknowledgement means the receiver validated the format, identity, and allowed state and either accepted or rejected the transaction.
| Transaction element | Minimum definition |
|---|---|
| Identity | Unique request plus run, sample, method, analysis, result, and report IDs |
| Scientific value | Endpoint, value, unit, qualifiers, model and criteria status |
| Traceability | Source, configuration, method, software, exclusions, and report identities |
| State | Created, sent, accepted, rejected, retrying, reconciled, corrected, or superseded |
| Error | Stable code, affected field or record, message, time, and retryability |
3. Make delivery and acknowledgement explicit states
Authenticate each system, restrict permissions, protect credentials, encrypt transport, and record the exact payload, request identity, send attempt, response, and time. Use idempotent handling so retrying an uncertain request cannot create a second result.
Expose queued, in-flight, accepted, rejected, retrying, and failed states to operators. Timeouts require reconciliation because the sender cannot infer from silence whether the receiver committed the transaction.
4. Reconcile the sender and receiver
Compare stable identities, versions, values, units, qualifiers, status, and report links on a defined schedule and after failures. Produce a reviewable list of missing, duplicate, mismatched, rejected, and unacknowledged records.
Assign ownership and deadlines for exceptions. Reconciliation is the evidence that both systems agree; a success log from only the sender is not enough.
5. Correct by superseding, then retain the evidence
Define who can correct a result, how the prior transaction is identified, which reason and approval are required, and how the receiver links the replacement without erasing history. Never overwrite a released value without an attributable relationship to its predecessor.
Retain the data contract, validation evidence, exact sent and received records, acknowledgements, errors, retries, reconciliation, corrections, access, monitoring, and change approvals for the required period.
Limits and current Provenarium support
CSV, JSON, an API, or a queue can carry the transaction; none is reliable without the same ownership, validation, state, retry, acknowledgement, and reconciliation controls. Choose the transport after the record contract is stable.
Provenarium does not currently provide a standard LIMS or ELN connector or public customer API. Integrations and custom data-exchange formats are separately scoped work and require customer validation in the implemented environment.
Frequently asked questions
Does Provenarium replace a LIMS?
No. Provenarium controls its supported assay-analysis records; a LIMS may remain authoritative for samples, worklists, inventory, release status, and broader laboratory operations.
What should a first integration deliver?
Start with one result transaction and prove ownership, identifiers, field meaning, validation, acknowledgement, retry safety, reconciliation, and correction before adding more record types.