Skip to content

Orbiplex Dator

Orbiplex Dator is a Node-attached, supply-side marketplace solution component. It owns local standing-offer publication, provider-side catalog answers, and provider-side service dispatch. It is the counterpart of Arca: Dator supplies offers and executes accepted work, while Arca observes catalogs, selects offers, and orchestrates buyer-side workflows.

Dator does not own settlement, procurement authority, peer transport, or buyer-side discovery. Those remain host-owned daemon capabilities or Arca responsibilities. This keeps Dator a hosted supply module rather than a protocol authority.

The v1 deployment runs as a supervised channel_json middleware service. Its host lifecycle, readiness, middleware dispatch, and host-capability calls use the shared channel. Dator separately retains a bounded loopback product/provider API (default 127.0.0.1:47971).

Purpose

The component is responsible for the solution-level execution path of:

  • committing local standing offers for the provider participant,
  • maintaining deterministic offer/id, monotonic sequence/no, and provider context for offers it owns,
  • handling participant-facing local publication through POST /v1/enact/participant/service-offers,
  • answering offer-catalog.fetch.request with local offers only,
  • exposing a daemon-facing local offer snapshot for local dispatch lookups,
  • accepting service_dispatch_execute payloads for local provider work,
  • routing executable offers to configured local role modules,
  • accepting service-order.dispatch.request.v1 through Artifact Delivery, executing the same local role-module path, and sending a terminal service-order.result.v1 back through the request reply/delivery_plan when present, otherwise through the request reply/target,
  • keeping the older peer service-order.dispatch.request / service-order.dispatch.response handler as a deprecated compatibility surface, not as the Story-009/default completion path,
  • refreshing its own local-offer-catalog capability passport through host capabilities,
  • publishing signed offer-snapshot records under the offer-snapshot-publisher role when Agora publication is configured.

Scope

This document defines solution-level responsibilities of the Dator component.

It does not define:

  • observed-offer storage, shared/federated offer-catalog projection, trusted-provider policy, peer catalog discovery, or combined buyer catalog reads — those belong to Arca and the shared offer-catalog module,
  • peer session establishment, generic peer message dispatch, passport issuance, and participant signing — those are daemon host capabilities,
  • procurement contract creation, settlement hold creation/release, or receipt signing — those are host-owned marketplace and settlement paths,
  • task semantics for a concrete work type — those belong to the role module selected by the Dator offer,
  • Sensorium connector selection — role modules may request sensorium.directive.invoke, but Sensorium-core remains the admission and connector-selection authority.

Must Implement

Supply-Side Standing Offer Publication

Based on:

  • doc/project/30-stories/story-006-voluntary-swarm-exchange.md
  • doc/project/40-proposals/021-service-offers-orders-and-procurement-bridge.md
  • doc/project/40-proposals/023-federated-offer-distribution-and-catalog-listener.md

Related schemas:

  • service-offer.v1
  • participant-service-offer-publish-request.schema.json
  • participant-service-offer-publish-response.schema.json
  • service-offer-relay.v1
  • agora-record.v1

Responsibilities:

  • own the local standing-offer write path for provider-side offers,
  • derive deterministic offer/id values for managed offers,
  • assign monotonic sequence/no values for offer updates,
  • inject provider participant and provider node context,
  • accept participant-facing local publication requests,
  • return published once the local commit succeeds,
  • treat outbound relay as best-effort metadata separate from local publication success,
  • honor relay hints such as relay.do_not_forward and relay.intended_node_id without making them catalog semantics.

Status:

  • done for the hard-MVP local publication path. Dator owns the local write, while the daemon remains transport and commit-log authority. The Node reference implementation also carries a catalog-layer Agora adapter that can publish an accepted service-offer.v1 snapshot as an agora-record.v1 with record/kind = offer-snapshot. The snapshot's record/about includes provider, publisher-node, and origin-node resource refs so Arca can preserve relay trust-admission semantics while replaying from Agora. Runtime relay wiring remains separate from the local commit contract.

Provider Catalog Responder

Based on:

  • doc/project/30-stories/story-006-voluntary-swarm-exchange.md
  • doc/project/40-proposals/023-federated-offer-distribution-and-catalog-listener.md

Related schemas:

  • service-offer.v1
  • service-offer-relay.v1

Responsibilities:

  • answer inbound offer-catalog.fetch.request with local offers only,
  • keep responder behavior supply-side and stateless with respect to observed remote catalogs,
  • expose POST /v1/enact/offers/snapshot for daemon-side local dispatch lookups,
  • refresh the provider's local-offer-catalog capability passport through the host,
  • avoid peer discovery and background pull responsibility.

Status:

  • done in the bundled Dator module.

Provider Service Dispatch

Based on:

  • doc/project/30-stories/story-006-voluntary-swarm-exchange.md
  • doc/project/30-stories/story-009-bielik-blog-arca.md
  • doc/project/40-proposals/021-service-offers-orders-and-procurement-bridge.md
  • doc/project/40-proposals/027-middleware-peer-message-dispatch.md

Related schemas:

  • service-dispatch-request.schema.json
  • service-dispatch-response.schema.json
  • peer-message-invoke.v1.schema.json

Responsibilities:

  • accept daemon-submitted service_dispatch_execute payloads for local provider work,
  • select the matching standing offer by service_type,
  • route executable offers through the exact distribution-installed dispatch.entry_ref = dator-dispatch:role-module-v1,
  • invoke the configured role host capability identified by dispatch.capability_id,
  • preserve workflow lineage fields such as workflow/run-id, workflow/phase-id, and correlation/id,
  • return pointer-sized service-dispatch responses suitable for Arca and procurement inspection.

Status:

  • done for the hard-MVP local and story-009 role-module path.

Dispatch Adapter Registry

Dator owns a domain-specific dispatch registry rather than branching on an offer-supplied implementation kind. The distribution installs the dator-dispatch:inline-template-v1 and dator-dispatch:role-module-v1 entries; operator configuration may narrow that set but cannot create executable behavior. Every invocation binds the exact entry ref, revision, implementation ref, canonical digest, request and response schemas, required capability, and timeout/retry constraints. An empty set, unknown ref, stale revision, changed digest, unavailable implementation, or missing capability refuses without falling back to another entry. After selection, Dator appends the exact entry ref, revision, implementation ref, and digest as host-controlled registry/* lineage in the closed service-dispatch-response.schema.json contract. The selected role module cannot choose or overwrite those values. The effective distribution/operator projection is resolved once and cached as an immutable value. Ordinary dispatches reuse its set and sorted inspection projection; request-local narrowing computes only the requested intersection, while revocation atomically replaces the cached projection.

Activation by configuration remains restart-bound. Exact deactivation is immediate, idempotent, append-only in the module SQLite store, and restored after process restart. At most one terminal deactivation fact exists per entry and activation generation; an exact replay returns the original result while a different event for that terminal entry and generation refuses. Historical facts stay available for audit but cannot revoke an entry in a newer activation generation. The configured generation is advanced explicitly by the operator or distributor; a durable monotonic high-water refuses startup on rollback to an older number. Legacy event migration runs atomically and refuses conflicting terminal facts without retaining a partially changed schema or index. GET /v1/dator/dispatch-registry/status exposes the bounded prompt-free semantic-registry-inspection.v1 projection; revocations carry the causal event ref. POST /v1/dator/dispatch-registry/deactivate is a daemon-authenticated host-control surface and does not claim a separately verified operator signature. Package-backed entries reuse the P085 signed package lifecycle: the manifest binds the exact Dator domain/ref/revision/implementation/digest tuple, and current grants, generation, rollback, restart, and revocation are checked before projecting an executable binding. This shared lifecycle does not replace Dator's dispatch selection or effect admission.

Remote Service-Order Dispatch over Artifact Delivery

Based on:

  • doc/project/30-stories/story-009-bielik-blog-arca.md
  • doc/project/40-proposals/027-middleware-peer-message-dispatch.md
  • doc/project/60-solutions/023-artifact-delivery/023-artifact-delivery.md

Related schemas:

  • service-dispatch-request.schema.json
  • service-dispatch-response.schema.json
  • dator-dispatch-entry.v1
  • dator.dispatch-entry-deactivation.v1
  • dator.dispatch-entry-deactivation-result.v1
  • semantic-registry-inspection.v1
  • service-order.dispatch.request.v1
  • service-order.result.v1
  • artifact-delivery-envelope.v1
  • peer-message-invoke.v1.schema.json

Responsibilities:

  • accept inbound AD service-order.dispatch.request.v1 artifacts through Dator's single supervised acceptor,
  • authorize and deduplicate before effects by request_id plus buyer/order identity,
  • execute the enclosed dispatch payload through the same local role-module path used by local provider dispatch,
  • correlate the response by request_id,
  • build terminal service-order.result.v1 artifacts and deliver them back to Arca using the request's reply/delivery_plan when present, otherwise using the request's reply/target,
  • treat provider-reported settlement references as diagnostics only; Dator never releases, refunds, freezes, or signs the buyer-host procurement receipt,
  • return AD admission status separately from provider-side execution completion,
  • keep inbound peer service-order.dispatch.request and service-order.dispatch.response as a deprecated compatibility surface without adding new semantics there.

Status:

  • done for terminal provider-result delivery — the direct node-to-node Artifact Delivery thin slice is implemented in the bundled Dator module. Dator admits private inline JSON service-order.dispatch.request.v1 artifacts, rejects conflicting replays, returns already-present for identical admitted requests without executing twice, runs the existing role-module dispatch path, and sends terminal service-order.result.v1 artifacts back through AD. When a request carries reply/delivery_plan, Dator uses that complete AD plan for the result, enabling direct-node-to-private-safe staged fallback without adding a Dator-owned retry loop. Large result payloads fail closed unless that reply plan includes an object-store-indirect target. The legacy peer-message remote-provider handler remains only as a deprecated compatibility surface; Story-009/default remote execution is AD-only. The buyer host, not Dator or Arca, validates the terminal result against durable correlation, derives the source peer from a one-shot host-owned AD invocation binding, and owns settlement closeout. The paid three-node Story-009 acceptance covers Dator providers on nodes B/C returning results to buyer node A through AD. Durable provider queueing remains a later layer.

Host Capability Bridge Consumer

Based on:

  • doc/project/20-memos/node-middleware-init-and-capability-reporting.md
  • doc/project/40-proposals/019-supervised-local-http-json-middleware-executor.md
  • doc/project/40-proposals/027-middleware-peer-message-dispatch.md
  • doc/project/60-solutions/023-artifact-delivery/023-artifact-delivery.md

Related schemas:

  • middleware-init.schema.json
  • middleware-module-report.schema.json
  • local-input-invoke.v1.schema.json
  • peer-message-invoke.v1.schema.json
  • artifact-delivery-envelope.v1

Responsibilities:

  • run as a supervised channel_json middleware module under the daemon,
  • consume per-launch channel credentials and the host-owned middleware_home contract without persisting or logging credentials,
  • declare handled service types and inbound routes through middleware-init/module-report,
  • use host capabilities for passport issuance, peer dispatch, and role capability invocation,
  • never open its own peer transport sockets.

Status:

  • done in the bundled middleware module.

May Implement

Provider Queue and Backpressure

Based on:

  • doc/project/30-stories/story-006-voluntary-swarm-exchange.md
  • doc/project/40-proposals/021-service-offers-orders-and-procurement-bridge.md

Related schemas:

  • service-order.v1
  • service-dispatch-request.schema.json

Responsibilities:

  • persist incoming accepted provider dispatches before execution,
  • enforce queue_max_depth as local admission/backpressure instead of relying only on buyer-side pre-contract rejection,
  • expose queue depth and dispatch status for operator inspection,
  • run one or more worker loops with explicit timeout and retry policy,
  • keep admission idempotent by order/id or dispatch id.

Status:

  • planned. Current config carries queue_auto_accept, queue_max_depth, and queue_current_depth-style metadata, but the bundled Dator path still executes accepted dispatches inline rather than through a durable provider queue.

Durable Offer Relay Outbox

Based on:

  • doc/project/40-proposals/023-federated-offer-distribution-and-catalog-listener.md

Related schemas:

  • service-offer-relay.v1

Responsibilities:

  • persist outbound relay attempts for locally published offers,
  • retry failed delivery under bounded policy,
  • expose delivery state separately from local publication state,
  • preserve relay.do_not_forward and relay.intended_node_id as relay-policy metadata.

Status:

  • partial. Local publication and best-effort relay dispatch exist; a durable retryable outbox remains post-MVP.

Public Template Catalog Participation

Based on:

  • doc/project/40-proposals/029-workflow-template-catalog.md
  • doc/project/40-proposals/044-host-owned-generic-module-store.md
  • doc/project/30-stories/story-009-bielik-blog-arca.md

Related schemas:

  • workflow-template.v1

Responsibilities:

  • publish workflow templates as supply-side catalog records when a node intentionally hosts a template catalog role,
  • list and fetch template records for remote Arca import,
  • keep template publication separate from ordinary task-offer publication.

Status:

  • planned. Arca has local template storage and instantiation through the host-owned module store; public/federated template catalog participation is deferred.

Rich Provider Operator Surface

Based on:

  • doc/project/30-stories/story-006-voluntary-swarm-exchange.md
  • doc/project/30-stories/story-009-bielik-blog-arca.md

Related schemas:

  • service-offer.v1
  • service-dispatch-response.schema.json

Responsibilities:

  • inspect local offers with publication and relay state,
  • inspect role-module routing and required Sensorium action declarations,
  • inspect accepted, running, completed, failed, and rejected provider dispatches,
  • expose provider-side health without leaking role-module private artifacts,
  • surface requester-visible tracking-id values for failed dispatches so the requester can report a provider failure while full diagnostics remain provider-local.

Status:

  • optional. MVP exposes enough module and offer state for the current harnesses; richer operator UX is a post-MVP surface.

Out of Scope

  • observed catalog storage and trusted-provider policy — Arca owns the demand-side catalog,
  • workflow orchestration and offer selection — Arca owns buyer-side orchestration,
  • peer session establishment and generic peer dispatch — daemon host capabilities own transport,
  • procurement, settlement, receipt signing, and release/refund/freeze transitions — host-owned marketplace and settlement paths,
  • concrete task semantics — role modules own task-specific work,
  • direct Sensorium connector invocation — Sensorium-core mediates connector access.

Consumes

  • service-offer.v1
  • service-offer-relay.v1
  • service-dispatch-request.schema.json
  • service-order.dispatch.request.v1
  • peer-message-invoke.v1.schema.json
  • middleware-init.schema.json
  • artifact-delivery-envelope.v1

Produces

  • service-offer.v1
  • service-dispatch-response.schema.json
  • service-order.result.v1
  • service-order.dispatch.response

Notes

  • Dator is bundled as a supervised Python channel_json middleware module.
  • The Arca/Dator split is the only deployment model for the current marketplace runtime: Dator is supply-side, Arca is demand-side.
  • service_type names the concrete marketplace service offered by Dator. task_type remains an Arca/workflow-side selector that may resolve to a service type during provider selection.
  • Remote provider execution now prefers Artifact Delivery for service-order transport: AD owns delivery, retry, admission, and route trace, while Dator owns provider-side execution state and result construction.
  • Queueing is the main remaining Dator completeness gap for provider execution hardening.