Build every site in four layers and verify what each must carry

Context and Problem Statement

Twelve sites, five of them real, each built on its own. The audit of 5 Oct 2026 found four implementations of the endorsement with three wordings, four footer variants of which none lists the units, at least six unit directories reading five data sources that disagree (eight units on three sites, nine on two, two sets of verbs), legal pages and a 404 on one site only, no consent anywhere, five language switchers and 95 hand-copied logo files. Each site invented what the group should have given it. What must every AKRIBIS site have, what may it change, and what is its own, in a form a build can verify?

Decision Drivers

Criteria 1 (trust: the same company everywhere), 2 (one coherent, expandable family), 7 (three languages) and 9 (generated and tested) of ADR-0009.

Considered Options

• Four layers with the patterns each holds, the pages every site has and the settings a site may touch, as data that the site checker verifies
• A written checklist per site, reviewed by hand before each deploy
• One shared layout component every site must mount, with the rest free

Decision Outcome

Proposed: the four layers, as data in brand/anatomy.yaml, published as /anatomy.json and verified by the checker (ADR-0025) through a data-pattern marker every shared component renders.

• Group. Identical on every site, 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 and the tokens. It says the site belongs to AKRIBIS and what the group is made of.
• Shared. One component, one source, configured by the site with its brand, its language and its content: the header, the language switch, the skip link, the contact form, the 404 page, consent.
• Expression. What a site sets through settings and never through code: its brand file, its imagery (topic 2.7), which units it features first, its tone within the voice (1.5).
• Own. The site’s content and the pages only it has, built with the tokens and the patterns and owned by the unit.
• Kinds. Unit sites, the parent (akribis.group) and AKRIBIS One (akribis.one). The anatomy says which patterns each kind carries: every kind carries the skip link, the header, the language switch, the group footer with the directory and the legal line on every page and a 404; a unit also carries the group bar with the endorsement on every page and the One module on its home. The parent and One are the endorsers, not the endorsed.
• Pages every site has, in each language and with translated slugs: home, contact, thank-you, privacy, legal notice and terms, 404.
• A site may change its brand file (the only colour setting), its imagery, which units the One module and the directory feature first, its own pages and navigation. It 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.
• Ownership of shared texts. The endorsement, the legal line and the form’s labels are Brand’s data in the three languages (today in units.yaml and the site strings). The legal pages’ text is the company’s, published by Brand as data when Voice (1.5) and legal review decide it. A site shows these texts; it translates and edits none.
• Verification. Each pattern renders data-pattern="<id>"; check-site.ts --kind <kind> reads the anatomy and fails when a pattern due on a page is missing. This site, of the parent kind, passes with every page carrying its five patterns and the 404 its own.

Consequences

• Good, because “what every site has” stops being a review item and becomes a failing build.
• Good, because a new unit’s site is a kind, a brand file and its own pages; everything else it inherits.
• The anatomy names patterns the sites do not have yet (legal pages, 404, consent): building them is Phase 6 and the sites’ rebuild; the list is the contract they are built to.
• Open: whether akribis.one carries a group bar; the templates of own content (product, service, case, article) and where they live; how the Wagtail PIM feeds the own layer.