ADR-0023: Atlas Nexus Operator-Safe Evidence Authority Model

Context

Atlas Nexus is being positioned as the cloud experience, coordination, and

evidence layer above customer-boundary HDIM services. The repo now has a

canonical operator-safe evidence envelope in

docs/plans/2026-04-24-atlas-nexus-operator-safe-evidence-contract.md, but it

did not yet freeze who is allowed to publish Atlas-visible truth for a given

lane.

That gap creates a predictable failure mode:

•workflow services can summarize a lane one way

•adapters can expose lower-level runtime events another way

•Atlas can accidentally become the place where competing truths are merged

•closeout decisions then drift away from the real workflow authority

This is especially risky in the current Atlas Nexus scope because questionnaire

routing, Regional Sync delivery state, InterSystems sync/bulk execution, and

future DQM gates all produce different classes of runtime detail. Atlas needs a

single authority rule that keeps the cloud layer safe, comprehensible, and

aligned with the source lane.

Decision

Atlas Nexus consumes only the normalized operator-safe evidence envelope. It

does not consume raw adapter telemetry as an Atlas-visible truth source.

For every Atlas-visible lane, exactly one producer must be named as the

authoritative publisher of that envelope.

Producer precedence is:

1.The workflow or control-plane service that owns the execution ledger, close

authority, or delivery/gate outcome for the lane.

2.The domain evaluation service that owns the gate verdict when no higher-level

workflow coordinator exists.

3.The adapter or execution service only for technical-readiness lanes that do

not yet have a higher-order workflow owner.

Additional rules:

•Raw adapter or runtime events may exist for local execution, audit, and

debugging, but they are not Atlas-ready by default.

•If adapter events need to appear in Atlas, the authoritative producer must

reduce them into the operator-safe envelope first.

•Atlas must not merge multiple competing producer truths for the same lane.

•Exactly one source_authority may be authoritative for a given lane_owner

within Atlas-visible authoritative event classes; conflicting claims are

rejected before projection.

•Atlas may aggregate multiple lanes, but each lane still has one named

authority producer.

•The authoritative producer for a lane must be named in the lane packet,

closeout packet, or equivalent operating artifact before the lane can be

called release-lane ready.

Consequences

Positive

•Atlas stays an evidence and coordination layer instead of becoming a shadow

workflow engine.

•Regional Sync, patient engagement, DQM, and InterSystems lanes can all use

one safe publication rule.

•Closeout decisions remain tied to the service that actually owns delivery,

gate, or run-state truth.

•UI teams can build Atlas views without inventing parallel data sources.

Negative

•Some teams must add a reduction or summary step before Atlas can consume their

data.

•Raw adapter telemetry alone is no longer enough to justify Atlas-facing

closure claims when a higher-order workflow owner exists.

•Lane packets now need an explicit authority field or equivalent cross-link.

References

•docs/plans/2026-04-24-atlas-nexus-operator-safe-evidence-contract.md

•docs/plans/2026-04-24-atlas-nexus-open-questions-register.md

•docs/plans/2026-04-24-atlas-nexus-completion-task-map.md

•docs/IMPLEMENTED_AND_TESTED_DEFINITION_OF_DONE_2026-04-19.md

•docs/architecture/ATLAS_NEXUS_HYBRID_3D_SYSTEM_ARCHITECTURE.md

•docs/plans/2026-04-24-atlas-nexus-questionnaire-oid-routing-contract.md

•docs/plans/2026-04-24-intersystems-phase2-sync-and-bulk-event-contract.md