Governed Web Build System

The operating problem

A website is a working system that changes often: its copy, pages, inquiry form, structure and the checks around them. Without control, a decision agreed in review gets lost during implementation, a later change quietly undoes an earlier fix, and nobody can say with certainty which version was approved.

BJV's own website had that problem. The answer was not more effort but a system.

The six controls

These are the six controls named on the homepage, in the same order. Each is shown with what it does in practice on this website.

1. One authoritative record of the current state

   A single record states what is current and what is history: which engagements are offered, what the primary action is, and that no price or duration is published. Older records are kept unchanged and classified as history rather than rewritten.

2. Evidence graded by what it proves

   Every case on this website states what it demonstrates and what it does not. A screenshot is treated as a picture of one page at one width, and a lab speed score as a lab result. Neither is presented as a real-world outcome.

3. Changes built only on already-accepted versions

   Each change starts from the version that is live and is reviewed as a preview of exactly that change. Work that was not accepted is never used as the starting point for the next change.

4. Review scaled to each change's risk

   A wording change is checked against the claims rules and the pages it touches. A new page adds its own checks for structure, links, claim limits, accessibility and behaviour without scripting. A change to the inquiry form is checked against the form's registration, so no answer is silently dropped.

5. Clear limits on who can make each decision

   The build process may prepare, test and propose. Prices, identity, privacy wording and the release itself are decided by the owner, and legal text by legal review.

6. Separate approval before a verified change is released

   Passing every check does not release a change. Release happens only on the owner's explicit instruction, and the released version is then confirmed to be the one that was tested.

The checks behind each change

• 90rules checked against the website's governing records
• 131checks that run with scripting turned off
• 526checks against the rendered website: layout at each width, keyboard use, reduced motion and page content
• 23checks that are themselves tested to fail when they should

These figures are read from the website's own verification record, which is regenerated from live check runs and verified on every change, so they cannot drift from the checks behind them. They count technical checks. They are not business results.

What it looks like

Captures of this website. The fixed header is hidden in each capture.

What this demonstrates

BJV has built and documented a controlled system for its own complex production work.

What this does not demonstrate

Client ROI, reduced customer costs, superior market performance, commercial adoption, or universal applicability.

What this means for a client workflow

The same controls shape how BJV approaches a client's workflow: establish what is current, grade the evidence, build only on what was accepted, scale review to risk, keep each decision with the person who owns it, and release only on their approval. This page shows those controls working on BJV's own system. It does not show them working on a client's.