Link the evidence from the sentence that rests on it, because a link somewhere on the site is not a link where the claim is made
Decided
A page that publishes a figure attributed to an outside party links that party from the paragraph making the attribution, not from a sibling route. /security links status.novelsystems.ca where it reports measured availability. /contact names Cal.com, its host and what it does, in server HTML, beside the button that goes there — and still embeds nothing.
Affects: app/security/page.tsx (the measured-availability panel), app/contact/page.tsx (the #book block).
What produced it. A review of tasks 12 through 20 returned seven findings. Five were false, one was true, and one is genuinely outstanding.
The two false ones with the most force: "no public status page link (e.g. status.novelsystems.ca)" and "Sandbox exists conceptually, but not on a distinct subdomain." Both subdomains are live and have been for weeks. sandbox.novelsystems.ca serves the CPQ sandbox through the host rewrite in next.config.mjs; status.novelsystems.ca serves a Better Stack board that was reporting 100% on every component while the review was being written. The reviewer did not type either address. They looked for links, and against the status page they were nearly right: exactly one route on this site linked it, /support#status, which is not where anybody goes to check an availability number.
The one that matters is where they were looking when they concluded it. They were on /security, in the panel that prints a measured figure and says "Measured by an independent monitor polling from outside ca-central-1." That paragraph asserts the existence of a third party and then offers no route to it. A reader who wants to check the strongest verifiable claim on the page — not a target we set ourselves, but a number somebody else recorded — has nowhere to click. They concluded there was no status page. Given what the page gave them, that was the reasonable conclusion.
The distinction from D-071, which is the whole point of a separate entry. D-069 was an artifact at an address nobody guesses. D-070 was an artifact that could only be described, never fetched. D-071 was an artifact published at an address nobody walks to. Each was fixed by making the thing reachable.
This one was already reachable. STATUS_URL was in the footer's neighbourhood, on /support, one hop from anywhere. Reachability was not the failure. The failure is that the claim and its evidence were on different pages, and a reader assessing a claim does not go looking — they evaluate what is in front of them and move on. The unit of discoverability is not the site. It is the paragraph.
What the review got right. "CTAs exist, but no visible booking flow." /contact rendered a button labelled "Book a demo" and nothing else. The button has pointed at a published Cal.com event type with a connected calendar since task 16, and the markup disclosed none of that. To anybody assessing the site rather than buying from it, that button is indistinguishable from one that opens a form.
Rejected: embedding the Cal.com inline widget. It is the obvious fix and it is wrong twice.
It is wrong on privacy. lib/scheduling.ts declines to embed anything, and the reasoning there still holds: an embed is a third-party script with vendor cookies, which means a new subprocessor row in the privacy policy and a new category in the consent banner, on the one page where a visitor hands us their name and their employer. Trading a real commitment for a better-looking booking step is a bad trade, and the finding is not worth it.
It is also wrong on its own terms. A CDN-mounted widget puts an empty <div> in the served HTML. The reader who filed this finding reads served HTML. The fix would be invisible to precisely the person it was for — which is the argument D-071 already made against Swagger UI, arriving here from a different direction.
So the fix is prose: the vendor named, the host linked, the mechanism stated, and an explicit sentence that nothing third-party runs on the page. That is true whether or not any script executes.
What is still outstanding, honestly. Task 20 — Crunchbase and Clutch — is not done and is not blocked on engineering. Both directories ask for a legal entity, and the entity question put to the owner has not been answered. Clutch additionally lists firms by verified client reviews, and we have none; a profile with zero reviews is a worse signal than no profile. Both stay parked with T11 under D-068 rather than being filled in with something plausible.
What would make this wrong. If a page ever links so much that the links stop meaning anything, the rule inverts and the right move is a single well-marked evidence route. That is a real failure mode and this site is not near it: two outbound links were added, to two claims, on two pages.