Build super-human expert systems
Tarski turns your experts' knowledge into rules that run. LLMs read the messy input and suggest actions. Your rules decide which suggestions to act on, and every decision traces back to the evidence behind it.
What Tarski is
An expert system makes decisions the way a specialist does: it applies rules to the facts of a case. Underwriting, triage, incident response, and pricing approval all work this way.
Expert systems are decades old, and two problems held them back. Someone had to write every rule by hand, and the system could read only clean, structured data. Coding agents now write the rules from your experts' policies and example cases. LLMs now turn documents, chat, and audio into structured facts.
Tarski is the platform that puts the two together. The LLM can propose facts and actions, and only your rules can accept them.
Where it outperforms a human expert
Your experts decide what the rules should be. Tarski applies those rules with more consistency and a longer memory than any one person.
Applies every rule to every case
A specialist under time pressure skips checks. The Tarski engine evaluates all of your rules each time a new input arrives.
Keeps a complete record
Every input is stored in a permanent log on object storage. You can replay any past decision and get the same result.
Explains each decision
Every fact and action links back to the inputs and rules that produced it. Studio shows the full chain.
Turns mistakes into tests
Save a wrong decision as a scenario. Every later change to the rules is checked against it.
How it works
Tarski records every input, uses your rules to derive facts and decisions from that record, and runs an action only after checking it against your invariants.
Record
Messages, documents, API events, and LLM outputs are appended to a permanent log. Entries are never edited in place.
Derive
Your rules compute the current facts from the log. The same log always produces the same facts, so any past decision can be replayed exactly.
Decide
LLM output arrives as candidate.* facts and proposal.* actions. A rule you can read accepts it, rejects it, or sends it to a person for review.
Act
Before an action runs, Tarski checks it against your invariants. An action that would break one is refused, and the receipt names the invariant.
What your experts review
Your experts don't need to read the generated rules. They review three short artifacts written in terms they already use, and Tarski enforces them.
Scenarios
A sequence of events and the outcome your expert expects. Tarski runs each scenario on the production engine and compares the result exactly.
scenario "refund above policy"
given refund.requested $1,900
policy.auto_limit $500
expect refund.state = held
effects.sent = noneInvariants
Outcomes the system must never produce, such as an offer below the price floor. Tarski checks every invariant before any action runs.
invariant no_offer_below_floor
never offer.price
< vehicle.floor_price
checked at every fixpointProvenance
The chain from an action back to the inputs that caused it. When a decision looks wrong, start here.
effect#e91 send_offer ← intent#i77 admitted ← fact offer.approved ← obs#o1042 mgr.confirmed
Check every case before you deploy
tarski verify runs every scenario on the production engine and checks every invariant. Your coding agent runs it after each change to the rules, and you review the result.
Example systems
These examples install with tarski examples install. Each one includes scenarios for the cases it must refuse as well as the ones it must handle.
Incident response
Assesses blast radius across services and gates remediation. Agent queries run on a budget your rules enforce, and an invariant blocks over-approval.
Medical intake
Details an LLM extracts from intake wait for clinician review. Patient health information stays inside clinical views, and agent reads require recorded consent.
Car dealership chat
An LLM talks to customers and suggests offers. Each offer arrives as a proposal, and your pricing rules decide whether it is sent.
Appointment booking
The tutorial app. Invariants prevent double holds and double bookings, and a declared query reports booking status.
The platform
What you use to build, run, and inspect an expert system on Tarski.
Tarski language and engine
Rules, invariants, and relays in a small Datalog language. The engine evaluates them to one deterministic result, and replay is byte-exact.
DocsScenarios and verification
Scenarios run on the production engine. One command checks every scenario and every invariant.
DocsWeb Studio
Inspect observations, facts, intents, and effects, and trace any decision back to its inputs.
DocsTypeScript SDK
Append observations, run declared queries, and subscribe to live results with exactly-once deltas.
DocsManaged Cloud
Deploys with receipts, lineage health monitoring, and the same behavior hosted or local. BYOC runs on the same contracts.
DocsTiered storage
History is kept permanently at object-storage cost, laid out by your ontology, and still answers queries.
DocsTarski compared with a standalone LLM agent
A standalone LLM agent keeps its expertise in a prompt. A Tarski system keeps it in rules you can read and test, and uses the LLM to read input and make suggestions.
| Standalone LLM agent | Expert system on Tarski | |
|---|---|---|
| Where the expertise lives | A system prompt and the model's training | Rules your experts can review and your coding agent can test |
| What stops a bad action | Prompt instructions and output filters | Invariants, checked before any action runs |
| Explaining a decision | A rationale the model writes after the fact | A provenance chain from the action to the recorded inputs |
| Fixing a mistake | Edit the prompt and re-test by hand | Save the case as a scenario; every later change is checked against it |
| Consistency | The same input can produce different output | The same log always produces the same decisions |
| Memory | The context window plus whatever retrieval returns | Every input, kept permanently and replayable |
Tarski is in private beta
We work with a small number of design partners at a time and help each one build its first expert system.