If a Number Is on the Page, It Needs a Source
My portfolio and work pages had believable but conflicting project counts. The fix was to stop treating metrics like copy and start treating them like derived data with generators, shared imports, and an audit surface.
FTI, LDR Hub, Vela, Doldol
after the sync pass
Jenn site, LDR Hub, Doldol
public numbers need provenance
The bug looked small, but it was architectural
What Was Broken
No owner
Copied Metrics
FTI page counts had drifted across the work page, portfolio page, case study, and older stakeholder material because each surface carried its own literal.
Harder to catch
Believable Wrongness
The dangerous part was that every count had been true at some point, which made the mismatch easy to miss and hard to challenge without retracing the source.
Maintenance debt
No Inspection Surface
There was no internal page that said which numbers were canonical, which files consumed them, or whether a stale literal had crept back in.
A tiny measurement system, not more manual edits
What The Fix Needed
Counting rule
Generator
Each metric family gets code that explains what is counted, what is excluded, and how the public label is derived.
Readable output
Snapshot
The generator writes JSON so the count becomes inspectable, repeatable, and easy to reuse across pages.
Single import path
Shared Module
Public cards import one shared source instead of retyping values in multiple components.
Failure visibility
Audit
A metrics audit checks that consumers still point at canonical sources and flags stale literals before they quietly ship.
The pattern is now live in three directions
Where It Landed
Cross-repo count
FTI Portal
The public `130+` label now comes from a generated snapshot of the LDR Hub route inventory instead of conflicting copy across Jenn site surfaces.
Local structure
Vela
Musings, projects, tools, and domains now derive from the actual site structure, so the work card updates when the underlying content changes.
Client showcase
Doldol
The portfolio card now reads actual page counts and flash-design inventory from the Doldol repo rather than stale hand-entered numbers.
The bug that finally forced this was embarrassingly ordinary: I kept seeing different page counts for the same FTI project. One surface said 71. Another said 72. Another said 88. An older stakeholder-facing artifact still said 64+. None of those numbers were random. They had just been copied into too many places and had stopped sharing an owner.
That changed how I thought about these cards. A metric on a portfolio page is not just decoration. It is a public claim. If the site is using the number to signal scope, then the number has to survive the same scrutiny as any other claim. "Seems right" is not enough.
So I stopped editing the cards directly and built a small supply chain instead. The first step was a generator: code that counts from the real source repo or data structure and writes a snapshot JSON file. The second step was a shared module that public pages import instead of carrying their own literals. The third step was an audit page that checks whether those consumers still point at the canonical source and whether stale values have reappeared.
That pattern is now running for the FTI portal, for Vela, and for Doldol. The FTI count is derived from the LDR Hub repo with an explicit inclusion rule and a public label of `130+`. Vela counts derive from the Jenn site content structure itself. Doldol reads page inventory and design counts from the client repo. The audit surface now shows four tracked metric families and reports whether they are in sync.
The lesson is simple and reusable: if a number is public, it needs provenance. Not necessarily a giant dashboard, and not a live analytics stack. Just a clear counting rule, one import path, and a place where drift can become visible before it becomes embarrassing.
SOURCE REPO / DATA -> count rule in code -> generated snapshot JSON -> shared public data module -> card imports canonical source -> internal audit verifies no stale literals THE RULE If a number is on the page, it needs a source. THE PAYOFF - one owner per metric family - easier updates across work / portfolio / case study surfaces - a visible audit trail when counts change - less "this used to be true" drift