Observations — situations Brand OS has met
What this answers: what has the brand run into that the system did not already cover?
Signals from consumer builds, stakeholder conversations, native-speaker review, the assistant, and anyone who read the corpus and found nothing. They land here before anyone decides what to do about them.
The output of a curation pass is promotion — into a Foundation page, a pattern, a filter, a constitutional rule, BASELINE.md, or a board card — or archival as "noticed, not acted on." Same shape as TAKS/doab.md, scoped to the brand. Portfolio-level signals that generalise past the brand still go to doab.md; this file holds what is specific to Aleris's brand system.
The model behind it is documentation/how-decisions-are-recorded.md. This file is the ledger; that document is why it exists.
How an entry gets in
Entries are earned, not generated. The discipline is stated once in TAKS/doab.md (2026-05-14) and is not restated here: an entry enters when something specific has been lost or won, single events rather than summaries, and "if the principle could plausibly have been written before the project started, it is confabulated."
Workflow. Claude proposes candidates with source pointers — date, session, what specifically happened. Torfinn approves and words them. Claude does not write the entry text as if it were settled; a proposed candidate is marked as one until he has taken it.
What an entry carries.
- The date and where it came from. A findings file, a session, a conversation, a page someone could not use.
- What happened, specifically enough that someone who was not there can tell it is real.
- The property — what made this situation different from the ones the system already covers. Not a name for the situation. The test in
how-decisions-are-recorded.md§9 obligation 1: could someone who was not in the situation have written this? - What it might reach, if that is visible. Often it is not, and saying so is better than guessing.
What does not belong here. Fixes with a known home — those go to the board. Technical patterns — those go to workspace/status/cookbook.md. Decisions already taken — those go to workspace/decisions/ and the changelog.
Curation ledger
No pass yet. The first one should say, per entry, what was promoted and where, or that it was noticed and not acted on. Resolved entries stay in place until a curation pass archives them.
Entries
Started 2026-08-25 and deliberately near-empty. A ledger filled on the day it is created is a ledger of things that were already known, which is the failure the discipline above exists to prevent.
2026-08-25 — Instructional imagery has no category in the corpus. (Claude-proposed candidate. Wording is Torfinn's; not yet taken.)
foundation/imagery.md governs identity imagery only, sorting images into Life, Care and Portrait by the story they tell. An injection-technique diagram is none of the three. The page's refusal of the clinically documentary image — "Images of equipment with no person, sterile corridors, data screens with graphs" — is correct and stands, but it was written about identity imagery and reads as a ban on a category the page never considered. Instructional imagery appears nowhere else in Foundation, and in Baseline only as a compression setting.
It is live in two products now. sundviktlakemedel (injection technique) and patientguide (preparation steps) both ship instructional images against no rule at all.
The property: the image is being read for what to do, not for who Aleris is. Nothing in the identity rules bears on it, and the rule that looks like it bears on it is about something else. That distinction reaches any medium where an image instructs — print, signage, video, a device diagram — not only the two products where it surfaced.
Source: workspace/decisions/decision-record-context-factors-and-emotional-modes-2026-08-25.md decision 4, amendment note. Board card 84 holds the task; this holds the observation.
2026-08-31 — A surface hosted outside Aleris cannot reach the typeface, and the declared fallback was designed for a different problem. (Claude-proposed candidate. Wording is Torfinn's; not yet taken.)
Two briefing pages for the session with Mohan and Sofia were published as Claude artifacts on claude.ai. Everything the brand specifies as a value travelled intact — the palette, the spacing, the radius and the surface rules are inline in the document and render correctly. The typeface did not. Two independent things blocked it: the artifact host permits no external stylesheet except Google Fonts, and middleware.ts echoes Access-Control-Allow-Origin for /fonts/* only to aleris.se, aleris.no, aleris.dk, aleris.ai and localhost. The pages render in substitute faces picked from what the host allows.
The corpus does have an answer here, and it is the wrong one for this case. aleris-tokens.css declares --font-family-primary: 'Museo Sans', Arial, sans-serif, and baseline/setup.md explains the fallback in terms of load time: font-display: swap so "text is visible immediately in the fallback font while the woff2 loads." That is a fallback for latency. A page hosted where the font can never load is not a page waiting for a font — it is Arial permanently, and nothing in the corpus distinguishes the two situations.
The property: the brand divides into what travels inside a document and what needs a fetch from an origin Aleris controls. Every rule, every value and every colour sits in the first group. The typeface is the only thing in the second, because it is a licensed binary rather than a declared value. So a surface hosted elsewhere degrades unevenly: every value correct, and the one thing a reader registers first wrong.
Two existing rules bear on this and neither answers it. _packages/README.md rule 4 forbids shipping font files, on drift grounds, and reads §2d of the webfont EULA as limiting use to sites the licensee owns or controls. Both are written for a consumer running on an Aleris origin, and neither says what a deliverable published on a platform Aleris does not own may do. The obvious workaround makes it worse rather than better: data-products/tokens/aleris-fonts.css exists because a bare local('Museo Sans') match picks whichever installed weight claims that family name, usually 900, and renders every weight in the page from one file.
What it might reach: any deliverable that leaves an Aleris origin — a deck on a partner platform, a shared prototype, an embedded document, a sandbox, anything a supplier hosts. Three routes are visible and the choice between them is not: state a substitute face for that case, take a licence position that lets the real face travel, or rule that such deliverables are published on brand.aleris.ai instead.
Source: this session, 2026-08-31. middleware.ts lines 5–11; data-products/tokens/aleris-tokens.css --font-family-primary; baseline/setup.md § "Step 1b — Link the hosted font stylesheet"; the header comment in data-products/tokens/aleris-fonts.css; _packages/README.md rule 4.
2026-10-14 — An internal AI assistant in a browser side panel meets rules written for patient chat and for full pages. (Claude-proposed candidate. Wording is Torfinn's; not yet taken.)
Albot, the intranet assistant, ships as an Edge extension: a toolbar icon opens it in the browser's side panel. Sofia Myrevik asked for the symbol and the name "Albot" to be removed from its green header. principles/logo-identity.md settles that part (a symbol with text beside it is a substitute logotype). Reviewing the rest found questions the corpus does not answer:
- Naming an assistant.
patterns/chat-response-simple.mdsays the chat is not a character with a name, but it was written for patient chat. Does it apply to an internal tool for staff, and so to "Albot"? The naming guideline draft (TAKS, 2026-06-05) names digital services after what they are, but only for patient-facing services. - Small icon sizes between 16 and 32 px. The logo page covers the generated 16 px variant and the unchanged mark from 32 px. A browser toolbar icon is 16 device-independent pixels, so at 125 % and 150 % scaling it renders at 20 and 24 px. Nothing says which asset applies there.
- The toolbar icon as an app icon. "The symbol in sand on petrol" is the app icon rule. Does it hold in a browser toolbar that is themed light or dark and where icons are usually monochrome?
- Sender in a browser-owned frame. The browser draws the panel's title row with the extension's name. Is that enough sender, or does the panel need the full logo, and where, given the symbol alone may not sit in the corner of a digital service?
- AI disclaimers. "I may be wrong, never share sensitive data": wording, voice (first person or not) and placement are not covered.
- Chat on an instrumental surface for staff.
patterns/chat-bubble.mdassumes a patient, a communicative surface and a 600 px column, and forbids an orange button in a bubble when the page has a hero CTA. A side panel has no hero; is send the one primary action? Suggested-question chips and a personal greeting ("Hej Sofia!") have no pattern.
The property: a Brand OS surface rendered inside someone else's frame (the browser owns the title row, the icon size and the panel width) and used by staff rather than patients. Rules written for pages Aleris fully controls do not say what happens when part of the frame is not ours.
Source: this session, 2026-10-14; Claude Design brief at TAKS/albot-claude-design-brief-261014.md.