> > > SpecAdr007AsynchronousM2mApiMiddleware

ADR-007: Asynchronous M2M API and Middleware Constraint

Status

Accepted

Date

2026-05-30

Context

External systems such as SEOS, SELECT, and ERP systems need to submit events, query validation status, and participate in the Providence loop.

Traditional enterprise integrations often expect synchronous REST validation: a client asks whether an operation is valid, receives an immediate response, and only then commits its own transaction.

SOTER follows save-first, interpret-later. Facts are recorded first; semantic interpretation and reconciliation happen later.

Decision

The SOTER API must not provide synchronous request/response validation for blocking business transactions.

The API exposes delayed outputs: ontological dissonance, reconciliation cases, derived verification status, and other interpretations over recorded facts.

Systems that require synchronous UI blocking must implement their own middleware layer:

SOTER <-- async --> Middleware Layer <-- sync --> SEOS / SELECT / ERP

Rationale

SOTER is not a transactional gatekeeper. It is a verification and reconciliation system over recorded events.

Blocking external business transactions would force SOTER into latency and availability guarantees that conflict with the ledger-first design.

Consequences

Positive

SOTER can analyze facts asynchronously or in batches.
External systems keep ownership of their transactional UX.
The save-first ledger model remains intact.

Negative

Some integrations require an additional middleware layer.
Users may need to handle reconciliation after an action rather than before it.

Neutral or Operational

Synchronous behavior belongs in client-owned middleware, not in SOTER core.

Alternatives Considered

Synchronous Validation API

Rejected because it would make SOTER a fast transactional authority instead of a ledger-backed verification layer.

No External API

Rejected because SOTER needs external event sources and verification consumers.

Migration or Adoption

External clients should write facts and query later interpretations. If they need blocking behavior, they must place middleware between their UI and SOTER.