What this answers: when we decide something, how do we record it so the next person can find it and knows what it covers?

Two halves of one job. Reach — what else does this decision apply to? Footprint — where has it been written down, and are those copies still right? Both are answered from one record, and both need the same thing built.

How decisions are recorded

Status: accepted · Owner: Torfinn · Scope: Aleris Group · Updated: 2026-08-25

What is in force: §1, §2, §3, §4, §8, §9, §10. Carried open, not in force: §7 (the language question — a hypothesis with its evidence tiers marked), §11 (the graph, unscoped), §13 (open questions), §14 (next step, parked).

Consolidated 2026-08-25 from context-architecture.md and dependency-reciprocity.md. The two were labelled model and mechanism. They were not: they were one argument written twice, five days apart, with the same worked example and the same three cases in the same order — the drift shape this project has now recorded five times, caught on consecutive days. git log shows the direction: the argument was written on the 24th and restated on the 25th under a header claiming neither file restated the other.

The reasoning and the alternatives are in workspace/decisions/decision-record-context-documents-coherence-2026-08-25.md. Both old paths remain as pointer stubs.

1. What Brand OS is

Torfinn, 2026-07-28, and it decides the shape of everything below.

Brand OS has several parts, some more document-like than others, but at its core it is a design system with tests. Documents are based on it, for the purposes of explaining and using the system.

Parts of the system are for digital and interactive contexts. Other parts are interior design, clothing, signage, voice, motion, lighting, furniture, vehicles. Baseline and the token system are the specific, detailed digital design system — one part of the whole, not the whole. Baseline can be versioned and packaged for different purposes, including upload to a repo as a reference for LLMs.

In its entirety, Brand OS will be a service supporting anyone who needs to work with the brand, in any of those media. That includes a library of visual examples and motion graphics that exemplify the brand.

The answer is both: documents and a system with tests, where the different representations are interdependent. That interdependence is the problem this document is about.

2. The two questions

One decision, two ways of asking about it. Both need the same thing built, and neither is reachable without it.

Reach — given a decision, what else does it apply to? Someone ratifies a target-size floor for the clinician console. Next month there is a bedside tablet, a waiting-room kiosk and an internal admin tool. Does the console's decision cover them? §3 is the answer.

Footprint — given a decision, where is it written down? One rule, "hover lightens, never darkens", was an Anchor in the governance doc, restated in BASELINE.md, cited in a token comment to justify a value, encoded in four token values, and mirrored into a shipped package. Six copies. Nothing connected them, so the rule sat next to three AA failures it had caused for six weeks, and we found them by writing a script. Same shape, same day: the colour-alone rule was stated in ten places rather than the six the de-duplication plan listed. Found by grep. §10 is the answer.

And the consumer asks the reverse of footprint: given this artefact in this situation, what constraints bear on it? Someone building a dense clinician worklist, a printed patient form, a wall marker in a lettered waiting area or a login page served before the stylesheet loads needs the applicable subset of the corpus, not the corpus. Today that subset is assembled by reading and remembering, which is why three consumers independently reimplemented BASELINE.md's component rules from prose and one of them got it wrong.

That third question is the one that justifies the work to anyone other than the person maintaining the corpus, and it is the shape the eventual service needs. All three are the same graph read from different ends: rules as addressable things, each decision declaring what it turned on and each document declaring which decision it represents. §11 step 1.

3. The property, not the label

The mechanism the rest of this document rests on.

The target-size floor was ratified 2026-08-19: 24px for the clinician console, 44px for patient surfaces. Next month someone designs a bedside tablet for nurses, a waiting-room kiosk and an internal admin tool. Whether the console decision reaches them depends on why the console was allowed the lower floor, and each candidate reason draws a different circle:

pointer input rather than touch → the admin tool is in, the bedside tablet is out
information density → all three, if they are dense
trained users in repeated daily use → tablet and admin tool in, kiosk out
internal system outside DOS-lagen's material scope → kiosk out, the other two in
not patient-facing → depends what the kiosk displays

The reasoning existed when the decision was made. The record kept the surface name and dropped the reason, so the next person cannot compute the circle and has two bad options: apply it too widely, or re-derive and produce a second answer to a settled question.

So the field a decision needs is the property of the situation the answer turned on, not a label for the situation: "applies where input is pointer and use is repeated" rather than "applies to the console".

Consequence: reach between situations is per-decision, not global. There is no single relation connecting situations to each other, so a taxonomy of relations authored up front will be wrong. Each decision defines its own reach, through the property it turned on.

Three cases already in the corpus, best behaved first:

sundviktlakemedel/BRAND-OS-FINDINGS.md §7, unprompted. "Worth Brand OS knowing about as a category: any consumer with a server-rendered pre-auth page (a login screen, an error page, a maintenance page) has the same problem." The property is that the page renders before the built stylesheet is reachable, and naming it named the reach.
The target-size ratification, halfway. The reasoning existed in the brief's AA/AAA and pointer-versus-touch argument; the record kept the surface.
The children's markers, brandguide/_state.md 2026-07-30. The constraint that reorganised the whole design was that the summons letter names a lettered waiting area. Not medium, not audience, not reader state, not surface temperature. Nothing a pre-declared scheme would have contained, and it arrived by asking Sanna.

How this relates to F6, and what it asks of a reader

principles/constant-and-contextual.md ends with three questions. This document attaches to the second of them, and that is worth saying plainly because nobody had.

F6 question 2 — "Beror rätt val på situationen…? → Kontextuellt. Läs situationen. Använd ditt omdöme." As written, the reader reads the situation and owes the system nothing back. The property this document asks for is that reading, written down. So the obligation lands here, on ordinary judgement inside existing guidance, not only on the gap.

This does not replace the judgement with record-keeping, and the reason is in the target-size case above: five properties were true of the console at once, and choosing which one the answer turned on is itself the reading F6 asks for. No table yields it. The children's markers case is the proof — nobody would have derived the summons letter names a lettered waiting area from a scheme.

F6 question 3 — "Hittar du ingen vägledning alls? → Du har hittat en lucka i systemet. Flagga den." Until 2026-08-25 there was nowhere to flag it to. There is now: workspace/status/observations.md. §8 lists it as the fifth arrival route.

F6 itself is unchanged and gains nothing. That position is settled — five attempts, three at global scope refused and two domain-local accepted; the measurement is in board card 79 and workspace/decisions/decision-record-context-factors-and-emotional-modes-2026-08-25.md § "What F6's position actually is". It is not re-argued here.

4. Observe, collect, hold

Three roles, in the order they happen.

Observe — notice that a situation exists. Today this happens when someone hits a wall while building or while talking to a stakeholder. It is real and it is unrecorded as observation: what gets written down is the fix that was needed, not the fact that a new situation was met.

Collect — get the observation into the system with enough attached that a later reader can use it. The load-bearing attachment is not a name for the situation. It is the property that made the existing answer not fit. A name lets you file the observation. A property lets you compute whether it reaches somewhere else.

Hold — keep it current: know which decisions are scoped to it and on what property, know when the core has moved underneath it, say plainly where it is empty, and name who has the standing to decide inside it. Custody is the part that decays without attention, and it is the part that markets already exercise better than any other boundary in the corpus.

5. The boundaries met so far

Observed, not designed. The list is a record of what the system has run into, open at the bottom, and it earns entries the way TAKS/doab.md does rather than by being filled in.

Boundary	Cuts across	Where it currently lives
Market	every layer that carries voice, plus service names, care-system vocabulary and regulatory scope	`_markets/`, `filters/language-quality-*`, the no-fallback rule in the site map
Medium	everything — digital, print, interior, signage, clothing, voice, motion, lighting, furniture, vehicles	the project's Why; only the digital part has depth
Surface temperature	digital surfaces	`BASELINE.md`, set by the situation and never by the user's role
Reader state	communication and interface both	`principles/emotional-modes.md`
Input and device	digital surfaces	the `targets` prop; ratified 2026-08-19
Regulatory scope	product surfaces	the sund vikt regulatory analyses; device versus non-device, DOS-lagen versus AFS 2023:11
Production method	physical work	film versus paint in the children's markers thread; the constraint runs back into the motif geometry
Delivery constraint	anywhere the surface cannot consume the system normally	consumer findings: the pre-auth page, 200% text at 320px, 250 rows

Market and medium are the two that cut across everything else. The rest sit inside one or two layers.

6. Markets as the largest boundary

Markets are where this is furthest along and where its failure mode is sharpest, which makes them the case to design against.

What already exists, and it is more than anywhere else. _markets/ with five rules and per-file provenance in MANIFEST.md. A filters/ layer with language-quality-sv accepted and -no and -dk deliberately empty. Two durable rules in the site map: markets sync with the core, not each other, and no fallback across markets — when a page is not decided for a market the site says so rather than showing another market's version.

The no-fallback rule is already custody, and it is the best example of it in the corpus. filters/language-quality-no.md refuses to borrow the Swedish ruleset and says so on the page: "per the no-fallback rule, it does not borrow the Swedish ruleset… this page lists structure only and carries no patterns." That is the system declining to pretend it has observed a situation it has not. Everything below is an attempt to generalise that stance rather than to invent one.

And the failure mode is the label problem in its purest form. Nobody can tell whether a Danish page is off-brand or simply Danish. That is what a market-labelled rule produces. "This applies in Sweden" records the outcome and drops the property, so a Danish reader meeting a Swedish-derived page has no way to test it. If the rule instead said what it turned on — Swedish formality conventions, a Swedish care-system term, a regulatory scope that is Swedish, a translationese profile specific to Swedish — the Danish reader could check whether the property holds in Denmark and get an answer rather than a guess.

"It is Norwegian" is a label. What are the properties? Candidates visible from here, each drawing a different circle:

formality and address conventions, which differ between all three and are the reason "warm without casual" is reached by different means in each
care-system vocabulary and pathway (remiss/henvisning, vårdcentral/fastlege), which changes what a patient is being told to do
regulatory and accessibility scope, which is national
payer and market position, which changes what the brand is arguing for
the language's own translationese profile, which is what filters/language-quality-* exists to hold

A decision that turned on the first does not reach a market that shares the fourth. Recording which one a decision turned on is the whole of the proposal.

Two open gaps _markets/README.md already names, restated as custody rather than tooling. There is no dependency wiring from a market page to the English page it derives from, and no staleness check when the English page moves. Under this document those are not missing scripts. They are the two obligations that make holding a market real, and they are the same two obligations _packages/README.md rule 6 records for packages and §10 records for shipped snapshots. One mechanism, three places waiting for it.

7. The language question, carried forward

Not in force. Carried from language-architecture-hypothesis.md (2026-08-21) with its evidence tiers intact.

What it challenges

The standing architecture decision from 2026-07-28 is that the corpus is LLM-first and English en-draft/ is the edit surface. National variants derive from it. The hypothesis is that this is right for one half of Brand OS and wrong for the other, and that the split is not currently drawn anywhere.

The split

Where an English core is sound. Tokens, component names, field labels, structure, the principles and the reasoning behind them. None of this is voice-bearing. Translating it is low-risk, and the internal-names convention already says these stay English so a reference resolves. No change proposed.

Where an English core is a problem. Voice, tone, and example copy. A brand voice defined in English and translated is not the same brand voice in three markets, whoever or whatever does the translating. Tone lives in register, formality gradient, sentence rhythm and what happens to be idiomatic, and none of those map across Swedish, Danish and Norwegian. Each market therefore drifts from the English source in its own direction, and the governance cost is that nobody can tell whether a Danish page is off-brand or simply Danish.

The proposed inversion, for the voice layer only

The native-language examples are the spec, not a derivative of it. A library of approved Swedish, Danish and Norwegian examples per page type is what the voice actually is. The English prose becomes a shared explanation of it — useful for alignment across the three countries, and not a source to translate from.

Consequences if adopted: three example libraries rather than one plus two translations; the three are not sentence-for-sentence equivalent, which is the point rather than a defect; and en-draft/ keeps its role for everything except the voice layer and the example library.

Evidence, separated by strength

Measured. Showing a model an English source text to render into another language increases the literal-translation bias. Giving it surrounding native-language context modestly reduces it. Idiomatic competence develops later in model training than grammatical competence, and instruction tuning on machine-translated data damages it while leaving syntax intact — so the output is grammatically clean and idiomatically wrong, which is the failure a generating pass cannot see. Sources in 2-areas/collaboration/swedish-language-rules.md.

Reasoned, not measured. That a translated voice diverges differently in each market. This follows from how tone works and from ordinary localisation practice, and there is no citation behind it here. It is the load-bearing claim and it is the unverified one.

Worth noting. The AI-translation effect is the smaller of the two problems. The larger one applies to human translators too, and would apply if no model were involved at all.

The test, and what it now answers

Take one page type that exists in all three markets. Have a native speaker in each mark up the current version against the English intent. Then compare the markups.

If the divergences are the same in all three, this is a translation-quality problem and better process fixes it. The standing decision holds.
If each market drifts its own way, the voice layer needs to be native-first and en-draft/ has to stop being its source.

The test answers a second question at the same time, and it is the more useful one. Read the three markups for what the reviewers reach for when they explain a divergence. If they say "that is not how we address people here", the property is formality convention. If they say "we do not have that step", the property is care-system pathway. If they say "that word is a Swedish loan", the property is the translationese profile. Whatever they reach for is the first real evidence of what a market boundary is made of, and it is the input the reach of every later market-scoped decision depends on.

Same reviewers, same page, no extra cost. The instrumentation is reading the markups for properties as well as verdicts.

8. Where observations arrive

Five routes, ranked by how well the system currently captures them.

Consumer builds — proven, and closest to working. BRAND-OS-FINDINGS.md in sundviktlakemedel, patientguide and aleris-assistant, with brand-provenance.json carrying expires_when per deviation. The last four to five package point releases came from this path. Three changes were made 2026-08-25 (cards 80–82): a fourth finding kind, new context, because several of the strongest entries are situations rather than missing values and the available box determines what survives; one field, what made this situation different; and a findings file installed in aleris-assistant, whose situation differs most from the other two. The carrying step is now a check at /wrap step 5c rather than a question, because a question asked every session becomes a question nobody hears.

Stakeholder conversation — highest value, weakest capture. The summons letter arrived this way. So did the two production tracks. _state.md is capped at twelve lines by design and is the wrong shape. workspace/status/observations.md is the destination as of 2026-08-25; whether that is enough is §13 question 3.

Native-speaker review — designed, not staffed. filters/language-quality-no and -dk are correctly empty. §9 treats that as a custody failure rather than an admin one.

Someone reading the corpus and finding nothing — F6 question 3. Added 2026-08-25. Previously the only line in F6 that asks something of the system, with no address to send it to. It goes to workspace/status/observations.md.

The brand assistant — the instrument already running, currently discarded. The site map calls the assistant the primary everyday interface: most people ask it rather than read the site linearly. Every question it cannot answer well is an observation that someone is in a situation the corpus does not cover, and it arrives with the person's own words for that situation attached, which is the field §4 says is hard to get. Nothing reads this today. Worth scoping as its own thing: what a logged unanswerable question would have to carry to be usable, and what the privacy position is on logging at all.

9. What holding a situation commits you to

Four obligations, each already visible somewhere in the corpus as an unmet gap.

1. Scope by property. Every decision scoped to a situation records what about the situation the answer turned on, not only which situation it was made in. This is the field the reverse query reads.

How a breach is detected. Not by whether the field is filled — a label fits in a property-shaped box, and "applies to the console" looks complete. The test is the one TAKS/doab.md already states for principles, 2026-05-14: "if the principle could plausibly have been written before the project started, it is confabulated." Applied here: could someone who was not in the situation have written this property? If yes, it is a name for the place, not a reason. sundviktlakemedel finding §7 passes — nobody outside that build writes the page renders before the built stylesheet is reachable. Checked by reading a sample, not by a script; there is no machine check and there may never be one.

2. A staleness relation to the core. When the core moves, what was derived from it is flagged. _markets/README.md §Open, _packages/README.md rule 6, and §10 below are three statements of the same missing mechanism.

3. An empty state that says it is empty. The no-fallback rule, generalised beyond markets. A situation the system has not observed shows as unobserved rather than inheriting a neighbour's answer, and inheriting is only allowed where a shared property is stated.

4. A named owner where judgement is required. Not every situation can be checked, so some need a person with standing to decide inside them. §10 requires verification method as a property of each node — automated, review, or unverifiable by design. This is the same requirement seen from the custody side.

The NO and DK reviewers are obligation 4 unmet. Two markets cannot be held at all until someone is named. filters/ says so on its own pages; _state.md has carried it under Blocked by for weeks. Parked on Torfinn's decision 2026-08-25 — not ready, and not an open action. Recorded here so the gap stays visible without reading as a task.

10. Representations — one decision, many copies

The other half of §2. Four consequences of documents being derived from the system.

Verification is uneven by medium, and that has to be designed in. Contrast is machine-checkable. A chair is not. Signage, lighting, upholstery and vehicle livery are verified by human review against a documented rule, and no amount of tooling changes that. So the graph cannot assume every node has an automated check. It needs verification method as a property of the node — automated, review, or unverifiable-by-design — otherwise the physical branches will read as gaps in coverage when they are a different kind of node. Getting this wrong would make the system look broken where it is merely non-digital, and that misreading would push effort toward the parts that are easy to test rather than the parts that matter.

Rules must be the nodes, not documents. If documents are derived from the system to explain and use it, then a change to the system has to reach its explanations. So the graph's job is not primarily which pages cite which. It is: given a decision, list every representation of it — and documents, tokens, comments, examples and packages declare which rule they represent.

Packages are dependents that have left the building. _packages/README.md rule 5 states the package table is the source of truth for versions, and "a Baseline change checks this list to know who is downstream." The concept is right and written down; what is missing is anything that performs the check. A shipped snapshot cannot be corrected in place. It can only be regenerated and re-sent, which means the check has to happen before sending, and the record of who holds what has to be accurate.

Historical, resolved. This section carried a sequencing flag from 2026-07-28: the vibe-coding repo brief must not ship agent-baseline v0.2 before the colour supersede landed, because the package held the retired hover Anchor, the wrong sRGB triplet for the brand orange, and the retired orange-400 token. The supersede landed and the packages were regenerated (cards 13, 14, 43, 51). The evidence that made the point stands: agent-baseline/MANIFEST.md recorded provenance in decided/fixed/anchor/active, the vocabulary the June ADR migration retired — a shipped package documenting its own contents in a status language the corpus no longer speaks.

The example library will drift the same way. A visual example or a motion graphic is a representation of a rule, so it is a dependent. An example can silently contradict the rule it exemplifies — the same class of failure as a token comment citing a retired Anchor, but harder to catch, because nobody greps an MP4. Any example added should declare which rule it exemplifies, so that retiring or changing a rule surfaces the examples that now misrepresent it. Cheap to establish now, expensive to retrofit once there are hundreds.

11. What it would take

Not in force — this is the unscoped half. Steps 1 and 2 are the expensive and the error-prone one respectively.

Make rules first-class nodes with an addressable identity, so representations can declare which rule they represent. This is the design work.
Add verification method to every node — automated, review, unverifiable-by-design. Prevents the physical branches reading as coverage gaps.
Derive the reverse index from the declarations. Small, once 1 exists.
Render it. The site already renders the corpus; a "represented in" list per rule is a display change.
Gate on it. Extend the handoff's integrity check: a rule cannot be retired or changed without its representations listed in the change, and the package table checked.
Situations as nodes, with the discriminating property recorded per decision rather than a taxonomy authored up front. Reach is computed from the property, not looked up from a hierarchy.
The reverse query as a deliverable rather than a byproduct. Given this artefact in this situation, what bears on it is what makes the graph worth building to anyone but its maintainer.
Findings-to-graph as the intake. Consumer findings are where new situations actually arrive. They should land as nodes rather than as prose someone re-reads and summarises later.

The contrast fitness check specced in the colour handoff §4c needs none of this and was done first. It verifies one class of claim directly from the token file, and it was the first instance of the system with tests half being real rather than asserted.

12. What this does not change

The standing decision that the corpus is LLM-first and English en-draft/ is the edit surface holds for everything outside the voice layer. Nothing here touches tokens, structure, field labels, component names or the internal-names convention.

F6 is unchanged and stays a stance. This document does not enumerate constants and does not propose to.

Nothing here proposes a taxonomy of situations authored up front. §5 is a record of boundaries met; §3 is the argument for why a designed taxonomy of relations between them would be wrong.

13. Open questions

What does a decision record have to carry for its reach to be computable? Testable now against decisions already made: the target-size ratification, the orange split into two roles, the hover Anchor retirement, the WCAG AA promotion. If the property can be recovered from each, the field is well defined. If it cannot, the graph would rest on a field nobody can fill.
Do situations get identity, or only properties? One with an addressable identity can be linked to and rendered. A set of properties cannot, but it also cannot be wrongly inherited. Probably both, with identity as a convenience over the properties, but this is undecided.
Is observations.md enough for stakeholder conversation, or does the highest-value route need something that fires during the conversation rather than after it?
What is the privacy position on reading the assistant's unanswered questions, and does that decision belong here or with the assistant?
Where do moments live? Board card 78. A moment — receiving a result — spans components and constrains their order, so it is not a pattern; whether it is a situation or a second thing beside one is open.

14. Next step

Parked: naming the NO and DK reviewers, and the three-market markup test that depends on it. Torfinn, 2026-08-25 — not ready, not an open action.

Live: §13 question 1, tested against the four decisions named there. It is smaller than the full graph and it decides whether step 6 rests on a field anyone can fill.

Relationship to other documents

principles/constant-and-contextual.md — F6, unchanged. It teaches a person to tell constant from contextual; this document is how the system learns what the situations are. §3 states where the two meet.
workspace/status/observations.md — where a situation lands before anyone decides what to do about it. This document is the model; that file is the ledger.
constitutional/a-thinking-tool-stays-a-thinking-tool.md — the rule that keeps F6 a stance rather than a checklist.
_markets/README.md and filters/_index.md — the only place a boundary is already held with rules, provenance and an empty state that says it is empty.
_packages/README.md — rules 5 and 6, the package table and the downstream check §10 depends on.
2-areas/collaboration/swedish-language-rules.md — the measured evidence behind §7.
TAKS/doab.md — the ledger this project's observations file is modelled on, and the source of the detection test in §9 obligation 1.