DKE for AI Developers: A Semantic Runtime for Stateful, Auditable Agents

Using the Deterministic Knowledge Engine as a semantic layer beneath probabilistic AI

LangSyn Technical Whitepaper
Version 1.0 — 27 September 2026

Abstract

Modern AI applications increasingly combine large language models with retrieval, tools, databases, workflows, and autonomous agents. The resulting systems are capable, but their knowledge and state are often fragmented across prompts, vector stores, application databases, tool outputs, and undocumented program logic.

This paper presents the Deterministic Knowledge Engine (DKE) as a semantic layer for AI systems.

DKE is designed to represent persistent knowledge as structured claims, execute deterministic semantic programs, maintain provenance, evaluate standing rules, preserve temporal state, expose conflicts, and support alternative or hypothetical states. It is also exposed as a service over the Model Context Protocol (MCP), allowing an MCP-capable AI agent to use DKE without adopting a bespoke agent SDK.

The central architectural proposal is simple:

Let the language model interpret, plan, communicate, and synthesize; let DKE maintain semantic state, execute explicit rules, and produce machine-verifiable derivations.

This creates a division of labor between probabilistic intelligence and deterministic semantic infrastructure.

The paper describes where this architecture is useful and how it differs from conventional databases and RAG systems, then presents concrete application patterns, a reference architecture, its limitations, and a practical adoption path for AI developers.

1. Introduction

The current generation of AI applications has created a new systems problem.

A language model can reason about an enormous amount of information, operate tools, summarize documents, write code, and plan multi-step tasks. Yet an application built around a model still needs to answer questions such as:

These questions are not primarily natural-language problems.

They are semantic state problems.

Most AI stacks address them indirectly. Conversation history becomes memory. Documents become embeddings. Business rules become application code. Auditability becomes logging. Conflicts become application-specific reconciliation logic. "Why?" becomes an LLM-generated explanation.

That approach can work, but it tends to distribute semantics across layers that were not designed to provide a single coherent model of knowledge.

DKE takes a different approach.

DKE treats knowledge as a programmable semantic state and provides a deterministic execution environment for working with that state. The published DKE documentation describes a language with a normative specification, an MCP service, traceable derivations, isolated stores, all-or-nothing compilation, and a library of reasoning modules.

The result is a possible foundation for a new class of AI application:

Probabilistic agents operating over deterministic semantic worlds.

2. The Core Thesis

The key architectural distinction is between probabilistic intelligence and deterministic semantic state.

A large language model is exceptionally useful for:

It is not, by nature, the right substrate for:

DKE is designed for the second category.

This suggests the following division:

                 HUMAN / EXTERNAL WORLD
                          |
                          v
                 +----------------+
                 |   LLM / AGENT  |
                 |                |
                 | interpretation |
                 | planning       |
                 | synthesis      |
                 | communication  |
                 +---+--------+---+
                     |        |
                    MCP     other tools
                     |        |
                     v        +-----------+-----------+
          +----------------+  |           |           |
          |      DKE       | APIs        RAG      databases
          |                |
          | semantic state |
          | rules          |
          | provenance     |
          | derivations    |
          | temporal state |
          | conflicts      |
          | hypotheses     |
          +----------------+

DKE sits beside the agent's other tools, not in front of them: the agent reaches APIs, retrieval, and databases directly, and brings what it learns to DKE as claims.

The point is not to replace the LLM.

The point is to give the LLM a semantic runtime.

3. What DKE Adds to an AI Stack

DKE occupies a space that is adjacent to, but different from, several familiar technologies.

3.1 DKE and relational databases

A relational database is excellent at storing structured records and enforcing schema and transactional constraints.

DKE is concerned with the meaning of claims and their derivations.

A database can store:

customer.plan = "enterprise"

DKE can represent a claim and the semantic relationships around it, allowing an application to ask not only what the current value is, but also what supports it and what follows from it.

The distinction is not "database versus DKE." A DKE-backed application can still use SQL databases as operational stores.

The distinction is:

A database stores application state; DKE can represent and reason about semantic state.

3.2 DKE and vector databases

Vector retrieval answers a highly useful question:

"Which information is semantically similar to this query?"

DKE answers a different question:

"Given the facts and rules in this semantic state, what is true, what follows, what conflicts, and why?"

A practical AI system can therefore use both:

Documents
    |
    v
Embedding / retrieval
    |
    v
Relevant evidence
    |
    v
DKE claims + provenance
    |
    v
Deterministic derivation
    |
    v
LLM explanation

3.3 DKE and conventional rules engines

Rules engines generally operate over explicitly defined application objects and workflows.

DKE makes rules part of a persistent semantic environment. A rule can derive knowledge from claims and participate in a broader derivation graph.

This is particularly relevant when the AI itself is helping construct or modify the rules.

3.4 DKE and knowledge graphs

Knowledge graphs emphasize entities, relations, and graph structure.

DKE adds a programming and execution model around semantic state: claims can be recorded, rules can derive consequences, provenance can be inspected, and alternative states can be explored.

A DKE application can therefore be thought of as a programmable knowledge environment, not merely a graph database.

4. DKE as Agent Memory

One of the most immediate applications is persistent agent memory.

An agent can record structured claims rather than relying solely on conversational history.

In DKE Python:

remember(User.alice.plan, "pro", "billing-system")
remember(User.alice.company, "Acme", "crm")
remember(User.alice.role, "administrator", "iam")

The important distinction is that these are semantic claims rather than arbitrary key/value entries: each one records the source it came from, given here as the last argument.

An application can then ask for current knowledge, inspect a stored claim, or retrieve its derivation and supporting information.

This gives agent memory three properties that ordinary conversational memory often lacks:

  1. Structure — knowledge is addressable and programmable.
  2. Persistence — state can survive individual conversations.
  3. Traceability — the system can preserve how a result was obtained.

4.1 From "memory" to institutional memory

The more important use is not remembering what a user said.

It is remembering what an organization knows.

For example:

Customer.alice
    subscription = enterprise
    account_owner = Bob
    region = EU
    renewal_date = 2027-01-15

The system can store these facts with their sources and derive secondary knowledge from them.

This makes DKE a candidate substrate for:

5. Provenance and "Why?"

An AI system frequently needs to answer two different questions:

What is the answer?

and:

Why is that the answer?

The second question is often approximated by asking the LLM to explain its reasoning.

That is not the same as having machine-verifiable provenance.

DKE exposes derivations so that a result can be inspected as a consequence of stored claims and rules.

Conceptually:

Customer.alice.refund_eligible = true
            |
            +---- rule: refund_policy
            |
            +---- subscription = enterprise
            |
            +---- months_active = 18   (the policy requires 12)
            |
            +---- issue = service outage

The model can turn that structured derivation into a human explanation.

The resulting architecture is:

DKE:
"What follows, and from which claims?"

LLM:
"How should this be explained to the user?"

This distinction becomes increasingly important as AI systems move from answering questions to taking actions.

6. Rules as Persistent Semantic Programs

A rule in an AI application should ideally not be a sentence buried in a system prompt.

Consider:

Every high-value order without a shipment must be reviewed.

An application can express the policy as executable semantic logic:

@rule
def needs_review():
    for order in Order:
        if order.total > 1000 and absent(order.shipment):
            order.review = True

This is DKE Python as published; the same rule appears in the DKE Python Language Reference. The syntax may still change while DKE is in alpha, but the architectural principle matters more than the syntax:

Policy becomes executable semantic state rather than prompt-level advice.

This enables an agent to propose actions while DKE evaluates the consequences under explicit rules.

LLM proposes action
        |
        v
DKE evaluates state + rules
        |
        +---- permitted
        |
        +---- denied
        |
        +---- insufficient information

That pattern can be used for:

7. Time as Part of Knowledge

Many AI applications collapse history into the latest known value.

For a large class of real systems, that is inadequate.

Consider:

Customer.plan
Product.price
Employee.role
Server.configuration
Contract.status

The relevant question may be:

What was true on 1 March 2026?

rather than:

What is true now?

DKE records when a claim holds and, separately, when the store learned it. A system can therefore ask both "what was true on 1 March?" and "what did we believe on 1 March?", and the two answers can legitimately differ.

This distinction enables applications such as:

An agent can therefore work with a semantic world that has a history, rather than with a snapshot that is overwritten at every change.

8. Contradiction as Data

Conventional application logic often tries to eliminate disagreement immediately:

source A says X
source B says Y
        |
        v
choose one

That can hide useful information.

DKE instead keeps conflicting claims visible, as a state that can be inspected and then resolved by application-specific policy.

For example:

CRM      -> customer.plan = enterprise
Billing  -> customer.plan = professional
Sales    -> customer.plan = enterprise

An agent can report:

The current sources disagree about the customer's plan.

This is materially different from silently selecting a value.

The distinction is important because agreement is not the same thing as truth.

An application may later define a domain-specific trust or reconciliation policy, but the semantic layer does not need to erase the disagreement before that policy has been applied.

This makes contradiction useful information.

9. Hypothetical and Counterfactual Reasoning

Another important capability is exploring alternative states.

Natural-language agents frequently perform "what if" reasoning inside the model:

What would happen if the customer cancelled?

What if we hired five people instead of two?

What if the server configuration changed?

DKE provides a more explicit basis for this kind of reasoning by allowing assumptions and alternative worlds to be evaluated against rules and semantic state.

Conceptually:

                     CURRENT WORLD
                           |
             +-------------+-------------+
             |             |             |
             v             v             v
         scenario A    scenario B    scenario C
         customer      customer      customer
         cancels       upgrades      pauses
             |             |             |
             +-------------+-------------+
                           |
                           v
                    derived consequences

This transforms "what if?" from an informal prompting technique into a computable semantic operation.

Possible applications include:

10. DKE as a Multi-Agent Shared World

Multi-agent systems often communicate by passing messages:

agent A -> agent B -> agent C

As systems grow, this can become difficult to reason about.

An alternative is a shared semantic state:

                +----------------+
                |      DKE       |
                | shared semantic|
                |     world      |
                +----------------+
                 ^       ^       ^
                 |       |       |
             research  sales  support
               agent   agent   agent

Each agent can contribute claims with provenance.

One agent may record:

Paper.p42.status = verified

Another may record:

System.s7.risk = high

A standing rule can then derive:

System.s7.approval_required = true

The agents do not need to exchange their entire conversation histories.

They can communicate through a common semantic world.

This is a promising pattern for:

11. A Reference Architecture

A practical AI application can combine DKE with existing components rather than replacing them.

                           USER
                             |
                             v
                       +-----------+
                       |    LLM    |
                       |   Agent   |
                       +-----+-----+
                             |
             +---------------+---------------+
             |               |               |
             v               v               v
          Web/API          RAG             DKE
          tools         retrieval        MCP service
             |               |               |
             |               |        +------+------+
             |               |        |             |
             |               |     semantic       rules
             |               |       state
             |               |        |
             |               |     provenance
             |               |        |
             |               |     derivation
             |               |        |
             +---------------+--------+-------------+
                                      |
                                      v
                                   LLM
                                      |
                                      v
                                  RESPONSE

Recommended division of labor

ComponentPrimary responsibility
LLMIntent, planning, language, synthesis, explanation
RAG / vector searchFinding relevant documents and evidence
DKEPersistent semantic state and deterministic derivation
SQL / operational DBApplication records and transactions
APIs / toolsExternal actions and data sources
UIHuman interaction and oversight

This is not a replacement architecture.

It is a compositional architecture.

12. MCP Changes the Adoption Path

A major practical feature of DKE is that the engine is exposed as an MCP service.

The public documentation describes the service as a small set of ordinary MCP tools for compiling modules, running programs, and inspecting stored state. An MCP-capable client can therefore drive DKE without adopting a bespoke DKE SDK.

This matters because the AI ecosystem is increasingly converging on tool protocols.

Conceptually, an agent's configuration then looks like this:

LLM
  |
  +-- web search
  +-- database tools
  +-- application APIs
  +-- DKE via MCP

DKE becomes one tool in the agent's toolbox, but it is the tool responsible for a different class of work:

semantic memory + deterministic reasoning.

13. Security and Isolation

A semantic runtime becomes important infrastructure as soon as it stores organizational knowledge.

The current DKE service documentation describes stores that belong to an account, and keys that each reach exactly one store at a chosen access level: read, read-write, or read-write-delete. A key is also the identity the store records each write under, so giving every agent its own key keeps their contributions separable.

That model supports an architectural pattern in which different agents receive controlled access:

Research agent   -> read-write          Store A
Support agent    -> read-write          Store B
Auditor          -> read                Store A
Maintenance job  -> read-write-delete   Store A

Key scope should be treated as part of the application architecture rather than an afterthought.

The principle is straightforward:

Decide an agent's access per body of knowledge, not merely per API.

14. Determinism Has a Different Role in AI

A common misconception is that deterministic software and probabilistic AI are competing paradigms.

They are complementary.

A probabilistic model is valuable precisely because it can deal with ambiguity, uncertainty, and language.

A deterministic engine is valuable precisely because some things should not depend on sampling.

For example:

Probabilistic:
"What did the user mean?"

Deterministic:
"Given the policy and current state, is this action permitted?"

Probabilistic:
"How should I explain the result?"

Deterministic:
"Which claims support that result?"

DKE occupies the deterministic side of this boundary.

The resulting system can be more capable without requiring every operation to become probabilistic.

15. A More Useful Mental Model: DKE as a Semantic Runtime

The most productive way for an AI developer to think about DKE may be to borrow an analogy from programming languages.

An AI agent has:

DKE can serve as the runtime for semantic programs.

The LLM can act as a programmer, interpreter, or controller:

Human intent
      |
      v
     LLM
      |
      | semantic program
      v
     DKE
      |
      | deterministic execution
      v
semantic result + derivation
      |
      v
     LLM
      |
      v
human explanation

This creates a useful separation:

LLM

Good at discovering what should be done.

DKE

Good at executing what has been explicitly defined.

Application

Good at connecting the semantic layer to the external world.

That separation is the foundation of the architecture this paper proposes.

16. Practical Application Patterns

The following patterns are especially suitable for early adoption.

16.1 Persistent agent memory

Use DKE for facts an agent should retain across interactions.

Examples:

16.2 Policy enforcement

Encode business or operational policies as executable semantic rules.

Examples:

16.3 Explainable decisions

Store claims and derivations so that the agent can provide a traceable basis for decisions.

Examples:

16.4 Temporal intelligence

Maintain knowledge whose validity changes over time.

Examples:

16.5 Multi-agent state

Allow multiple specialized agents to contribute to one semantic world.

Examples:

16.6 Scenario analysis

Use alternative states to calculate consequences.

Examples:

17. What DKE Should Not Be Used For

DKE is not intended to replace every part of an AI stack.

It should not be treated as:

Its value comes from its specific role.

The strongest architecture is likely to be hybrid.

Use each technology for what it does well.

18. Limitations and Engineering Considerations

DKE is an evolving technology and should be evaluated accordingly.

The current public documentation identifies the project as DKE alpha, API 1. Developers should therefore distinguish between the architectural concepts described here and the current language and API details, which may still change during the alpha phase.

Other engineering considerations include:

18.1 Semantic modeling cost

A useful semantic system requires more deliberate modeling than throwing arbitrary JSON into storage.

That is intentional, but it means that developers need to think about entities, claims, rules, and provenance.

18.2 LLM integration quality

An LLM can generate poor DKE programs just as easily as it can generate poor SQL.

The integration layer should therefore validate, constrain, and observe model-generated semantic programs.

18.3 Domain-specific policy

DKE can expose conflicts and derivations, but it cannot determine organizational truth on its own.

Questions such as "which source is authoritative?" remain domain decisions.

18.4 Operational architecture

Production systems still need ordinary infrastructure:

DKE should be integrated into that architecture, not expected to replace it.

19. Suggested Adoption Strategy

AI developers do not need to redesign an entire system to experiment with DKE.

A sensible path is incremental.

Stage 1 — Memory

Give one agent a DKE store and record a small set of persistent claims.

Measure whether the resulting memory is easier to inspect and reuse than conversation history or ad-hoc JSON.

Stage 2 — Rules

Move one important policy out of prompts and application glue code into explicit semantic rules.

Verify the resulting derivations.

Stage 3 — Provenance

Expose "why" information to operators and users.

Test whether the system can distinguish:

Stage 4 — Multi-agent state

Allow multiple agents to read and contribute to the same semantic world.

Measure whether this reduces message passing and duplicated context.

Stage 5 — Hypothetical worlds

Introduce scenario evaluation for a real planning problem.

At this point DKE begins to function not merely as memory but as a semantic environment for the agent.

20. A Minimal Conceptual Example

Consider an autonomous customer-service system.

Inputs

CRM:
customer = Alice
plan = enterprise

Billing:
months_active = 18

Support:
issue = service outage

The LLM can interpret the incoming support message and store relevant facts in DKE.

A policy rule can derive:

refund_eligible = true

The agent asks DKE for the derivation.

DKE returns the semantic basis.

The LLM then produces:

Alice is eligible for a refund under the current enterprise-service policy. The determination is based on her enterprise plan, 18 months of service, and the qualifying outage condition.

The important property is that the language model is not being asked to invent the policy or silently maintain the state.

It is communicating a deterministic semantic result.

21. DKE and the Future of Agent Architecture

The current AI stack often looks like:

LLM
+
prompt
+
RAG
+
tools
+
memory

A more mature architecture may look like:

             Probabilistic Intelligence
                        |
                        v
                 +-------------+
                 |     LLM     |
                 +------+------+
                        |
                     MCP/tools
                        |
                        v
             +----------------------+
             | Semantic Runtime     |
             |                      |
             | DKE                  |
             |                      |
             | claims               |
             | rules                |
             | time                 |
             | provenance           |
             | derivation           |
             | contradictions       |
             | alternative worlds   |
             +----------------------+
                        |
                        v
                External Systems

This is more than an implementation detail.

It suggests a conceptual separation that may become increasingly important as agents become more autonomous:

Intelligence does not have to imply that state is probabilistic.

A system can use a highly capable probabilistic model while maintaining a deterministic semantic world around it.

22. Conclusion

For an AI developer, DKE is best understood neither as another database nor as another LLM framework.

It is a semantic runtime for AI systems.

Its most useful contribution is the ability to make knowledge:

This leads to a simple architectural principle:

Use the LLM where uncertainty and language are strengths. Use DKE where semantic state, explicit rules, and reproducible derivation are strengths.

That division can support AI systems that are not merely conversational, but stateful, inspectable, and capable of operating over an explicit model of the world.

The opportunity is not to make DKE compete with the rest of the AI stack.

The opportunity is to make DKE the layer that gives the stack a semantic spine.

References

  1. LangSyn, DKE Documentation
    https://dke.langsyn.com/
  2. LangSyn, DKE Python Language Specification
    https://dke.langsyn.com/spec/dke/python/
  3. LangSyn, DKE Python Language Reference
    https://dke.langsyn.com/ref/dke/python/
  4. LangSyn, DKE MCP — Wire & Tool Contract
    https://dke.langsyn.com/ref/dke/mcp/
  5. LangSyn, DKE Python Tutorial
    https://dke.langsyn.com/tutorial/dke/python/
  6. LangSyn, DKE MCP Tutorial
    https://dke.langsyn.com/tutorial/dke/mcp/

About DKE

The Deterministic Knowledge Engine (DKE) is a LangSyn technology for programming, storing, and reasoning over semantic state.

The published DKE interface includes:

The DKE documentation is published and versioned at:

https://dke.langsyn.com/

DKE is currently published as alpha, API 1.