Components

Represent the work, not just its appearance.

Every component has a semantic job: show a source, separate a claim from its evidence, expose a decision, or report an effect within its verified scope. The plan decides what must be present and what may be acted on.

Overview

Use the Work Object Shell for the complete representation. Use the individual parts when a host can still satisfy the relevant contract. These components are not a second policy engine.

Anatomy

  1. Persistent carrier. Work Object Shell preserves the work’s identity. Status Mark names one independent state.
  2. Evidence and interpretation. Source Record, Claim Block, Evidence Unit and Interpretation Block keep observations, assertions and readings distinct.
  3. Decision and authority. Alternative Set, Decision Record, Impact Preview and Authority Gate expose options, consequences and bound permission.
  4. Effects and continuity. Execution Trace, Recovery Panel, Verification Result, Handoff Packet and History Timeline preserve target-level outcomes and the work left to do.

States

A surface can contain an applied execution and pending verification at the same time. Do not compress independent axes into one universal success badge.

Usage and avoid

When to use

Compose these parts when a person supervises work delegated to an agent: examining its basis, deciding within authority, and checking the resulting effects. Start from the required disclosures in the plan, not from the smallest attractive card.

When not to use

A purely presentational button, form or navigation menu can use the underlying Plot vocabulary. It does not become a supervisory component merely by adopting Lyotic’s color or motion.

Do not hide a missing check

Showing a verification result means preserving its limits, not only displaying a green label.

Evidence limits

The examples use deterministic fixtures. Passing the plan and DOM checks establishes only the properties those checks observe. Remote adapter behavior, unobservable effects and human understanding need separate evidence.

Contract

This is the composition contract shared by the catalog, not a new runtime component. Each component page specifies these same thirteen fields for its own responsibility.

The thirteen fields every component documents
Semantic inputsAuthoritative data plus the matching Representation Plan.
Allowed statesDeclared, independent axis values applicable to the part.
Forbidden statesStronger claims, invented authority and premature completion.
Evidence requirementsThe basis, freshness and missing support for each displayed claim.
Action scopeOnly actions permitted by the plan; disabled actions explain why.
Meaning of authorityWhether the part displays, requests or records authority. Rendering never grants it.
External effectsThe executor’s actual effects, if any; none from rendering.
Verification conditionsExact checked, preserved and unobservable scope.
Failure and recoveryTarget-level outcomes and explicit available recovery paths.
TransitionsPreserved identity, input, action meaning and focus; leaving content is inert.
AccessibilityNames, roles, reading order, keyboard access, announcements and reflow.
Observable eventsReal emitted events and payloads, or explicitly none.
Test conditionsPlan/DOM assertions plus temporal, interaction and evidence limits.

Accessibility

Composition changes reading order and focus behavior, so inspect the whole surface as well as the parts. Preserve headings and region names, text-based state, version-specific action labels and a keyboard path to pending work. Never use motion as the only explanation.

Code

import { resolve, checkDom } from '../../packages/core/src/index.js';
import { WorkObjectShell } from '../../packages/components/src/index.js';

// state comes from the application; host is a persistent DOM element.
const shell = new WorkObjectShell(host);
const plan = resolve(state);
shell.render(state, plan, { initiator: 'system' });
const report = checkDom(host, plan);
// Record report.violations AND report.limits. Neither validates a remote write.

See Develop for the adapter boundary and the invariants for the rules these parts must preserve.