Deterministic Knowledge EngineAlpha, API 1

State the rule once. The engine keeps the conclusion true.

Attach DKE to your agent over MCP. It records what it learns, reads it back, reasons over it, and states the standing rules that keep its own conclusions current. The engine keeps all of it honest: every fact carries its source, every rule holds only while its premise does, and why returns the derivation behind any answer. You install it; your agent does the rest.

Your agent is stochastic. Nothing downstream of it is.

Create an account Read the tutorial

orders.dpy, a standing rule

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

Order.o1.total = 1500(asserted, source: sales)

orders.needs_review

Order.o1.review = True(derived, source: derived)

What why(Order.o1.review) returned, set as the derivation it describes.

Connect your agent

MCP client configuration

{
  "mcpServers": {
    "dke": {
      "type": "http",
      "url": "https://dke.langsyn.net",
      "headers": {
        "Authorization": "Bearer dke_s_…"
      }
    }
  }
}

Without the header, some clients report an OAuth registration error rather than a missing key. The key is what they lack.

Declared once. From then on Order.o1.review is true exactly while the premise holds, and withdraws the moment logistics records a shipment — no job to schedule, no cache to invalidate. why(Order.o1.review) returns the claims it was built from.

The transcript as the engine returned it

OK script explain(): 1 claim written, 3 prints
  remember Order.o1.total = 1500
  print review = True, concluded by orders.needs_review
  print   Order.o1.review = True (derived, source: derived)
  print   Order.o1.total = 1500 (asserted, source: sales)

DKE is in alpha. The engine runs, the service is live, and you can build against it today. The published surface still moves between releases — nothing here is frozen yet. Beta is the next stage, and carries no date.

What the engine gives you

Provenance is structural.

Every write names a source. There is no unattributed fact.

proof = why(Order.o1.review)

Tutorial, chapter 12

Disagreement is kept.

Two sources, two co-active claims. conflicts() lists them; agreement() counts them.

held = conflicts()n = agreement(Order.o2.total, 900)

Tutorial, chapter 5

Time is built in.

Write a validity window; read any cell as of any past instant.

r = current(Rate.vat.pct, datetime("2024-06-30T00:00:00Z"))

Tutorial, chapter 4

Rules stand.

Declare the condition and the conclusion; the engine maintains both directions.

@rule

Tutorial, chapter 8

What-ifs commit nothing.

suppose() runs your rules against a fact that isn't true, then discards it.

would = suppose(Order.o1.total, 2000, Order.o1.review)

Tutorial, chapter 8

Writes land together, or not at all.

with branch(...) commits when its block completes; an uncaught failure rolls the store back.

with branch("import"):    remember(Order.o4.total, 300, "import")

Tutorial, chapter 10

Where it sits

Beside your agent's other tools, not in place of them.

DKE doesn't replace the model, your retrieval or your database, and it doesn't call any of them. A DKE program reaches nothing but its own store. Your agent works with each tool, and brings what it learns to DKE as claims with their sources attached.

The model interprets.: Intent, ambiguity, planning, and the explanation a person reads: the work where being probabilistic is the point.
Retrieval finds.: Which documents bear on the question. DKE doesn't rank text; it holds what your agent concluded from it, and where that came from.
Your database keeps its records.: Orders, accounts and application state stay where they are. When one of them matters to a conclusion, your agent records it in DKE with the database named as its source.
DKE keeps what follows.: Facts with their sources, the rules that stand over them, and the derivation behind every answer. Same program, same store, same answer, byte for byte.

What it isn't. A document store, a vector index, a search engine or a language model. Finding things is retrieval's job. DKE's starts once something has been found: recording it with its source, and keeping what follows from it current.

The argument

Why any of this should exist

An answer you can't check is a rumour with better grammar. Most systems resolve contradictions before you see them, discard the question of who said what, and can't tell you what a record said last March. DKE refuses all three — structurally, not as policy.

Provenance has to be structural, not optional.
Disagreement is information.
Time is not metadata.
A system that can't be made to halt can't be relied on.
We publish the contract and keep the engine.

Read the argument

The uncomfortable question

“An LLM writes to my knowledge store.”

It's an alarming sentence, and it should be. Here is the answer — not a promise, a list of shipped features:

Erasing is a separate permission from writing. A key issued to read and write can remember new facts and update existing ones — an update supersedes the old value rather than silently overwriting it — but it cannot permanently remove anything. Erasure takes an explicit delete grant on the store, so an agent can build knowledge up without the power to destroy it.
Every agent write is attributed. src is mandatory, so agent-recorded claims are stamped as such and sit beside human-sourced facts — distinguishable, never silently merged.
All-or-nothing when it matters. with branch(...) gives the agent a transaction; a failure rolls the store back.
It can reason without committing. suppose() runs your rules against a fact that isn't true and discards it.
Nothing persists by accident. An inline run executes and stores nothing — throwaway work leaves no trace. A rule takes effect only once it's compiled and stored, so standing logic is never a side effect of casual agent work; making something persist is an explicit step, visible in the verb.

A design choice, stated

Why it's Python-shaped.

Python is the language an LLM writes most fluently — it saturates the model's training, so the DKE Python your agent emits is idiomatic and correct by default. And it's a real language, not a fixed API: your agent programs the question dynamically — parameters, computed values, standing rules, data and logic in, an answer back — where a JSON endpoint offers only the operations we anticipated. That a human can also read what the agent wrote, on sight, is the bonus. That's the answer to “why not just a JSON API.”

Who it's for

For work that has to be checkable.

DKE is for teams putting a stochastic agent in front of a system of record — where an answer has to be traceable to its sources, a contradiction can't be quietly resolved away, and every write has to say who made it. If your agent's output feeds a decision someone is accountable for, the engine is the part of the stack that doesn't guess.

Try it

Test the engine. Check the work.

An account gives you a dashboard: create a store, issue a key that reaches exactly that store at exactly the access you choose, and hand the key to your agent. You can see when each key was last used and which clients have presented it, change what a key may do, or revoke it outright.

Open your dashboard Create an account

Alpha is a working service, not a waiting list — an account works today. It also means you are early: expect the surface to change between releases rather than be surprised by it. Anything that breaks is worth an email.