Build Log
When One Site Improves the Standard
A standard becomes useful when it remembers actual work. On 2 July the Knowledge Manager record promoted lessons from this project into the shared website standard.
From local choices to reusable rules
The site had combined a utility-first homepage with a content ecosystem, generated factual pages from the same verified data as the tool, encoded shareable calculator state in URLs, and built matching legal and error surfaces. Those were not abstract recommendations. They were already working together in a release.
The portfolio standard adopted that shape for future utility sites: keep the tool direct, surround it with genuinely useful guides and segment pages, generate facts from shared data, maintain separate Articles and Build Log roles, and preserve clean shareable state without turning query strings into duplicate canonical pages.
Incidents teach too
The wrong favicon and an overlapping social preview became explicit visual-QA requirements. Empty interface placeholders became a rule against shipping dead layout. A mismatch between privacy language and analytics behaviour became a requirement to describe actual data flow. Later, URL redirects and thin computed output further tightened the standard.
This is the difference between a style guide and an operating standard. The latter records why a rule exists, the symptom it prevents, and how another project should verify compliance.
What became standard
The Knowledge Manager treats project history as an input to governance. Proven patterns travel outward; brand identity does not. New sites inherit release discipline, evidence requirements, and architecture while remaining visually and editorially distinct.
The exemplar pattern can be seen in the utility-first homepage, the pillar guide, and the separate Articles and Build Log hubs.