The evidence page reads its exhibits by value, not by name
Decided
/engineering publishes the artifacts behind the claims made on /security#engineering — the migration SQL that enforces the margin floor in Postgres, the sixteen checks in the verify chain with each one's purpose read out of its own header comment, the test modules and their coverage gates, the five Lighthouse reports, the architecture diagram, and the commit being served. Every figure is read from the filesystem at build time. Nothing on the page is typed.
Affects: app/engineering/page.tsx (new), lib/engineering-evidence.ts (new), config/routes.ts, config/site.ts, app/security/page.tsx
The defect this decision was written to prevent, found in the first draft. getDatabaseFloors() originally selected constraints whose *name* matched /margin/. That returned four, of which two enforce nothing: quotes_margin_range permits margin_percent anywhere from -10 to 1 — everything the floor forbids — and margin_rules_min_quantity_positive is about quantity and matched only because its table is margin_rules. The page would have displayed four SQL exhibits under a heading asserting the floor is enforced in the database, and half of them would have contradicted it. Selection is now on the *value* CPQ_CONSTANTS.MARGIN_FLOOR, in both its 0.5 and 0.50 spellings, in addition to a /margin/i test on the expression. It returns exactly the two constraints that do the work.
The property that buys. Raise CPQ_CONSTANTS.MARGIN_FLOOR without writing the migration and the exhibit *empties* on the page, rather than continuing to display constraints that no longer say what the heading claims. The page fails toward silence.
Why the route is `force-static`, declared rather than inferred. Every input is a file on the build machine plus the git metadata Vercel injects. Those cannot change while a deployment is live. Rendering per request would re-read the same files and print the same values, forever, at a cost. Declaring it means that adding a cookies() or headers() call anywhere in the tree fails the build instead of silently converting the route to dynamic — and it makes explicit that the timestamp in the provenance block is the *build* time, labelled as such, because a reader who read it as "now" would draw a wrong conclusion about how recently anything was checked.
What the page's existence was actually for. The four engineering claims on /security were already true and already derived. What was missing was any way for a reader to check them. Discoverability was the gap, not the artifacts — which is why the page is registered in PUBLIC_ROUTES (so the sitemap and robots pick it up), linked from the footer's Resources column on every page, and linked from the section on /security that makes the claims.
What would have to change for this to be wrong. If the readers ever became a maintenance burden that outweighed the page — if the migration format changed often enough that the parser needed constant repair — the honest response is to delete the section, not to hard-code its output.