Product model · 01

A task is a
commitment, not a prompt.

LibreTask binds intent, acceptance criteria and authority into a task contract, then carries that agreement through a persistent execution thread.

The work has a structure you can inspect.

Every capability call, human decision and result becomes part of a durable task model.

01 / THREAD

Task thread

The permanent execution entity that survives interruptions and can be resumed.

DURABLE
02 / CONTRACT

Task contract

Outcome, acceptance criteria, constraints, permissions and intervention policy.

VERSIONED
03 / EVENT

Execution event

An append-only record of planning, routing, calls, checks and human decisions.

APPEND ONLY
04 / CAPABILITY

Capability card

A callable contract for an endpoint, including cost, health, side effects and boundaries.

VERSION LOCKABLE
05 / PACKAGE

Delivery package

The outcome, evidence trail, unresolved questions and acceptance checklist.

IMMUTABLE SNAPSHOT

The model proposes. The contract decides.

A task cannot be silently reinterpreted after execution begins. Changes create a new contract version and a new execution event.

CONTRACT SPECIFICATION

Market thesis source review

V3 · ACTIVE
Intent Outcome, expected output and three acceptance criteria
Constraints Deadline, token budget, currency cap and data boundary
Authority Allowed capabilities, automatic actions and confirmation gates
Checkpoints After planning, on failure, at 80% budget and before delivery
Any contract change creates a new version and an immutable event.

Find the right tool inside the right boundary.

LibreTask does not put every tool into the model context. Governance narrows the set before intelligence creates a plan.

01

Enrich

Build searchable capability profiles from names, aliases and examples.

02

Retrieve

Combine vector and lexical retrieval against the structured task view.

03

Rank

Score relevance, history, preference, cost and latency.

04

Restrict

Enforce permission, data boundary, budget and version compatibility.

05

Plan

Let the model plan only from the approved, explainable candidate set.

An answer is not a delivery.

The final artifact carries the proof behind it, so acceptance is based on evidence rather than confidence in a model response.

◇

Outcome

The result in its intended format, ready for review and acceptance.

◎

Evidence trail

Sources, calls, costs and decisions linked to the execution thread.

✓

Acceptance checks

Passed and unresolved criteria shown side by side.

?

Open questions

The honest gaps a human should understand before accepting.

L
Delivery is a closed loop, not a final message.

A human can accept, return, revise or take over while the complete proof remains attached.