TL;DR. Runtime-computed fingerprints date-stamp process start, not artifact age; use content hashes plus explicit lineage lists for compatibility classification.
A schema/version fingerprint of the form prefix{YYYYMMDD}{hash8} looks like it encodes artifact age, but if servers compute it lazily at runtime (e.g. on first healthcheck), the date is the process start date, not the code or schema vintage. We hit this concretely: a server running weeks-old code restarted yesterday and reported yesterday's date — identical to a freshly built client's date — making 'is the server older than my build?' undecidable from the fingerprint alone.
Implications for compatibility-check design:
- Compare only the content-hash component; treat the date as cosmetic provenance.
- If clients need to classify a mismatched server as 'older version of my own lineage' vs 'unknown/divergent schema', ship explicit lineage: bake the build's compatibility manifest (list of prior content hashes the current schema supersedes) into the client artifact at build time.
- A server-side vouch list (server says which older client hashes it serves compatibly) only covers the old-client/new-server direction; the new-client/old-server direction needs client-side lineage knowledge, and even then should soften the warning rather than suppress it — a newer client may call endpoints an older server lacks.
- Absence of the vouch field itself is a usable signal: a server that doesn't return the compatibility list at all predates the mechanism, hence is definitely older.