How is provenance recorded and verified?

kafSIEM records provenance for edges, detector decisions, alerts, and analyst-visible artifacts. Provenance is tied to the source record and transaction that produced the artifact, so analysts and auditors can trace a visible result back to the originating evidence.

KafSIEM | Entity Graph Platform for Defense and Critical Infrastructure

Q: Can kafSIEM operate fully air-gapped?

Yes. kafSIEM is designed for self-contained deployment in air-gapped and restricted environments. Core product functions do not require cloud services or vendor telemetry. Classification and network boundaries remain under operator control.

Q: Does kafSIEM replace our existing detection stack, SIEM, or fleet command surface?

No. kafSIEM ingests from existing detection tools and adds an entity graph and link-analysis layer. Sensors keep sensing, SIEM tools keep triaging alerts, and command surfaces remain in place. kafSIEM is used to connect entities, events, evidence, and provenance across those systems.

Q: What storage does kafSIEM require?

kafSIEM uses an embedded relational storage layer. It can operate without an external database, uses WAL journaling, and supports file-level backup and restore patterns.

Q: How are the domain packs extended or customized?

Domain packs declare ontology, detectors, views, queries, map layers, and reports as YAML configuration. They are reviewable file sets that teams can inspect, fork, or co-author with Scalytics. The v1 release includes domain packs for unmanned systems and critical infrastructure.

Q: Is the source available before purchase?

Yes. The kafSIEM repository is available at github.com/scalytics/kafSIEM. The OpenAPI specification defines the contract. A live OSINT mode is available at osint.scalytics.io.

Q: Does kafSIEM observe and audit autonomous agent actions?

Yes. kafSIEM can place agent traffic, requests, responses, traces, and decision chains into the same entity, edge, and provenance graph as human actions. This makes autonomous actions traceable by actor, touched entity, cited evidence, and resulting decision.

In plain terms

What is kafSIEM?

What it is

A typed entity and link analysis surface for investigations and threat networks. Every edge carries a citation back to the source event.

Who it is for

Analysts and operators in defense and critical infrastructure who need agent traffic, OSINT, and operational telemetry on one surface.

The problem it solves

Intelligence is scattered across feeds and logs with no provenance. kafSIEM fuses them into one entity graph where every link is traceable.

What it connects to

Agent traffic, OSINT sources, and operational telemetry such as SCADA. Two analysis packs at launch: unmanned systems and SCADA.

Why it is different

Single binary, single SQLite file, single operator box. Every edge has a citation, so findings hold up to review.

Six commitments. No exceptions.

kafSIEM is a small set of architectural decisions that make link analysis usable for engineering teams, incident responders, and auditors who need to cite their work. These commitments hold across every pack, every API endpoint, and every release.

Provenance on every write

Every edge, every detector decision, every alert writes a provenance row in the same transaction that produces it. Not an enrichment column added later. Not a log line you correlate after the fact. The chain is reproducible from the source record offset.

Capture is isolated from analysis

Two services with a read-only boundary between them. Ingest cannot corrupt analyst state. Analyst queries cannot interfere with ingest. A bad source, a hot consumer, or a query storm stays contained on its own side of the line.

Runs where your network cannot reach

The deployment unit is a protected enclosure, not a cloud service. Ruggedized box on a vessel, node inside a SCIF, co-located enclosure adjacent to a plant control network. Air-gapped operation is the default assumption.

Built on contracts you can audit

The API is versioned and specified in OpenAPI. Errors follow RFC 9457. Integration does not require our code inside your environment. A reviewer with the specification can reproduce any query, any response, any state.

Domain logic is declarative, not code

A pack declares ontology, detectors, views, queries, map layers, and reports as configuration. No plugin runtime, no foreign code execution inside the core, no marketplace. Pack contents are reviewable line by line by the team that will be accountable for the decisions they produce.

Standards at every boundary

Kafka-compatible wire protocol inbound. RFC 7946 GeoJSON at WGS84 for geospatial. OpenAPI for the analyst surface. RFC 9457 for errors. No proprietary protocol sits between you and your own information.

Each commitment is a red line in the build. They are documented in the source, enforced in the integration pipeline, and visible at the API. A buyer who wants to verify them does not need a sales call.

The system

Capture, store, serve. Three stages. One boundary.

kafSIEM consumes agent traffic from a Kafka-compatible spine, writes typed entities, edges, and provenance to an embedded data layer with flight-certified heritage, and serves an entity-centric REST API to the analyst surface. The capture tier is the sole writer. The serve tier is read-only.

Three operating modes. Product contract, not marketing copy.

The mode names appear in the API, the documentation, and the analyst UI navigation. They are not category labels invented for a webpage.

OSINT

External intelligence

CVE feeds, adversary advisories, open-source telemetry, threat intel. The advisory that surfaced this morning on a new threat actor, cross-referenced against every asset, vendor, or individual your organization has touched in the last eighteen months, with every source citation preserved.

▸ See it live

OPERATIONS

Agentic-aware telemetry

Plant and fleet operations, workflow state, change history, alarm streams, and agent traffic: requests, responses, traces, autonomous decision chains. The same entity-edge-provenance model applies to autonomous actions as to human ones. Who acted, what they touched, what evidence they cited.

▸ See the workspace

FUSION

Joined workflows

The CVE that dropped this morning, ranked by which devices in your plant run the vulnerable firmware, ranked by process criticality, with every authenticated session that touched those devices in the last seventy-two hours. One query. One chain of citations.

▸ Runs across OSINT and OPERATIONS

Domain interfaces

Two packs ship in v1. Drones and SCADA.

A pack declares ontology, detectors, views, queries, map layers, and report templates as data. No plugin runtime, no arbitrary code, no marketplace. Two packs at launch is the architectural commitment: one would let the core drift toward a single domain, three would mean we built a platform before earning it. Two forces the core to stay pack-agnostic, which the build enforces in the integration pipeline.

Unmanned Systems

packs/drones

For sea-trial validation, pre-mission readiness, fault clustering, EW correlation, and software regression analysis across an unmanned fleet. Built for the engineer signing off on whether a vehicle is safe to field, and the program lead accountable for the decision.

Entity types

platformvariantsubsystemcomponent softwaremissionsortiecontact areaew_eventfaultfault_mode signoff

Detectors at launch

cohort-failure-early-warningroe-driftsilent-subsystem autonomy-rollback-candidatelot-anomalypre-mission-readiness-gap

Show every fault on this airframe across all trials, then show all platforms running the same software version. Two clicks.

Critical Infrastructure

packs/scada

For OT change auditability, CVE-to-criticality link analysis, incident reconstruction, and compliance evidence production across the Purdue model. Built for the OT security lead and plant engineering manager who own the consequences of every write to the process.

Entity types

plantzonedevicefirmware processtagalarmchange engineersessionwork_order vulnerabilitytradecraft

Detectors at launch

purdue-violationchange-without-work-orderfirmware-drift tradecraft-matchstale-sessionalarm-flood-after-change

Every change to tags A, B, C in the 72 hours before this alarm flood, with the work order each change cites. Two clicks.

Provenance

Every edge has a citation.

Provenance is a first-class write, not a log line. Every edge, every detector decision, every alert writes a row in the same transaction that produced it. The analyst surface walks any visible artifact back to the source record in one click.

Other systems call this context. It isn't. Context is an enrichment column added after the fact. Provenance is a transactional commitment: the row exists because of a specific input, the input is named, and the chain is reproducible from that input alone. That is what makes kafSIEM useful for a post-incident engineering review, an audit evidence bundle, or a no-go signoff memo.

Run Queue 4 / 12

all anomaly live pinned

flow:f1129 14:02

Pre-mission readiness

3 ent · 14 edges · ok

flow:f1130 14:08

Sortie 114 · IMU drift

7 ent · 23 edges · ▲ anomaly

flow:f1131 14:04

Cohort fault check

12 ent · 41 edges · inspect

flow:f1132 ● live

EW correlation · box-bravo

5 ent · 18 edges · +3/s

replay1

failures2

raw3

operator4

topology5

map6

traversed

evidence edge

background

⊡

↺

-24h-12hNOW · 2026-04-22T14:08Z

Platform

auv-07

first_seen 2025-11-14 · 214 records

fields edges prov hist

variantblock-2 mk-iii

softwarev3.4.1

cohort_size14

open_faults3 ▲

last_sorties-114

last_signoff2026-04-19

approvereng-mira

readinessno-go

Active detectors

cohort-failure-early-warning
autonomy-rollback-candidate

pin [p]

expand [e]

annotate [n]

export [x]

▸ prov · edge F-1207→imu-04 topic.faults:0:84211 → graph-writer-v0.5.2 → handleRecord/responses → 2026-04-22T14:08:11Z

Analyst workspace · topology tab · provenance drawer pinned

Architecture commitments

Red lines, in plain text.

A buyer in defense, critical infrastructure, or regulated process operations reads architectural commitments more carefully than they read case studies. Each line below is enforced in the integration pipeline, documented in the source, and visible at the API.

Capture and serve are separate processes. A read-only boundary is the contract between them.

The API is entity-centric and versioned. /api/v1 never ships a breaking change.

Provenance is written in the same transaction that produces the edge. No exceptions.

Packs are constrained domain interfaces. Not plugins, not arbitrary code, not a marketplace.

Replay never mutates the live consumer group.

Geospatial is core, not pack-local. RFC 7946 GeoJSON on the wire, WGS84 at rest. No provider lock-in.

Deployment posture

Runs where your mission runs.

kafSIEM is designed for environments where a cloud dependency is a dealbreaker. No external service calls in the core loop. No telemetry back to the vendor. Classification and network boundaries are the operator's decision, not a platform-imposed constraint.

Footprint

A ruggedized industrial PC, an enclosure on a vessel, a node inside a SCIF, or a VM on your own hypervisor. Zero external dependencies in the core loop. The deployment does not phone home.

Storage

The embedded storage runs on SQLite, a database layer widely used in embedded systems, including aerospace and other mission-critical environments. It is the most deployed database in the world and is engineered for mission-critical reliability. Zero-config, zero-daemon, WAL-journaled file-level semantics.

Backup and restore

WAL-aware file snapshot. Restore is copy-back. A single operator can produce a verifiable backup in one command. Disaster recovery does not require our involvement.

Transport

Kafka wire protocol inbound. S3-compatible object storage outbound for long-term segment retention if you want it. If we lose the deal, your data leaves on the same standards it arrived on.

Integrates

kafSIEM does not replace your existing detection stack, your SIEM, or your fleet command surface. It ingests from them and provides the link-analysis layer those systems leave to spreadsheets and case management add-ons. Your sensors keep sensing. Your queue keeps queueing. kafSIEM answers the questions the other tools structurally cannot.

Agentic-ready

Autonomous agents and human operators produce the same kind of event on the wire: a request, a response, a decision, a trace. kafSIEM models both the same way. Every autonomous action is subject to the same provenance chain as a human one. Who acted, what they touched, what evidence they cited. Agent audit is not a feature add-on. It is a consequence of how the graph is built.
▸ Our agent runtime · kafclaw.scalytics.io

Source access

kafSIEM is developed openly at github.com/scalytics/kafSIEM. The repository is inspectable before purchase. The OpenAPI specification is the contract; any third-party client that honors it interoperates without our involvement. The OSINT mode is running live at osint.scalytics.io.

Procurement questions

What buyers ask before a first briefing.

The seven questions procurement officers, OT security leads, and defense program managers raise in every early call. Answered here so the briefing time can go to your actual problem.

Can kafSIEM operate fully air-gapped?

Yes. The deployment unit is self-contained. No external service calls in the core loop. No telemetry back to the vendor. No cloud dependency for any product function. Classification and network boundaries are the operator's decision, not a platform-imposed constraint.

Does kafSIEM replace our existing detection stack, SIEM, or fleet command surface?

No. kafSIEM ingests from existing detection tools and adds the link-analysis layer those systems leave to spreadsheets and case management add-ons. Your sensors keep sensing. Your SIEM keeps triaging alerts. Your command surface stays where it is. kafSIEM answers the questions the other tools structurally cannot.

What storage does kafSIEM require?

kafSIEM comes with an embedded relational storage layer built on SQLite, a database known for high-reliability embedded use. No external database is required. Storage is single-file with WAL journaling. Backup is a file-level snapshot. Restore is copy-back.

How is provenance recorded and how is it verified?

Every edge, every detector decision, every alert writes a provenance row in the same transaction that produced it. The chain is reproducible from the source record offset. Any visible artifact in the analyst surface walks back to the originating record in one click. Third-party auditors with only the OpenAPI specification can reproduce any query and any state.

How are the domain packs extended or customized?

Packs declare ontology, detectors, views, queries, map layers, and reports as YAML configuration. No plugin code runs inside the core. A pack is a reviewable file set that your team can inspect, fork, or co-author with us. Two packs ship at v1 release: unmanned systems and critical infrastructure. Additional packs are built by the team accountable for the decisions they produce.

Is the source available before purchase?

Yes. The repository is at github.com/scalytics/kafSIEM. The OpenAPI specification is the contract. Any third-party client that honors the specification interoperates without our involvement. The live OSINT mode is running at osint.scalytics.io.

Does kafSIEM observe and audit autonomous agent actions?

Yes. Agent traffic (requests, responses, traces, decision chains) enters the same entity-edge-provenance graph as human actions. Every autonomous action is subject to the same provenance chain: who acted, what they touched, what evidence they cited. Agent audit is a consequence of the architecture, not a separate feature. The agent runtime is at kafclaw.scalytics.io.

Where this is in the build

Foundation shipped. Packs in flight. Design partners welcome.

The technical buyer reads this section more carefully than the case studies. A platform that admits what is shipped and what is in flight is one the buyer can plan against. A platform that claims everything is ready is one the buyer assumes is hiding the integration cost.

SHIPPED

Foundation

Entity, edge, and provenance schema. Query primitives with k-hop traversal. Entity-centric API tier with OpenAPI as the source of truth. Generated TypeScript client. Pack-aware analyst surface with the three-column workspace home.

IN FLIGHT

Packs

The unmanned systems and SCADA packs target v1.0 release in the next development cycle. Pack file format is locked. Detectors are landing. Map layers and report templates are in review. Both packs shipping together is the architectural gate.

OPEN

Design partners

We are working with a small number of unmanned systems programs and OT operators on the v1 contract. If you operate a fleet, a plant, or a regulated process where the gap described above is your gap, request a briefing.

Who builds this

Built by a team with Apache, military, and enterprise engineering experience.

Scalytics brings together Apache open-source leadership, military operational experience, and enterprise engineering depth. The team includes the original inventors of Apache Wayang and senior operators and engineers from organizations including Allianz, Cloudera, Confluent, E.ON, McKinsey, and Scout24. kafSIEM reflects that background: disciplined system boundaries, auditable contracts, and design choices made for mission-critical environments.

Request a technical briefing.

45 minutes. Architecture, pack file format, integration paths, design partner terms. Bring your hardest entity-resolution question. Or try the OSINT mode live first.

Book a briefing Try the live OSINT demo

kafSIEM

Your analysts need evidence. Not another dashboard.