API modules

The Analytics Data Plane is intentionally split into a small execution path and the signaling needed to connect it to a dataspace. Multi-party coordination is outside this process and belongs to the analytics use-case application.

Data plane and dataflows

DataPlaneModule

Exposes the configured worker identity and supported execution/data profiles. The Control Plane provisions tenant-local registrations with execution leases. This module neither self-registers nor loads a process-wide tenant catalog.

DataflowModule

Receives control-plane dataflow lifecycle callbacks (prepare, start, complete, suspend, resume, and terminate). An orchestration dataflow allocates the authenticated execution endpoint. A data-access dataflow binds a dataset to a local data source. The module records those bindings and applies their lifecycle to local execution and event channels.

Execution

AlgorithmInstancesModule

Stores the local algorithm instance, validates the submission against a started orchestration dataflow, starts or terminates the local job, and exposes the management and execution endpoints. It owns local job status only; it does not coordinate other participants.

OrchestrationModule

Runs isolated Docker or Kubernetes jobs with exact owner and worker labels, resource limits and API-based authority checks. Kubernetes also uses native Job deadlines. The module approves images and derives the job callback boundary. Split servers do not initialize this runtime.

DatasourceModule

Resolves named local, HTTP, and S3 sources at job start using the execution configuration of the LAN-side runner. The source location and upstream credentials remain local to the LAN runner. Every source requires its exact execution scope. The job receives an ADP proxy URL and a short-lived token bound to its owner, algorithm instance and dataset grants. Jobs receive no dataset mounts, source credentials or presigned S3 URLs. Expiry, revocation and job removal fence access.

Events and split deployment

EventsModule

Accepts algorithm and internal events from local jobs, stores event metadata and payloads, and serves cursor-based reads. Provisioned event channels deliver metadata and payloads directly between participant execution endpoints. In split mode the bridge carries only the event and job-control messages needed by the client runner.

Bridge modules

The server bridge sends execution metadata and start requests to a client. The client bridge sends job status and locally produced events back to the server. The authenticated bridge binds each runner to explicit owners and immutable job assignments. Its persistent authority ledger fences expired or revoked work across reconnects and restarts.

Auth, config, and audit

OAuth and explicit human operator issuer/subject allowlists protect global management. Tenant grants authorize only their flow-bound execution APIs. The API specification in openapi.yaml is generated from the active controllers.

Event creation assigns timestamps on the server. Event payloads are uploaded as bytes into the configured payload storage; callers and split runners cannot register external payload URLs.