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.