# Lyotic — Canonical Model

Version 0.1 · Source of truth: [`00-definition.ko.md`](00-definition.ko.md). This file restates that
definition as a buildable model: named objects, independent state axes, the EBSRC contract, invariants
with IDs, component responsibilities, token layers and motion rules. Code, tokens, Figma and docs cite
these IDs. If this file and the definition disagree, the definition wins and this file is fixed.

---

## 0. One paragraph

Lyotic is a design system for **supervising delegated AI work**. It turns an independently
authoritative work state (what is being handled, what was observed, what is inferred, who allowed what,
what changed, what has been verified) into a representation a person can understand and act on, and it
ties every judgment and control in that representation to real evidence and real authority. The form of
the interface adapts to the work; the meaning does not. *Form adapts. Meaning persists.* "Meaning" is not
the sentence on screen. It is the work's identity, state, evidence, judgment, authority, impact, execution
history and verified scope, together.

**The problem** is the *Agentic Work-State Integrity Gap*: the state a person understood, the state an
agent inferred, the state external systems hold, the actions currently allowed, the effects that already
happened, and the results that were verified can all drift apart. Lyotic's job is to stop one fluent
answer or one green check from papering over that gap.

**Integrity is not sameness.** Roles, devices and moments see different projections. Each projection may
omit, but none may contradict, and no omission may change the meaning of a fact or of an authority.
*Different screens are allowed. Different realities are not.*

## 1. What Lyotic is not

| Not this | Why |
| --- | --- |
| Systead | Systead is the first product built on Lyotic. It keeps business relationships across systems ("Different representations. Same reality."). Lyotic represents that work to people. Connected, not the same definition. |
| H.A.R.D. Protocol | H.A.R.D. reviews choices (purpose, alternatives, impact, implementation, evidence). Lyotic is the interaction system that is reviewed. H.A.R.D. asks *why expand here*; Lyotic specifies *what state requires which representation and what it must preserve*. |
| "AI makes the UI" | Generative UI, mixed-initiative control and mid-run approval already exist in research and products. They are inputs to Lyotic, not its claim. |
| A work ledger, a policy engine, an executor | Lyotic connects to them. Applications own domain objects and execution boundaries; adapters declare read / write / version / outcome capabilities. |
| "The first adaptive AI design system" | The claim is narrower and testable: a contract (EBSRC) and an implementation that bind independent work state, evidence, authority and outcome to bounded supervisory representations, detect meaning distortion, and are evaluated for their effect on human supervision. |

## 2. Ontology

Eighteen objects. None may disappear into a single "AI message".

| Object | Is | Key fields | Depends on |
| --- | --- | --- | --- |
| **WorkCase** | One persistent piece of work | goal, scope, owner, lifecycle, revision, decisions, executions, evidence graph, open questions, relatedCases | — |
| **WorkObject** | A thing the work is about (product, order, invoice, document, repo, PR) | id, kind, representations (per system), relations | — |
| **ContextSnapshot** | A projection of the Case chosen for one person/agent at one moment | caseRevision, role, fields included, fields withheld (and why) | WorkCase |
| **Source** | Where an observation came from | system, authority scope (what it is authoritative *for*), access | — |
| **Observation** | What a source reported at a time | source, field, value, observedAt, freshness | Source |
| **Evidence** | An observation *in relation to a claim* (supports / refutes / insufficient) | claim, observation, relation, note | Observation, Claim |
| **Claim** | A reviewable proposition | text, epistemic state, evidence[], status (active / superseded / retracted) | Evidence |
| **Interpretation** | Meaning assigned to observations and claims | premises, uncertainty, alternatives considered | Claim |
| **Recommendation** | A proposal for what to do next | basis (claims, criteria), alternatives | Interpretation |
| **Decision** | The alternative actually chosen | chosen, alternatives, criteria, decidedBy, evidenceUsed, acceptedLimits, recordedAt | Claims, criteria |
| **ProposedAction** | An intended change not yet executed | targets, diff, preserved[], risk vector, version | Decision |
| **Authorization** | Who allowed which action, in what scope, on which version | layers (§4), approver, approvedVersion, conditions | ProposedAction |
| **Execution** | One performed operation | action, target, submittedAt, outcome, control | Authorization |
| **Effect** | A change observed after execution | target, field, before, after, observedAt, expected? | Execution |
| **Verification** | Expected vs observed comparison | checks[], scope (checked / preserved / unobservable), at, premises, state | Effect |
| **Recovery** | Clean-up after failure or uncertainty | path (retry / compensate / reconcile / escalate), dependsOn | Execution, Verification |
| **OpenLoop** | An unresolved question or obligation | kind, owner, blocking[] | any |
| **Handoff** | The state bundle for a new owner | see §9 | WorkCase |

**Relations between Work Objects are typed**, never a bare "same": `alias` (one item, two names),
`packaging` (box of 10 ↔ 10 units, with a unit conversion), `shared-component` (different products using
one part), `inventory-pool` (one stock, many listings), `distinct` (looked related, is not). A wrong
identity claim poisons every later comparison and automation.

**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.

**Case 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.

## 3. State axes (independent)

Never one grand sequence. Each axis moves on its own; the product shows combinations.

| Axis | Applies to | Values |
| --- | --- | --- |
| Work | WorkCase | `open` · `awaiting-judgment` · `in-progress` · `blocked` · `resolved` · `closed` · `superseded` |
| Epistemic | Claim, Interpretation | `observed` · `supported` · `inferred` · `ambiguous` · `conflicted` · `unknown` |
| Freshness | Observation | `fresh` · `aging` · `stale` · `unknown` |
| Authority | ProposedAction | derived from the five layers in §4: `permitted` · `needs-approval` · `blocked` · `stale` |
| Execution | Execution (per target) | `not-started` · `submitted` · `running` · `applied` · `partially-applied` · `failed` · `outcome-unknown` |
| Control | Case execution | `running` · `stop-requested` · `halted` |
| Verification | Verification | `pending` · `verified` · `failed` · `inconclusive` (always with a scope) |
| Representation | ContextSnapshot / view | mode `compact` · `compare` · `decide` · `authorize` · `execute` · `verify` · `recover` · `handoff`; disclosure `collapsed` · `expanded`; attention `none` · `requested` |

Rules that follow:

- `compare` is a representation, not a work state. Comparing does not resolve anything.
- `granted` authorization is not execution. `applied` is not `verified`.
- A Case can hold a verified action and an outcome-unknown action at once. Showing only
  success/failure is a distortion.
- `stop-requested` (the person asked) is not `halted` (new runs are blocked). Work the remote side
  already accepted may still complete; both facts are shown.

**Uncertainty is not one number.** Model confidence, agreement across sources, evidence sufficiency,
freshness and verification are separate. Three agreeing sources may be copies of one stale record; high
model confidence may compare fields that mean different things. No `confidence: 0.8` stands in for the
epistemic state. (Numeric scores may appear as *observations about a classifier*, e.g. a document
classifier's 0.71, never as the state of a claim.)

## 4. Authority

Five layers, evaluated per action, never collapsed into "autonomy 80%":

| Layer | Question | Example |
| --- | --- | --- |
| Capability | Can the adapter technically do it? | API credential can write inventory |
| Permission | Does org policy allow this actor/role? | Ops may edit mappings; finance may not |
| Delegation | Is it inside what this Case delegated? | "Check stock" delegates reading, not editing |
| Approval | Did the required person approve *this version*? | Approved mapping v3 for Shopify + Amazon |
| Validity | Is all of the above still true *at execution*? | Mapping changed since approval → revalidate |

- A credential is not permission. A click is not permission beyond the clicker's role.
- The approval path is separate from the agent's execution path. An agent writing "human approved" proves
  nothing; the application must know who reviewed which version.
- Approval binds to a version: targets, recipients, amounts, scope. A material change invalidates it;
  an immaterial one does not force re-approval.
- The **Allowed Action Set** is the result of evaluation at plan time. It is not a standing right. At
  execution the action is re-validated; a stale control leads to a *re-check* transition that says what
  changed, never to an execution against the old state.

**Risk is a vector, not a label.** Dimensions: money, privacy exposure, blast radius (object count),
reversibility, downstream propagation, detectability, recovery cost, time sensitivity, evidence gap,
authority ambiguity. Policy combines them, but **no total score may cancel a hard prohibition**.

**Consequence-proportional disclosure** means enough information for the judgment, not a bigger card:
affected objects, preserved objects, scope of change, reversibility, external notifications,
alternatives, verification conditions, when they matter. Small, reversible, delegated work gets no
ceremony, so attention is left for the moments that need it.

**Human judgment points** are not "the agent feels unsure". They are: a new interpretation changes what
an action means; an evidence conflict remains; the action leaves the delegated scope; an irreversible
effect is about to start; recovery needs a business decision. The person decides a concrete choice with
stated evidence and consequences, never "do you trust the AI?".

## 5. EBSRC — Evidence-Bound Supervisory Representation Contract

A deterministic transform from independently authoritative delegated-work state to a bounded
representation for human supervision. Supervision means: the person who delegated can understand the
current state, intervene at the moments that matter, and confirm the result of intervening.

**"Independently authoritative"**: an agent writing "verified" does not make an input verified. Which
system is authoritative for which fact, which records were observed, who approved which scope, are
established by the application's contract. Authority of source, accuracy, freshness and fitness of
interpretation are handled separately; authoritative data is not assumed to be reality.

**Deterministic**: same Case revision, role, policy version and presentation conditions → same meaning of
facts and same allowed actions. Colour and layout may vary within bounds. A model swap never turns
`outcome-unknown` into "done" or adds an execute button to a read-only job.

### Input

```
EBSRCInput {
  case:          WorkCase + revision
  objects:       WorkObject[]           // with typed relations
  role:          { id, permissions }
  observations:  Observation[]          // with freshness
  evidence:      Evidence[]
  claims:        Claim[]                // open ones included
  proposals:     ProposedAction[]       // with risk vectors and versions
  authority:     Authorization[]        // five layers each
  executions:    Execution[]
  effects:       Effect[]
  verifications: Verification[]
  view:          { mode, disclosure, focus }   // what the person is looking at now
  access:        { reducedMotion, screenReader, zoom, pointer }
  policy:        { version }
}
```

### Output — Representation Plan

Not HTML. A plan the renderer must follow.

```
RepresentationPlan {
  caseId, caseRevision, policyVersion, resolverVersion
  mode:          compact | compare | decide | authorize | execute | verify | recover | handoff
  focus:         WorkObject id shown as the centre
  mustShow:      disclosure keys that may not be omitted (e.g. "preserved.production-qty")
  relations:     relations to explain (e.g. alias, field-meaning-mismatch)
  controls:      [{ action, allowed, reason, needsApproval, boundVersion }]
  forbidden:     completion expressions not allowed now (e.g. "resolved", "verified", "synced")
  attention:     { level: none | requested, reason }
  transitions:   [{ to, when }]
  reason:        one human sentence for why this representation, tied to the state change
  announce:      [{ politeness: polite | assertive, text }]   // status messages
}
```

The **reason** is part of the design record: why Compact became Compare, why authorization is needed, why
Recovery instead of a completion. "A new record arrived" is weak; "the quantities compared use different
field meanings, so the mapping needs review" is the kind of reason required.

**Models may help** interpret and propose, but proposals enter as structured, checkable data. Generated
prose cannot declare success, verification or permission around the contract.

**Division of responsibility**: application → domain objects and execution boundary · adapter → declared
read/write/version/outcome capabilities · contract layer → checks inputs meet representation
requirements · resolver → plan · renderer → accessible components · harness → contract holds across
inputs and events. A "deterministic executor" forwards allowed requests by rule; it cannot remove remote
latency or partial failure, so the plan must still say what was sent, what is observable, and which
follow-ups are blocked or allowed under uncertainty.

## 6. Invariants

Each has a test. Areas a test cannot observe are reported as **coverage limits**, never as passes.

| ID | Invariant |
| --- | --- |
| INV-01 | No representation states a fact more strongly than its evidence. Wording, glyph and colour are capped by the epistemic state. |
| INV-02 | Completion expressions (`resolved`, `verified`, `synced`, a green check) appear only when the verification for exactly that scope is `verified`. |
| INV-03 | Rendered controls ⊆ the Allowed Action Set of the current plan. Executing re-validates; a stale control yields a re-check, not an execution. |
| INV-04 | Approval binds to a version (targets, recipients, amounts, scope). A material change invalidates it; an immaterial change does not. |
| INV-05 | `stop-requested` and `halted` are distinct. Accepted remote work that may still complete is shown alongside the stop. |
| INV-06 | Partial application is shown per target. It is never collapsed to success or failure. |
| INV-07 | Collapsing is a person's right at any time; the collapsed form keeps pending judgments and unknown outcomes visible. Only the system's *resolved* summary is gated by verification. |
| INV-08 | System-requested expansion happens only at human judgment points, proportional to consequence. Person-requested exploration is always available. |
| INV-09 | Background updates never overwrite in-progress input or swap a control under the pointer. If a control's meaning changes, the change is announced and input is preserved for review. |
| INV-10 | A projection (role, device, snapshot) may omit but may not contradict. Omission never changes the meaning of a fact or an authority. |
| INV-11 | A verification shows its scope: what was checked, what was preserved, what could not be observed. Unobservable scope is `inconclusive`, never passed. |
| INV-12 | `verified` is time-bound. A later change to its premises re-opens it; history keeps the old result without vouching for now. |
| INV-13 | Agent-authored text cannot assert verification, authorization or success. Those come from contract fields only. |
| INV-14 | Theme, model, layout and density changes do not change allowed actions or state meaning. |
| INV-15 | Identity claims are typed relations (alias, packaging, shared component, inventory pool, distinct). |
| INV-16 | No state is carried by colour alone: each has a glyph and a label. Focus and reading order survive every morph. |
| INV-17 | Rolling back configuration is not compensating external effects. Recovery shows both. |
| INV-18 | The Handoff Packet, not a chat summary, is the record a new owner starts from. |
| INV-19 | Numbers with different field meanings are never compared as the same quantity; the representation names the meanings. |
| INV-20 | A persuasive explanation never raises the displayed strength of evidence. |

## 7. Components

Grouped by semantic responsibility. They combine on screen into one continuous surface but are not the
same component and do not share guarantees.

| Responsibility | Component | Shows | May claim | Must not claim |
| --- | --- | --- | --- | --- |
| Work representation | **Work Object Shell** | The Case/Object identity across modes; hosts the other parts | Identity, current mode, what is pending | Anything its children do not carry |
| Work representation | **Status Mark** | One state on one axis: glyph + label, rest or lit | Exactly its axis value | A different axis (e.g. `applied` drawn as verified) |
| Evidence | **Source Record** | Value, field meaning, source, observedAt, freshness | "System X reported V for field F at T" | That V is true or current beyond freshness |
| Evidence | **Evidence Unit** | An observation's relation to a claim | supports / refutes / insufficient | Promotion of its contents to fact |
| Interpretation | **Claim Block** | Proposition + supporting/refuting evidence + epistemic state | The epistemic state | A stronger state than its evidence |
| Interpretation | **Interpretation Block** | Premises, uncertainty, what would change it | The interpretation and its premises | That it is observed |
| Decision | **Alternative Set** | Comparable options with consequences | Options are real and comparable | A hidden default as "the answer" |
| Decision | **Decision Record** | Chosen option, criteria, who, evidence used, accepted limits, when | What was decided and why, as recorded then | Reasons invented later |
| Consequence | **Impact Preview** | What changes *and what is preserved*, reversibility, notifications, future runs | The planned effect | That the effect happened |
| Authorization | **Authority Gate** | The five layers, the bound version, the approve control | Who may approve which version | Approval of anything but the shown version |
| Execution | **Execution Trace** | Work-meaningful steps per target, control state | Per-target execution state | Aggregate success over partial results |
| Verification | **Verification Result** | Checks, time, scope, preserved values, unobservable areas | The verified scope only | Whole-case resolution |
| Recovery | **Recovery Panel** | Current consistency, separate paths: retry, compensate, reconcile, escalate | Which paths are safe now | One "try again" for all |
| Handoff | **Handoff Packet** | See §9 | The state as of the packet | A summary's word for it |
| History | **History Timeline** | Decisions, evidence, executions, verifications and what they invalidated | Recorded relations | Chronology as causality |

**Every component contract lists**: semantic inputs · allowed states · forbidden states · evidence
requirements · action scope · meaning of authority · external effects · verification conditions · failure
and recovery · transitions to other representations · accessibility · observable events · test
conditions. A component without this contract may wear Lyotic's style; it does not implement Lyotic.

**One surface, not one small card.** The Shell starts compact; Source Records and Claim Blocks appear when
comparison is needed; Alternative Set and Impact Preview when a choice is needed; Execution Trace and
Verification Result continue inside the same object after execution. With hundreds of objects the Shell
may grow into a full workspace. What is preserved is the same Case, Object, judgment context and current
selection, not a fixed outline.

## 8. Tokens — four layers

| Layer | Is | Lives in | Example |
| --- | --- | --- | --- |
| Foundation | Base expressive values: colour, type, space, radius, motion, elevation, density, focus | CSS custom properties (`--ly-*`), from Plot | `--ly-ease-out`, `--ly-space-4` |
| Semantic presentation | Roles used to *present* states | CSS custom properties (`--ly-role-*`) | `--ly-role-attention-fg`, `--ly-role-intended-line` |
| Interaction state variable | Runtime data: epistemic, authority, impact, execution, verification, freshness | `data-ly-*` attributes set from the plan, never authored by hand | `data-ly-verification="inconclusive"` |
| Policy rule | Which actions and representations a combination allows | JavaScript (`@lyotic/core`), never CSS | `resolve(input) → plan` |

Risk and authority are never colour tokens. Visual consistency (same brand values) and semantic
consistency (green always means `verified`, never "submitted") are checked separately; a different brand
theme on the same semantic layer keeps Lyotic's meaning, which is why Lyotic can run on another design
system.

**Status language** (semantic presentation): each axis value has a glyph, a label and a hue; hue is
never the only carrier (INV-16). Solid strokes are things that exist; dashed strokes are things that are
only intended (proposed, pending); a tint plus hairline stroke means *lit* (needs the eye now); no fill
means *at rest*. Lit → rest fades fill and stroke only, so nothing moves.

## 9. Handoff Packet

Goal · current state per axis · observed information · unconfirmed claims · important assumptions ·
decisions and reasons · executed operations · observed effects · remaining verification · open loops ·
required authority · next owner. The receiver must be able to read "this is done, this remote operation's
outcome is unknown, this action is allowed with your authority", not "the last agent said it was nearly
done". Persistence is bounded: access and retention rules apply per role, and evidence that becomes
inaccessible re-evaluates the claims that relied on it.

Repeated open loops and manual exceptions may be surfaced as **Management System Debt**; surfacing a
pattern does not grant authority to change business policy. It opens a new Case with an owner.

## 10. Motion — the morph grammar

Motion explains a state change of the same object. It never hides loading, never signals "AI is
thinking" by moving containers, and is tested separately from adaptation. Rules (checked against
`.agents/skills/emil-design-eng` and `review-animations/STANDARDS.md`):

| ID | Rule |
| --- | --- |
| MOT-01 | **Continuity (the film's shapeshift).** A Work Object is one surface. Anchored to its row it rests as a status pill; it grows out of that pill into a card, changes shape between representations, and shrinks back into the row when verified. Position, size and radius spring (`duration 0.55, bounce 0.12`, the Systead film's values); its chrome (chip · card · good · warn · judgment) crossfades in 0.28s. The surface is interruptible: a new target retargets from current velocity. |
| MOT-02 | **Asymmetry.** Content exits faster than it enters: exit spring 0.2s to blur 4px and scale 0.985; entrance spring 0.34s from a 4px offset and 4px blur after 50ms; rows marked `data-ly-in` follow 50ms apart. CSS transitions use strong ease-out `cubic-bezier(0.23, 1, 0.32, 1)`; colour uses `ease`. Never ease-in. |
| MOT-03 | **Stagger** rows 30–80ms (50ms inside a shapeshift, 45ms elsewhere). Stagger never blocks input. |
| MOT-04 | **No scale(0).** Content enters from a 6px offset, opacity 0 and a 3px blur; popovers from `scale(0.97)` at their trigger; modals from centre. Press feedback `scale(0.97)` in 140ms. Nothing appears from nothing. |
| MOT-05 | **Attention vs exploration.** A system-requested expansion (judgment point) grows the object out of its pill and posts a polite status message; it never moves focus. A person-requested expansion follows the person's focus. Hovering or focusing a resting pill opens a lens (the film's Mismatch lens); leaving closes it. |
| MOT-06 | **Lit → rest.** A just-changed status stays lit for a breath (≈ 1.1s), then fades fill and stroke (≈ 420ms, ease-out) to match its neighbours. Position and label do not move. |
| MOT-07 | **Controls hold still.** The primary control keeps its position through a morph; a control never becomes a different action under the pointer (INV-09). |
| MOT-08 | **Keyboard-invoked surfaces do not animate** (command bar ⌘K, shortcuts). Hover motion is gated by `(hover: hover) and (pointer: fine)`. |
| MOT-09 | **Reduced motion** removes movement and size springs (jump to target), keeps opacity/colour at ≤ 150ms. Meaning never depends on seeing the motion. |
| MOT-10 | **UI durations stay under 300ms**; only the Shell's spatial morph and explanatory sequences may run longer. |
| MOT-11 | **Only transform, opacity, filter and clip-path animate** on the hot path. The one exception is the Shell's size morph: a spring on the height (and, for content-fit, width) of one container with `contain: layout`, because the object must push what follows it; children never animate layout. Colour changes use `ease`; transforms use the strong ease-out. |
| MOT-12 | **No perpetual motion.** A spinner only while a real execution is in flight; `outcome-unknown` is still, not spinning. |

## 11. The reference case (Systead: 5,400 / 1,620)

Illustrative values, not customer results. ERP and Excel show **5,400**; Shopify and Amazon show **1,620**.

1. **Compact** — not "inventory error found". There are records to compare and a stated scope of judgment.
2. **Compare** — two claims split: *these four records relate to one item/stock structure* (supported by
   identifiers and history) and *these four numbers are the same quantity* (unknown → reviewed separately).
3. **Interpretation shift** — ERP 5,400 is *Produced Quantity*; Shopify 1,620 is *Available to Sell*.
   Neither number is wrong. The representation moves from "values conflict" to "compared fields mean
   different things". The change is in Interpretation, and it changes the Recommendation.
4. **Precondition** — does ERP hold a real Available-to-Sell field or an approved rule? If not, the work
   stays in domain judgment (`blocked`), not mapping execution. Renaming or inventing a formula is
   forbidden.
5. **Alternatives** — keep as is · temporary manual adjustment · change the mapping rule so the correct
   available quantity feeds the marketplaces' Available field. The Decision records which and why:
   adopting a verified domain meaning as an operating rule, not approving the AI's answer.
6. **Impact Preview** — current values on Shopify and Amazon, future sync runs, order availability;
   preserved: production quantity record; Excel read-only; existing orders and reservations untouched;
   customer notifications none.
7. **Authorize** — approval binds mapping version, targets, record versions, policy conditions. At
   execution the premises are re-checked; if another user changed the mapping or authority was revoked,
   the old approval is not used and the plan says what changed.
8. **Execute** — Shopify applied; Amazon's response lost → `partially-applied` / `outcome-unknown`. Not
   success, not failure. Show what is confirmed, what is unknown, what was sent, what was not.
9. **Recover** — reconcile by reading Amazon's state through its contract; no automatic unsafe retry.
   Rolling back the mapping config does not restore values already written remotely (INV-17). Only
   actions that depend on the unknown result wait.
10. **Verify** — right field relation used, expected targets updated, preserved values protected,
    observations close enough in time. Excel: only "unchanged and relation confirmed", never "write
    succeeded". Unobservable side effects narrow the verified scope.
11. **Compact, verified** — "A2 · available 1,620 · mapping verified", with production 5,400 and each
    source's relation one step away. Integration keeps the difference and why it is valid. `verified`
    stays open to premise changes (INV-12): Systead's *Maintain* is a live check, not a green decoration.

**Second domain (coding agent)** — Work Object = Issue/PR; Observation = code and failing logs; Claim =
cause of the bug; Proposed Action = patch. Writable branch and file scope are authority; deploy rights are
separate. *Patch applied*, *named tests passed*, *review approved*, *deployed*, *user problem solved* are
five different results. Generalization means the same distinctions and contracts hold, not the same
component names.

## 12. The Systead film, read through Lyotic

The product film (`demos/work-creates-interface/`) shows the forms; this is how each maps, and where the
film simplifies what the model requires.

| Film scene | Lyotic parts | What Lyotic would add |
| --- | --- | --- |
| 01 Edit → Impact preview → sync-all | Impact Preview, Authority Gate (implicit), Status Mark | "Synced" right after the tool call is `applied`; `verified` needs a read-back. Sync-all is a scope change: the approval covers 16 more objects and must say so. |
| 02 Drop → Schema matcher | Interpretation Block (field mapping), Alternative Set (Customer ID 82% / Account No. 41% / Skip) | The percentages are classifier observations, not epistemic states. "Matched" should read as `supported` with the evidence (sample values). |
| 03 Drop a pile → Document sorter | Claim Block per page, policy threshold (≥ 0.95 auto-file), Decision Record ("confirmed by you") | Auto-filing is a delegated action; its scope (which folders, reversible) belongs in the Case. |
| 04 System detects → Mismatch lens | Claim Block (`conflicted`), Source Records, Evidence Units | A drift is a claim about divergence; each source's field meaning is shown before calling it a conflict (INV-19). |
| 05 Drag together → Identity merge | Work Object relation, Alternative Set | "Same product?" becomes a typed choice: alias / packaging / shared component (INV-15). |
| 06 Type intent → forms, plan, apply | Representation Resolver, Impact Preview, Authority Gate, Execution Trace, Verification Result | The plan resumes paused sync before writing (authority validity at execution). "3 of 3 applied" is execution; the settled row should say verified only after read-back. |

## 13. Evaluation boundaries

- Compare EBSRC against a **well-built fixed supervisory interface** with the same evidence, authority,
  proposals and recovery; beating chat-only alone proves little.
- Keep inputs fixed (same authoritative state, same agent trace, same allowed actions) and vary only the
  representation; the initial scope uses a deterministic resolver and fixed traces.
- Backend-blocked unauthorized runs are not a UI win. Measure interface understanding/intervention and
  runtime enforcement separately, then together.
- Schema checks, semantic checks, temporal checks (approval then change, late responses, stop, reconnect)
  and human studies are different claims.
- Synthetic user ensembles (MatrAIx, UXAgent, RealUserSim, TinyTroupe) stress scenarios; each sees only
  its role's real observations; agreement is not human understanding; text-only simulators cannot judge
  morph continuity.
- Human studies measure state understanding, recognition of judgment points, catching wrong proposals,
  appropriate intervention, false-completion belief, evidence understanding, supervision load,
  resumption and handoff accuracy, accessibility, transfer to a second domain; report effect sizes,
  uncertainty and null conditions. Faster wrong decisions are not improvements.
- Test adaptation and animation separately. A fixed representation winning some tasks is a finding.

## 14. Research lineage (claims Lyotic does not make)

Mixed-initiative interaction (Horvitz 1999) · levels and types of automation (Parasuraman, Sheridan,
Wickens 2000) · interface plasticity, SUPPLE · Human-AI Interaction Guidelines (Amershi et al.) ·
appropriate reliance (Lee & See) · explanations raise acceptance regardless of correctness (Bansal et al.)
· cognitive forcing (Buçinca et al.) · Plan-Then-Execute · Human-Agent Communication · Magentic-UI ·
Generative Interfaces for Language Models · DuetUI · Affora · Agent-Integrated Software · EffectMatch ·
WCAG 2.2. Lyotic adopts agent-readable semantic structure (Affora) as a base requirement, does not assume
progressive disclosure is efficient for agents, and does not claim the general Case–authority–execution
architecture (Agent-Integrated Software) or effect-matching verification (EffectMatch) as its own. Its
contribution is the representation layer's contract and implementation, and evidence of what it adds.

## 15. Done means per target

Ontology documented ≠ schema implemented ≠ transition tests passing ≠ connected to external systems ≠
people understand better ≠ holds in operation. Each status is stated against a version of code, run
records and evaluation material. The next goal is one executable reference case (§11) that closes the
loop end to end, the same contract surviving the second domain, and Figma and code expressing the same
meaning under independent checks.