Workviews, Collectors & modules

Tarski gives you workflow-shaped tools without making a workflow engine the source of truth. There is no program counter, no hidden call stack, no workflow state store — the durable model stays observation-first, and these layers organize what it derives.

Workviews

A Workview is a package-owned inspection contract: it maps ordinary derived relations into process-shaped roles — instance, phase, waiting reason, obligation, terminal state, at-risk state, child link, effect link. Workviews are read models: they execute nothing, own no state, and never change evaluator identity unless the underlying ontology does.

Contradictions surface instead of resolving silently: overlapping phases report ambiguity, terminal-plus-active evidence reports a conflict with provenance, and invalid child or effect links fail closed or surface as diagnostic rows.

tarski workview list
tarski workview inspect

Work Queues

Work Queues are frozen operational dispatch policy for admitted effects — capacity, partitions, ordering, leases, rate limits, saturation behavior — with durable queue-control records for operator adjustments. They decide when admitted work may start, never whether something may happen. See Effects & reconciliation.

Collectors

A Collector is scenario-driven data acquisition: rules derive plugin inputs, receipts return as observations, and the derived frontier — “what is still missing” — decides the next request. No worker memory owns progress; the worldview does.

input:    Google product identity + country + provider parameters
frontier: missing product details, then missing offer page N
drives:   product-detail and offer-page plugin inputs
progress: requested/captured pages and collected offers
seal:     terminal partial page, declared page bound, failure, or reconcile evidence
view:     one Collector Workview instance per request scope
queue:    bounded offer-page dispatch through a Work Queue

Completion seals are the load-bearing idea: a same-scope proof that a collection frontier is complete, required before non-monotone reads — “the cheapest offer”, “no merchant matched”, a final count — can be trusted. Monotone reads (“any offer below threshold”) may react as soon as evidence appears; that distinction is the CALM boundary from the Tarski language. V1 accepts a closed set of seal shapes (terminal witnesses, terminal partial pages, declared bounds, refresh epochs); custom proofs fail closed by design.

Collector outputs (collected_exports) must structurally join back to the request scope — a seal cannot govern data whose scope was projected away.

Modules

A module packages reusable behavior above connector plugins: ontology rules, Workviews, Collector metadata, queue references, invariants, fixtures, exports, and explicit drives declarations naming which dependency inputs it may derive into. Modules read only declared dependency exports; the composed app, modules, and plugins still evaluate as one stratified fixed point.

Composition is checked, not hoped. On shared write surfaces the platform computes amalgamation agreement per input: amalgamates, guarded (single-driver policy), or disagreement. Exactly one class rejects at load — an exclusivity-shaped invariant asserted directly over a raw multi-driven union (error E2810), which provably cannot hold. The fixes are declaring a single driver or moving exclusivity to the owner’s derived resolution relation.

For architecture guidance, the advisory report proposes module splits from the ontology’s own mathematics:

tarski composition architecture

It emits one module-split proposal per non-owned namespace, a coupling score, readiness verdicts (clean, entangled with a work list, blocked with a witness), hotspots, and invariant-coverage gaps — advisory only, never a new rejection.