Facts, decisions & intents

Inside the evaluator, candidates, proposals, decisions, trusted facts, intents, and inspection relations are derived tuples in one fixed point. The taxonomy on this page is the vocabulary Tarski enforces at load time — simple enough for a product review, exact enough for the loader to check.

The two domains

Derived relations sit in two product-facing domains:

Domain	Provisional form	Committed form	Question answered
Fact	candidate.*	trusted app-defined fact	What is true?
Action	proposal.*	intent.*	What should happen?

The analogy to keep in mind:

candidate : fact :: proposal : intent

candidate.* is provisional evidence about state. proposal.* is provisional evidence about action. Trusted facts and intents are committed outcomes, but they are not interchangeable — a committed fact does not execute by existing. Only a committed intent may be admitted to an effect.

Decisions

decision.* is the deterministic adjudication between provisional and committed. Replay the same observations and rules, and Tarski derives the same decisions. Canonical decisions use:

decision.<outcome>.<domain>.<subject>(...)

The outcome segment is closed and load-checked:

Outcome	Domain	Meaning	May authorize
accepted	Fact	Candidate evidence is accepted as trusted truth	Trusted facts derived from fallible evidence
refuted	Fact	Candidate evidence is denied as trusted truth	Nothing — auditable denial evidence
approved	Action	Proposal evidence is authorized for the reviewed action	Reviewed world-facing intent.*
rejected	Action	Proposal evidence is denied for the reviewed action	Nothing — the proposal remains evidence
requires_review	Either	The subject must be routed for human or agent review	Review-routing work only

decision.requires_review.* declarations must expose reviewer_kind: text and reviewer_id: text. Review is not a terminal authorization: reviewer output re-enters the lineage as observations, and later rules derive accepted, refuted, approved, or rejected when the app has enough evidence.

The graph-cut safety boundary

Tarski enforces the decision model as a relation-level graph cut over positive dependencies from fallible relay relations (candidate.*, proposal.*, and runtime-populated rows such as queryresult.<query_name>):

• Every positive dependency path from fallible relay evidence to a trusted fact must pass through decision.accepted.*.
• Every positive dependency path from fallible relay evidence to a reviewed world-facing intent must pass through decision.approved.*.
• decision.requires_review.* can cut only a path to an explicitly manifest-tagged review-routing intent. It cannot authorize the reviewed action.

This is a graph property, not a local lint. If a fallible relation reaches a trusted fact through an intermediate relation, the path is still fallible-origin until it crosses the right decision outcome — and a parallel ungated path fails the load even when a correct gated path also exists.

Decision relations must carry the payload that downstream facts or intents need. A rule that derives trusted.fact(id, detail) from decision.accepted.foo(id) and then joins back to candidate.foo(id, detail) still bypasses the payload decision. Carry detail on the accepted decision relation instead.

Trivial acceptance is allowed, but it must be explicit:

decision.accepted.identity.verified_email(addr) :-
  candidate.verified_email(addr).

That rule states, in the ontology, “this app auto-accepts this candidate shape” — with provenance and fixture coverage. It is no longer an invisible promotion.

Effects and invariants

Effects are the action domain’s operational tail:

proposal.* → decision.approved.* → intent.* → admitted effect request → attempt → receipt observation

The fact domain carries epistemic complexity before commitment: unknown, stale, refuted, contradicted, or review-required evidence. The action domain carries operational complexity after commitment: admission identity, capability, attempt state, retry policy, receipts, and reconciliation. Facts are hard to know; actions are hard to do. Tarski keeps epistemic complexity in the ontology and execution complexity in the runtime.

Invariants are fail-closed backstops over the fully materialized model — not ordinary proposal validators. A bad proposal should commit as proposal.* evidence and then derive decision.rejected.* or decision.requires_review.*. An invariant should reject the attempted checkpoint only when the completed model violates a declared impossible state.

Authoring checklist

• Treat observations and typed atoms as evidence input, not truth.
• Put fallible sensor or extraction output under candidate.*.
• Put fallible action suggestions under proposal.*.
• Use decision.accepted.* / decision.refuted.* for fact-domain outcomes.
• Use decision.approved.* / decision.rejected.* / decision.requires_review.* for action-domain outcomes.
• Carry every fallible field needed downstream on the decision relation.
• Mark review-routing intents explicitly in the manifest; never rely on naming.
• Derive reviewed world-facing intent.* only from decision.approved.*.
• Use invariants for impossible committed states, not ordinary denial.
• Prove happy, denied, review, contradiction, and bypass paths with fixtures.

Common mistakes

Mistake	Why it fails
Deriving a trusted fact directly from candidate.*	Missing decision.accepted.* graph cut — rejected at load
Deriving an executable intent from proposal.*	Missing decision.approved.* graph cut — rejected at load
Letting decision.requires_review.* authorize the reviewed action	Review only opens review work
Joining back to fallible evidence after a decision for payload fields	The decision did not endorse the full payload
Treating rejected proposals as invariant failures	Ordinary denial should commit as decision evidence
Calling an intent a fact	Fact is reserved for committed fact-domain truth