All specimens

Architectural R&D specimen 01 — Reference: this site

Zero-trust briefing pipeline, held to a measured performance budget

Architectural R&D specimen: studio research and development, built and measured in this repository. It is not client work and describes no client. Every figure on this page is measured or computed, and its method is stated.

Design question

Can a public website that takes enquiries from principals refuse everything it cannot verify, set no cookies and run no analytics, and still be measured at a Lighthouse performance score of 100 on desktop and on a throttled phone? This site is the specimen: the studio’s own front door, built to the tolerances it sells.

Evidence tier A: implemented in this repository and exercised by its tests. The measurements are lab data from one machine class; their limits are listed under Trade-offs and limits.

I

Constraint and tolerance

Three constraints were fixed before any code, and each is checked on every release.

  1. Trust boundary: nothing from the browser is trusted. Origin, body size, schema, honeypot and fill time, a bot check and a sanitiser run on the server, in that order. A request that fails any of them is refused, never repaired.

  2. Data minimisation: no cookies, no analytics, nothing stored in the browser. The only third party is a bot check, loaded at the last step of the form and only where delivery is connected.

  3. Frame cadence: the display’s own rhythm is kept while the page scrolls. In the sampled scroll the frame interval is 16.7 ms at the median and 16.9 ms at the 99th percentile on a 60 Hz display, one frame per refresh.

II

Architecture

One route, one pipeline, and a rendering path that keeps the framework off the critical path.

  1. Delivery pipeline: browser, origin check and rate limit, schema validation, bot check, sanitiser and priority class, then delivery by a signed webhook (HMAC-SHA256, idempotent) or by SMTP over TLS to the studio mailbox. Each step can refuse; a refusal ends the request and offers the visitor an email draft. The system fails closed.

  2. Rendering: server-rendered pages under an enforced Content-Security-Policy with a nonce per request. The framework starts after the first contentful paint behind a single loader script, so the first paint does not wait for it. Sections below the fold are drawn on demand against a measured placeholder height.

  3. Cryptography in the open: a security simulator on the page signs and seals a message in the visitor’s own browser with Web Crypto (HMAC-SHA256, AES-256-GCM), using the same functions and the same tests as the reference architecture.

III

Verification

Claims are held to executable checks, not to screenshots.

  1. Before every release a design audit of more than two hundred checks and an HTTP smoke test of more than a hundred and eighty run against a production build, followed by a real-browser flow in two viewports; a live check runs after the release.

  2. Accessibility is scanned with axe across pages, languages and viewports (no violations). The Content-Security-Policy is exercised in a real browser against the live site (no violations, no console errors). The share card is rendered and compared in every language the site is published in.

  3. Layout movement is tested as it happens: placeholder heights within 15 % of the drawn height, and choosing a budget level moves nothing. The browser’s layout-shift metric ignores shifts within 500 ms of a click, so the test compares positions and heights instead.

Delivery is verified end to end against a loopback SMTP receiver with a real bot-check token. No claim is made about any particular mail provider’s acceptance.

IV

Measured result and limits

What is measured, and the profile it was measured on.

Measured

These are the published, dated measurements of the live site. The frame figures are the intervals between frames of one recorded scroll of the whole page.

Lighthouse performance
100 · 100
desktop · mobile
Largest contentful paint
425 ms
desktop
Layout shift (CLS)
0.00
desktop
Frame interval (median · 99th percentile)
16.7 · 16.9
ms · 60 Hz display, one frame per refresh

Lighthouse, desktop preset, live production (syncflow.agency), median of 5 runs, Oct 17, 2026. Frame sampler: 1280×800, headless Chrome, 60 Hz, Oct 8, 2026.

Trade-offs and limits

What this design costs, and what the numbers do not prove.

  1. Lab data, not field data

    Lighthouse runs are lab measurements on one machine class. The mobile score is the median of runs on a quiet machine, as the profile above states; on a busy host the same build scores lower, because hydration falls inside the total-blocking-time window. A loaded run is never published as 100.

  2. Frame cadence, not frame work

    The frame figures are intervals between frames at 60 Hz, where 16.7 ms is one frame. They show that no frame was dropped in the recorded scroll; they do not say how long each frame’s own work takes.

  3. Strictness has a price

    An enforced policy and a route that refuses on failure mean a missing setting produces an error instead of a quiet success. The form says so before it is used and offers an email draft.

Measured on

  • Lighthouse 13.5 · live production
  • 412×823 · slow 4G · 4× CPU
  • 1280×800 · 60 Hz · frame sampler
Strategic Briefing