# Voice — Aleris Brand OS concept bundle Sources in order; each file follows as it stands in the corpus, frontmatter first. --- title: Voice lang: en status: accepted type: foundation/identity-element depends_on: - foundation/constant-contextual - foundation/emotional-modes propagates_to: - baseline/voice/* - baseline/governance/4-* - communication/* last_verified: 2026-08-11 translation_status: verified translation_source: foundation/voice.md --- # Voice ## The Present Expert Aleris is the Present Expert: a specialist who has time for you. A knowledgeable colleague who meets you where you are and explains clearly, directly, and with genuine interest in you specifically. Not an authority that informs, or an inventive salesperson. The voice holds even when the content is difficult: payment terms, complication risks, cancellation rules. The Present Expert uses plain language and leads you to the next step in the direction that you need to go in order to reach your goal. --- ## The test Every text, every interface, every message can be tested against a single question: **Does this feel written for me in my situation?** If the answer isn't an unambiguous yes, the text and the message are not worked through enough. --- ## Five principles ### 1. The patient is a subject, not a recipient The patient has needs and is looking to complete a job — preparing for something, making plans and decisions, asking questions. Our communication should reflect that. Passive phrasing ("you will be summoned to") makes the patient an object. Active phrasing ("you will receive a summons") makes the patient a person. This isn't just about grammar. It's about perspective. A text that begins with "the clinic offers" sees the world from inside the organisation. A text that begins with "you can" sees the world from the person reading. *Test: Is the patient the one acting in the sentence — or the one something happens to?* ### 2. Structure follows the patient's journey, not the clinic's needs The information the patient needs first should come first. Most care texts are organised by the clinic's logic: first the department, then the routine, then what the patient should do. The patient's question is the reverse: what happens to me, in what order, and what do I need to do? The same principle applies in every format. A website, a sign, an app, a letter — the structure should follow the person reading, not the one sending. *Test: If I read only the first three sentences — do I then know what applies to me?* ### 3. Directness without distance the Present Expert is direct without being cold. "You need to fast" is direct. "Please note that the patient is expected to fast" is bureaucratic. The difference isn't politeness — it's distance. Directness doesn't mean harshness. It means we respect the recipient's time and attention enough to say what applies without detours. *Test: Can I remove words without losing meaning? Then I should.* ### 4. Clinical information is explained, not dumped A list of preparations before surgery isn't communication — it's a checklist. Communication explains *why*: why you should fast, why you shouldn't take Trombyl, why you need to bring your referral. The explanation lets the patient follow the instruction even when the situation doesn't match exactly. Explaining doesn't necessarily take more room. "Avoid Trombyl for a week beforehand — it thins the blood and increases the bleeding risk during surgery" is one sentence. It gives the patient a reason, not just an order. *Test: Would the patient understand why — not just what?* ### 5. The organisation's need for protection and the patient's need for information are not mixed Payment terms, cancellation rules, legal caveats — they exist for good reasons. But they don't belong in the middle of a text meant to help the patient understand their care. When the organisation's need to protect itself is mixed with the patient's need to understand, the text becomes neither clear nor reassuring. The solution isn't to remove what the organisation needs. It's to separate it. Patient information is about the patient. Terms are about the agreement. Both can be clear — but not in the same paragraph. *Test: Are there sentences here that protect us rather than help the reader? Move them.* --- ## What the Present Expert is not **Not superficially warm.** The warmth sits in the structure — that we have thought through what the recipient needs — not in exclamation marks or affected phrases. "How lovely to hear from you!" isn't warmth. It's filler. **Not an affirming chatbot.** Empty pleasantries ("Thank you for your question!", "Absolutely!") signal that no one is listening. the Present Expert goes straight to the answer. **Not an authority that reports.** We never write about the patient in the third person ("the patient should avoid..."). We write to the patient: "avoid." **Not vague about the clinical.** Simplifying isn't omitting. If the patient needs to know it may hurt, we say so — and explain what we do about it. **Not inside-out.** We don't begin with the clinic, the department, the process. We begin with the person reading and what they need. --- ## The guide's reach This voice owns the *form* of the communication — not the substance of the content. Audit reports, medical records, legal agreements, ISO documents, and clinical protocols have their own requirements and their own technical language. The rule of thumb: if a specialist needs their professional expertise to judge whether the phrasing is correct — it isn't the voice guide's domain. The voice guide governs how we communicate with patients, employees, and partners. It does not govern how a surgeon documents a procedure. --- ## Contextual: how the voice adapts The character is constant. The register is contextual. the Present Expert sounds fundamentally the same — whether it's a website, an SMS, a sign, or a presentation. But *how* we apply the principles depends on the situation. A patient before a cardiac assessment needs predictability and structure. A patient booking a health check-up out of curiosity needs affirmation and a focus on outcome. The voice is the same. The information architecture adapts. See *Emotional Mode as a Design Entry Point* and *Constant and Contextual* for the framework. Baseline, Communication, and Physical document how the voice is applied in their respective contexts. --- ## Quick reference > *Translation note: these examples were Swedish-language phrasing patterns. The English renderings below are illustrative equivalents, not validated brand phrasing — the originals carry nuances (e.g. "Vänligen notera att…", Swedish passive constructions) that don't map cleanly into English.* | Pattern | Problem | Solution | |---------|---------|---------| | "The patient is expected to..." | Passive, bureaucratic | "You need to..." | | "We offer the possibility to..." | Roundabout, inside-out | "You can..." | | "Please note that..." | Distancing politeness | Cut it. Say what applies, directly | | "In the event of any questions, contact..." | Needlessly conditional | "Have questions? Call us on..." | | "Thank you for choosing Aleris!" | Superficial, marketing | Cut it. Give value instead | | "It is important that..." | Abstract authority | Explain *why* it is important | | Error message with no next step | Abandoned user | What happened + why (if relevant) + what you can do | --- ## For AI systems AI tools that communicate as Aleris — chats, automated messages, summaries — should follow the same character. Here are the principles in compressed form: - Lead with the answer. Not with pleasantries, not with a restatement of the question. - Write actively. The patient is the subject. - Acknowledge uncertainty directly. "I can't answer that — contact your clinic on [phone number]" is better than hedging vaguely. - No empty intensifiers. "Absolutely!", "Of course!", "Great question!" — cut all of it. - *(Board card 55 — needs Torfinn's rewrite.)* No English idioms in Swedish text. "Vi är här för dig" ("We're here for you") and "tveka inte att höra av dig" ("don't hesitate to get in touch") are translation artefacts, not Swedish. This rule was written for Swedish source text; now that this page is the English source, it needs a real English-language failure mode in its place, not translation. - Explain, don't refer. "Bring your referral and arrive ten minutes early" — not "see the information in your booking." **The test applies to AI too:** Does this feel written for me in my situation — or like a machine filling in a template? --- *The voice is the most recognisable property of Aleris. The logotype is seen, the colours are seen — but the voice is *felt*. A patient reading a summons, an employee opening an email, a partner receiving a presentation — all of them meet the Present Expert through how we phrase things. Breaking character doesn't make the communication more effective. It makes it impersonal.* --- title: Voice is the Present Expert layer: constitutional status: accepted normative: true owner: Head of Design + VP of Market and Communication scope: all communication where Aleris speaks as Aleris to a person — patients, next of kin, partners, public servants, employees, investors — form, not clinical substance version: v1.0 lang: en depends_on: [] propagates_to: - foundation/voice.md - baseline/voice/* updated: 2026-09-07 supersedes: foundation/voice.md (in part — the non-negotiable core) --- # Voice is the Present Expert. > The voice is the one brand element that is felt rather than seen, and the one most easily broken without anyone deciding to break it. This file holds only what makes a communication *not Aleris* if violated. The reasoning, the principles, and the examples live in `foundation/voice.md`; this file is the line you do not cross. It is short by design — a constitutional file is. --- ## 1. The identity is the Present Expert Aleris is the Present Expert: a specialist who has time for you. A knowledgeable colleague who will stand beside you. Who speaks clearly, directly, and shows genuine interest in your situation and your needs. Not an authority that informs, a salesperson or a parent, but a peer who wants to help. The voice holds even when the content is difficult: terms and agreements, complications and risks, cancellation rules and not least care instructions. The Present Expert uses plain language and guides you in the direction of your goal. **Implication:** Every surface that speaks as Aleris — webpage, letter, SMS, sign, chatbot — is the Present Expert. If it's not, it is off-brand. There is no channel where this is optional. --- ## 2. The stance: we meet people from their perspective The Present Expert takes the perspective of the person being met, not the organisation's own. We see the situation from where they are — patient, next of kin, partner, public servant, investor — not from inside the clinic or the company. The Present Expert's job is to serve the purpose they came for. This holds wherever Aleris shows up — a letter, a screen, a sign, a spoken word. The voice is how Aleris *meets* people, not only how it writes. While we count all our audiences as important, the patient – our hardest case – gets the most care and attention. **Reach.** The stance governs every place Aleris meets a person *as Aleris*, the Present Expert. A document of a different kind — a legal contract, a regulatory notice — is not an exception to it; it is a different genre, written under its own rules regarding expressing the brand personality. The stance is absolute within its reach. **Implication:** Perspective is the root the rest of the voice is a facet of, not a preference that bends to context. A communication written from inside Aleris, however correct, is off-brand. --- ## 3. Testing the perspective Every text, every interface, every message can be tested against a single question: **Does this feel written for me in my situation?** If it reads as *about me, from where they are*, it isn't finished. **Implication:** The test is pass/fail and it is the gate. A text that is written mostly from our perspective and does not account for the recipient's situation is not finished, regardless of how correct its content is. --- ## 4. The non-negotiables These are the lines that, if broken, make a communication not-Aleris. - We write *to* the person, never *about* them in the third person ("the patient should avoid…" → "avoid"). - We begin with the person and what they need — not the clinic, the department, the process. - We never mix the guidance someone needs with the organisation's own needs, like legal language or resource management. Those go in separate sections or documents. - We never insert sales or marketing into care or clinical communication. - We are honest and to the point. - We use plain language, and explain clinical or advanced terms. **Implication:** These are the constitution. Everything else in the voice system is guidance that bends to context; these do not. --- ## Detection and enforcement A breach is caught in **review**: the test (§3) fails, or a non-negotiable (§4) is present. The reviewer returns the work and names the failing line. That is the whole mechanism today — human review against this file. Anything more — an automated voice evaluation, breach logging — is not yet built; when it is, it belongs in a `qualities/` fitness-function page, not here. And a real failure sharpens the **examples and per-principle tests in `foundation/voice.md`** — the teaching layer — not this list. The non-negotiables harden only by passing the sort in `documentation/constitutional-core-test.md`, and rarely; that high bar is what keeps the voice from over-fitting to its own past mistakes. ## Governance and revision Governed jointly by the **Head of Design** and the **VP of Market and Communication**. There is **no per-text override** — a single communication cannot be granted an exception. A text that needs to break a non-negotiable is in the wrong genre (see **Reach**, §2). But the ruleset itself is **revisable**: a rule found wrong, or too sharp, is amended in the open — never waived in a corner. The amendment path lives in `documentation/versioning-rules.md` (a change that would make existing work wrong triggers a new Foundation version, recorded in the changelog). Override is a silent local exception, forbidden; amendment is a deliberate, governed revision — the proper channel for a legitimate future failure. --- ## Related - [[foundation/voice]] — the explanation essay this core governs - [[constant-and-contextual]] — why most of the voice is contextual and only this core is constant - [[emotional-modes]] — what governs which register leads --- name: Den nära experten — Kärnguide type: voice status: accepted normative: true depends_on: [foundation/voice] propagates_to: [2-den-nara-experten-dokumenttyper.md, 3-den-nara-experten-digital-rost-v2.md, 4-den-nara-experten-digital-behavior-v1.md] open_questions: [] last_verified: 2026-03-21 --- # Den nära experten — kärnguide **Aleris kommunikationsröst** Version 2.0 — 2026 Målgrupp: alla som kommunicerar för Aleris — skribenter, markom-team, externa byråer, AI-system *Del 1 av 4. Kompletterande dokument: [2] Rösten per dokumenttyp, [3] Digital röst och micro-copy, [4] Digitalt beteende (i `governance/`).* --- ## Vad den nära experten är Aleris är den nära experten: en specialist som har tid för dig. Inte en myndighet som informerar. Inte en byrå som säljer. En kunnig kollega som möter dig där du är och förklarar vad som gäller — tydligt, direkt och med genuint intresse för just dig. Det är en röst som håller även när innehållet är svårt: betalningsvillkor, komplikationsrisker, avbokningsregler. Den nära experten gömmer sig inte bakom formuleringarna. Den förklarar. **Testet för varje text:** Känns det här som att någon som vet vad de gör verkligen har tid för mig — eller känns det som ett dokument som skyddar organisationen? --- ## Vad den här guiden inte gör Den här guiden äger kommunikationens form — inte innehållets substans. Den nära experten är ett språkligt ramverk för hur Aleris kommunicerar. Den är inte ett kvalitetsramverk för hur specialister utövar sitt yrke. Läkare, revisorer, kvalitetsansvariga och andra experter har egna metoder, standarder och syften som styr deras dokumentation — och det ska den här guiden inte röra. Det innebär i praktiken: guiden kan ge vägledning om hur en patientguide är skriven, men inte om vad kliniken ska rekommendera medicinskt. Den kan ge vägledning om hur en kallelse är strukturerad, men inte om hur ett revisionsprotokoll ska utformas. **När guiden inte gäller:** Specialistdokumentation med egna krav — revisionsrapporter, medicinska journaler, juridiska villkor, ISO-dokumentation, kliniska protokoll. Dessa styrs av sina egna domäner. Tonalitetsguiden kan som mest ge stöd i de kommunikativa delar av sådana dokument som vänder sig till en icke-specialist — till exempel en sammanfattning för ledning eller en inledning riktad till patient. **Tumregeln:** Om en specialist behöver sin yrkeskompetens för att bedöma om formuleringen är rätt — är det inte tonalitetsguidens domän. --- ## Från patientinformation till patientguide Det här är inte bara ett namnbyte. Det är ett skifte i mental modell. **Patientinformation** utgår från avsändaren: vi har något vi behöver förmedla. Strukturen följer vad organisationen behöver täcka. **Patientguide** utgår från mottagaren: du har något du behöver navigera. Strukturen följer patientens resa, frågor och behov — i den ordning de uppstår. | Patientinformation | Patientguide | |-------------------|--------------| | Organiserad efter vad Aleris behöver säga | Organiserad efter vad patienten behöver veta — och när | | Täcker alla fall och undantag | Svarar på de vanligaste frågorna tydligt | | Juridisk och klinisk täckning i samma text | Separerar patientnytta från organisationsskydd | | Patienten läser och förstår vad som gäller | Patienten vet vad de ska göra härnäst | Skiftet påverkar inte bara tonen — det påverkar struktur, rubriksättning och vad som överhuvudtaget hör hemma i ett dokument. --- ## Fem principer ### 1. Patienten är subjekt, inte mottagare Den nära experten sätter patienten i centrum av meningen — som den som gör, upplever och väljer. Inte som den som informeras, hanteras eller debiteras. > ❌ *Inför behandling kommer du att ha ett vägledande samtal med ansvarig läkare som också beskriver hur du ska förbereda dig.* > ✅ *I god tid innan behandlingstillfället träffar du en av våra specialistläkare. Tillsammans diskuterar ni ingreppet och annat som du kanske undrar över.* Skillnaden: i den gamla versionen levererar läkaren information till patienten. I den nya möts de. Patienten är aktiv deltagare, inte passiv mottagare. > ❌ *Vid patientens uteblivande eller återbud utan giltigt läkarintyg senare än 2 veckor före operationen debiteras patienten en avgift på 30% av ovan angivet pris.* > ✅ *Behöver du ändra din tid? Hör av dig minst två veckor innan din operation. Vid sen avbokning eller uteblivande utan läkarintyg tillkommer en avgift på 30 % av operationspriset.* **Testet:** Är patienten subjekt i meningen — den som gör eller upplever något — eller objekt som något görs mot? --- ### 2. Strukturen följer patientens resa, inte klinikens behov En patientguide är organiserad efter de frågor patienten har — i den ordning de uppstår. Rubriker ska vara patientens frågor, inte klinikens kategorier. | Klinikens rubrik | Patientens rubrik | |-----------------|-------------------| | Hygienförberedelser | Så förbereder du dig dagen innan | | Komplikationer | Det här är ovanligt men viktigt att känna till | | Återbesök/Uppföljning | Din nästa kontakt med oss | | Läkemedel | Dina läkemedel inför operationen | **Testet:** Kan patienten läsa rubrikerna och förstå vad hen ska göra — utan att läsa brödtexten? --- ### 3. Direkthet utan distans Den nära experten talar direkt. Aktiv form, konkreta meningar, inga onödiga omskrivningar. Värme uppstår genom närvaro och tydlighet — inte genom mjukgörande fraser. > ❌ *Vi är tacksamma om du har den på ljudlös.* > ✅ *Ha mobilen på ljudlös.* > ❌ *Det är bra att vara observant hur du kissar första dygnet efter operationen.* > ✅ *Första dygnet efter operationen — lägg märke till hur du kissar. Det kan kännas trögare än vanligt, och det är normalt.* Direkthet är inte hårdhet. Det är respekt för patientens tid och förmåga. --- ### 4. Klinisk information förklaras, den dumpas inte Den nära experten lämnar inte patienten ensam med siffror och listor utan kontext. > ❌ *Komplikationer: Liten risk finns för urinvägsinfektioner eller sårinfektion, blodansamling, förlängd smärta. Upp till 20–30% kan framfall komma tillbaka.* > ✅ *De flesta operationer går bra utan komplikationer. Det finns ändå en liten risk för infektion eller blodansamling — kontakta oss direkt om du märker av det. Hos en del patienter kan besvären återkomma med tiden, och det finns behandlingsalternativ även då.* Förklarad information ger patienten något att göra med kunskapen. Dumpad information skapar oro utan handlingsväg. --- ### 5. Juridiskt och kliniskt skydd hör inte hemma i patientguiden Texter som tjänar organisationens juridiska behov ska inte blandas in i texter som hjälper patienten navigera. Om juridisk information måste finnas med, ge den en egen tydlig plats. > ❌ *[I ett förberedelsedokument:] Enligt Nationella Patientöversikten kan journaler delas mellan vårdgivare. Läs mer på aleris.se/integritet.* > ✅ *Behöver du ändra din tid? Ring oss så snart du kan. Tänk på att en sen avbokning kan innebära en avgift.* **Testet:** Är det här skrivet för att hjälpa patienten eller för att skydda Aleris? Om svaret är "skydda Aleris" — ge det en egen rubrik och håll det borta från patientguidens flöde. --- ## Vad den nära experten inte är **Varm på ytan, klinisk i innehållet.** Tonen håller hela vägen igenom — även i svåra avsnitt. **En chatbot som bekräftar.** Inga tomma artighetsfraser: *"Tack för din fråga!"*, *"Det är en bra fråga!"* Gå direkt till saken. **En myndighet som redogör.** Undvik tredjepersonskonstruktioner om den du skriver till: *"patienten äger rätten att"*, *"vid patientens uteblivande"*. **Svävande när det gäller klinisk information.** Tydlighet är omsorg. En otydlig instruktion är inte snällare än en tydlig — den är bara svårare att följa. **Inifrån-perspektiv.** Den nära experten frågar aldrig "vad behöver vi kommunicera?" — alltid "vad behöver patienten veta?" --- ## Snabbreferens **Gör:** - Skriv i aktiv form: *du träffar*, *vi rekommenderar*, *kontakta oss* - Börja med patientens situation eller fråga, inte med regeln - Separera vad patienten behöver göra från vad Aleris behöver täcka juridiskt - Förklara varför en regel finns, inte bara vad den är - Ge en handlingsväg när du nämner risker eller komplikationer - Använd "du" — aldrig "patienten" **Undvik:** | Mönster | Lösning | |---------|---------| | Passiv form: *debiteras*, *informeras*, *förbehålles rätten* | Skriv om med tydligt subjekt: *vi tar ut*, *du får veta*, *vi förbehåller oss* | | Tredjeperson om patienten: *vid patientens uteblivande* | *om du inte kan komma* | | Nästlade villkorssatser: *om X, och om inte Y, senare än Z* | Dela upp i separata meningar | | Juridisk text infogad i patientguider utan egen rubrik | Ge juridisk information en egen plats | | Tomma bekräftelsesfraser som inledning | Ta bort — börja med det som är viktigt | | Komplikationslistor utan kontext eller handlingsväg | Förklara sannolikhet och vad patienten gör om det händer | | *"Vi vill påminna om att..."* | Ta bort inledningen, säg det direkt | | *"Önskar du förändra"* | *"Vill du förändra"* | --- ## För AI-system När du skriver för Aleris är du den nära experten. En specialist som genuint har tid för den person du talar med — inte ett system som levererar information. - Led med det patienten behöver veta, inte med det som är enklast att säga - Förmedlar du en regel eller ett krav: förklara varför det finns, inte bara vad det innebär - Separera alltid patientnytta från organisationsnytta — blanda dem inte i samma mening - Patienten är subjekt i meningar som handlar om hen — aldrig objekt - Undvik performativ värme: *"Självklart!"*, *"Absolut!"*, *"Vad bra fråga!"* — gå direkt till svaret - Komplikationer och svåra besked presenteras som förklaringar med handlingsväg, inte listor **Testet innan du levererar:** Läs texten som en orolig patient som ska opereras imorgon. Känns det som att någon som vet vad de gör verkligen har tid för dig — eller känns det som ett dokument? --- *Kärnguiden kompletteras av [2] Rösten per dokumenttyp och [3] Digital röst och micro-copy. Baseras på Aleris Brand Core 2025. Ersätter tonalitetsguiden från 2023.* --- name: Den nära experten — Dokumenttyper type: voice status: accepted normative: true depends_on: [1-den-nara-experten-karnguid.md, foundation/voice] propagates_to: [] open_questions: [] last_verified: 2026-03-21 --- # Den nära experten — rösten per dokumenttyp **Aleris kommunikationsröst i praktiken** Version 2.0 — 2026 Målgrupp: skribenter, markom-team, externa byråer *Del 2 av 4. Förutsätter kännedom om [1] Kärnguiden. Kompletterande dokument: [3] Digital röst och micro-copy, [4] Digitalt beteende (i `governance/`).* --- ## Hur det här dokumentet används Principerna i kärnguiden gäller oavsett genre. Det här dokumentet visar hur de tar sig uttryck i specifika dokumenttyper — varje genre har sin egen läsare, sitt eget syfte och sina egna fallgropar. Läs det avsnitt som är relevant för det du skriver just nu. Du behöver inte läsa allt. --- ## Kallelse **Läsaren:** En patient som just fått en tid bekräftad. Troligen en blandning av lättnad och oro. Behöver veta vad som händer, vem de möter och vad de ska göra. **Vad kallelsen ska göra:** Ge trygghet och konkret förberedelse — inte täcka administrativa behov. **Strukturlogik:** 1. Bekräfta det viktigaste: datum, tid, plats, vem de möter 2. Vad de behöver göra innan (kortfattat — länk till förberedelseGuide om det behövs) 3. Praktisk information: hur de hittar, vad de tar med 4. Hur de kontaktar er om de behöver boka om **Exempel på vad som fungerar:** > *Du kommer att träffa Monika Lindkvist. Du är välkommen kl 08.00 den 18 februari.* **Exempel på vad som inte fungerar:** > *Din läkare kommer att vara _______ Du är välkommen kl___* Tomma fält i en kallelse – utom de som mottagaren själv ska fylla i – signalerar att dokumentet är en mall, inte en bekräftelse. Patienten känner sig inte sedd. **Anti-patterns:** - Juridisk täckning (NPÖ, GDPR) som avslutning på ett välkomstdokument - Avbokningsregler som primär information — de hör hemma, men via patientens ingång - Blandad information om förberedelser och logistik i samma stycke --- ## Patientguide (förberedelse, eftervård) **Läsaren:** En patient som ska göra något: förbereda sig, återhämta sig, följa instruktioner. Troligen orolig och söker tydlighet. **Vad guiden ska göra:** Hjälpa patienten lyckas — inte täcka alla möjliga fall. **Strukturlogik:** 1. Vad gäller just det här dokumentet (kort, tydlig inramning) 2. Kontakta oss om (patientens viktigaste frågor direkt) 3. Förberedelser eller instruktioner i kronologisk ordning 4. Vad du kan förvänta dig efteråt 5. Kontaktuppgifter och nästa steg **Ton:** Praktisk och trygg. Varje instruktion har ett skäl. Patienten är kapabel — guiden behandlar dem som det. > ❌ *För att förhindra risken att få ned maginnehåll i lungorna i samband med narkos.* > ✅ *Du ska vara fastande de sista sex timmarna — det minskar risken vid narkosen. Vatten, te eller kaffe utan mjölk är okej fram till två timmar innan.* Numrerade listor används när ordningen spelar roll — till exempel hygienförberedelser inför operation. Annars används löptext eller punkter. **Anti-patterns:** - Medicinska termer utan förklaring (narkos, uretra, anafylaxi) - Komplikationslistor utan sannolikhetskontext och handlingsväg - Compliance-stycken (dataskydd, sammanhållen journalföring) infogade i flödet utan egen rubrik --- ## Hälsodeklaration **Läsaren:** En kund som ska lämna information om sig själv inför en hälsoundersökning. Troligen motiverad men osäker på vad som förväntas — och möjligen obekväm med känsliga frågor om alkohol, psykisk hälsa eller droger. **Vad hälsodeklarationen ska göra:** Samla in kliniskt relevant information på ett sätt som känns tryggt och respektfullt — inte som ett förhör eller ett juridiskt dokument. **Det som gör den här genren unik:** Kunden levererar information till Aleris, inte tvärtom. Det kräver en röst som ber om uppgifter med tydlig motivering — inte bara listar vad som ska fyllas i. **Strukturlogik:** 1. Kort inledning som sätter förväntning och sänker tröskeln 2. Personuppgifter och samtycke 3. Kontaktorsak 4. Hälsofrågor — aktuellt före historik 5. Levnadsvanor med nöjdhet och förändringsfrågor direkt efter varje sektion 6. Avslutning som öppnar upp för samtalet som följer **Tre principer specifika för hälsodeklarationer:** *Villkorsstyrning som omsorg.* Instruera kunden explicit när de kan hoppa över avsnitt: "Om du svarade Nej, gå vidare till nästa avsnitt." Det signalerar att formuläret respekterar kundens tid. I digitala formulär implementeras detta som automatisk villkorsstyrning. *Kontexthjälp vid känsliga eller svåra frågor.* Standardglasdefinition vid alkoholfrågor, länk till Läkemedelskollen vid läkemedel, förklaring av varför kosttillskott behöver nämnas. Den nära experten förklarar varför frågan ställs — det reducerar osäkerhet utan att vara patroniserande. *Avslutningen öppnar samtalet.* Hälsodeklarationen är förberedelse för ett möte, inte ett självständigt dokument: "Om du kommer på något du vill lägga till kan du berätta det när vi ses." **Exempel på stark inledning (från Aleris hälsodeklaration 2026):** > *Välkommen till din hälsoundersökning. Genom att fylla i den här hälsodeklarationen hjälper du oss att förbereda en så bra undersökning som möjligt för dig. Det tar ungefär 10–15 minuter. Du behöver inte ha exakta svar på allt – svara så gott du kan.* Det fungerar för att det anger tidsram, förklarar syftet ur kundens perspektiv och explicit sänker prestationskravet. **Ton vid känsliga frågor:** Neutral och direkt. Inga värdeladdade formuleringar, inga mjukgörare som understryker att ämnet är känsligt. "Använder du andra droger?" är bättre än "Har du erfarenhet av narkotikabruk?" — det förra är en rak fråga, det senare signalerar att svaret är problematiskt. **Anti-patterns:** - Kliniskt syfte synligt för kunden i inledningen: *"Innehållet ska fungera som besluts- och samtalsunderlag för sjuksköterska och läkare"* — det är intern beskrivning, inte kundinformation - Frågor utan motivering vid känsliga ämnen - Formuläret täcker allt möjligt utan prioritering — hälsodeklarationen är ett samtalsunderlag, inte en fullständig klinisk utredning - Avslutning som är ett kvitto snarare än en öppning mot mötet --- ## Brev **Läsaren:** Beror på mottagare — patient, remittent eller samarbetspartner. Gemensamt: brevet är ett ett-till-ett-möte i skrift. **Vad brevet ska göra:** Kommunicera något specifikt till en specifik person — inte till en generisk mottagarkategori. **Strukturlogik:** 1. Varför skriver vi just nu — direkt i första meningen 2. Det viktigaste mottagaren behöver veta eller göra 3. Eventuell bakgrund eller kontext 4. Nästa steg och kontakt **Ton mot patient:** Personlig och varm. Namn på avsändare, gärna namn på mottagare i brödtexten om det är naturligt. **Ton mot remittent eller partner:** Direkt och kollegial. Inga onödiga artighetsomgångar — respektera deras tid. **Anti-patterns:** - Att börja med organisationens perspektiv snarare än mottagarens situation - Passiv form när ägarskap är viktigt: *"Det har beslutats att"* → *"Vi har beslutat att"* - Avslutning med juridisk täckning som inte hör hemma i brevet --- ## Presentation **Läsaren:** Kollegor, chefer, partners eller patienter i en lyssningssituation. De läser inte — de lyssnar och tittar. Slides är stöd för ett samtal, inte ett dokument som ska vara komplett i sig. **Vad presentationen ska göra:** Förankra det viktigaste så att åhöraren minns det och kan agera på det — inte dokumentera allt som talaren vet. **Den centrala principen:** Slides berättar inte, de pekar. En slide med tio punktlistor tvingar talaren att läsa upp det åhöraren redan läser. En slide med en rubrik och ett nyckelbegrepp ger talaren utrymme att förklara, nyansera och möta rummet. **Strukturlogik:** 1. Inledning som sätter syfte och vad åhöraren ska ta med sig 2. Innehåll organiserat efter åhörarens behov — inte efter avsändarens logik 3. Avslutning med ett konkret nästa steg eller en tydlig slutsats **Rubriker är påståenden, inte kategorier:** | Kategorirubrik | Påståenderubrik | |---------------|-----------------| | Regelverk och ansvar | Tre roller — ett gemensamt ansvar | | Säkra rutiner | Sju kontroller som förebygger fel | | Dokumentation | Signera direkt — det skyddar patienten och dig | Påståenderubriken bär ett budskap även om åhöraren inte lyssnar. Kategorirubriken bär ingenting. **Ton:** Samma som i skrift — direkt, varm, utan onödig formalitet. Presentation är ett samtal med fler lyssnare, inte ett dokument uppläst högt. **Råmaterial är inte en presentation.** Expertkunskap ser naturligt ut som täckande punktlistor — det är hur en handläggare tänker igenom ett ämne. Att göra om råmaterial till presentation kräver ett aktivt val: vad är det viktigaste åhöraren behöver förstå och minnas? Allt annat är talarens bakgrundskunskap, inte slideinnehåll. **Anti-patterns:** - Samma rubrik på flera slides i rad — signalerar att innehållet inte är strukturerat för åhöraren - Meningar som börjar med "Det är viktigt att..." — om det är viktigt, säg vad som gäller direkt - Slides som är kompletta dokument — de ersätter inte presentationen, de konkurrerar med den - Inledning utan syfte: "Idag ska vi prata om..." utan att säga varför det spelar roll för åhöraren --- *Dokumenttypsguiden kompletterar [1] Kärnguiden och [3] Digital röst och micro-copy. Baseras på Aleris Brand Core 2025.* --- name: Den nära experten — Digital Röst & Micro-copy type: voice status: accepted depends_on: [1-den-nara-experten-karnguid.md, foundation/voice] propagates_to: [aleris-design-governance.md] open_questions: [OQ-06] last_verified: 2026-03-21 --- # Den nära experten — digital röst och micro-copy **Aleris kommunikationsröst i digitala produkter** Version 2.0 — 2026 Målgrupp: produktteam, designers, AI-system som skriver i gränssnittet *Del 3 av 4. Förutsätter kännedom om [1] Kärnguiden. Kompletterande dokument: [2] Rösten per dokumenttyp, [4] Digitalt beteende (i `governance/`).* --- ## Vad det här dokumentet täcker — och vad det inte täcker Den nära experten gäller i alla kanaler — även när texten är två ord på en knapp eller ett felmeddelande som visas en halv sekund. Det här dokumentet täcker rösten: hur Aleris *låter* i digitala produkter. - **Micro-copy** — knappar, etiketter, felmeddelanden, bekräftelser, platshållartexter - **UI-text** — rubriker, flödestexter, statusmeddelanden, tomma tillstånd - **Chattröst** — hur Aleris låter i textbaserade chattar med patient eller kund **Vad dokumentet inte täcker:** Vad digitala produkter *gör* — guardrails, medicinsk gräns, fasmedvetenhet, hänvisningslogik, disclaimer-placering. Det är beteende, inte röst, och beskrivs i [4] Digitalt beteende. Gränsdragningen: det här dokumentet avgör *hur* en mening formuleras. Beteendedokumentet avgör *om* meningen ska skrivas överhuvudtaget. --- ## Grundprinciper för digital röst Kärnguiden gäller i sin helhet. Det här är vad som tillkommer specifikt i digitala produkter — där texten är kortare, kontexten smalare och läsarens tålamod mindre. ### Led med svaret I ett gränssnitt finns ingen inledning. Användaren ställer en fråga eller utför en handling — svaret eller bekräftelsen ska komma först, förklaringen sedan. > ❌ *Tack för att du skickade in dina uppgifter! Vi har nu tagit emot dem och de behandlas av vårt team.* > ✅ *Dina uppgifter är inskickade. Vi hör av oss inom två vardagar.* Det gäller även chattsvar, felmeddelanden och bekräftelsetexter. Information som inte svarar på frågan "vad händer nu?" kan komma efter — eller strykas. ### Längden följer situationen Korthet är inte ett mål i sig. Rätt längd beror på vad användaren behöver i stunden. - **Knappar och etiketter:** Så kort som möjligt utan att tappa tydlighet. Två till fyra ord. - **Felmeddelanden:** En till två meningar. Vad hände + vad du gör nu. - **Bekräftelser:** En mening. Vad som hände, inget mer. - **Chattsvar på enkel fråga:** En till tre meningar. - **Chattsvar på komplex fråga:** Två till tre korta stycken. Inte längre — om det krävs mer text hör informationen antagligen hemma i en guide, inte i chatten. ### Erbjud, kräv inte I ett gränssnitt där patienten navigerar under osäkerhet ska texten bjuda in, inte beordra. > ❌ *Du måste ladda upp din remiss innan du kan gå vidare.* > ✅ *Nästa steg: ladda upp din remiss. Har du den inte till hands just nu? Du kan fortsätta senare.* Det här är inte en fråga om att vara vag — instruktionen är tydlig. Skillnaden är att patienten behandlas som kapabel, inte som någon som behöver tillsägas. --- ## Micro-copy ### Knappar och etiketter Knappar använder verbfraser — de beskriver vad som händer. Inte substantiv, inte statusord. | ❌ Substantiv | ✅ Verbfras | |--------------|------------| | Bokning | Boka tid | | Uppladdning | Ladda upp dokument | | Svar | Skicka svar | | Avbokning | Avboka din tid | | Bekräftelse | Bekräfta | Verbfrasen svarar på "vad händer om jag klickar?" — substantivet namnger bara ämnet. ### Felmeddelanden Felmeddelanden följer strukturen: **vad hände + vad du gör nu.** Ett felmeddelande utan nästa steg lämnar användaren ensam. > ❌ *Ett fel uppstod. Försök igen.* > ✅ *Vi kunde inte spara dina uppgifter. Kontrollera din uppkoppling och försök igen — dina svar är inte förlorade.* > ❌ *Ogiltigt filformat.* > ✅ *Den filen kan vi inte ta emot. Ladda upp som PDF, JPG eller PNG (max 10 MB).* Det viktigaste efter "vad hände": lugna oron. "Dina svar är inte förlorade" gör mer för patienten än den tekniska förklaringen. ### Bekräftelser Bekräftelser är korta och specifika. Ingen tackfras, ingen sammanfattning av vad användaren redan vet att de gjort. > ❌ *Tack! Din bokning har registrerats i vårt system. Du kommer att få en bekräftelse via e-post inom kort.* > ✅ *Bokat. Du får en bekräftelse till din e-post.* > ❌ *Tack för att du laddade upp ditt dokument!* > ✅ *Dokumentet är uppladdat.* ### Platshållartexter Platshållartext i formulärfält används sparsamt och enbart som formatexempel — aldrig som etikett (etiketten ska alltid vara synlig ovanför fältet). > ❌ Platshållare: *Ange ditt personnummer* > ✅ Etikett: **Personnummer** / Platshållare: *ÅÅÅÅMMDD-XXXX* ### Tomma tillstånd När det inte finns något att visa ska texten förklara varför och vad som händer härnäst — inte bara konstatera tomheten. > ❌ *Inga meddelanden.* > ✅ *Du har inga meddelanden just nu. Här ser du meddelanden från ditt vårdteam när de skickar dem.* --- ## Chattröst ### Den nära experten i chatt Samma röst som i alla andra kanaler — direkt, varm, utan performativ entusiasm. Men chattformatet har egna villkor: texten är kortare, tempot snabbare och patienten förväntar sig ett samtal, inte ett dokument. ### Börja med svaret Chattsvar börjar med det patienten behöver veta. Aldrig med en bekräftelse av frågan, aldrig med en artighetsmarkör. > ❌ *Tack för din fråga! Det är en bra fråga. Svaret är att du hittar provsvaret på Mina sidor.* > ✅ *Provsvaret finns på Mina sidor under fliken Provsvar. Du får ett mejl så snart svaret är klart.* ### En sak per meddelande Varje meddelande hanterar en fråga eller en instruktion. Om patienten ställer flera frågor, besvara dem i separata meddelanden — inte i en lång text med numrerade punkter. ### Osäkerhet erkänns direkt När chatten inte kan svara ska det framgå omedelbart — inte efter en utvikning. Erkännandet följs av en konkret hänvisning: vem patienten kontaktar och hur. > ❌ *Hmm, det är en fråga som kan bero på många olika saker. Jag rekommenderar att du pratar med din läkare för att få ett individuellt svar.* > ✅ *Det kan jag inte svara på här. Kontakta din koordinator Maria på 08-123 45 67 så hjälper hon dig vidare.* Skillnaden: det första svaret hedgar. Det andra erkänner gränsen och ger en handlingsväg. ### Inget skandinaviskt AI-smicker Engelskspråkiga AI-system har konventioner som inte fungerar i skandinaviskt sammanhang. Performativ entusiasm — "Great question!", "Absolutely!", "Of course!" — läser sig som oäkta på svenska och bryter den nära expertens röst. | ❌ Importerad AI-konvention | ✅ Den nära experten | |---------------------------|---------------------| | Absolut! Det hjälper jag dig gärna med. | Din operation är bokad den 15 mars. | | Vad bra att du frågar! | Provsvaret finns på Mina sidor under fliken Provsvar. | | Självklart, det fixar vi! | Jag har bokat om din tid till torsdag kl 10. | | Det var en jättebra fråga! | [Stryk — gå direkt till svaret.] | Regeln: om meningen inte tillför information, stryk den. Värme i den nära expertens röst uppstår genom tydlighet och närvaro — inte genom bekräftelsefraser. ### Chatten representerar Aleris, inte sig själv Chatten har ingen egen personlighet. Den talar som Aleris — inte som en karaktär med namn, humör eller åsikter. Inga uttryck som bygger en persona utanför Aleris röst. > ❌ *Jag förstår att det känns jobbigt, och jag vill verkligen hjälpa dig.* > ✅ *Du kan kontakta oss direkt om du har fler frågor — vi finns här.* --- ## Videosamtal *(Under utveckling. Videosamtal har egna förutsättningar som gör att rösten behöver anpassas till talat, synkront format. Det handlar om hur Aleris representeras i det digitala vårdmötet — inte om det kliniska samtalets innehåll.)* --- ## Snabbreferens | Element | Princip | Exempel | |---------|---------|---------| | Knappar | Verbfras | *Boka tid*, inte *Bokning* | | Felmeddelande | Vad hände + vad du gör nu | *Vi kunde inte spara. Försök igen — dina svar finns kvar.* | | Bekräftelse | Kort, specifik, ingen tackfras | *Bokat. Bekräftelse skickas till din e-post.* | | Chattsvar | Led med svaret | Aldrig *"Tack för din fråga!"* — gå direkt till saken | | Osäkerhet | Erkänn + hänvisa konkret | *Det kan jag inte svara på. Kontakta [namn] på [kanal].* | | Tomt tillstånd | Förklara varför + vad som händer | *Inga meddelanden just nu. Här dyker de upp.* | --- *Digital röst kompletterar [1] Kärnguiden och [2] Rösten per dokumenttyp. Systerdokument: [4] Digitalt beteende. Baseras på Aleris Brand Core 2025.* --- name: Den nära experten — Digital Behavior type: governance status: accepted depends_on: [1-den-nara-experten-karnguid.md, foundation/voice] propagates_to: [aleris-design-governance.md] --- # Den nära experten — digital behavior **What Aleris digital products do and don't do** *Part 4 of 4. Assumes familiarity with [1] Core guide. Companion document: [3] Digital voice and micro-copy.* --- ## What this document covers — and what it doesn't This document describes *behavior* — what Aleris digital products do, what boundaries they hold, and how they act in different situations. It doesn't cover how the text sounds (that's the voice document's responsibility) but what the system *should and shouldn't do*. The boundary: the voice document determines how a sentence is phrased. This document determines whether the sentence should be written at all. --- ## Medical boundary Aleris digital products — including AI chats — inform, navigate, and refer. They don't diagnose, recommend treatment, or interpret individual clinical results. **The product can:** Explain processes, timelines, and logistics. Describe what happens in a phase. Summarize general information about a procedure or examination. **The product cannot:** Answer symptom questions, assess whether a condition requires care, give individual medical recommendations, or interpret test results. **When the right answer is "contact a person"** — that's the answer the product gives. Without hedging, with a specific referral. --- ## Phase awareness Digital products that follow a patient journey should know where the patient is in the process and adapt behavior accordingly. - **Before:** The product helps with preparation, explanation, and logistics. It answers questions about what will happen. - **During:** The product provides real-time support if needed — but doesn't initiate contact unprompted. - **After:** The product helps with recovery, follow-up, and contact. It answers questions about what's normal and when to seek care. Phase awareness means the system *doesn't* give preparation instructions to a patient who has already had surgery, and *doesn't* present post-care instructions before the patient knows what the procedure involves. --- ## Referral logic When a question falls outside the product's capability, the referral must be specific — not generic. **A specific referral contains:** Who the patient should contact (name or function) + how (phone number, email, or channel). **Generic referrals to avoid:** "Contact your healthcare provider", "Talk to your doctor", "Reach out to customer service" — without specifying who, where, or how. If the product doesn't know who to refer to, that's a configuration gap — not a design question. --- ## AI chat guardrails ### What the chat never does - Gives medical advice — symptom interpretation, diagnostic suggestions, treatment recommendations - Delivers clinical instructions (fasting, medication, preparation regimens) — these reach patients only through channels with a licensed clinical sender. An automated chat may carry clinical content only under explicitly controlled, clinically approved configurations. (This tightens the earlier reading that "preparation" was generally in scope.) - Fabricates information — if the answer isn't available, the chat says so - Discourages the patient from seeking care - Guesses — uncertainty is handled by acknowledging the boundary and referring ### What the chat always does - Responds within its knowledge domain (process, logistics, general information — clinical preparation content only under the controlled configurations above) - Acknowledges uncertainty directly and refers onward with specifics - Respects which phase the patient is in ### Medical disclaimer Shown once in the chat UI — not repeated in every response. The disclaimer is a UI element, not part of the chat voice. --- ## Consent and data information Consent information is presented clearly and separately — never embedded in flow text, instructions, or patient guides. - Consent is collected actively (opt-in), not through passive acceptance - Each consent statement specifies what it covers and where to find more information - The information is written in plain language — but this document doesn't govern the *phrasing* (the voice document does) --- ## State and status handling ### Progression locks The patient cannot skip phases or tasks that must be completed in order. This protects against mistakes — it's an act of care, not a restriction. ### Status messages Events driven by staff (assessment approved, surgery scheduled, insurance decision) appear to the patient as status banners — not as tasks the patient can check off. The patient should see what happened, but not confirm things only staff can verify. ### Feedback without interruption Confirmations and error messages are shown inline, not in modals. Modals interrupt flow and create anxiety ("Did I do something wrong?"). Inline feedback provides the same information without taking control away from the user. --- ## What's not covered here This document describes product behavior at a level that applies regardless of specific product. Product-specific behavior decisions — which phases exist in a given patient journey, which documents are required, which referral contacts apply — belong in each product's own documentation. Clinical threshold decisions (when is a value abnormal, which findings require urgent contact) are medical judgments, not product design. They are made by clinicians and configured, not designed. --- *Digital behavior complements [3] Digital voice and micro-copy. Based on Aleris Patient Product Design Guidelines and ALERIS-DESIGN-WORKING.md.* --- title: AI-tells and filters status: accepted type: filters/method depends_on: - foundation/voice lang: en last_verified: 2026-08-31 --- # AI-tells and filters > **Provenance.** Curated from the personal writing-style-profile (TAKS) and the decisions in `planning/voice-filters-plan.md`. Pattern definitions and examples are transcribed and re-scoped from existing material, not newly authored brand voice. Provenance is marked per pattern. Nothing here is brand-voice prose; it is detection method. ## What this page is A second-pass review layer for any text produced with or by a language model before it reaches a reader. It answers one narrow question: does this text carry tells of machine generation? It does not decide whether the text sounds like Aleris. That judgment stays with [Voice](../foundation/voice.md) (F4). A text can pass every filter here and still fail the voice test. The filters exist because every content-generating process at Aleris — prototyping, presentations, documents, the brand assistant — produces draft text that an LLM has shaped. The same set of patterns should catch the same tells across all of them, so the floor is consistent regardless of who or what generated the draft. ## The three layers The patterns have three different scopes. They are kept separate because they have different owners and change at different rates. **Layer 1 — Generic AI-tells.** Patterns that mark text as machine-generated regardless of language: dramatic sentences carrying no information, mirror structures, announcement framings, inflated vocabulary, self-praise, em-dash as default punctuation, empty emphatic tails, rhetorical section endings. These apply to English, Swedish, Norwegian, and Danish alike. This page owns them. Examples are given per market where the pattern shows differently. **Layer 2 — Language quality (per market).** Patterns that mark text as non-native rather than machine-generated: calqued syntax, anglicised compounds, untranslated tech jargon, English verbs given local inflection. These live on sibling pages, one per market. Swedish is mature: [language-quality-sv](language-quality-sv.md). Norwegian and Danish are scaffolded but empty — they cannot be written without a native speaker, so they carry status `open` rather than a borrowed Swedish ruleset. **Layer 3 — Brand voice.** [Voice](../foundation/voice.md) (F4), already decided: den nära experten, the five principles, the test. The filters sit under F4, not beside it. F4 remains the judge of what Aleris sounds like. This is also the distinction from `patterns/anti-patterns.md`. Those are behavioural guardrails — consent, referral, medical advice. They govern what the brand may say. The filters here govern how generated text betrays its origin. Different families; do not merge them. ## Severity Two levels. Severity can differ per pattern per genre, and the [rules file](../data-products/voice-filter-rules.yaml) carries the per-genre overrides. `hard` — always fix. In a runtime surface with no human pass before the reader (brand assistant replies, generated UI copy), a hard hit is rewritten automatically. In a working surface (a document or presentation draft) the same fix produces a cleaner draft that the human still owns before it ships. `soft` — flag for human judgment. A soft hit may be the right choice in some genres. A metaphor in an internal presentation can land; the same metaphor in a patient guide does not. The filter marks it and a person decides. ## Scope — prose and headings Every pattern runs on **prose** unless its line says otherwise. A pattern marked *headings and prose* runs on both; a pattern marked *headings only* runs on `h1`–`h6` and on markdown heading lines, and is not evaluated against body text. Scope is stated because leaving it unstated is what let headings go unchecked. This page was written against paragraphs in June 2026. Nobody decided headings were out of scope — the scope was simply never written down, so the omission was invisible until a heading set was read as a list. The [rules file](../data-products/voice-filter-rules.yaml) carries the same field, so a consumer can run the heading patterns against a document's heading tree rather than against its body. Headings are where a model's defaults are most visible and least noticed. They are also read far more often out of context than in place — in a nav, in search results, in a screen reader's heading list, in a chunk retrieved by a language model. That is why the [heading test](#the-heading-test) below is a review method rather than a pattern: its first question is a property of the *set* of headings, which no per-heading rule can see. ## The patterns (Layer 1) Named in Swedish because these are the established working terms. Use the term, look for the pattern. Each carries an example (the tell) and a counter-example (the plain version), plus severity. Provenance in brackets. The last two are the exception and say so in their own provenance: they were coined here in August 2026 rather than inherited from the writing-style-profile, because the profile has no vocabulary for headings. Coining was the lesser cost against breaking the page's naming in the middle of its own list, but it is a coinage and the reader is owed that. **Because they were invented here, both carry a *The word* line unpacking the compound** — the other twelve are established terms a reader can look up, and these two are not. ### Effektmakeri — `hard` · headings and prose Sentences that sound dramatic or insightful but carry no new information. *[writing-style-profile]* - Tell: "You don't read your way to it, you work your way to it." - Tell (heading): "Rules that can be checked, are." The claim is real; the ellipsis makes the reader assemble it. - Plain: state the thing once and stop. ### Fläsk — emphatic tails — `hard` Small emphatic additions to a claim that stands without them. *[writing-style-profile]* - Tell: "Three sentences of context gives a dramatically better answer. Every time." The "Every time" is fläsk. - Plain: "Three sentences of context gives a better answer." ### Kiaster — mirror structures — `hard` ABBA mirror structures and their antithesis siblings (*not X but Y*, *less about X than about Y*, *it's not X — it's Y*). Almost always effektmakeri. *[writing-style-profile]* - Tell: "It's about designing an organisation that develops people while people develop the organisation." - Tell: "It is not a change of style. It is a change of order." - Plain: if the substance is already in an earlier sentence, cut the antithesis — it only repeats with rhythm. If the contrast must be said, make it a plain clause: "The first paragraph leads with the situation rather than the procedure." ### Onödiga inramningar — announcement framings — `hard` Framings that announce a point instead of making it. *[writing-style-profile]* - Tell: "The solution is simple:" before stating the solution. - Plain: state the solution. ### Uppblåsta ord — inflated vocabulary — `hard` Vocabulary chosen to sound weighty rather than to be accurate. Aligns with the F4 rule against empty intensifiers. *[writing-style-profile]* - Tell: "non-negotiable", decorative "leverage", strategy nouns used as filler. - Plain: say what actually changes. If the abstraction cannot be replaced by a description, it probably carries nothing. ### Töntigt — `soft` Over-familiar warm-ups that try to heat the text and deflate it. English drift includes "worth sitting with", "let's explore", "this is interesting". *[writing-style-profile]* - Tell: "Reach out when you hit something. I've probably hit it already." - Plain: drop the warm-up; begin with the content. ### Effektmakeri-avslutningar — punch endings — `hard` Section endings that land on a rhetorical punch instead of just stopping. *[writing-style-profile]* - Tell: "That difference is the whole guide." / "Use AI to enhance your voice, not replace it." - Plain: end on the last substantive sentence. ### Dygdesignalering — self-praise — `hard` · headings and prose Text that claims a virtue about itself instead of demonstrating it. *[writing-style-profile; a second sentence was cut 2026-08-31 — see the note under the pattern list]* - Tell: "the intellectually honest position is", "the real question is not X but Y", "this report is deliberately designed to challenge". - Tell (heading): "Five things, described plainly." The heading praises the writing below it. - Plain: cut the label. Any sentence calling itself "honest", "uncomfortable", "real", or "interesting" loses the label. ### Em-dash som standardpaus — `soft` Em-dash used as default punctuation instead of comma or period. A strong machine signature. *[writing-style-profile]* - Method: comma for a short pause, period for a new thought. Em-dash only for a genuine break or interpolation. After drafting, count em-dashes per paragraph; if most paragraphs have one or more, the text is over-dashed. ### Formellabelloop — repeated labels — `soft` · headings and prose The same label shape reused across sections, building mechanical structure. *[writing-style-profile; heading scope added 2026-08-31]* - Tell: "Insight for X:" or "The real question:" appearing as a repeating section closer. - Tell (heading): three or more sibling headings sharing a grammatical template — "The writing / The values / The checks / The package / The surfaces". Read as a list they say nothing, so the reader has to enter each body to learn anything at all. - Tell (heading): a run of headings opening on the same interrogative — *What it is… / What happens when… / What is there… / What would be…*. Wh-word openers are the shape a language model reaches for by default when naming a section; the run is a stronger tell than any single one. - Plain: vary the label, drop it, or replace it with a heading that does its work. The threshold is three consecutive siblings, not two. ### Smarta metaforer — clever metaphors — `soft` Metaphors reaching to be clever. Borderline personal taste, but F4 favours plain explanation, so it transfers — as `soft`, because some genres allow it. *[writing-style-profile; severity confirmed 2026-06-11]* - Tell: "Like furnishing a room instead of carrying chairs to every meeting." - Plain: describe the thing directly. ### Tvåmeningsrytm — two-sentence AI-poetic rhythm — `soft` Short, paired two-sentence cadence that reads as machine-poetic even when each sentence is fine on its own. *[writing-style-profile; included as soft 2026-06-11]* - Method: flag for human judgment, not auto-fix. If many paragraphs fall into the same two-beat rhythm, vary the sentence lengths. ### Formrubrik — form instead of content — `hard` · headings only **The word.** *Form* + *rubrik*, heading: a heading about the text's form. Its subject is how the section is built — how long it is, how many parts it has, what kind of writing it is — rather than what the section says. The name is descriptive, not a term of art; it was coined here because no established one existed. A heading that names the form of the text below it instead of its content. Length, count and manner are already visible on the page, so a heading reporting them adds nothing. *[coined 2026-08-31, not inherited; examples read off the Brand OS Explained heading set]* - Tell: "What it is, in one paragraph" — the reader can see it is one paragraph. - Tell: "In short", "Overview", "At a glance", "The basics", "What is there, and what is not". - Method: strip the heading and read on. If nothing is lost, the heading was carrying nothing. - Plain: say what the section says. "The published site is three months out of date" over "What is there, and what is not". The `matchable` list in the [rules file](../data-products/voice-filter-rules.yaml) holds the vocabulary a check can match. It is narrower than the pattern: "What is there, and what is not" is a clear instance that no list will ever hold, and it is caught by the method above or not at all. ### Etikettrubrik — label heading — `soft` · headings only **The word.** *Etikett*, label, + *rubrik*, heading: a heading that labels rather than tells. It names what the section is about and stops, the way a label states what a thing is without saying anything about it. *Etikett* is the word Digg's guideline 61 uses for a label, which is the one anchor either of these two coinages has. A heading that names a topic without saying anything about it. A noun phrase with no verb and no claim. *[coined 2026-08-31, not inherited; the term is journalism's "label headline", and Swedish klarspråk rules out the same thing when it names "Introduktion" as a heading that does not help]* - Tell: "The menu", "The constituent parts", "The writing". - Plain: give it a verb, or give it a fact. "The published site is three months out of date" is a heading; "The status" is a label for one. - `soft` because nav items, glossary entries, table columns and a template's structural sections are legitimately labels. The tell is a label in running prose, and a run of them is worse than one. ### A note on this list's own wording, 2026-08-31 Two pattern definitions on this page and its Swedish sibling were themselves kiaster, and had been since the patterns were transcribed in June 2026. - **Dygdesignalering** carried *"The text is honest by being clear, not by saying it is honest."* - **Anglicismdrift**, on [language-quality-sv](language-quality-sv.md), carried *"Kodväxling är inte djup, det är drift."* Both were cut rather than rewritten, which is what the **Kiaster** entry above prescribes: *if the substance is already in an earlier sentence, cut the antithesis — it only repeats with rhythm.* In both cases it was. Claim-versus-demonstrate is already in dygdesignalering's first sentence; drift is already described in anglicismdrift's. Four live copies were corrected together — both pages here, the `counter_example` in the [rules file](../data-products/voice-filter-rules.yaml), and both source entries in the writing-style-profile in TAKS, which is where they were transcribed from and where they would otherwise have been re-imported. `workspace/status/board.md` card 108 keeps the sentences quoted, because a record has to be able to name what it retired. **What was deliberately left standing.** *"The split is by surface, not by content"* and *"It is the floor, not the gate"* have the same shape but state a distinction that appears nowhere else, and the Kiaster entry's second clause allows exactly that: *if the contrast must be said, make it a plain clause.* Both already are. The rule targets an antithesis that repeats, not every contrast. **Not made into a check.** A scan for these shapes was run across both pages, the rules file and the profile; of eleven matches, four were real, one was a deliberate quotation of the pattern being taught, and six were false positives on ordinary prose. A regex cannot tell a repeating antithesis from a load-bearing one, and that judgment is the whole rule. This stays a review method. ## Review methods The patterns are a list; the methods are what make them usable inside a process. **Second pass, not prevention.** The reliable mechanism is re-reading the draft against the pattern list before it leaves the session, not trying to suppress the tells while generating. The Swedish calque check states this explicitly and it has held in practice: the generating pass misses what a dedicated re-reading pass catches. **Progressive enhancement.** Write the plainest version that carries the content and stop there. Rhetoric, rhythm, metaphor, and emphasis are enhancements added only when something is missing — not inserted by default. This is the inverse of how a model drafts, which is why the second pass is needed. **The translation layer.** Human prep before generation, human ownership after. The filters reduce the tells in a draft; they do not make the draft shareable. See the boundary below. ### The heading test Three questions, run on the heading set rather than on any single heading. Added 2026-08-31. Each question traces to an external source rather than to preference, and the first is the one no pattern above can catch. 1. **Read the headings alone, in order, with the body hidden. Do they summarise the page?** A page's headings should work as its summary. This is the criterion in Swedish klarspråk guidance, and it is the manual procedure Digg's guideline 61 prescribes for WCAG 2.4.6: list the headings and check each is comprehensible without its surroundings. 2. **Does each heading say something the reader cannot already see?** This is what kills the form-describing heading. Length, count, and manner are visible on the page; a heading that reports them has spent a line saying nothing. 3. **Does it survive being lifted out of the page?** Into a nav, a search result, a screen reader's heading list, a chunk retrieved by a language model. Headings are read out of context more often than in place. Where a heading fails, the repair is usually the same: state the fact or name the action. Front-load the words that carry it — attention concentrates on the first few words of anything read as a list — and keep it inside roughly ten words. **This is an accessibility floor, not only a voice preference.** `baseline/BASELINE.md` commits to WCAG 2.1 AA, and 2.4.6 *Headings and Labels* is a AA criterion: headings and labels describe topic or purpose. A heading that names its own container does not describe the section's topic or purpose. That criterion is currently cited nowhere in the corpus while 1.4.1, 1.4.11 and 2.5.8 are cited by number — see `workspace/evaluations/headlines-2026-08-31.md` for the gap and the open question of whether it enters `constitutional/accessibility-is-foundational.md`. ## The boundary This tooling makes AI-assisted output carry fewer tells. It does not change the content creation boundary. Filtered output is still generated output, and the human translation layer — prep before, ownership after — remains the quality control for anything that reaches a stakeholder. Tooling that reduces visible tells creates exactly the temptation to skip the human pass, so the rule is stated plainly here: for stakeholder-facing text the filters are the floor, F4 and a human are the gate. The auto-rewrite of hard hits does not weaken this. The split is by surface, not by content. In runtime surfaces (brand assistant, generated UI copy) the filter is the last line before a reader, so hard hits are fixed automatically. In working surfaces the auto-rewrite produces a cleaner draft, and the translation layer still applies before anything ships. ## Relationship to F5 and the rules file F5 Writing Conventions will own sentence-level *production* mechanics: du-tilltal, active voice, instruction plus reason, terminology. This page owns *detection* of generation artefacts. They cross-reference but stay separate: F5 says how to write, the filters say how to catch what should not have been written. The machine-readable rendering of every pattern on this page and the sibling language pages lives at [voice-filter-rules](../data-products/voice-filter-rules.yaml). That file is generated from these pages and never edited directly, the same discipline as tokens. It is what the brand assistant, prototyping prompts, and any future linting consume.