Worldviews & lineages

Tarski uses explicit identities so agents, humans, and runtimes never confuse which history, which semantics, and which frozen package a fact belongs to.

Core identities

• lineage_id — names one immutable observation history or child branch.
• evaluator_digest — identifies the semantic evaluator: ontology IR, mapper semantics, helper digests, authority defaults, intent identity, and payload schemas.
• package_digest — identifies the frozen evaluation package handed to a runtime.
• mapper_output_digest — identifies the canonical mapper export for one observation.

These are not interchangeable. The evaluator digest is the primary semantic identity. Prompt-only changes do not rotate the evaluator digest, because prompts are fallible tools feeding candidate or proposal channels — not the semantic authority itself.

Declared queries follow the same discipline: a query body is prompt-like (body-only edits never rotate the evaluator digest), while an agent-exposed query’s result relation signature joins the evaluator identity, because result observations must be interpreted into atoms. See Declared queries.

Worldview scope

A worldview is the set of facts derived for a particular evaluator over a particular lineage at a particular committed head:

(lineage_id, evaluator_digest, committed_head)

This scoping prevents a fact from one observation history or evaluator from being mistaken for truth in another. It also lets Tarski run shadow evaluators and compare outputs without making those shadow packages effect-authoritative.

Lineage behavior

A lineage is a durable observation history. Child branches inherit the parent prefix and then diverge. Tarski does not use merge-back as a hidden workflow primitive: if two histories need comparison, the system compares worldviews instead of collapsing lineages.

Effect authority

For a lineage, exactly one committed activation may execute effects. Shadow builds and compare runs can derive facts and intents for inspection, but they cannot execute effects until promoted. External actions stay tied to one declared evaluator identity — this is what makes “which version did that?” always answerable.

Where you meet these identities

• Development — changing .ta rules, mapper semantics, helpers, authority defaults, intent identity, or payload schemas creates a new semantic evaluator.
• Verification — expected outputs are meaningful only for the evaluator and lineage that produced them.
• Export — the package digest proves the frozen handoff contents; the evaluator digest proves semantic equivalence.
• Hosted operation — the cloud runtime labels which evaluator and package are authoritative before executing effects.
• Studio — worldview selection tells you which lineage, evaluator, and committed head you are reading. Raw digests stay behind deliberate disclosure.

Common mistakes

• Treating a package digest as proof of semantic equivalence without checking the evaluator digest.
• Treating prompt revisions as semantic changes when they only alter fallible candidate/proposal behavior.
• Comparing facts across lineages without naming both lineage_id values and committed heads.