v0.14's identity and components, now with the foundations (color tokens, spacing scale) made visible, the deferred components (date-and-time, rich text) specified at a working starting point, the mobile-pattern adaptations, and the motion system documented. The pre-v0.14 principle — defer until real surfaces need these — is relaxed in v0.15; conservative choices have been made where design decisions were required, and each choice carries a Discovery-record note so it can be walked back when real surface requirements arrive.
The mark in condensed form. Two-part logo system — foundry wordmark for signatures, stamp mark for compact use — with the primary lockup and the full favicon set. The detailed specification (size ladders, clear space, environmental behavior, reductions, case forms, rule-weight scaling) lives in the logo-system document.
Both marks reserve the iron-oxide accent for the stamp's single pixel square — nowhere else in the identity does the accent appear. LOOMWORKS carries the mark weight in display contexts; Loomworks carries the mark as a word in prose. Both forms are IBM Plex Serif 500. Rule weight under the wordmark scales with font size per the spec in the logo-system document. Dark mode is inversion-only: same geometry, flipped fills.
Full spec — lockup proportions, clear space, environmental behavior on the four rooms, reductions for print and watermark, DUNIN7 cosign configurations, the settled resolutions from wordmark-study v0.5 — is in loomworks-logo-system-v0_1.html.
Components in their natural settings, working together. Each context is a surface an Operator or reader would actually encounter. Below each one, annotations note which primitives are in use and how they behave.
| ID | Consideration | Voice | State | Opened |
|---|---|---|---|---|
| c-13 | Middle-tier grandfather clause. Two voices — one proposing 12 months, one lifetime. Awaiting third voice. | nia.h | open | 18 Apr |
| c-12 | Tier names — categorical or numeric? Testing whether tiers should refer to customer type or be numbered. Closing soon. | marvin.p | open | 17 Apr |
| c-11 | Annual billing discount ratio. 15% annual discount held through testing with pricing panel. | nia.h | promote | 16 Apr |
| c-10 | Scope expanded to include international. The seed was updated — prior version retained. | leon.k | amend | 15 Apr |
| c-9 | Current tier naming conventions. Starter / Pro / Business held under review. | marvin.p | attest | 14 Apr |
| c-8 | Enterprise pricing opacity. Known departure from public-pricing default — reasoning logged. | nia.h | deliberate_exception | 14 Apr |
| c-7 | Pricing-page redesign budget. Raised above team scope. | leon.k | escalate | 13 Apr |
| c-6 | Free trial policy. Fourteen-day trial stands against new structure. | marvin.p | no_change | 13 Apr |
Primitives in use: breadcrumbs, room-switcher, tabs, text input, select input, ghost/iron buttons (small), table with hover and row-open state, state badges (7 variants + neutral open variant), mono-styled IDs and timestamps.
Behaviors worth noting: The open badge is a distinct form — solid press-ink, no dot — because an open consideration isn't a terminal state. State dots only appear on closed considerations. The primary action ("Open consideration") uses the iron-oxide button because it's the generative action of this surface; secondary and sort actions are ghost weight. The room-switcher shows all four rooms with dots in their atmospheric colors — the same system across every surface.
Primitives in use: standard cards (four), badges with and without dots, room-variant badges (outlined), ghost and secondary buttons.
Why this reads as Memory not Shaping: the cool grey environment is the only atmospheric cue that says "you are looking back." The cards themselves are visually simpler than the consideration-list rows — no hover highlighting, no open state, no action affordances beyond the card surface itself. Memory is read-only by temperament; nothing about the layout invites editing.
Primitives in use: emphasis cards (press-ink left border, vellum fill), iron card (iron-oxide left border for high-relevance surfacing), badges, secondary and iron buttons (small).
The iron card is doing real work: when Manifestation surfaces a consideration because drift detection identified it as critical, the iron-oxide border signals urgency without shouting. The iron button on that card matches — "bring this in, it matters." Regular surfaces use secondary buttons. The hierarchy is visible in the stroke color.
The current seed asked about pricing three tiers for the Q3 launch. You're replacing it with an expanded version that includes international pricing.
The prior version will stay on the record. Every consideration opened under the old seed keeps its provenance — but new considerations will respond to the new framing.
Primitives in use: modal surface on backdrop, modal header with iron-oxide kicker, textarea input, ghost button (Cancel), iron button (Confirm).
Why the iron-oxide kicker: amend is the one state in Loomworks that inherits the brand accent because it's the most consequential action — the seed itself changes. The kicker marks this modal as doing that kind of work. Destructive or high-consequence modals use iron-oxide in the kicker and the confirm button; routine modals use press-ink kickers and primary (dark) confirm buttons.
Primitives in use: toasts with state-colored dots (three of the seven shown as examples), empty state with kicker / title / body / dual actions, loading dots (pulse animation), skeleton loading (sweep animation).
Voice notes: the empty state doesn't apologize for being empty — "The workshop is empty" is a neutral observation, not a problem to solve. Toast copy uses short declarative sentences that say what happened. Loading labels use mono caps ("Retrieving from Memory") rather than generic "Loading…" — they name the action.
Every primitive in its variants and states, laid out for specification. The composed contexts above show how the pieces work together; this gallery is where you look something up when you need to implement it.
This consideration will be closed with terminal state promote. The reasoning and voices are preserved. The action cannot be reversed — but the record will always show what happened and why.
The tokens behind everything in parts one through three. Grouped by role: press and ink (the foreground), accent (the one hot color), paper (the grounds), rules (the dividers), environments (the four rooms), terminal states (the seven outcomes). Each swatch shows token name, hex, role, and usage.
Specimen, not decision. Every color in this part was defined in the CSS at the top of v0.13 and used throughout v0.14; this section just makes them visible. No new color choices were introduced in v0.15.
One conventional token set. The palette is organized by role, not by hue family. There is no "gray scale," no "red family," no "100/200/300 steps." A designer used to framework-style token systems (Material, Radix) will find this minimal and opinionated — that's deliberate.
Eleven spacing tokens, from a quarter-rem hairline gap up to a five-rem full-block separator. Each shown at actual size so the bar is the space, not a representation of it.
h2.section-h); large set-piece separation.
Intentional. A complete 1-through-20 scale invites precision that isn't real. The scale skips the values that don't have a distinct use from their neighbors. If a designer finds themselves wanting --s-7, the decision is between --s-6 and --s-8, not between the three.
This was established in v0.13 and carries forward unchanged; no spacing decisions were introduced in v0.15. This section just makes the scale visible.
Two component families the prior work deferred — now given conservative starting specifications. Each carries a Discovery-record note pointing at the design decisions made and the easier paths to walk them back.
"This engagement was created in Loomworks on 19 April 2026, last amended on 21 April, and has eleven considerations open."
Mono precision form (2026-04-19T14:22:08Z): ISO-8601 UTC in IBM Plex Mono. Used in provenance displays, log views, metadata strips, export formats — anywhere the exact moment matters and the reader is expected to be technically fluent.
Prose written form ("19 April 2026"): day-first European ordering in IBM Plex Serif italic. Used inside sentences, in narrative descriptions, in the Operator's reading surfaces. Follows the two-case-form pattern: the precise form is the mark, the prose form is the word.
Relative form ("4 days ago"): IBM Plex Serif italic, paired with the absolute time. The relative is always secondary to the absolute — never shown alone, because it loses meaning as soon as the page sits for a day.
Considered and set aside: US-ordered dates (4/19/2026) — ambiguous in an international product; slash-ordered ISO (2026/04/19) — reads as a filepath, not a date; "today/yesterday/tomorrow" relative anchors — brittle across timezones.
Walk-back risk: low. Both forms are conventional. The only way the Operator may want to change this is toward a single house-style (e.g., mono everywhere, or prose everywhere) — but the two-form approach has room for both preferences.
Week starts Monday. ISO week convention and what almost every professional calendar tool has converged on. Sunday-first is a US consumer-app convention, not suited to an Operator-facing engagement-memory tool.
Today is outlined, not filled. Today and selected are different states — today is reference, selected is action. Filled-today conflates the two; outlined-today keeps them separable.
Other months are muted, not hidden. Seeing the boundary-dates of adjacent months is useful orientation; hiding them mid-row creates an uneven grid. Muted-but-visible is the compromise.
Range-end matches selected color; range-interior uses vellum. The two endpoints are interactive (draggable); the interior is informational (shows what's in the range). Same visual language as other brand surfaces — press-ink for action, vellum for reference.
Considered and set aside: an always-visible year navigator (adds chrome the Operator rarely uses); month-switcher as a drop-down (heavier than arrows for monthly browsing); multi-month side-by-side display (overkill at the current scale — reserved for a possible v0.16 if the Operator actually needs it).
Walk-back risk: medium. Week-start is locale-dependent in a way that may matter to some Operators; the current single-month display may feel constrained for range selection across months. If a real Operator surface shows these limits biting, the structure supports both changes without breaking the aesthetic.
The grandfather clause was originally set at six months, which held through Q2 without exception. The question now is whether it should extend to twelve months for enterprise tier given the contract-review cadence.
Grandfather policy is a retention tool, not a feature. Length should follow what it's buying us in renewals, not what feels fair in isolation.
Three considerations worth attention before deciding:
renewal_review_cadence fieldWhat's in: bold, italic, two heading levels (H2 and H3), bulleted list, numbered list, blockquote, inline code, hyperlink. The vocabulary of considered prose.
What's not in: font size, color highlights, text alignment controls, font family changes, strikethrough, underline, tables, images, video embeds, emoji picker, mentions. Each of these was explicitly considered and set aside.
Why minimal. Loomworks is a thinking-and-remembering environment. The rich-text editor serves Operators writing considered prose — seeds, considerations, amendments — not rich-media documents. Every tool added to the bar is a decision the Operator has to make every time they write; a minimal toolbar keeps attention on the words.
Underline is absent specifically. Underline reads as hyperlink on the web; having an unlinked underline format invites confusion. Italic and bold cover emphasis; underline adds nothing here.
Considered and set aside: a Markdown-source-only editor (too engineer-facing — Operators should not see syntax); a Notion-style "/" block insert menu (adds a command layer that breaks the writing flow for a conservative toolbar); Strikethrough (edits aren't struck-through in Loomworks — amendments get their own record with full provenance, so strike-through would misrepresent what happened).
Walk-back risk: high. This is the most opinionated set of choices in v0.15. The "considered prose" framing may prove wrong — real Operator surfaces may need tables, images, or a richer block vocabulary. If that happens, v0.16 should reconsider the toolbar as a whole rather than adding tools one by one, because ad-hoc additions tend to muddy the underlying premise.
Three transformations beyond basic responsive behavior: tables become card stacks, navigation becomes a drawer, modals become bottom sheets. Plus a tap-target scale. Shown side-by-side desktop / mobile so the transformation is visible.
| Engagement | Status | Last considered | Voices |
|---|---|---|---|
| Pricing Q3 grandfather clause | amend | 21 Apr 2026 | 3 |
| Tier rename consideration | retire | 3 Nov 2023 | 4 |
| Middle-tier retention analysis | attest | 14 Feb 2026 | 3 |
Table → card stack is the default. Trying to shrink a table horizontally produces unreadable mush. Transforming into a card stack preserves the data's structure while reformatting for portrait reading. The first field (engagement title) is promoted to a header; the remaining columns become key-value pairs.
Nav → drawer, not bottom tab bar. iOS convention would be a bottom tab bar for the four rooms; the drawer choice is deliberate. The rooms are not peer destinations the Operator switches between frequently — they are environmental contexts. Putting them in a drawer keeps the chrome quiet when the Operator is working, and surfaces the room-switch as a deliberate move rather than a thumb-flick.
Bottom sheet for high-consequence confirms. Centered modals on mobile are reachable only with thumb-stretch and feel disproportionate on tall screens. Bottom sheets are thumb-zone-native and allow the body of the surface to stay visible above them, maintaining context. Amend is the canonical high-consequence action and gets a bottom sheet.
44px is the floor, not the target. 44px is Apple's stated minimum; 52px is comfortable for the Operator-is-not-hurried temperament of Loomworks; 60px marks the amend/escalate actions that must be deliberate. The iron-oxide button at 60px is a moment of consequence — its physical size matches its semantic weight.
Walk-back risk: low for the table→card and bottom-sheet patterns (these are conventional); medium for the nav drawer (a tab bar is the iOS default and Operators on iOS may expect it). If real Operator testing shows drawer friction, v0.16 can revisit.
Duration tokens, ease curves, and the patterns that use them. Motion in Loomworks is patient — the brand is unhurried by temperament, and the motion system supports that: nothing snaps, nothing bounces, nothing demands attention. Transitions confirm that the system has registered an action, without making that confirmation the point.
| Pattern | Duration | Ease | Property |
|---|---|---|---|
| Hover — button, row, card | fast · 150ms | ease-out | background, border, color |
| Focus ring — input, button | fast · 150ms | ease-out | box-shadow, border |
| Tab / accordion switch | normal · 250ms | ease-in-out | opacity, transform |
| Toast enter | normal · 250ms | ease-out | transform, opacity |
| Toast exit | normal · 250ms | ease-in | transform, opacity |
| Modal open | slow · 400ms | ease-out | transform, opacity, backdrop |
| Modal close | normal · 250ms | ease-in | transform, opacity, backdrop |
| Bottom-sheet slide up | slow · 400ms | ease-out | transform |
| Drawer slide in | slow · 400ms | ease-in-out | transform |
| Room switch — background | slow · 400ms | ease-in-out | background-color |
| Loading pulse | 1.5s cycle | ease-in-out | opacity |
| Skeleton sweep | 1.8s cycle | linear | background-position |
Confirm. An action registered — a button press, a state change. The motion says heard you.
Orient. Where did that element come from, where did it go. The motion shows the geometry of the transition, so the Operator doesn't have to reconstruct it.
Set pace. The motion timing tells the Operator what kind of moment this is — a micro-interaction (fast), a state change (normal), a set-piece transition (slow).
Perform. No bounces, no springs, no elastic overshoots. Loomworks is a patient environment; performative motion breaks the voice.
Decorate. No ambient motion, no idle animations, no "this element is interactive" pulses that run without cause.
Stack. Two motions rarely happen at once. A click that triggers a modal does not also trigger a hover-exit on the button plus a ripple plus a toast — pick one.
Override prefers-reduced-motion. When the operating system requests reduced motion, durations collapse to zero and transitions become instant state-changes. No workarounds, no "essential" exceptions.
Inherited from v0.13: the --ease-out curve cubic-bezier(0.22, 1, 0.36, 1), the fast/normal duration pair (150ms / 250ms), and the two utility animations (loading pulse, skeleton sweep). v0.15 extends these — does not replace them.
New in v0.15: a slow duration (400ms) for set-piece transitions, two additional ease curves (ease-in-out for bi-directional motion, ease-in for exits), and a full pattern table assigning duration/ease/property to each motion surface.
Considered and set aside: spring physics (too performative — doesn't suit the considered temperament); choreographed multi-element transitions (too showy for an Operator tool); motion-on-scroll effects (distract from content, add no information); anticipation/follow-through beyond basic ease curves (again too performative); shared-element transitions between surfaces (real technical complexity with unclear Operator payoff at this stage).
Walk-back risk: low for duration and ease tokens (conventional). Medium for the motion-principles list — the motion does not perform stance is opinionated, and Operators coming from more expressive product backgrounds may find it austere. The stance is defensible but not the only possible one.
Parts one through three carried forward from v0.14 unchanged (identity, composed contexts, reference gallery). Parts four and five newly surface the foundations the prior work used implicitly — color tokens grouped by role, spacing scale shown at actual size. Part six adds two deferred component families at working starting specifications (date-and-time display plus inline/range calendars; conservative rich-text editor). Part seven introduces mobile-pattern transformations (table → card stack, nav → drawer, modal → bottom sheet) with a tap-target scale. Part eight specifies the motion system — duration tokens, ease curves, a full pattern table, and the principles that govern what motion does and does not do.
v0.13's closing note stated that date pickers, rich-text editors, mobile patterns beyond basic responsive, and a full motion system all belong downstream of shipping the first real surfaces, when their actual requirements are known rather than guessed at. v0.15 relaxes that principle and produces them anyway, with conservative choices that are explicit about what they defer and what they decide. Each new-in-v0.15 section carries a Discovery record noting which decisions were made, which alternatives were considered and set aside, and what the walk-back risk is. This lets any future real-surface requirement land as a revision to specific choices rather than a rebuild of the whole section.
Identity (with full logo specification in the sibling document). Components at both composed and reference levels. Foundations (color, spacing). Additional components (date/time, rich text). Mobile adaptations. Motion. Enough for a product team to implement a real surface and have it read as the brand across desktop, mobile, and rendered-artifact contexts.
Typography scale specimen. The three typefaces (IBM Plex Serif, Inter, IBM Plex Mono) are in use throughout, and their weights/sizes are visible in the component vocabulary, but there is no dedicated type-scale reference section. Candidate for v0.16. Voice and copy guidelines. The brand voice is demonstrated in every heading and lede but not documented as a ruleset. Candidate for v0.16. Iconography library. Loomworks has so far resisted a generic icon library; any icons used are hand-drawn into their surfaces (the stamp mark, the state dots). If real surfaces need icons, v0.16 or later should decide the icon system from scratch rather than importing a library. Applied templates. The brand system has been specified; applied templates (landing pages, engagement pages, rendered artifacts) live in the sibling loomworks-applied-surfaces-v0_1.html and will continue to evolve there.