Single-process operational boundary
Keep critical runtime behavior inside one JVM process.
Architecture
The architecture changes. The execution boundary does not.
StreamKernel fits between the systems that evaluate or recommend and the systems that act or commit. It governs that transition without replacing your decision engine, transport, or protected system.
Architecture level 1 · Your environment
Start with where a proposed action becomes real.
Kafka, REST, MQ, payment switches, agent frameworks, models, and vendor platforms can all sit around this boundary. StreamKernel is transport- and vendor-agnostic; Kafka is one supported integration pattern, not a prerequisite.
Existing decision system Evaluate · score · recommend Fraud engine · agent · model · rules · application
StreamKernel governed execution boundary Policy → Authority → Control → Execution → Evidence Fail closed before downstream action
Protected system Act · commit · deliver API · payment · case platform · database · enterprise app
Architecture level 2 · Runtime implementation
How StreamKernel implements the boundary.
The customer architecture comes first. Inside the boundary, a compact plugin-based runtime keeps policy, transforms, provenance, delivery, and failure handling inspectable.
Runtime narrative
Source Plugin -> Core Orchestrator -> Policy Plugin -> Transformer Chain -> Sink Plugin.
Deny and failure paths flow to DLQ, while Prometheus and OpenTelemetry metrics are emitted across kernel, transform, and sink. MLflow model registry support can promote or roll back artifacts into the transform path, and sink plugins cover Kafka, MongoDB Vector, Postgres, PostgreSQL pgvector, Delta Lake, Snowflake, and custom targets.
Config-driven pipelines
Use .properties files to define pipeline behavior.
Plugin-owned extensibility
Let customers or authors bring plugins without giving up kernel control.
Policy at execution time
Enforce policy, provenance, and cost controls while the event is executing, before sink delivery or action.
Evidence-first runtime
Emit logs, metrics, settings, and replay metadata.
Commercial AI boundary
Keep protected AI implementation details outside public source.
Plugin model
Customers can bring plugins without giving up kernel control.
Source, policy, transform, sink, metrics, AI, OpenTelemetry, and MCP paths are extensible at the edge while the runtime preserves the auditable execution envelope. Postgres and PostgreSQL pgvector are first-class sink targets alongside Kafka, MongoDB Vector, Delta Lake, and Snowflake.
Runtime signals
- Effective settings and replay metadata.
- Per-batch policy outcomes and audit headers.
- Transform, sink, DLQ, and kernel metrics exported through Prometheus and OpenTelemetry.
- Model/version labels for AI-enriched records.
- Opt-in MCP JSON-RPC tools for local agent status, config validation, audit verification, and guarded model lifecycle operations.
Commercial path
Need to map StreamKernel into your platform architecture?
Review the runtime boundary, plugin model, policy path, and commercial packaging options with the team.