A social link asserts identity, so it needs a human verification, and the check enforces that a human did it
Decided
No URL on an identity host — LinkedIn, GitHub, X, Facebook, Instagram, YouTube, Crunchbase, Clutch — may appear in shipped source unless somebody has signed in to that account, confirmed we administer it, and written the date and the login into VERIFIED_PROFILES. The register is empty, so the footer's social row renders nothing rather than something.
Affects: scripts/check-social-identity.mjs (new), config/site.ts, components/layout/site-footer.tsx, package.json
What the problem was. config/site.ts carried three social URLs, all three of which resolved, and none of which was ours: linkedin.com/company/novel-systems is NOVEL SYSTEMS PVT LTD, github.com/novel-systems is a two-follower organisation in Finland, x.com/novelsystems is Novel Power Shop in Lagos. Each had been written by guessing the handle from the company name. They rendered in the global footer on every page, so for as long as they were live the "check us out" affordance pointed at three unrelated businesses.
Why `check:links` could not have caught it and still cannot. That checker deliberately makes no network calls, and adding them would not help: a 200 from linkedin.com/company/novel-systems is a true statement about *reachability* and says nothing about *ownership*. Those are separate properties. The link checker owns the first; this script owns the second.
Why the enforcement is a register rather than a fetch. No automated check can tell whether the humans behind an account are the humans behind this company. So the script does the only sound thing: it refuses to let a social URL ship unless the verification has been written down, with a date and a named login so a stale entry can be traced to somebody who can re-confirm it. The verification is human; the enforcement that it happened is mechanical. The failure mode this closes is not "wrong URL" — it is "URL added without anyone checking", which is what produced all three.
Two escapes, and they mean different things. // third-party-profile: <who> marks a URL that is somebody else's account and therefore not a claim about us — linking a vendor's GitHub org from /integrations is legitimate, it just has to say so. // build-identity: <vars> marks a URL whose identifying segments are interpolated from the build environment; lib/engineering-evidence.ts builds its commit link from VERCEL_GIT_REPO_OWNER and VERCEL_GIT_REPO_SLUG, so whatever repository Vercel actually deployed from is the one that gets linked. That is a *stronger* guarantee than a register entry, because a typo cannot point it at the wrong account. The second escape is honoured only when the matched URL still contains a ${, so it cannot be copied onto a hard-coded handle to silence the check.
The alternative that was rejected. Fixing the three URLs and moving on. That repairs the symptom and leaves the mechanism — guess a handle, see that it resolves, ship it — completely intact.
What would have to change for this to be wrong. If an empty footer social row ever costs more than a wrong one, this inverts. It does not: an absent link teaches a reader nothing, a wrong one teaches them something false.