# AKRIBIS Brand

> The source of truth for the identity of AKRIBIS, its nine units and AKRIBIS One: the decided rules, and the files and data generated from them, at stable addresses on https://brand.akribis.group. Anything a site shows comes from here.

Generated 2026-10-07 from the repository that builds the site. The site is a map of 29 topics in 5 sections: 1 ratified, 21 proposed, 7 open. A topic is open until a decision record (ADR, MADR 4.0.0, in English) decides it; "proposed" means a complete proposal is on the page and awaits the decision. Pages exist in Spanish (/es/), English (/en/) and Portuguese (/pt/); this file carries the English rules. Every file below is rebuilt on each build from the same source as the pages, so a page and a file never disagree.

## How a site or a tool uses this

- Link `/tokens/base.css`, `/tokens/type.css`, `/tokens/shape.css` and then `/tokens/<brand>.css` (one of the brand ids below). Style only with the roles they define (`--color-*`, `--type-*`, `--size-*`, `--space-*`, `--radius-*`, `--duration-*`, `--focus-*`), never with a hex, a size, a spacing or a duration of your own.
- To show another brand inside a page, wrap the element in `data-brand="<brand>"` and link `/tokens/all.css`: the roles resolve to that brand inside it.
- Every site renders light; dark comes with the brand file only on request: `data-theme="dark"` on the root element, set by the theme toggle and remembered in the cookie `akribis-theme` (ADR-0037). Never follow `prefers-color-scheme`.
- Marks are files under `/marks/<brand>/`: `<brand>-wordmark-{colour|ink|white}.svg` (with clearspace), `-tight.svg`, `-inline.svg` (currentColor), PNG at 512, 1024 and 2048; `favicon.svg`, `favicon.ico`, `apple-touch-icon.png`, `icon-192.png`, `icon-512.png`, `icon-maskable-512.png`, `site.webmanifest`; `<brand>-avatar.svg` and `-avatar-ink.svg` with PNG at 400, 800 and 1200. AKRIBIS One adds `akribis-one-ring-*` and `akribis-one-lockup-{ring|dot|letters|stacked}-*`. `/manifest.json` lists every file with its size.
- Write as `/voice.json` says: impersonal; usted (es), você (pt) or you (en) only when the reader must be addressed; buttons from its CTAs, terms from its glossary, and a claim only as its register words it, never beyond the credential in force. Icons come from `/icons/` only.
- Never set a unit's name in type instead of its wordmark; never recolour, stretch or respace a mark; never pick a colour that is not a role or a step.
- `/tokens.json` is the same system as the CSS in DTCG format; `/units.json` is the register (`/units.schema.json` its schema); `/strings.json` the shared strings; `/fonts/fonts.json` describes the fonts; `/tokens/contrast.json` is the contrast proof.
- An AKRIBIS site is built with `@akribis/site` (ADR-0031): one Astro integration, `akribis({ brand, kind, site })`, sets the languages, the token CSS, the shared 404 and robots.txt, the sitemap and the checker; its components are the patterns of the anatomy; its `starter/` folder is a site as it begins. Download it from `/packages/index.json`. A site keeps no copy of a token, a font, a mark or a pattern.

## Rules by topic

### 1. Foundations

What every decision is judged against, who we are and how we speak.

#### 1.1 Criteria (ratified; ADR-0009)

https://brand.akribis.group/en/foundations/criteria/

Question: What is every brand decision judged against, and in what order?

Rules:
- 1. Trust of a regulated buyer: every claim traceable, every document auditable.
- 2. One coherent, expandable family: ten members that read as one company and can be told apart; an eleventh can join without breaking the system.
- 3. Register: a precise scientific-instruments maker; never a software start-up, never a consumer brand.
- 4. Accessibility: WCAG 2.2 AA is the floor on every surface; APCA is reported and decides when the two disagree in a way that matters.
- 5. Works beyond the screen: print, Office and documents are first-class.
- 6. Recognition: what people already recognise changes by the smallest amount the criteria above require: the letterforms; AKRIBIS's teal; AKRIMET's orange; SOLFARMA's blue, more loosely.
- 7. Three languages: Spanish (es-AR), Portuguese and English, each first-class.
- 8. Open licences: typefaces and tools every unit and site may use without a per-seat cost.
- 9. Generated and tested: values come from code and data in this repository; a rule that cannot be checked in the build is not a rule yet.

#### 1.2 Brand architecture (proposed; ADR-0010)

https://brand.akribis.group/en/foundations/architecture/

Question: How do AKRIBIS the company, AKRIBIS the unit, the nine units and AKRIBIS One present themselves when they appear together?

Settled:
- AKRIBIS is both the parent brand (the company, at akribis.group) and the instrumentation and equipment unit (at akribis.info).
- AKRIBIS One is a commercial offer that packages the units into one productised solution. It is neither the parent brand nor the corporate entity.
- There are nine business units. Each can still be sold on its own.
- Every unit presents itself as "Una unidad de AKRIBIS One" (ADR-0005).
- The nine units form three categories of three: Product (AKRIBIS, AKURALAB, AKUTEMP), Service (AKRIMET, SOLFARMA, AKLEIA) and Hard Service (AKZOTEC, SINGULAR4, AKIoT). In a 3 × 3 grid the categories are columns; in a circle, the established clockwise order with AKRIBIS at the top centre; in a line, the same cycle opened at AKLEIA (ADR-0010).

#### 1.3 Naming (proposed; ADR-0032)

https://brand.akribis.group/en/foundations/naming/

Question: How is each name written, in text, in web addresses, in files and in every language?

Settled:
- Unit names are written, in order of preference: all capitals (AKRIBIS, AKURALAB, AKUTEMP, AKRIMET, SOLFARMA, AKLEIA, AKZOTEC, SINGULAR4, AKIoT); all lowercase; initial capital only when truly necessary.
- AKIoT keeps a lowercase "o", because it refers to IoT.
- SOLFARMA is one word. Never "SOL FARMA" or "Sol Farma".

Rules (proposed):
- In running text, headings and buttons the names are in capitals (AKRIBIS, AKURALAB, AKUTEMP, AKRIMET, SOLFARMA, AKLEIA, AKZOTEC, SINGULAR4, AKIoT); all lowercase only where the mark is lowercase or a design asks for it; an initial capital only where capitals would shout (a legal text, a long list). The names do not change in English or Portuguese.
- The parent is AKRIBIS Group; the offer is AKRIBIS One, two words and a capital O, never with the lockup's middle dot: "AKRIBIS · One" set in type is a redrawn mark. The endorsement is "Una unidad de AKRIBIS One" (ADR-0005), never "Parte de".
- Identifiers: the brand id is lowercase ASCII (akribis, akuralab, akutemp, akrimet, solfarma, akleia, akzotec, singular4, akiot, akribis-group, akribis-one), the same in file names, CSS files, data-brand, the register and the repositories; the Workers drop the dot (akrimetcom). Files follow ADR-0028: <brand>-<piece>-<colourway>[-<variant>].<format>.
- Addresses: under the URL grammar of ADR-0025 (lowercase ASCII, hyphens, a trailing slash) the shared pages are called, in Spanish, English and Portuguese: home /; contact: contacto, contact, contato; thank-you: gracias, thank-you, obrigado; privacy: privacidad, privacy, privacidade; legal notice: aviso-legal, legal-notice, aviso-legal; the 404 is one file at the root. They live in anatomy.json; the site package reads them, so no site types a slug; the checker verifies that each exists in every language. A site's own slugs follow the same grammar, translated, without accents.
- The check: standards.yaml lists the spellings that are never written (SOL FARMA, Sol Farma, AKIOT, Akiot, AKRIBIS · One, AKRIBIS ONE, Akribis One, Parte de AKRIBIS, among others); the checker's naming rule reads every page's visible text and fails the build on one. What quotes a wrong form as an example says so with data-naming="quoted"; code is skipped.

#### 1.4 Unit register (open)

https://brand.akribis.group/en/foundations/unit-register/

Question: What is the single record of each unit that every site and document reads from?

Settled:
- AKRIBIS · Instrumentación y Equipamiento · medir
- AKURALAB · Equipamiento para Laboratorios · analizar
- AKUTEMP · Cadena de Frío y Equipamiento Térmico · controlar
- AKRIMET · Metrología, Calificaciones y Validaciones · calibrar
- SOLFARMA · Calificación y Validación Farmacéuticas · validar
- AKLEIA · Consultoría en Ciencia Reguladora · regular
- AKZOTEC · Ingeniería, Automatización e Instalación · construir
- SINGULAR4 · Software e Inteligencia de Datos · modelar
- AKIoT · IoT Industrial · monitorear
- AKRIBIS One · sinergizar

Open questions:
- Areas and verbs in Portuguese and English.
- Which facts each record holds (domain, contacts, WhatsApp, countries, accreditations), each with its source.
- Accreditations, with status and evidence. For example: four sites claim AKRIMET's ISO/IEC 17025 as current, while akribis.info says it is in progress.
- How the record reaches the sites and Wagtail, which today hard-codes eight units.

#### 1.5 Voice and messaging (proposed; ADR-0033, ADR-0038)

https://brand.akribis.group/en/foundations/voice/

Question: How does AKRIBIS sound, and what may it claim?

Settled:
- AKRIBIS One's lines: "Sinergizando conocimiento y tecnología" and "Nueve especializaciones. Un equipo."
- Addressing the reader: usted, impersonal by default. Decided by Demian Montes de Oca, 2026-10-06.
- Claims: for now only what can be verified with documentation or provider information is stated. Decided by Demian Montes de Oca, 2026-10-06.
- A partner's text: what is copied verbatim from a partner (Vaisala) and attributed is exempt from the voice and claims rules, which govern AKRIBIS's own words; naming and every other rule still apply. The package draws it inside data-source="partner" (ADR-0038). Decided by Demian Montes de Oca, 2026-10-07.

Rules (proposed):
- AKRIBIS One's lines in English and Portuguese (proposed, 2026-10-05): "Synergising knowledge and technology" and "Nine specialisations. One team."; "Sinergizando conhecimento e tecnologia" and "Nove especializações. Uma equipe.". A literal translation: One's verb is "synergise" in the three languages (unit register); British spelling and Brazilian Portuguese, like the rest of the site. They live in the register (lines) and each site shows its language's pair.
- Addressing the reader: impersonal by default. Buttons as plain verbs ("Request a quote"), the rest in the third person or the first person plural. When the reader must be addressed: usted in Spanish, você in Portuguese, you in English. Never voseo or tú: voseo reads as local outside Argentina and tú as informal; usted is the B2B norm across the region and in Spain. akribis.info today mixes the two almost half and half.
- Languages: Río de la Plata Spanish is the source text; Portuguese is Brazilian and English international with British spelling. Portuguese and English are adaptations a native speaker writes or reviews with the glossary; nothing machine-translated is published without that review.
- Register: precision before effect; short sentences, one idea each; exact technical terms; one thing, one name; no urgency, superlatives or promises; numbers, dates and units through Intl and the SI. The seven principles are in voice.json.
- Claims: only what can be verified with documentation is stated, AKRIBIS's own (a certificate, a contract, a register, an audit) or the provider's published information for what concerns its product. Every claim of scope, quantity, accreditation, legal status, performance or client sits in the voice.json register with its source, status (current, in progress, no source) and date; without a record it is not published. Recognition, accreditation and certification are different: AKRIMET holds OAA Level I Recognition (RE-016) with ISO/IEC 17025 accreditation in progress, and the checker refuses "17025 vigente", "accredited laboratory" and their equivalents. Clients only with written permission; never comparisons with competitors.
- Glossary and calls to action: one term per language for each concept (measurement, calibration, traceability, measurement uncertainty, monitoring…) with the words it replaces, and eight canonical calls to action in the three languages. Names, standards and technical acronyms are never translated.
- The endorsement in English and Portuguese, "A unit of AKRIBIS One" and "Uma unidade da AKRIBIS One", and AKRIBIS One's lines in both languages stand as proposed in the register.
- The check: standards.yaml lists, per language, the voseo and tú forms and the inflated phrases, and the claim wordings that say more than the credential in force; the checker reads every page's visible text and fails the build on one.

### 2. Identity

Marks, colour, type and imagery. They are decided together, because each depends on the others.

#### 2.1 Parent brand (proposed; ADR-0011, ADR-0014, ADR-0017, ADR-0019)

https://brand.akribis.group/en/identity/parent-brand/

Question: What does AKRIBIS the company look like, as distinct from AKRIBIS the instrumentation unit?

Settled:
- The parent mark is "akribis group", composed from the glyph library with the system's word space (ADR-0011).
- Its colour is the deep teal: the wheel's teal slot (204°) at L 0.44, #005e65, which coincides with the delivered AKRIBIS teal. The company keeps the colour already recognised; the unit takes the signature tone, step 500 (ADR-0014). Published in colour, ink and white at /marks/akribis-group/.
- Stacked version: "akribis" over "group", centred, by the same rule as the stacked AKRIBIS One lockup (ADR-0019, amendment). Published in the three colourways; it is the one inside the circle of the black-and-white profile picture.

#### 2.2 AKRIBIS One mark (proposed; ADR-0011, ADR-0012, ADR-0016, ADR-0017, ADR-0019)

https://brand.akribis.group/en/identity/akribis-one/

Question: How is AKRIBIS One drawn, what colour is it, and how does it endorse the units?

Settled:
- "one" is set from the glyph library, in the same construction as "akribis" (ADR-0011).
- The ring derives from the letters: diameter = x-height, stroke = stem / 3, dot = one stem wide. The ring lockup is primary; dot and letters-only are alternatives by use; the stacked one sets "akribis" over "one", centred and without the ring (ADR-0012, amended by ADR-0019). All four are published at /marks/akribis-one/.

Rules (proposed):
- A colour of its own (ADR-0016, proposed): the AKRIBIS hue at ramp step 950, the teal ink (#002f34). Three marks called AKRIBIS, one hue, three steps: the unit at 500, the company at 800, One at 950. No free slot of the wheel is spent. It is the tone akribis.one already used as its "deep teal-ink" (#0e2a2e, ΔE 1.9 away).
- The spectrum: in the colour version, the ring is one continuous, closed gradient through the nine signatures in hue order, AKRIBIS at the top centre, clockwise with rising hue, in equal shares (40° each), interpolated in OKLCH along the shorter hue arc. In SVG it is drawn as 360 one-degree arcs; in CSS it is --one-spectrum (conic-gradient in oklch). Letters and dot take the teal ink.
- One dot: the ring's centre dot, the dot lockup's separator and the favicon's dot are the same size, one stem wide (radius = stem / 2), like the i's dot.
- Geometry set once and used everywhere: brand/marks/ring.yaml holds proportions (of the stem and the x-height), not measurements; units.json and manifest.json publish the numbers and the fractions of the diameter (stroke 8.77 %, dot 26.32 %), and base.css exposes them as --one-ring-stroke and --one-ring-dot.
- Colourways: colour (teal ink + spectrum), ink and white, for the ring and the four lockups; tight, with clearspace, inline (currentColor) and PNG at 512, 1024 and 2048. Icons (ADR-0017): the ring in white on the teal ink, solid in favicon.svg and .ico and with the spectrum from 64 px up.
- The spectrum appears only in the ring, and in at most one signature element per page; never as a background, a wash or decoration. Below 24 px, the solid ring.
- Roles on One's site: signature 950, accent 800 (the structural teal akribis.one already uses), hover 900, active 950; in dark, signature 200, accent 300.

#### 2.3 Unit wordmarks (proposed; ADR-0008, ADR-0017, ADR-0019)

https://brand.akribis.group/en/identity/wordmarks/

Question: Are the nine wordmarks one consistent design, and how are they used?

Settled:
- The nine wordmarks are one type design, measured letter by letter in the original files. They are composed from one glyph library on a shared grid, with one spacing table (ADR-0008).

Rules (proposed):
- The nine wordmarks are composed from one library of 19 glyphs (a b c e f g i k l m n o p r s t u z 4), drawn on a shared grid: x-height 500, baseline at 750, box 1000. No wordmark is drawn by hand.
- Each glyph exists once. Every letter was measured in all nine original files: every occurrence of a letter is the same outline (distance ≤ 0.05 units at scale 1), so the library takes each letter from a file exported at scale 1 and well placed.
- Spacing follows one table of side bearings per glyph, fitted on the six originals that agreed with each other (AKRIBIS, AKURALAB, AKUTEMP, AKZOTEC, SOLFARMA, SINGULAR4), except SINGULAR4's i→n and n→g, which sat outside the family's rhythm; glyphs built the same way share bearings (n as m, g as o). AKRIMET, AKLEIA and AKIoT, which were spaced differently, take the table.
- Clearspace: half the x-height on all four sides. The files carry it; the "tight" version does not, and exists to align baselines in layout.
- Minimum size (proposed): x-height of 10 px on screen and 3 mm in print.
- Colourways: ink and white. Each unit's own colour is set with the colour system (2.4), and the on-dark versions with its ramps.
- Never: stretch, outline, add effects, change the spacing, set the name in type instead of the wordmark, or use versions older than this one.
- Favicons and app icons (ADR-0017): tile in the signature; in white, the mark's letters from the library at its own spacing: "ak" for the ak- units and the parent, "sf" for SOLFARMA, "s4" for SINGULAR4, at one scale on every tile (the widest pair spans 72 %); AKRIBIS One carries the ring (60 % of the tile) and the AKIoT platform its cloud (70 %). Rounded square (radius 22 %) where nothing crops; full-bleed square where the platform masks, its letters fitted by their ink to the 80 % safe circle (ADR-0019), which is also the profile picture. Published with a site.webmanifest per brand; the AKIoT app under /marks/akiot/app/.
- A new unit is composed from the same library. Missing letters are drawn to the recorded construction (stem widths, overshoots, terminals) and added to the library with their bearings.

#### 2.4 Colour (proposed; ADR-0013, ADR-0014, ADR-0015, ADR-0016)

https://brand.akribis.group/en/identity/colour/

Question: What colour is each brand, and how does colour behave on screen, in print and in shared contexts?

Settled:
- The nine signatures are generated from a 12-slot wheel (every 30°, three free) and one lightness grid: the signature at step 500 (L 0.635, at least 3:1 on white) and the same hue as text at step 600 (L 0.55, the highest at which all nine reach 4.5:1); chroma up to 0.20: AKRIBIS 204°, AKURALAB 174°, AKUTEMP 234°, AKRIMET 54°, SOLFARMA 264°, AKLEIA 84°, AKZOTEC 24°, SINGULAR4 354°, AKIoT 294° (ADR-0013).

Rules (proposed):
- A unit has a hue: its slot on the wheel, in OKLCH degrees, in the unit register. Its colours are generated: the step's lightness, the highest sRGB chroma up to the cap. Nobody picks a hex by hand.
- One hue, two jobs, one step apart: the signature (step 500) is the mark and large graphics, at least 3:1 on white; brand-coloured text and controls use step 600, at least 4.5:1. On a tinted surface (band, soft), text goes one further step down (700).
- A new unit takes a free slot (114°, 144° or 324°) and gets its signature from the same calculation.
- AKRIBIS One takes the AKRIBIS hue at step 950, the teal ink, and carries the nine signatures as one continuous spectrum in the ring, and nowhere else (ADR-0016, proposed). Three marks called AKRIBIS, one hue, three steps: 500, 800, 950.
- The parent mark takes the AKRIBIS hue at L 0.44, the deep teal (ADR-0014).
- Eleven-step ramps on one lightness grid, neutrals with a trace of the teal, four semantic ramps, roles in light and dark, and 342 contrast pairings proven on every build (ADR-0015).
- Ramps (ADR-0015): eleven steps (50 to 950) on one lightness grid, the same for every brand; 500 is the signature, 600 the text colour and 800 the parent's deep tone. Chroma follows the signature's own by a tint curve; hue drifts toward yellow or blue in the tints only.
- Neutrals: the same grid with a trace of the AKRIBIS hue (chroma 0.008); 0 is the page, white; 1000 is the ink.
- Roles: page, surface, band, line, text, body text, muted text, signature (500), accent (600), accent as text on a tinted surface (700), hover (700), active (800), soft (50), subtle (100), accent line (300), secondary (200), on-accent (white). In dark mode, the same names with other steps.
- Semantic: success 145°, warning 72°, danger 20°, info 250°, each a ramp from the same machine; never without an icon and a label. Semantic text uses 700; fills with white text use 700.
- Every declared pairing is checked in the build for the eleven brands (nine units, the parent and AKRIBIS One), light and dark; if one drops under its WCAG 2 minimum, the build fails. APCA is reported.

#### 2.5 Typography (proposed; ADR-0020)

https://brand.akribis.group/en/identity/typography/

Question: Which typefaces does AKRIBIS use, and do all ten brands share them?

Rules (proposed):
- Two families for the ten brands: IBM Plex Sans for text, headings, interface and data; IBM Plex Mono for code, identifiers, file names and small uppercase labels. No unit has a typeface of its own: its identity is in the wordmark and the colour.
- Web: files of our own under Brand's /fonts/, generated on every build from IBM's packages at pinned versions: Plex Sans variable (roman and italic, weight axis 300–700, width fixed at 100) and Plex Mono 400 and 500. Subset by rule: Latin, Latin Extended-A, Greek, typographic punctuation and technical symbols; fonts.json lists every declared character the font lacks. A site links /tokens/type.css after base.css and styles with the roles; no site loads Google Fonts or another copy.
- Weights: Regular 400 for text; Medium 500 for interface (labels, buttons, table headers, emphasis at small sizes); SemiBold 600 for headings and strong; Bold 700 for display. Light 300 travels in the file without a job.
- Scale in rem: base 1; upward a major third (1.25): 1.25 · 1.5625 · 1.9531 · 2.4414 · 3.0518; downward 2 px a step: 0.875 and 0.75, and nothing smaller. Steps 3 to 5 are fluid: one step smaller on a 20 rem viewport, nominal from 80 rem. A site invents no sizes: it uses the steps (--size-N).
- Line height per step: 1.5 for text (steps −2 to 0), then 1.4 · 1.3 · 1.2 · 1.15 · 1.1. Measure: 68ch, 45ch in narrow columns. Tracking: none at text sizes; −0.01em from step 3; +0.06em on uppercase labels.
- Figures: lining and tabular by default in Plex (every digit is 0.6 em in the Sans), so columns align with nothing set; slashed zero (font-variant-numeric: slashed-zero) in codes and serials where 0 and O meet. Fractions, superscripts and subscripts through the OpenType features the subset keeps (frac, sups, subs).
- Roles, with font: var(--type-…): display, title, heading, subheading, lede, body, small, caption, label (mono, medium, uppercase), code and data (tabular). The same roles travel in tokens.json as DTCG typography tokens.
- Fit with the wordmarks (measured on every build): at the same x-height, Plex Sans Medium's stem matches the mark's within 6 % and SemiBold weighs 9 % more; the constructions differ on purpose. A mark aligns with text by x-height (--font-sans-x-height: 0.516 of the font size). A unit's name is never set in Plex instead of its wordmark (2.3).
- Office and print: the complete static instances as TTF (Sans Regular, Italic, Medium, Medium Italic, SemiBold, SemiBold Italic, Bold, Bold Italic; Mono Regular, Medium) in a versioned zip with the licences, to install for all users. The Office templates (4.1) use the same weights for the same jobs.
- Licence: SIL Open Font License 1.1 for both families: no per-seat cost, for every unit, site and document.

#### 2.6 Unit motifs (open)

https://brand.akribis.group/en/identity/unit-motifs/

Question: What can each unit express itself with, beyond colour?

Open questions:
- What the sites already invented: AKLEIA's meander, AKIoT's live readouts, SOLFARMA's stage rail, the orbit.
- Whether every unit gets a motif, and what makes a motif valid.
- Where a motif may appear, and where it may not.

#### 2.7 Imagery (proposed; ADR-0034, ADR-0040)

https://brand.akribis.group/en/identity/imagery/

Question: What do AKRIBIS images look like? Photography, products, icons and diagrams.

Settled:
- AI-generated images: only when absolutely necessary. Decided by Demian Montes de Oca, 2026-10-06.
- A partner's video: YouTube's privacy-enhanced player (www.youtube-nocookie.com) is allowed in an <iframe> only, lazy, titled and with the least permissions; every YouTube address is drawn that way (ADR-0040). Decided by Demian Montes de Oca, 2026-10-07.

Rules (proposed):
- Photography: instruments at work in real installations, the laboratory and its procedures, field work with people doing the task, the region's industry. True light and colour; no colour overlays, duotones or filters; text never on a photograph, where its contrast cannot be proven. Three ratios: 16:9, 3:2 and 1:1.
- Never: posed stock people, or stock people presented as a client, an employee or a testimonial; futuristic renders; abstract visuals in place of the subject; a manufacturer's lifestyle imagery as our own. Own photography first; a manufacturer's with written permission and credit; every image recorded with source, licence, credit, date and consent.
- Product: cut out on white or on the band, three-quarter view lit from the top left across the family, a contact shadow only, and in 1:1 between 70 and 80 % of the width.
- Icons: one set, IBM's Carbon icons (Apache-2.0), drawn to accompany IBM Plex on a 32 px grid. Brand publishes the subset at /icons/ and the Icon component of @akribis/site sets them in currentColor at 16, 20, 24 or 32 px. Never mixed with another set, never IBM's product icons or logos; decorative ones aria-hidden, named when they mean something. Each unit has the icon of its verb.
- Diagrams: SVG with the tokens, 1 and 2 px lines in ink and neutrals, a unit's colour only to identify it, the spectrum only for AKRIBIS One; flat; labels as real text in Plex in the page's language; an accessible title and description. No illustration.
- Video: hosted by AKRIBIS (the site or the company's Cloudflare Stream), never linked from a manufacturer, except a partner's video in YouTube's privacy-enhanced player (ADR-0040); never with automatic sound; an automatic loop is muted, with a poster and playsinline, and stops under prefers-reduced-motion; all speech subtitled in the three languages.
- The check (the checker's media rules): images and video only from the site, Brand or the company's video, and an <iframe> also from www.youtube-nocookie.com; photographs served as AVIF or WebP (astro:assets), JPEG and PNG only as a fallback inside <picture>; no image over 300 kB; every <video> with a poster, and muted and playsinline if it starts by itself.
- Sources, in order: 1) own photography, commissioned per unit or taken by the team with a shot list and consent; 2) the manufacturer's media library (Vaisala's partner media bank, for example), under the distribution agreement; 3) open institutional archives by subject: NIST, NOAA, USGS, NASA, the CDC Public Health Image Library, the Library of Congress, Wikimedia Commons and Europeana, credited and never implying endorsement; 4) licensed stock, one paid provider for the whole group, and Unsplash or Pexels only for scenes without recognisable people, brands or artworks, since they warrant nothing about what they show; 5) generated, only when none of the above will do. Every image is downloaded and hosted on the site; never hotlinked. Each source's terms and credit are in imagery.json; each image's own terms decide.
- AI-generated images: only when absolutely necessary, when nothing real can show what is needed, and never of people. Never presented as a photograph of real work, a real place, real equipment or a real client, nor in a case, a datasheet or a certificate; recorded as generated, with the tool and the date, and marked as such in their alternative text or caption.

### 3. Digital system

What the twelve sites share, what each may change and what is its own.

#### 3.1 Tokens (proposed; ADR-0015, ADR-0020, ADR-0021, ADR-0037)

https://brand.akribis.group/en/digital-system/tokens/

Question: Which values does the system define, and how does each site receive them?

Settled:
- The colour tokens exist and this site consumes them: base.css (neutrals, semantic, signatures), one CSS file per brand with its ramp and roles in light and dark, all.css with every brand under data-brand, and tokens.json in DTCG format (ADR-0015).
- The typography tokens exist and this site consumes them: type.css with the fonts, the scale, the line heights, the tracking, the measure and the roles (--type-…), and the font and typography groups of tokens.json (ADR-0020, proposed).
- The shape tokens exist and this site is built with them alone: shape.css with spacing, radii, layout, motion, focus and elevation, and the space, radius, layout, motion, focus and elevation groups of tokens.json (ADR-0021, proposed).

Rules (proposed):
- The contract is CSS custom properties: a site links /tokens/base.css, /tokens/type.css, /tokens/shape.css and then /tokens/<brand>.css, and styles only with the roles (--color-page, --color-text, --color-accent…; font: var(--type-body)…), never with raw ramp steps or sizes of its own.
- A component that shows another brand is wrapped in data-brand="<brand>" with all.css: the roles resolve to that brand inside the element.
- Light and dark: each brand's CSS carries both; every site renders light and dark switches on only on request, with data-theme="dark" on the root element, which the theme toggle sets and the cookie akribis-theme remembers; never from the system setting (ADR-0037, proposed).
- tokens.json (DTCG) is the same source for tools that do not read CSS.
- Shape (ADR-0021): a spacing is a multiple of 0.25 rem (4 px), --space-1 to --space-24 (0.25 to 6 rem): 1–2 inside a control and between a label and its value; 3–4 inside a component; 6–8 between components; 12–20 between sections. Nothing in between.
- Radii: 0 on surfaces, cards, tables and images (tight corners read as precise); 2 px on tags and chips; 4 px on controls; 8 px on dialogs, menus and toasts; pill on status; round on avatars and dots.
- Frames: container 80 rem, content 64 rem, reading column 46 rem; gutter 1 rem, 2 rem from md; 12 columns with a 1.5 rem gap; breakpoints sm 36, md 48, lg 64, xl 80 rem, always mobile-first (min-width only); interactive targets at least 1.5 rem (24 px), controls 2.75 rem (44 px) tall; a site's primary bar 3.25 rem (52 px).
- Motion: 120 ms for a change of state (hover, focus), 200 ms to reveal (menus, tooltips, accordions), 320 ms to move (dialogs, panels); easing standard cubic-bezier(0.2, 0, 0, 1) and exit cubic-bezier(0.4, 0, 1, 1). Under prefers-reduced-motion every duration is 0.
- Focus: a 2 px ring in the accent, 2 px outside the element, on every interactive element; on an accent-filled control the ring is on-accent and sits inside the edge.
- Elevation: structure is drawn with 1 px hairlines in --color-line and with bands; the one shadow is for overlays (menus, dialogs, toasts) and never for cards; layers raised 1, sticky 10, overlay 100, toast 1000.
- This site styles with these tokens alone: the build fails on a spacing, radius, shadow, duration or breakpoint of its own.

#### 3.2 Site anatomy (proposed; ADR-0023, ADR-0031, ADR-0032)

https://brand.akribis.group/en/digital-system/site-anatomy/

Question: What must every AKRIBIS site have, what may it change, and what is its own?

Rules (proposed):
- Every AKRIBIS site is built in four layers. Group: identical everywhere, from Brand as is, the site's brand its only setting (the endorsement, the group bar, the group footer block with the unit directory, the AKRIBIS One module, the legal line, the marks, the tokens). Shared: one component, one source, configured by the site with its brand, its language and its content (header, language switch, skip link, contact form, 404, consent). Expression: what a site sets through settings and never through code (its brand file, its imagery, which units it features first, its tone). Own: its content and the pages only it has.
- Three kinds of site: the nine units, the parent (akribis.group) and AKRIBIS One (akribis.one); the anatomy says which patterns each kind carries, and anatomy.json publishes it.
- What every site carries, verified on every build through the data-pattern marker every shared component renders: on every page the skip link, the header with the site's mark, the language switch, the group footer block with the unit directory and the legal line; on every page of a unit's site, the group bar with the endorsement as well; on a unit's home, the AKRIBIS One module; a 404 page; and, where there is a form, the shared one.
- Pages every site has, in each language and with translated slugs: home, contact, thank-you (after the form), privacy, legal notice and terms, and 404. Today one site of five has legal pages and a 404.
- A site may change: its brand file (/tokens/<brand>.css, the only colour setting), its imagery within Imagery (2.7), which units the AKRIBIS One module and the directory feature first, and its own pages with their navigation.
- A site never has: tokens, fonts or logo files of its own; another wording of the endorsement; a unit list or order of its own; a contact form of its own. The register (units.json) is the one list: today five sites keep five lists that disagree (eight or nine units, two sets of verbs).
- The texts of the shared patterns (the endorsement, the legal line, the form's labels) are Brand's data in the three languages; the text of the legal pages is the company's, published by Brand as data once Voice (1.5) and legal review decide it. A site translates and edits none of it: it shows it.
- The shared pages have their slug per language in the anatomy (ADR-0032): contacto/contact/contato, gracias/thank-you/obrigado, privacidad/privacy/privacidade, aviso-legal/legal-notice/aviso-legal; the 404 is one file at the root. The checker verifies that each exists in every language (the pages rule). The starter of @akribis/site brings them ready-made (ADR-0031).

#### 3.3 Shared patterns (proposed; ADR-0024, ADR-0031)

https://brand.akribis.group/en/digital-system/shared-patterns/

Question: Which components are built once and used by every site?

Rules (proposed):
- Built once in Brand and used by every site: the group bar, the endorsement, the group footer block with the unit directory, the AKRIBIS One module, the language switch, the legal line, the contact form, the 404 page and consent. Prototyped on this site first: this page shows them inside other brands, and this site runs them.
- The endorsement is the line "Una unidad de" ("A unit of", "Uma unidade da"; the Spanish decided in ADR-0005, the others proposed) followed by the AKRIBIS One lockup from the published file, all of it linking to akribis.one: at bar size with the solid ring, as a block with the spectrum, white on a dark ground. Never "Parte de", never "AKRIBIS · One" set in type, never a redrawn ring.
- The group bar sits above the header of every unit site, on AKRIBIS One's teal ink, identical on all: the endorsement at the start, the language switch at the end. The parent and AKRIBIS One do not carry it.
- The unit directory is the register in the grid order (ADR-0010): three categories, three units each, every mark in its colour from the published file, its verb and the link to its site. One component serves every site's footer and the directories of akribis.group and akribis.one; the site only chooses whether to show the verbs.
- The AKRIBIS One module on a unit's home: the ring with the spectrum, the slogan and the second line from the register in the page's language, and the link to akribis.one.
- The contact form: name, organisation, email, phone, about (a unit or the group), message and the consent line linking the privacy policy; every field labelled, with autocomplete and inputmode; a honeypot instead of a third-party captcha. It posts to the site's own /contact, which validates, relays to the CRM with the site's lead source and sends to the thank-you page in the same language. One implementation replaces today's seven copies, which post straight to Salesforce without consent.
- A component takes its colour from the brand file it sits in: wrapped in data-brand="<brand>" with all.css, its roles resolve to that brand; nothing is recoloured by hand.
- Every pattern renders a data-pattern marker; the anatomy (3.2) says where each is due and the checker (3.4) verifies it.
- Where they live and how they arrive (ADR-0031): in the @akribis/site package, built on every build with the brand's data inside. Its components are these patterns; its integration (akribis({ brand, kind, site })) sets the site up; its Shell.astro layout is the page; its Worker serves the site and receives the form; its checker runs after every build. This site uses the same components from the same package.
- The server side of /contact is the package's Worker, one per site: it drops what filled the honeypot, validates the required fields, relays to the CRM with the address and lead source the Worker's variables hold (CONTACT_RELAY, SF_OID, LEAD_SOURCE) and sends to the thank-you page in the same language. Without a relay it answers 503; it never loses a message silently. The HTML carries no CRM id and no third-party script.
- The patterns' texts (the skip link, the language switch, the form, the 404, the titles and descriptions of the shared pages) are Brand's data in brand/strings.yaml, published as /strings.json and inside the package; a site shows them and translates none.

#### 3.4 Web standards (proposed; ADR-0025, ADR-0031, ADR-0032)

https://brand.akribis.group/en/digital-system/web-standards/

Question: What quality bar does every site meet?

Rules (proposed):
- WCAG 2.2 AA is the floor on every surface (criterion 4). What a static check can see is checked on every build: lang on html, one h1 and no skipped heading level, one main and a skip link, alt on every image, a name or aria-hidden on every inline SVG, text on every link, a label and autocomplete on every control. Focus (the ring), target size (24 px) and reduced motion are the shape tokens' job; contrast is proven by the colour build.
- Addresses: every page under its language (/es/, /en/, /pt/), every segment translated, lowercase ASCII with hyphens and a trailing slash; the root redirects by Accept-Language with Spanish as the fallback; x-default points at the root. Old addresses redirect permanently.
- Languages: lang equals the page's language (es, en, pt); hreflang for the three plus x-default, absolute, the page itself included; a canonical that is the page's own address. Numbers, dates and units through Intl in the page's language (es-AR, pt-BR, en): decimal comma in Spanish and Portuguese, a thin space before the unit and the %.
- SEO on indexable sites: a title of 10 to 70 characters, a description of 30 to 160, og:title, og:description, og:url and og:image (the brand's profile picture at 1200 px unless the page has its own), Organization JSON-LD on the home page with AKRIBIS Group as parentOrganization, and a sitemap with every page. Brand is noindex while it is a draft and carries everything but the sitemap.
- Budgets per page, uncompressed: HTML 200 kB, CSS 80 kB, JS 150 kB, fonts 260 kB, at most three preloaded fonts; every image with width and height; fonts only from Brand, never from a font CDN; study sheets and marks as files, not inlined.
- Consent: no third-party script loads before consent; a script from an analytics or advertising host is gated (data-consent). The default is none: where nothing tracks, no cookie notice is needed. The one analytics without consent is Cloudflare's cookieless beacon.
- The checker (brand/src/check-site.ts) runs these rules over a built site, plus the anatomy's patterns for the site's kind, lists every violation and exits with an error; this site runs it in its tests on every build, with zero violations over 175 pages; every site runs it before deploying.
- Not static, still a rule: keyboard operation of every component, visible focus, nothing lost at 400 % zoom or 320 px, motion stopped under prefers-reduced-motion, forms announcing their errors. Checked by hand on every shared component when it is built.
- Three more rules (ADR-0031, ADR-0032): pages, every shared page exists in every language at its slug; headers, the site publishes the response-header baseline in _headers (X-Content-Type-Options, Referrer-Policy, Permissions-Policy, X-Frame-Options); naming, no page writes a forbidden spelling in its text. The checker runs inside every site's build: the @akribis/site integration runs it over dist/ and one violation fails the build.

#### 3.5 Unit-site templates (proposed; ADR-0035, ADR-0036)

https://brand.akribis.group/en/digital-system/unit-site-templates/

Question: Which template draws each page of a unit site that reads the CMS, and what does each carry?

Rules (proposed):
- One template per page type, chosen by the type the CMS sends (window 4) and never by the address: home, section index (index), catalogue front page (product_index), quantity, axis (instrument type, brand, family), segment, industry, application, topic or service (standard), rubric index, publication, product, contact and search. A type the table does not know is drawn as a topic: its body. The table lives in packages/site/src/templates/registry.ts.
- Every template has the same regions, in this order: head (PageHead: breadcrumbs from the tree, eyebrow, title, summary, the main action and the partner's attribution when the content is a partner's), body (the sections in the editor's order), derived rails (what the axes and the relations give), the ecosystem narrative (on service, segment, industry and application pages, and on the home with the AKRIBIS One module) and the closing (the index's own call, window 3, or the voice's: «Talk to a specialist»).
- The home follows akribis.info's order: hero (the body's first hero block), solutions (the rest of the body), services and units, segments with their industries and applications, the ecosystem, contact, the Expertise hub (its rubrics, the upcoming events and the latest news from window 10), quick access, applications and instrumentation (its axes and the featured instruments). Each block appears only when there is data for it.
- Catalogue front page: the axes on top (each value with its count of instruments) and the full portfolio, paginated, with window 1's facets. Quantity: its instruments, the industries and applications where it appears, and its notes (window 8 by category). Axis: its instruments (a family by its own facet) and the crossings with the other axes; a brand shows its logo and its relation with AKRIBIS. Segment: its industries and applications, the services and the notes, with no grid: a segment groups, it does not classify. Industry and application: their relations, the instruments of their category, their notes and their segment.
- A facet combination is a query on the written page: one value per axis, combined with AND, noindex, follow, with the canonical and the alternates on the page without the query; the pages keep the query. An option that gives nothing is not offered.
- The navigation and the footer come from the same tree: Instrumentation opens its axes as columns with counts (an axis without pages does not appear) and the full portfolio; Segments opens each segment with its industries and applications, plus all industries and all applications; the footer has five columns (contact, categories, services, Expertise, about) above the group block.
- Every page carries the cache tags the CMS purges: the department's, page: of the page (a bare page: on the home) and of the segments index, whose panel window 3 builds in one request, product: of every instrument any grid shows, category:, rubric: and resource:. Every grid also publishes its ItemList in JSON-LD, beside BreadcrumbList, Product, Event or Article.
- A product with an options tree (window 7) carries the configurator as a section of its page: the groups, exclusions live, the rules on request and before adding, the order code both ways, services and accessories apart. The browser asks the site itself for the tree (/configurator/<id>.json), which asks the CMS with the key; what is configured joins the quote list with its full summary and reaches the CRM that way.
- A CMS site's sitemap is built on request: /sitemap-index.xml with its parts for pages (the tree, the shared ones, the site's own), products (window 6) and publications (window 8), each address with its alternates in the three languages, cached and tagged; robots.txt names it and can carry the site's per-bot policy. The entry at / picks the language by the cookie the switch writes, then the browser, then the country.
- Search (window 11) lives at a translated address (/es/buscar/, /en/search/, /pt/buscar/), groups its results into pages, instruments and publications, and is not indexed.
- The proof (packages/cms-proof) is checked against a local CMS with an example of every type (mock/cms.mjs): pnpm --filter @akribis/cms-proof check:mock starts the CMS and the Worker, checks that each address is drawn by its type's template and runs the live check over the three languages.

### 4. Applications

The brand beyond the web. Prioritised by real use, not built all at once.

#### 4.1 Office templates (proposed; ADR-0027)

https://brand.akribis.group/en/applications/office/

Question: Which Office templates are needed, and what do they contain?

Rules (proposed):
- The fonts: IBM Plex Sans and Plex Mono installed for all users from Brand's package (2.5); the theme names the families as Windows registers them so that SemiBold is the heading face and Regular the text face.
- One Office theme per brand, generated from the tokens (ADR-0027): dk1 ink, lt1 paper, dk2 the deep tone (800), lt2 neutral 100; accents 1 to 6 for charts: 600, 400, 800, neutral 600, 200, neutral 400; links 600 and, followed, 800. Published as the DrawingML scheme (theme1.xml) a template embeds, and as JSON.
- Print values per brand: sRGB as the reference, OKLCH and CIELAB (D65) device-independent, and an uncalibrated CMYK the printer's profile replaces; no Pantone until a printer asks with its profile. ASE swatches per brand (signature, text and the eleven steps) and for the family.
- The templates (.potx for presentations, .dotx for proposals and quotes) are built with the theme and the fonts once the theme is ratified: one master with each brand's theme, the mark from the published files, the shape tokens as margins and radii, never effects or shadows.
- Who maintains them: Brand generates the theme and publishes the templates; people download them from their brand's asset page (5.1); a brand change is a new build, not a hand edit.

#### 4.2 Email signature (proposed; ADR-0026)

https://brand.akribis.group/en/applications/email-signature/

Question: What does each unit's email signature look like?

Rules (proposed):
- One template per brand and language, generated from the register on every build (/signatures/<brand>.<lang>.html): the brand's mark in colour as a PNG hosted on Brand (150 px wide from the 512 px file, sharp on dense screens), the name in bold, the role, the brand's line (name and area) in its text colour, phone, mobile, email and site, a hairline, the endorsement "Una unidad de AKRIBIS One" with the AKRIBIS One lockup (units only) and the company's legal line.
- A 480 px table with inline styles, in the recipient's Arial: no mail client loads web fonts, and the mark is the one element that must be exact. No background images, floated columns or social icons.
- The colours are the tokens: ink for the name, neutral 700 for what is secondary, neutral 200 for the hairline and the brand's text colour (step 600, at least 4.5:1 on white) for its line and its links; the parent and AKRIBIS One use their signature.
- A person's data is five fields: name, role, phone, mobile and email. The generator on this page fills the template in the browser, drops the empty rows and copies the signature as rich text to paste into Gmail or Outlook, or as HTML. Nobody edits the HTML by hand.
- The legal line is one, the company's, in the three languages; proposed until Voice (1.5) and legal review fix it.

#### 4.3 Datasheets (open)

https://brand.akribis.group/en/applications/datasheets/

Question: How are product and service datasheets laid out?

Open questions:
- Manufacturers' products against our own services.
- Generated from Wagtail's data, or designed by hand.
- Languages, units of measurement and numbers.

#### 4.4 Certificates and reports (open)

https://brand.akribis.group/en/applications/certificates/

Question: How are AKRIMET's and SOLFARMA's calibration certificates and reports designed?

Open questions:
- What accreditation rules require on the document.
- Layout and legibility: results with their uncertainty.
- Brand presence against the neutrality a technical document needs.

#### 4.5 Stationery (open)

https://brand.akribis.group/en/applications/stationery/

Question: Which printed pieces does each unit need?

Open questions:
- Letterhead, business cards, envelopes, and which are still needed.
- Print specifications: paper, CMYK, Pantone.

#### 4.6 Social media (proposed; ADR-0018, ADR-0019)

https://brand.akribis.group/en/applications/social-media/

Question: How do the units appear on social media?

Settled:
- The profile pictures (ADR-0019): each brand's full-bleed tile, the disc in the signature with the two letters fitted by their ink to the safe circle; AKRIBIS One, the ring with its dot; the parent, "ak" in deep teal. For black and white, the whole word in white on ink; AKRIBIS One and the parent stacked. Published per brand at /marks/<id>/<id>-avatar.svg and -avatar-ink.svg, with PNG at 400, 800 and 1200 px.

Rules (proposed):
- The profile picture is square and the platform crops it round: it is the same artwork as the maskable icon, so what holds for one holds for the other. The ground is opaque, in the signature, because platforms flatten transparency unpredictably.
- The letters are fitted by their ink, the smallest circle around the outlines, to the 80 % safe circle; one scale for all, set by the widest pair, so all share one x-height (40 % of the square). The centre of the ink's circle, not the box's, goes to the centre.
- Black and white: the whole word in white on ink, each fitted to the circle on its own, because the words differ in length; legible from about 80 px. The two-word marks, AKRIBIS One and the parent, are stacked and centred, without the ring.
- Upload the 400 px PNG where 400 is asked (LinkedIn, X), the 800 where more is (YouTube, WhatsApp), the 1200 as the master.

#### 4.7 Events (open)

https://brand.akribis.group/en/applications/events/

Question: How does AKRIBIS present itself at trade fairs and events?

Open questions:
- Banners, booths, badges.
- A shared presence as AKRIBIS One against each unit's own presence.

#### 4.8 Video (open)

https://brand.akribis.group/en/applications/video/

Question: How do videos open, close and carry titles?

Open questions:
- Openings and closings.
- Name and role titles.
- Subtitles in all three languages.

### 5. Delivery

How each decision reaches whoever uses it, as a file or as data.

#### 5.1 Asset library (proposed; ADR-0028)

https://brand.akribis.group/en/delivery/asset-library/

Question: Where does anyone get the right file, in the right format?

Rules (proposed):
- One page per brand under this topic (/<lang>/delivery/asset-library/<brand>/): its identity (name, area, verb, site), its colours with the token file and the ASE swatches, its marks in every version, its icons, its email signature templates, its Office theme and every published file with its size.
- Formats: SVG (master with clearspace, tight and inline), PNG at 512, 1024 and 2048 px, icons (favicon.svg and .ico, iOS, Android and maskable) with site.webmanifest, profile pictures at 400, 800 and 1200 px, token CSS, signature HTML, theme1.xml and ASE. PDF and EPS stay open.
- Names: <brand>-<piece>-<version>[-<variant>].<format>, lowercase ASCII; addresses do not change (/marks/<brand>/…, /tokens/…, /signatures/…, /office/…, /print/…) and manifest.json lists every file with its size.
- A site keeps no copies: it links the published file or installs the package (5.2). The 95 copies that live in the sites today, in three folders and with two different versions of the same file, are retired when they are rebuilt.
- The pages are part of this site: they pass the same standards (3.4) as any other.

#### 5.2 Packages (proposed; ADR-0029, ADR-0031)

https://brand.akribis.group/en/delivery/packages/

Question: How do the sites receive tokens and components?

Settled:
- Packages are public.

Rules (proposed):
- Two packages. @akribis/tokens, built on every build from the published files: the CSS (base, type, shape, one per brand, all) with the fonts pointing at Brand, tokens.json, units.json, contrast.json, anatomy.json and standards.json. No dependencies, no JavaScript.
- The version is the build date as a calendar version (2026.10.6), the same the data and the changelog (5.4) carry. A site pins the version it uses and raises it when the changelog tells it what changed.
- Published on npm once AKRIBIS decides the package's licence (the marks, colours and texts are AKRIBIS's; the fonts, OFL); until then the tarball installs from Brand (/packages/).
- A site links the package's CSS in the contract's order (base, type, shape, its brand) and copies nothing.
- @akribis/site (ADR-0031) is the shared layer of every site: the Astro integration, the patterns as components, the page layout, the Worker, the checker and the starter a new site begins from, with the brand's data and the token CSS inside. A site installs this package and nothing else from Brand; the marks and the fonts load from brand.akribis.group. Same version as the tokens package, built in the same build.

#### 5.3 Data for sites and agents (proposed; ADR-0022, ADR-0031)

https://brand.akribis.group/en/delivery/data/

Question: Which facts and rules are published as machine-readable data?

Rules (proposed):
- Everything Brand decides is also data, generated on every build from the same source as the pages: /units.json (the register with colours, orders and the ring's geometry), /manifest.json (every published mark file, with its size), /tokens.json (the whole system in DTCG: colour, typography and shape), /tokens/contrast.json (every proven pairing), /fonts/fonts.json (every font file, its coverage and the fit test), /anatomy.json and /standards.json (what every site has and the standards the checker runs) and /llms.txt (the rules as plain text).
- Addresses do not change: a file may gain fields, never lose or rename one without a decision. The web fonts carry a content hash in their name and the Office package the font version, so caches may keep them for a year.
- Every file carries its generation date as version (version or generated). Numbered versioning and its changelog come with 5.4.
- All are served with Access-Control-Allow-Origin: *, so any AKRIBIS site or tool reads them from another origin.
- llms.txt is the rules for agents: the English specification of every proposed or ratified topic with its status, the open questions of the others, how to use the tokens and the marks, the register with its colours, the file index and the list of decisions. It is regenerated on every build and replaces the design part of Kanon.
- The page and the data cannot disagree: this site's components read those same files, and the build fails if llms.txt names an address it did not publish.
- Two more files (ADR-0031): /strings.json, the texts of the shared layer in the three languages (brand/strings.yaml), and /units.schema.json, the JSON Schema that units.json already named. The same data travels inside @akribis/site at the build's version.

#### 5.4 Changelog (proposed; ADR-0030)

https://brand.akribis.group/en/delivery/changelog/

Question: How does a site know what changed in the brand?

Rules (proposed):
- The brand has a version: the date of its last build, as a calendar version (2026.10.6). The package, tokens.json, units.json, fonts.json, manifest.json and changelog.json carry it; a version is a complete state of the brand, never a loose change.
- The changelog is the decision log by date: every ADR with its title, its status and the topics it decides, as JSON at /changelog.json and as this page's list. What is not a decision is not a brand change.
- A site compares its version with changelog.json's and reads the entries after it; it knows which topics changed before it updates the package.
- Notice to the sites: changelog.json is the channel; once the sites have continuous integration, a daily check against it. An email to the owners goes with every ratification.

## Every site: the anatomy

Kinds of site: unit, parent, one (the nine units' sites; akribis.group; akribis.one). Four layers:
- Group: Identical on every site: it comes from Brand as is, the site's brand its only setting. It says the site belongs to AKRIBIS and what the group is made of.
- Shared: One component, one source: built once in Brand and configured by the site with its brand, its language and its content.
- Expression: What a site sets through settings and never through code: its brand file (the colour), its imagery, which units it features first, its tone within the voice.
- Own: The site's content and the pages only it has: products, services, cases, articles. Built with the tokens and the patterns; the unit owns them.

Patterns (each renders a `data-pattern` marker; the checker verifies every-page, home and not-found scopes for the site's kind):
- `skip-link` · Skip link · shared layer · every-page · every site
- `site-header` · Header with the site's mark · shared layer · every-page · every site
- `site-nav` · Deep navigation with panels · shared layer · when-needed · every site
- `language-switch` · Language switch · shared layer · every-page · every site
- `theme-toggle` · Light or dark theme toggle · shared layer · every-page · every site
- `utility-bar` · Utility bar · shared layer · every-page · unit
- `group-bar` · Group bar · group layer · every-page · unit
- `endorsement` · Endorsement "Una unidad de AKRIBIS One" · group layer · every-page · unit
- `group-footer` · Group footer block · group layer · every-page · every site
- `unit-directory` · Unit directory · group layer · every-page · every site
- `one-module` · AKRIBIS One module · group layer · home · unit
- `legal-line` · Legal line · group layer · every-page · every site
- `attribution` · Partner content attribution · shared layer · when-needed · every site
- `site-footer` · Five-column site footer · shared layer · when-needed · every site
- `site-search` · Site search · shared layer · when-needed · every site
- `contact-form` · Contact form · shared layer · page · every site
- `not-found` · 404 page · shared layer · not-found · every site
- `consent` · Consent (only when a script needs it) · shared layer · when-needed · every site
- `whatsapp-link` · Floating WhatsApp link · shared layer · when-needed · every site

Pages every site has, in each language with translated slugs: Home; Contact; Thank you (after the form); Privacy; Legal notice and terms; Page not found.

A site may change: Its brand file (/tokens/<brand>.css): the only colour setting. Its imagery, within Imagery (2.7). Which units the AKRIBIS One module and the directory feature first; never which exist. Its own pages and navigation. It never has: Tokens, fonts or logo files of its own. Another wording of the endorsement, another unit list, another order. A contact form of its own.

## Every site: the standards

WCAG 2.2 AA is the floor. URLs match `^/[a-z0-9]+(?:/[a-z0-9-]+)*/$` under a locale. Title 10–70 characters, description 30–160. Budgets per page, uncompressed: HTML 200000 B, CSS 80000 B, JS 150000 B, fonts 260000 B, at most 3 preloaded fonts. Fonts come from Brand only. No third-party script before consent. Run `node brand/src/check-site.ts <dist> --kind <unit|parent|one>` over a built site: it lists every violation and the anatomy's missing patterns; `/standards.json` and `/anatomy.json` hold the rules.

## The register

Brand ids, as used in file names, CSS files and `data-brand`. Hue in OKLCH degrees; the signature is the mark's colour (ramp step 500), the text colour the same hue one step down (600).

- `akribis-group` · AKRIBIS Group · The company as a whole · akribis.group · signature #005e65 (the AKRIBIS hue at step 800)
- `akribis` · AKRIBIS · Instrumentation and Equipment · measure · akribis.info · hue 204°, signature #009da9, text #00818b
- `akuralab` · AKURALAB · Laboratory Equipment · analyse · akuralab.com · hue 174°, signature #01a285, text #02856d
- `akutemp` · AKUTEMP · Cold Chain and Thermal Equipment · control · akutemp.com · hue 234°, signature #0096ce, text #017baa
- `akrimet` · AKRIMET · Metrology, Qualification and Validation · calibrate · akrimet.com · hue 54°, signature #d26a01, text #ad5601
- `solfarma` · SOLFARMA · Pharmaceutical Qualification and Validation · validate · sol-farma.com · hue 264°, signature #4c82ff, text #3467e1
- `akleia` · AKLEIA · Regulatory Science Consulting · regulate · akleia.info · hue 84°, signature #b08201, text #906b01
- `akzotec` · AKZOTEC · Engineering, Automation and Installation · build · akzotec.com · hue 24°, signature #eb484b, text #cc2631
- `singular4` · SINGULAR4 · Software and Data Intelligence · model · singular4.com · hue 354°, signature #e04893, text #c22879
- `akiot` · AKIoT · Industrial IoT · monitor · akiot.es · hue 294°, signature #946af5, text #7c4fd8
- `akribis-one` · AKRIBIS One · The ecosystem's commercial offer · synergise · akribis.one · signature #002f34 (the AKRIBIS hue at step 950; the ring carries the nine signatures as one spectrum)

Orders when the units appear together: grid akribis/akuralab/akutemp · akrimet/solfarma/akleia · akzotec/singular4/akiot; circular akribis → akutemp → akzotec → akrimet → akiot → singular4 → solfarma → akleia → akuralab; linear akleia → akuralab → akribis → akutemp → akzotec → akrimet → akiot → singular4 → solfarma.

## Files

- `/tokens/base.css` · neutrals, semantic colours, the signatures and the AKRIBIS One spectrum
- `/tokens/type.css` · the fonts (@font-face), the scale, the type roles
- `/tokens/shape.css` · spacing, radii, layout, motion, focus, elevation
- `/tokens/<brand>.css` · one file per brand: its ramp and colour roles, light and dark
- `/tokens/all.css` · every brand under [data-brand]
- `/tokens.json` · the whole system in DTCG
- `/tokens/contrast.json` · every declared pairing with its WCAG 2 and APCA values
- `/units.json` · the register with colours, orders and the ring's geometry
- `/units.schema.json` · the JSON Schema of the register
- `/strings.json` · the shared strings every site shows, in the three languages (ADR-0031)
- `/voice.json` · the voice: address per language, principles, the claims policy and register, the CTAs, the glossary (ADR-0033)
- `/imagery.json` · the imagery rules: photography, product shots, video, icons, diagrams (ADR-0034)
- `/icons/index.json` · the icon subset from IBM Carbon (Apache-2.0), each at /icons/<name>.svg in currentColor (ADR-0034)
- `/manifest.json` · every published mark file, with sizes
- `/fonts/fonts.json` · every font file: coverage, axes, features, metrics, the fit test
- `/anatomy.json` · what every site has: layers, patterns, pages, what a site may change
- `/standards.json` · the web standards the checker runs: rules, budgets, hosts
- `/signatures/index.json` · the email signature templates per brand and language (ADR-0026)
- `/office/index.json` · the Office theme per brand (theme1.xml, JSON) and the font package (ADR-0027)
- `/print/colours.json` · print values: sRGB, OKLCH, CIELAB, uncalibrated CMYK; ASE swatches beside it
- `/packages/index.json` · the packages: @akribis/tokens (ADR-0029) and @akribis/site, the shared layer of every site with the starter (ADR-0031), as tarballs, calendar-versioned
- `/changelog.json` · the decision log by date: what changed and which topics it decides (ADR-0030)
- `/llms.txt` · this file

## Decisions

- ADR-0000 · Use MADR 4.0.0 to record Design's decisions · accepted, 2026-10-02 · https://brand.akribis.group/en/decisions/0000/
- ADR-0001 · Write Design's decision records in English · accepted, 2026-10-02 · https://brand.akribis.group/en/decisions/0001/
- ADR-0002 · Publish content in English, Spanish and Portuguese · accepted, 2026-10-02 · https://brand.akribis.group/en/decisions/0002/
- ADR-0003 · Do the new work on a branch named `next` · superseded by ADR-0004, 2026-10-02 · https://brand.akribis.group/en/decisions/0003/
- ADR-0004 · Rename Design to Brand, with its own repository · accepted, 2026-10-03 · https://brand.akribis.group/en/decisions/0004/
- ADR-0005 · Endorse every unit as "Una unidad de AKRIBIS One" · accepted, 2026-10-03 · https://brand.akribis.group/en/decisions/0005/
- ADR-0006 · Structure Brand as one page per topic, each with its status · accepted, 2026-10-03 · https://brand.akribis.group/en/decisions/0006/
- ADR-0007 · Build Brand with Astro, as static files on its Worker · proposed, 2026-10-03 · https://brand.akribis.group/en/decisions/0007/
- ADR-0008 · Compose every wordmark from one glyph library on a shared grid · accepted, 2026-10-03 · https://brand.akribis.group/en/decisions/0008/
- ADR-0009 · Rank the criteria every brand decision is judged against · accepted, 2026-10-03 · https://brand.akribis.group/en/decisions/0009/
- ADR-0010 · Present the units by category, in fixed grid, circular and linear orders · accepted, 2026-10-03 · https://brand.akribis.group/en/decisions/0010/
- ADR-0011 · Set "one" and "group" from the glyph library; the parent mark is "akribis group" · accepted, 2026-10-04 · https://brand.akribis.group/en/decisions/0011/
- ADR-0012 · Derive the AKRIBIS One ring from the letters, and make the ring lockup primary · accepted, 2026-10-04 · https://brand.akribis.group/en/decisions/0012/
- ADR-0013 · Generate the nine signatures from one lightness band on a 12-slot hue wheel · accepted, 2026-10-04 · https://brand.akribis.group/en/decisions/0013/
- ADR-0014 · Colour the parent mark in the deep tone of the AKRIBIS teal · accepted, 2026-10-04 · https://brand.akribis.group/en/decisions/0014/
- ADR-0015 · Build the ramps, neutrals, semantic colours and roles on one lightness grid · accepted, 2026-10-04 · https://brand.akribis.group/en/decisions/0015/
- ADR-0016 · Colour AKRIBIS One in the teal ink, and draw the ring as one continuous spectrum · proposed, 2026-10-04 · https://brand.akribis.group/en/decisions/0016/
- ADR-0017 · Set the favicons as two letters on the signature, with the ring for One and the cloud for the AKIoT app · proposed, 2026-10-05 · https://brand.akribis.group/en/decisions/0017/
- ADR-0018 · Give every unit a profile picture: its letters inside the AKRIBIS One ring · superseded by ADR-0019, 2026-10-05 · https://brand.akribis.group/en/decisions/0018/
- ADR-0019 · Make the tile the profile picture, fit its letters to the circle, and centre the stacked One lockup without the ring · accepted, 2026-10-05 · https://brand.akribis.group/en/decisions/0019/
- ADR-0020 · Set IBM Plex Sans and Plex Mono for every brand, self-hosted and subset by rule, on a documented scale · proposed, 2026-10-05 · https://brand.akribis.group/en/decisions/0020/
- ADR-0021 · Build the shape tokens on one 4 px base: spacing, radii, layout, motion, focus and elevation · proposed, 2026-10-05 · https://brand.akribis.group/en/decisions/0021/
- ADR-0022 · Publish the brand as data at stable addresses, with llms.txt as the rules for agents · proposed, 2026-10-05 · https://brand.akribis.group/en/decisions/0022/
- ADR-0023 · Build every site in four layers and verify what each must carry · proposed, 2026-10-05 · https://brand.akribis.group/en/decisions/0023/
- ADR-0024 · Build the shared patterns once in Brand and prototype them on this site · proposed, 2026-10-05 · https://brand.akribis.group/en/decisions/0024/
- ADR-0025 · Set the web standards as data and check every build against them · proposed, 2026-10-05 · https://brand.akribis.group/en/decisions/0025/
- ADR-0026 · Generate the email signature per brand and language from the register · proposed, 2026-10-06 · https://brand.akribis.group/en/decisions/0026/
- ADR-0027 · Generate the Office theme per brand and publish the print values and swatches · proposed, 2026-10-06 · https://brand.akribis.group/en/decisions/0027/
- ADR-0028 · Publish one asset page per brand with every file at stable addresses · proposed, 2026-10-06 · https://brand.akribis.group/en/decisions/0028/
- ADR-0029 · Build the tokens package on every build with a calendar version · proposed, 2026-10-06 · https://brand.akribis.group/en/decisions/0029/
- ADR-0030 · Version the brand by build date and publish the decision log as the changelog · proposed, 2026-10-06 · https://brand.akribis.group/en/decisions/0030/
- ADR-0031 · Deliver the shared layer of every site as one Astro package with a starter, and check each build inside it · proposed, 2026-10-06 · https://brand.akribis.group/en/decisions/0031/
- ADR-0032 · Name the shared pages in each language and check the spellings on every build · proposed, 2026-10-06 · https://brand.akribis.group/en/decisions/0032/
- ADR-0033 · Write impersonal with usted, keep a claims register, and check the voice on every build · proposed, 2026-10-06 · https://brand.akribis.group/en/decisions/0033/
- ADR-0034 · Photograph real work, draw icons from IBM Carbon, and check every image a site serves · proposed, 2026-10-06 · https://brand.akribis.group/en/decisions/0034/
- ADR-0035 · Render each site's own layer from the CMS's windows inside the site package, cached at the edge by tag · proposed, 2026-10-06 · https://brand.akribis.group/en/decisions/0035/
- ADR-0036 · Build every unit site from one information architecture: the tree, the axes and the relations · accepted, 2026-10-06 · https://brand.akribis.group/en/decisions/0036/
- ADR-0037 · Render every site light by default and dark only on request · proposed, 2026-10-06 · https://brand.akribis.group/en/decisions/0037/
- ADR-0038 · Check AKRIBIS's own words, not the partner's it quotes · accepted, 2026-10-07 · https://brand.akribis.group/en/decisions/0038/
- ADR-0039 · Let a site keep its own proven contact form · accepted, 2026-10-07 · https://brand.akribis.group/en/decisions/0039/
- ADR-0040 · Allow YouTube's privacy-enhanced player for partner video · accepted, 2026-10-07 · https://brand.akribis.group/en/decisions/0040/