Execution¶
The execution layer controls how a configured pipeline runs. It is built from three components working together:
- an orchestrator that walks the pipeline graph and coordinates node
execution,
an executor that runs individual node tasks, and
a transport that carries payloads between nodes.
By default Semantiva uses a local, single-process stack that is well suited for development and small-scale runs on a single machine:
LocalSemantivaOrchestratortraverses the pipeline graph, instantiatesnodes, and drives execution.
SequentialSemantivaExecutorruns node tasks one after another in thecurrent process.
InMemorySemantivaTransportpublishes node outputs via in-memorychannels without serialization.
These defaults can be overridden via the execution block in the pipeline
configuration or the corresponding CLI flags (see Semantiva CLI).
Component Registry System¶
Semantiva uses a dual-registry architecture to manage execution components while avoiding circular import dependencies:
ExecutionComponentRegistrySpecialized registry for orchestrators, executors, and transports. This registry is designed to break circular import dependencies with the main ProcessorRegistry and graph builder modules.
build_orchestrator()Factory function that uses ExecutionComponentRegistry to construct orchestrators from configuration, supporting dependency injection of executors and transports.
The component registry follows the dependency inversion principle, acting as a dependency sink rather than creating webs of interdependence. See Registry System for detailed architectural information.
Template-method orchestrator¶
The core lifecycle now lives in
SemantivaOrchestrator.
It canonicalises the pipeline, snapshots context before/after each node, collects
context_delta details, emits built-in pre/post assertions, and attaches environment
pins for every SER. Concrete orchestrators implement only two hooks:
_submit_and_wait(node_callable, *, ser_hooks)Runs a node and returns its
Payload._publish(node, data, context, transport)Forwards the node output through the orchestrator’s transport.
All error handling, timing, and tracing responsibilities are handled by the
base class. LocalSemantivaOrchestrator simply delegates to the injected
executor/transport while benefiting from the shared SER logic.
During on_pipeline_start the orchestrator also emits a semantic fingerprint:
pipeline_config_id summarises the set of (node_uuid, semantic_id) pairs
computed from live processor metadata, and node_semantic_ids exposes the
per-node values used in that hash. Structural identifiers (pipeline_id and
node UUIDs) remain unchanged.
Public API Surface¶
Component Registry:
semantiva.execution.component_registryOrchestrator Factory:
semantiva.execution.orchestrator.factoryExecutors:
semantiva.execution.executor.executorOrchestrators:
semantiva.execution.orchestrator.orchestratorTransports:
semantiva.execution.transport.in_memory
Autodoc¶
- semantiva.execution.orchestrator.factory.build_orchestrator(exec_cfg, *, transport=None, executor=None)[source]¶
- class semantiva.execution.executor.executor.SemantivaExecutor[source]¶
- class SERHooks(upstream, trigger, upstream_evidence, context_delta_provider, pre_checks, post_checks_provider, env_pins_provider, redaction_policy_provider)[source]¶
- context_delta_provider¶
- env_pins_provider¶
- post_checks_provider¶
- pre_checks¶
- redaction_policy_provider¶
- trigger¶
- upstream¶
- upstream_evidence¶
- class semantiva.execution.orchestrator.orchestrator.LocalSemantivaOrchestrator(executor=None)[source]¶
- class semantiva.execution.orchestrator.orchestrator.SemantivaOrchestrator[source]¶
-
- execute(pipeline_spec, payload, transport, logger, trace=None, canonical_spec=None, run_metadata=None)[source]¶
- property last_nodes¶
- class semantiva.execution.transport.base.Message(data, context, metadata, ack)[source]¶
- ack¶
- context¶
- data¶
- metadata¶