Build every unit site from one information architecture: the tree, the axes and the relations

Context and Problem Statement

ADR-0035 makes the CMS tree the site: /[locale]/[...path] draws whatever window 4 answers at that path. That holds only if the tree is the site, and on 6 October 2026 it is not. In the live CMS the node aplicaciones/ holds akribis.info’s six industries, which the site publishes under /industrias/, while /aplicaciones/ on the site is 33 other pages (16 industries and 17 applications) that have no node at all; and the site itself called two different levels “industries”. The instrument-type and brand pages of the site’s three-axis menu have no node either; the brand is free text on Product.manufacturer; of 34 application categories one is live (clean-room), and the migration that creates the rest is in the CMS repository but not deployed. Rendered by the package as it stands, /es/aplicaciones/ciencias-de-la-vida-y-farma/ would show an industry inside Applications, and 34 live addresses would be 404.

akribis.info is to become the standard for every unit site, and its most valuable asset is this structure. How is a unit site’s information organised, so that the package can draw any unit from its department in the CMS without losing what akribis.info does, and without each site inventing its own?

Decision Drivers

Criteria 1 (trust), 2 (one family), 7 (three languages) and 9 (generated and tested) of ADR-0009; ADR-0023 (the layers: the own layer is the unit’s), ADR-0035 (the tree is the site); akribis.info’s decisions 16, 16.1, 18, 19 and 20 and its three-layer taxonomy spec (2026-05-29); the CMS contract (PIM-de-Akribis-One/cms/CONTRACT.md); vaisala.com’s structure, which akribis.info shares and from which partner content is loaded.

Considered Options

• Three things kept apart: the tree (written pages, which give the address, the breadcrumbs and the menu), the axes (typed catalogue categories and the manufacturer entity, which decide what products and publications a page shows) and the relations (fields an editor sets, such as an industry’s segment); one written page per axis value
• The tree alone: every cross-cut written as nested pages (/industrias/x/aplicaciones/y/)
• Axes alone: pages generated from every category and combination, with no written tree

Decision Outcome

Proposed: the first option.

• A path is a page someone wrote. Every address is a node of the department’s tree. A combination of axes lives in the query string, noindex, follow, with its canonical on the written page (akribis.info’s decision 18); it becomes a path only when someone writes it.
• The axes are typed. Category.kind is one of magnitude, instrument_type, industry, application; the manufacturer is its own entity (logo, partner status). Products and publications link to them. A grid or a rail is always asked for by key, never by title.
• One page per axis value, bound to one key. MagnitudePage (exists), InstrumentTypePage, ManufacturerPage, FamilyPage, IndustryPage (16 for AKRIBIS), ApplicationPage (17). The page draws the products and publications of its key and the crossings with counts; a crossing with zero results is not offered, an empty page is not indexed.
• Segments group; they do not classify. A segment (Kanon: segmento, the customer-facing grouping; vertical is internal to sales and never public) is a written SegmentPage at /segmentos/<slug>/ that lists its industries and applications. An industry or application carries its segment (FK) and may appear in others; no product is classified by segment. Decided by Demian Montes de Oca, 2026-10-06: six segments, sixteen industries, seventeen applications, three names for three levels.
• The unit tree (a department’s root per language): instrumentacion/ with magnitud/, tipo/, marca/, familia/ and the catalogue; the unit’s topic sections (for AKRIBIS equipamiento/, metrologia/, meteorologia/, servicios/); segmentos/ with the segments; industrias/ with the industries; aplicaciones/ with the applications, flat; expertise/ with the rubrics; nosotros/; contacto/. A unit uses the branches it has; their order is the editor’s.
• The group’s pages stay out of the tree. The ecosystem and its bridges come from the unit register (units.json, the order of ADR-0010); thank-you, privacy and legal are the anatomy’s shared pages (ADR-0032).
• Navigation is derived. The primary nav is the root’s children; a panel is an item’s children, and Instrumentation shows its axes as columns. The footer is drawn from the same nodes. Breadcrumbs follow the tree, never the visit; a product is always Home → Instrumentation → product.
• Every template has the same regions: a head (breadcrumbs, eyebrow, title, summary, primary action), the body in the editor’s order (sections[]), rails derived from the axes, the ecosystem narrative and a closing CTA from voice.yaml.
• Partner content is a source, not a copy without a name. Every page carries source: {partner, url, retrieved}; a page loaded from a partner (Vaisala first) shows its attribution. An AKRIBIS page can later replace or combine partners’ pages for the same node at the same address.
• No address that answers today stops answering. A unit moving onto this architecture keeps every live URL as a 200 or a single 301, proven against a crawl taken before the move.

Consequences

• Good, because a unit’s site is its department’s tree: the package draws akribis.info and AKRIMET with the same code, and a new axis value is a page an editor writes, not a deploy.
• Good, because the axes give every page its products, notes and crossings without anyone listing them, and a product renamed or moved updates every page that shows it.
• Good, because the three-layer taxonomy akribis.info built by hand (6 segments, 16 industries, 17 applications) and its three-axis menu become CMS data every unit can use.
• Bad, because the CMS needs new page types, a typed category, a manufacturer entity and a move of six pages, and 22 addresses move with a 301 (segments to /segmentos/, industries to /industrias/), before the package can render akribis.info; until then the site keeps its own pages for those branches.
• Bad, because slugs below the section stay Spanish in English and Portuguese until the CMS has translated slugs.

Confirmation

akribis.info’s ledger (docs/19-ledger.md, generated by scripts/ia-ledger.mjs) has a row for every address the reference build answers, naming its node, its page type and its template; the rebuild is accepted when the live check answers every row and every production address with a 200 or one 301.

More Information

akribis.info docs/19-arquitectura-de-informacion.md is the site’s version of this record, in Spanish, with the full tree and the list of CMS changes in order.