The Bottom Line
A Decision Fabric is Scalytics’ proposed architecture for keeping evidence, state, policy, authority, action and outcome connected in an accountable decision graph. It treats the transition from insight to operational effect as a governed act, not a side effect of model access. Kafka can preserve event history, but event history alone cannot establish that an action was lawful, authorized or morally defensible. So any automation with real consequences needs human judgment, intervention and review built into the runtime record.
Insight is evidence rather than authority
A sudden divergence between a supplier’s delivery events and its contracted schedule can reveal a supply interruption. It remains evidence. An analysis can strengthen that evidence by estimating causes, consequences and confidence. It still does not authorize an effect.
The distinction becomes visible when an AI system can act. A pricing recommendation becomes consequential when a published price changes. A logistics forecast matters when inventory is redirected. A risk score acquires force when a transaction is restricted. In each case, the system crosses several different boundaries:
- A signal reports an observed change.
- An analysis assigns meaning to that change.
- An authorized effect changes the operational world.
- An outcome shows whether the change achieved its purpose and what else it caused.
A model can contribute to the second step. Tool access can permit the third. Neither fact proves that the action should occur.
This is why model quality cannot carry the whole accountability argument. A highly accurate model may act under an obsolete policy. A well-grounded answer may exceed delegated authority. A technically valid action may create a disproportionate effect. The hard question is not whether the system produced an informed recommendation. It is whether the transition from evidence to effect remained lawful, authorized, contestable and attributable.
That question now appears in public guidance on agentic systems. The UK National Cyber Security Centre advises that greater autonomy requires stronger controls, including active oversight, attribution, observability and an emergency shutdown capability. These controls sit around the model because the model cannot grant itself authority.
Insight has informational value. A decision acquires institutional meaning only when evidence, permission and responsibility meet.
The governed transition is the missing boundary
Data architectures usually govern information. AI architectures usually govern models, context and tools. Neither one necessarily governs the act that turns a recommendation into a real effect.
A Decision Fabric addresses that gap. A Decision Fabric is an event-driven control architecture that binds the evidence for a decision to its governing state, applicable policy, delegated authority, resulting action and observed outcome.
That definition says what is being governed. It is not only a dataset, prompt, model call or workflow. It is the decision itself, kept as one connected and durable record.
The following comparison is an analytical framework, not an industry standard. Its purpose is to expose the question each architecture leaves for another layer.
This boundary cannot be created by adding more data to a lake. Exporting events, policies and logs into one central store may support later analysis. It does not guarantee that the policy checked during action was the policy later reviewed. A centralized ontology may describe relationships well while still separating the operational event from the authority that governed it.
Our design idea is stricter. Keep the event history, maintained state, policy version, authority check, action and outcome connected when the decision occurs. Do not depend on later reconstruction across systems with different clocks, retention rules and identifiers.
We built Apache Wayang, and at Scalytics we use Sovereign Decision Fabric for the further requirement that this connected record and its reasoning remain under the organization’s control. The category argument is set out in the Sovereign Decision Fabric definition. Sovereignty matters here because control over data without control over decision provenance is incomplete.
Six elements make a decision inspectable
An accountable decision graph needs six connected elements. Each answers a different question, and none can substitute for another.
Evidence records what the system observed. Useful references include an event identifier, event time, source position, schema version and integrity information. These fields are recommended controls rather than universal standards. Their purpose is to identify the exact inputs used, including late arrivals and corrected records.
State records the maintained facts that gave the evidence meaning. It can include current relationships, unresolved cases, prior decisions and freshness status. Retrieval can find similar material, but similarity does not prove that the material describes the current operational state. State therefore needs a version or checkpoint that the decision can cite.
Policy states the constraints that applied. A policy reference should identify its version, effective period and required evidence. It should also encode rejection and escalation conditions. Recording “policy passed” is too weak when the underlying rule can later change.
Authority identifies the permission to create an effect. It should state who or what delegated that permission, its scope, its limits and its expiry. The ability to call a tool is a technical capability. Authority is a normative permission. Confusing the two turns access control into an accidental ethics system.
Action describes the proposed and executed effect. It needs a stable action identifier, target, parameters and idempotency control. Idempotency matters because replaying a decision must not repeat an irreversible effect. The record must distinguish simulation, proposal, approval, execution, rejection and compensation.
Outcome connects the action to what followed. It can identify whether the intended change occurred, whether side effects appeared and whether a corrective action followed. Without this edge, a system can count actions while remaining blind to consequences.
Together, these elements form an event-driven decision graph. The graph does not make a decision morally right by itself. It makes the grounds, authority and consequences available for examination. That is the minimum condition for meaningful challenge.
Event history needs maintained meaning
Apache Kafka’s design documentation defines each topic partition as a totally ordered log and explains that records remain available according to configurable retention and compaction policies. The scope matters: order is established within a partition, not across an entire distributed history, and retention settings can remove records. Kafka Streams also distinguishes event time from processing time, so an event’s source timestamp and the time at which a system evaluates it are not interchangeable.
These properties make replay powerful, but they do not make replay proof of authority or lawful action. An external effect may complete in another system after a decision event is appended, fail before acknowledgement, or be compensated under a later policy. The log can preserve what its producers recorded. It cannot, by itself, establish that delegated authority covered the effect, that a person could intervene, or that the action complied with the law.
KafGraph is a BadgerDB-backed property graph with an OpenCypher subset, a Bolt v4 interface and JSON-schema tool-call APIs. Those are implementation facts. In the Decision Fabric proposed here, that graph capability can be used to connect source events with entities, state versions, policies, approvals, actions and later outcomes. That is a way of using the graph. It is not a claim that KafGraph decides authority or legal questions on its own.
That division of responsibility is useful:
- Kafka records that an event was appended within the log’s defined ordering guarantees.
- Maintained state records what the system believed at a specific checkpoint.
- The graph connects that state to the evidence, policy and authority used.
- A decision event records the proposal and disposition.
- An outcome event records what happened after execution.
The graph edge must carry provenance. If a relation says that an account controls an asset, the edge should point to the source event or governed record supporting that claim. If a policy changes, decisions made under the earlier version must retain their original policy reference. Current truth cannot overwrite historical justification.
This approach differs from reconstructing provenance after exporting records into a lake. Reconstruction asks several systems to agree after the event. Recording in place captures the evidence-to-action relationship while the relevant versions and permissions are active. The resulting graph can still be queried centrally, but its accountability does not begin with the query.
There are limits. A graph can preserve a false assertion perfectly. An ordered event can carry bad data. A complete lineage record can show that an unauthorized decision was processed exactly as designed. Provenance improves inspectability, not truth. Validation, policy review and human judgment remain necessary.
Can replay prove that an AI decision was accountable?
No. Replay can show how a system reached a result, but accountability also requires lawful authority, meaningful human control and an attributable choice.
A useful AI decision record should bind the technical trace to the normative decision. At minimum, it should include:
- a stable decision identifier and subject;
- exact evidence references, including source positions and schema versions;
- the maintained state version and freshness status;
- policy identifiers, versions and evaluation results;
- authority references, delegated limits and expiry;
- the proposed action, target and idempotency key;
- human intervention status, including approve, reject, modify, halt or not required;
- model, prompt, tool and runtime versions where AI contributed;
- decision time, execution time and relevant event-time boundaries;
- outcome references and compensation status;
- replay status, including any nondeterministic or unavailable dependency.
The record should separate facts from model inferences. It should also preserve rejected proposals. Rejection is evidence that a control worked, and repeated rejection may expose a model or policy defect.
Replay then becomes a test with explicit scope. It can ask whether the same evidence and versions reproduce the same recommendation. It can verify whether the authority check ran. It can show whether an action was modified before execution. It cannot prove that a policy was lawful or that a person exercised sound moral judgment.
NATO’s revised AI strategy makes this distinction visible. Its Principles of Responsible Use include lawfulness, responsibility and accountability, explainability and traceability, reliability, governability, and bias mitigation. Traceability is one principle among several. A trace can support responsibility, but it cannot replace it.
The practical implication is direct. An accountable system needs both reproducible technical evidence and a defensible chain of authority. One without the other is an incomplete record.
Human judgment belongs inside the control loop
Human-in-the-loop cannot mean placing an approval button after a machine-generated recommendation. Meaningful control requires enough time, information and authority to change the result.
The UK Government AI Playbook calls for human validation of high-risk decisions and strategies for meaningful intervention. That standard has architectural consequences. The system must present the evidence, uncertainty, policy basis and proposed effect before approval. It must also record modification, rejection and inaction.
The bar is higher where the Law of Armed Conflict applies. The UN guiding principles on lethal autonomous weapons systems affirm that international humanitarian law continues to apply and that human responsibility cannot be transferred to machines. A model cannot bear legal or moral responsibility. Nor can a graph.
The person authorizing force needs more than a confidence score. The control interface must display the target basis, applicable constraints, uncertainty, expected effect and alternatives, then require an attributable approval or withholding of action before execution.
The person interpreting evidence needs to see provenance and contradiction, not only a synthesized answer. The evidence view must expose source records, disputed facts and confidence limits without forcing acceptance of the model’s summary.
The person reviewing events afterward needs to distinguish what the system observed, inferred, recommended, authorized and executed. The after-action record must preserve those stages as separate, time-stamped entries, including modifications, rejected proposals and any later compensation.
These are different acts of judgment. The decision record must preserve each one.
A runtime authority test should reject or escalate an action when any of the following is true:
- evidence is missing, stale, contradictory or outside its permitted use;
- policy is absent, expired or ambiguous for the proposed effect;
- delegated authority does not cover the target, action or consequence;
- the human cannot inspect the basis or intervene in time;
- the action is irreversible while material uncertainty remains;
- the system cannot attribute the decision or preserve its record;
- observed conditions have moved beyond the tested operating boundary.
A halt control must operate independently of the model proposing the action. Otherwise, the same component that exceeded its limits controls the remedy. Secure AI system development requires controls that address the system across its lifecycle. The NCSC’s advice to preserve an emergency shutdown capability follows the same logic.
Human agency is therefore a system property as well as a moral principle. It depends on what the interface reveals, when it reveals it, and whether intervention can still change the outcome.
Outcomes close the accountability loop
A decision architecture remains incomplete until it connects action to consequence. The outcome edge supplies the evidence needed to assess value, harm and policy fitness.
Consider a logistics redirection. Execution records can prove that inventory moved. They cannot show whether the move reduced disruption, created scarcity elsewhere or required a later reversal. A pricing change may increase revenue while breaching a policy constraint. A transaction restriction may prevent loss while imposing an unjustified cost on a legitimate party.
Outcome linkage supports three distinct forms of review.
- Operational review asks whether the action produced its intended result.
- Policy review asks whether the governing rule remains appropriate after observing consequences.
- Moral and legal review asks whether the decision respected duties that cannot be reduced to performance.
This changes how improvement works. A system should not learn only from accepted actions or successful predictions. It should also learn from rejected proposals, overrides, appeals, reversals and harmful side effects. Those records reveal where evidence, policy and authority diverged.
Outcome attribution will often remain uncertain. Several actions may contribute to one result, and the result may emerge long after the decision. The fabric should represent that uncertainty rather than manufacture a clean causal story. Links can record contribution, sequence and confidence without claiming proof of causation.
That restraint is part of accountability. A complete record is not the same as a complete explanation.
The policy choice can no longer be avoided. We propose this burden: any system that can create operational effects must prove that evidence, policy, authority, action and outcome remained connected at decision time.
If that burden is rejected, what weaker form of accountability are its sponsors prepared to defend?
We build parts of this in the open: Apache Wayang, KafScale and KafGraph.
