Foundations
Meaning model
Eighteen objects, none of which may disappear into a single “AI message”. A representation is only as honest as the model it is drawn from.
The unit is the Work Case
A Work Case is one persistent piece of work: a goal, a scope, an owner, a lifecycle and a revision, with its decisions, executions, evidence and open questions attached. Its identity is continuity, not a frozen goal. Goals and scope may change; what changed, when and why is recorded, and existing decisions and approvals are re-checked. A genuinely different job becomes a new Case with an explicit relation.
A Work Object is a thing the work is about: an item, an order, an invoice, a document, a repository, a pull request. Each system’s record is a different representation of it. A Context Snapshot is the projection of the Case chosen for one person or agent at one moment, including which fields were withheld and why.
The eighteen objects
| Object | Is | Depends on |
|---|---|---|
| Work Case | One persistent piece of work | — |
| Work Object | A thing the work is about, with a representation per system | — |
| Context Snapshot | A projection for one role at one moment | Work Case |
| Source | Where an observation came from, and what it is authoritative for | — |
| Observation | What a source reported for a field, at a time, with freshness | Source |
| Evidence | An observation in relation to a claim: supports, refutes, insufficient | Observation, Claim |
| Claim | A reviewable proposition with an epistemic state | Evidence |
| Interpretation | Meaning assigned to claims, with premises and uncertainty | Claim |
| Recommendation | A proposal for what to do next, with its basis | Interpretation |
| Decision | The alternative chosen, by whom, on which criteria, accepting which limits | Claims, criteria |
| Proposed Action | An intended change: targets, diff, preserved values, risk, version | Decision |
| Authorization | Who allowed which action, in what scope, on which version | Proposed Action |
| Execution | One performed operation, per target | Authorization |
| Effect | A change observed after execution | Execution |
| Verification | Expected vs observed, with scope and premises | Effect |
| Recovery | Reconcile, retry, compensate or escalate after uncertainty | Execution, Verification |
| Open Loop | An unresolved question or obligation, with an owner | any |
| Handoff | The state bundle a new owner starts from | Work Case |
Relations are typed, never “same”
A wrong identity claim poisons every later comparison and automation. Lyotic never draws two records as simply “the same” (INV-15).
| Relation | Means | Example |
|---|---|---|
alias | One item, two names | ERP ITEM-40211 is Shopify variant 4471 |
packaging | A pack and its units, with a conversion | A box of 10 and 10 single units |
shared-component | Different products using one part | Two bottles sharing one cap stock |
inventory-pool | One stock, many listings | One warehouse count behind a Shopify and an Amazon listing |
distinct | Looked related, is not | Same name, different SKU and supplier |
Field meaning is a relation too. Produced Quantity and Available to Sell are different fields that happen to hold numbers; comparing them as one quantity is the distortion Lyotic exists to prevent (INV-19).
Dependencies drive invalidation
Claim ← Evidence. Decision ← Claims + criteria. Action ← Decision + Authorization. A new observation that shakes a claim re-evaluates the recommendations and unexecuted actions built on it. Changes that do not touch meaning or authority (a font, an unrelated field) do not. The model must say which dependencies are material.
In the reference case, reading the ERP schema supersedes the claim “these four numbers are the same quantity”. The agent’s proposal to write 5,400 to both marketplaces rested on it, so it becomes not actionable. The superseded claim stays visible, struck through, and the History Timeline records what the change invalidated.
Persistence is bounded
A Case persisting does not mean everything is stored forever. Personal and sensitive data have access and retention limits, and each role gets its own snapshot. If evidence is deleted or becomes inaccessible, the claims that relied on it are re-evaluated. “Verified in the past” and “can be re-checked now” are different states.