Sovereign Decision Fabric

What is a Sovereign Decision Fabric?

The events, the reasoning, and the record of every decision stay together, in place.

A category for organizations that need to run assisted and autonomous AI on their own events without shipping those events, or the reasoning about them, into a platform they do not control.

Scalytics · Published Jul 2, 2026 · ~11 min read

Live AI. Real-Time Decisions. High-Impact Results.

Your analysts need evidence. Not another dashboard.

kafSIEM turns alerts, relationships, and detector decisions into auditable link analysis for defense, unmanned systems, and critical infrastructure.

Book a call

A Sovereign Decision Fabric is a Kafka-native platform where every business-relevant event is observable in real time, agents and policies reason over the stream where the data is produced, and every decision is written back as an immutable, auditable event, so reasoning and data never leave the organization's jurisdiction.

It matters because regulated organizations can now run AI on their own events without exporting those events, or the interpretation of them, to a platform they do not govern. The audit trail becomes a property of the system rather than a report assembled afterward.

The concept

What a Sovereign Decision Fabric is

Picture your organization's activity as a continuous stream of events rather than a set of tables updated overnight. A payment clears, a sensor reports, a case file changes state, an operator approves a dispatch. Each of these is an event, and on a Sovereign Decision Fabric each one is observable the moment it happens.

The fabric places three things on that stream. First, the events themselves, kept as an ordered, immutable log. Second, the agents and policies that read the stream and reason about what is happening. Third, the decisions those agents and policies produce, written back onto the same stream as new events.

The defining move is where the reasoning runs. Compute goes to the data. Agents reason in the environment where the events are produced, rather than the events being copied out to a separate platform to be reasoned about elsewhere. Nothing about a decision, the inputs, the policy that applied, the model that ran, or the output, has to leave the jurisdiction the data already sits in.

Because every decision is itself an event on the log, the fabric is replayable. You can reconstruct why any decision happened by replaying the events that led to it, in order. There is no separate black box to interrogate and no after-the-fact reconstruction from disconnected logs.

A CIO can hold the whole idea in one sentence: the events, the reasoning, and the record of every decision stay together, in place, on infrastructure the organization controls.

Why the category exists now

Why this category exists now

The category exists because three pressures arrived at the same time.

The first is regulatory. In the European Union, DORA has applied to financial entities and their critical ICT providers since January 2025, requiring them to show how automated processes reach outcomes and to keep those processes resilient and traceable. NIS2 extended cybersecurity and incident-reporting duties across a wide set of critical sectors, with transposition falling due across member states from late 2024. The EU AI Act adds record-keeping, logging, and human-oversight obligations for high-risk systems, phasing in through 2026 and 2027. The common thread is that an organization is now expected to explain and evidence automated decisions, not just produce them.

The second pressure is the cost and control of data movement. The default AI pattern copies data out of the systems that produce it and into a separate platform for processing. At scale, the egress and duplication carry real cost, and the copy sits somewhere the organization no longer fully governs.

The third is the one the first two make unavoidable: outsourced cognition. When the reasoning about your events happens inside a platform you do not control, you have handed over not just the data but the interpretation of it. For a defense agency, a grid operator, or a bank, that is a sovereignty problem before it is a technical one.

A Sovereign Decision Fabric answers those three pressures at once. It keeps the events in place, runs the reasoning where they are produced, and records each decision as evidence by construction.

The definition

What makes something a Sovereign Decision Fabric, and what does not

Five properties define the category. A system that lacks any one of them is something else.

01 · In-situ reasoning

Compute goes to the data

The data is never exported into someone else's platform to be reasoned about. The moment events leave the jurisdiction they were produced in, control and provenance both weaken. A fabric keeps reasoning and data in the same place.

02 · Event-native

Live events, not snapshots

Every relevant event is observable in real time on the stream, not read from a batch taken hours later. Decisions made on stale snapshots describe a state the organization has already left.

03 · Decisions as events

Every decision is written back

Each decision an agent or policy makes is emitted onto the log as a new, immutable event carrying its inputs and the policy that produced it. A decision not recorded as it happens cannot be audited later without reconstruction.

04 · Replayable provenance

You can reconstruct any decision

Replay the ordered log that led to a decision and you have its full provenance. This is the difference between a system you can explain and a black box you can only describe. Replay turns audit from an investigation into a query.

05 · Sovereign and open

In-jurisdiction, on open foundations

Reasoning, data, and audit stay in-jurisdiction, on-premises or air-gapped where required, on Apache-licensed foundations that extend existing Kafka rather than replacing it. Sovereignty that depends on one vendor's goodwill is not sovereignty.

The boundary

What does not qualify

A platform that reasons on copied data fails property one. A batch analytics system fails property two. A system whose decisions are not themselves auditable events fails three and four. A closed platform you cannot inspect or run in your own jurisdiction fails five, whatever else it does well.

The distinctions

How it differs from a data lake, a RAG stack, or a SaaS agent platform

It is easy to mistake a Sovereign Decision Fabric for something you already have. The distinctions are at the level of architecture, not features.

A data lake or warehouse centralizes data so it can be queried. It is built for data at rest and for questions asked after the fact. A fabric is built for data in motion and for decisions made as events occur. The lake answers what happened; the fabric acts on what is happening and records what it decided.

A retrieval-augmented generation stack pairs a language model with a search index over your documents. It is a good way to answer questions about a corpus. It is not a decision system: it does not observe live events, it does not emit decisions as auditable records, and the reasoning usually runs against a model and index hosted outside your control.

A SaaS agent platform gives you agents, but on the vendor's terms. Your events flow into their environment, the reasoning runs there, and the record of what was decided lives there too. That is the outsourced-cognition pattern the fabric exists to avoid.

	Sovereign Decision Fabric	Data lake / warehouse	RAG stack	SaaS agent platform
Where data lives	In place, on the organization's own infrastructure	Centralized copy	Copied into an index	In the vendor's environment
Where reasoning runs	On the stream, in situ	In query engines, after load	Against a hosted model and index	In the vendor's cloud
What a decision produces	A new immutable event on the log	A query result	A generated answer	An action in the vendor's system
Audit and replay	Built in; replay the log	Reconstruct from query history	Limited to prompt and response logs	Depends on vendor export
Jurisdiction and control	Stays in-jurisdiction, organization-controlled	Depends on where the lake sits	Depends on the model and index host	Vendor-controlled
Effect on existing Kafka	Extends it, no rip-and-replace	Separate system	Separate system	Separate system

The planes

What it is made of

At the concept level a Sovereign Decision Fabric is built from a small set of planes. Each one answers a different question about running autonomous agents on your own events.

Event plane. It makes everything that happens observable the moment it happens. An ordered, immutable log of every business-relevant event, Kafka-native and backed by object storage, so it extends the streaming platform you already run and keeps long event history at object-storage cost.

Reasoning plane. It is where production agents coordinate and act, next to the data. The runtime where agents and policies read the stream and decide. It runs in situ, inside your network, rather than in an external service, so the reasoning never leaves your control.

Memory plane. It gives teams of agents one shared, persistent memory instead of isolated context. Operational memory across the stream, so agents reason with context beyond a single event and a single agent. Isolated agents cannot run real missions; shared memory is what lets them act as one.

Provenance and audit plane. It makes every decision a replayable event, so audit is a query, not an investigation. Every agent message, action, and decision is persisted as an immutable record, and every edge in the resulting graph carries a citation. This is what makes the fabric explainable on demand.

Capability plane. It turns agent skills into governed, provable, revocable assets. This is the trust layer for what autonomous agents are allowed to do. The capability plane governs what the agents themselves are allowed to do. Every skill an agent can use is packaged, signed, and given a verifiable identity, so its origin and permitted use are provable before it ever runs. Capabilities are granted, attested, and revoked on demand, and each check is offline-verifiable, needing no external authority in the verification path. This is what lets an organization run autonomous agents in production with confidence: not only is every decision recorded and replayable, every ability an agent holds is itself authorized, provable, and revocable.

The core components are open, Apache 2.0, and free to run yourself, including the Community Edition. Scalytics's supported realization of a Sovereign Decision Fabric is Lascaris: the same parts, integrated, hardened, and maintained under one contract. Policy enforcement at the edge of the stream is a distinct facet worth reading on its own in policy enforcement for agentic AI at the edge.

What it changes

What it changes, by sector

Defense and national security

Operational and intelligence data is reasoned over inside the air-gapped boundary, with entity and link analysis where every edge carries a citation and every automated decision recorded as evidence. Autonomy never means loss of accountability.

Explore defense →

Energy and critical infrastructure

Grid and site operators act on live telemetry to flatten peak demand and absorb renewable surplus, with every recommendation logged and a human approving any control action before an asset moves.

Explore energy →

Regulated industries

Companies in audit-bound sectors run AI on live operational data and meet record-keeping duties by construction, because every decision is already an immutable, replayable event. Compliance without compromise.

Explore regulated industries →

In every case the change is the same shape: the decision moves to where the data already is, and the record of it is a byproduct of making it.

FAQ

Questions buyers ask

Is a Sovereign Decision Fabric the same as a data lake?

No. A data lake centralizes data so you can query it after the fact. A Sovereign Decision Fabric reasons over live events in place and writes each decision back as an immutable record. One describes what happened; the other acts as things happen and keeps the evidence.

Do we have to replace our existing Kafka?

No. The fabric is Kafka-native and extends the streaming platform you already run. There is no rip-and-replace of your event backbone.

Where does the AI actually run?

On the stream, in the environment where your events are produced. The reasoning is brought to the data rather than the data being copied out to a hosted service.

How is a decision made auditable?

Every decision is emitted as a new immutable event carrying its inputs and the policy that produced it. You reconstruct why anything happened by replaying the ordered log, so audit becomes a query rather than an investigation.

Is this on-premises only, or can it run in the cloud?

It runs wherever your jurisdiction requires, including on-premises and air-gapped environments. The point is that reasoning, data, and audit stay in a place the organization controls.

What makes it sovereign rather than just self-hosted?

Three things together: the data and reasoning stay in-jurisdiction, the foundations are open and inspectable so you can verify what the system does, and it runs on your terms with no dependence on a single vendor's platform.

How is it different from a RAG chatbot on our documents?

A RAG stack answers questions about a document corpus. It does not observe live events, does not emit decisions as auditable records, and usually runs against a model and index hosted outside your control. A fabric is a decision system, not a question-answering layer.

Last updated Jul 2, 2026