Build the tokens package on every build with a calendar version

Context and Problem Statement

No site imports a shared package; each keeps its own tokens (37 to 138 custom properties) and fonts. The topic settled only that packages are public. How many packages, what each holds, how they are versioned and how a site receives them were open.

Decision Drivers

Criteria 2 (one family) and 9 (generated and tested) of ADR-0009; ADR-0015, 0020 and 0021 (the token files); ADR-0022 (the data).

Considered Options

• One tokens package built from the published files on every build, versioned by the build date, downloadable from Brand and published to npm once the licence is decided
• One package with tokens and components together
• No package: the sites link the files on Brand directly

Decision Outcome

Proposed: the first option. brand/src/package.ts stages @akribis/tokens and packs it with npm into /packages/; an index names the version and the contents.

• Contents. The CSS files (base, type, shape, one per brand, all) with the font URLs rewritten to Brand’s origin, so the fonts have one home and one cache; tokens.json, units.json, contrast.json, anatomy.json and standards.json; a README with the link order and a licence file. No dependencies, no JavaScript; the rules file stays a web address, since it names the package.
• Version. The build date as a calendar version that npm accepts as semver: 2026.10.6. A version is a complete state of the brand; the data files and the changelog (ADR-0030) carry the same date.
• Publishing. Built and downloadable on every build; published to npm once AKRIBIS decides the licence (the marks, colours and texts are AKRIBIS’s; the fonts are OFL) and the npm organisation. Until then npm install https://brand.akribis.group/packages/<file> works.
• Components travel in a second package once their format is decided (topic 3.3); a tokens package has no reason to wait for them.
• Proof. The tests unpack the tarball and check its version, its files, that the CSS points at Brand’s fonts and that it carries no /fonts/ of its own.

Consequences

• Good, because a site pins a version, and the version names a day in the decision log.
• Good, because the package is a by-product of the build, never maintained by hand.
• Open: the licence and the organisation; automatic publishing once there is continuous integration; the components package.