VALUE.md - "The Web Quality Discipline" canonical reference

Date: 2026-06-19 Type: Research brief, written as a VALUE.md per the Keep a Value discipline (see https://www.keepavalue.com/). Addressed to: A research LLM with web-research, code-reading, and long-form-writing capability. The brief is self-contained; no prior conversation context is required.

This brief is itself a contract: a working VALUE.md for the research project. The reader's job is to read it once, produce the deliverable described below, and pass the gate at the bottom of this page.

Q0 - Grounding observation

On 2026-06-18 the author of Keep a Value spent a single working session moving the live site at https://www.keepavalue.com/ from "audit-clean" to "Lighthouse 100/100/100/100 with 0 failed audits, 46 of 77 audit findings shipped, 6 strengths confirmed, 7 obsoleted by a clean architectural refactor, 8 accepted as design-intent, 7 documented as vendor-blocked, 2 awaiting external action, 1 documented as a permanent-URL commitment, 0 still open." The workflow used:

  1. A multi-agent audit produced a register of 77 findings across 7 axes (Lighthouse, HTTP, SEO, Content/IA, URL/Canonicals, Sitemap/Crawler-Signals, Code/HTML-Quality).
  2. Each finding carried fields: severity, evidence, recommendation, sources, effort, how-to-verify-the-fix.
  3. Findings were re-rated by IMPACT = (user-visible + security + discoverability) x effort-multiplier, so that severity calibration didn't hide a real CVE under a "medium" label.
  4. Sub-agents were dispatched in parallel batches by axis-cluster to ship the fixes, with deterministic verification of each shipped fix.
  5. A final closure pass triaged the remaining items into shipped / obsoleted / strength / accepted / vendor-blocked / external-pending / documented.

The work was completable in one session because the author already had a mental model of the axes, the best practices on each, and the verification recipes for each finding. Most web developers, including the senior ones who care about their craft, do not have this mental model written down anywhere. They have fragments: a Lighthouse run from their CI, a Google Search Central article they bookmarked, a Twitter thread on HTTP/3, a vague sense that "I should be doing SRI." When they want to hold their site to a high standard, they have to assemble this model from first principles every time, and they have no operational artifact that converts the assembled model into shippable work.

The build trap here is specific: the senior web developer builds another performance pass, another a11y pass, another SEO pass - each pass produces a list of opinions, none produces a discipline. The recipient experiences the result as "my site is good according to what I checked, but I don't know what I didn't check, and I have no way to know if I regressed last week."

Q1 - Who it's for

The senior web developer who holds their public-facing work to the highest standard available in 2026, and who personally owns the one domain in question. They run a personal site, a docs site, a startup landing page, an open-source project page, or a small SaaS marketing surface. They have shipped real production code. They have read Lighthouse reports and run them in CI. They know what Brotli is and have opinions about HTTP/3. They are not the audience for "5 SEO tips for beginners."

One named example (per Keep a Value's recipient-naming rule): the author of an open-source library who launches a new docs site, runs Lighthouse on it, sees 99/100/100/100, and is told by the report "DOM size could be smaller." They want to know: which other axes did Lighthouse not check, and how do I bring every axis to the same 100? They have a Monday afternoon, a Cursor session open, and the energy to do the work. They do not have the canonical reference.

Scope discipline (whom this document is NOT for, and why): this document is for the operator of a single domain who controls the CDN, the DNS, the build, and the content. It is not the agency taxonomy for a 60-person shop shipping 40 client stacks across Next.js / Astro / Sanity / Vercel / Cloudflare. The agency taxonomy needs additional standalone axes (accessibility-as-legal-exposure, consent-mode / cookie governance, internationalization / hreflang, security-headers as a lane separate from HTTP versioning, performance-budgets as RUM/CrUX separate from Lighthouse lab scores) that this document covers but does not promote to top-level axes. Agencies and platform teams should treat this document as an input to their internal QA taxonomy, not a replacement for it. The brief names this scope explicitly so that a senior agency lead reading the deliverable does not assume the absence of an axis means it doesn't matter; it means it is out of scope for the solo-operator framing.

Q2 - What changes for them

Before: A senior web developer holding their site to a high standard has the following operational reality:

The cumulative effect: they ship a "good enough" site, periodically panic about what they might have missed, and have no way to measure regression or improvement except by re-running Lighthouse and trusting the score.

After: Reading the document this research project produces, the same senior web developer can do all of the following without further reading:

The change is operational. The recipient stops assembling the discipline from first principles every quarter and instead operates against a written reference that survives across projects, browsers, CDN vendors, and the next 18 months of web platform churn.

Recipient-defined verification: when this document lands, the same senior web developer should be able to:

  1. Read it in a single sitting and identify every axis they were not auditing before.
  2. Run the baseline-capture recipes against their own site within 90 minutes.
  3. Produce their own audit register with no fewer than 50 findings (their site won't be perfect) and no fewer than 5 strengths.
  4. Ship at least 3 trivial-effort fixes within the same week.
  5. Re-run the baseline 90 days later and observe a measurable delta.

If a sample of three such developers can each do steps 1-5 against their own site, the document delivered. If they bounce off because the document is too abstract, too tied to one CDN, too anecdotal, too academic, too breezy, or too long, the document failed.

Q3 - How will you know the change happened for them?

A stranger (defined here as: a senior web developer who has never read Keep a Value, has never spoken to the author, and only sees the published document) can do the following without asking for help:

The six-part gate this document must pass before publication

  1. No hedge-words. No "you might want to consider", "it's generally a good idea to", "depending on your situation". Replace with "do X" or "do Y in case A; do Z in case B". Hedge-words are the discipline's #1 indicator of a writer who has not done the work.
  2. A stranger gets it. A senior web developer who has never heard of Keep a Value can pick up the document cold and act on it within 90 minutes. The document is verified against this gate by giving it to three real senior web developers (not LLMs, not friends-of-the-author) and asking them to act. If two of three bounce, gate 2 has failed.
  3. Reads aloud without footnotes. Every paragraph that names a concept either defines it inline or links to its canonical source. No "we'll come back to that"; no "see the Appendix"; no "if you don't know what this is, read X first" pointing at a non-canonical source.
  4. One recipient across all of it. The senior web developer named in Q1. Not "developers and PMs". Not "SREs". Not "marketers who care about SEO". When the prose drifts toward another recipient (e.g. an SRE who runs production infra), the document explicitly names the drift and either prunes or scopes it.
  5. Subject test. The document only promises the writer's own behavior - it does not promise that Google will rank you higher, that LLMs will index you, that your conversion rate will improve, or that your site will be future-proof. It promises that the reader will have a written discipline at the end.
  6. Names what gets worse. Coverage of every 2026 quality axis produces a document that is longer than a blog post. The document is honest about that tradeoff. It says: "this is not the document you skim; this is the document you read once and bookmark."

What the document must NOT do

Anti-LLM-tell discipline

This brief is being handed to a research LLM, and the deliverable will be an LLM-authored document. The deliverable's biggest failure mode is that it reads as an LLM document: tidy, balanced, comprehensive-sounding, opinion-free, footnote-shaped, and full of phrases ("it's worth noting that", "in conclusion", "broadly speaking", "let's dive into") that mark the prose as machine-flattened. The discipline below names the tells and bans them. The reasoning is operational, not stylistic: a reader who recognizes one tell stops reading.

  1. No em-dashes, no en-dashes. ASCII hyphens only. Clauses join with commas, colons, semicolons, or sentence breaks. Em-dashes are the single most consistent token-level tell of unedited LLM output across major models in 2026. Banning them forces the writer to restructure sentences, which produces voice. Real authors use em-dashes too; the cost of false positives here is small, the cost of missing the tell is the whole document.
  2. No hedge-words. Same list as gate 1. Replace "may", "might", "could", "depending on", "in some cases", "you might want to consider" with "do X" or "do X when A, do Y when B." A hedge is a writer who has not done the work and is hoping the reader doesn't notice.
  3. No throat-clearing transitions. No "it's worth noting that", "broadly speaking", "in conclusion", "as we've seen", "this is where it gets interesting", "let's dive into". Cut and re-join. The transition was load-bearing only because the LLM was filling a sentence quota.
  4. No false-balance scoping. Every LLM-trained-on-the-web reflexively adds "of course, there are trade-offs" or "this depends on your specific context." When the document genuinely depends on context, name the contexts. When it doesn't, take the position.
  5. No comprehensive-sounding lists with no operational delta. "There are many tools available: X, Y, Z, and W" is a tell. The discipline is: pick one, say why, name what loses.
  6. Opinion-having is required, not optional. Every axis section ends with "what we recommend and why." The recommendation is allowed to be vendor-bounded, controversial, or unfashionable. The recommendation is not allowed to be absent. An LLM document with no recommendations is the failure mode this section exists to prevent.

The taste problem this section is fighting: a research LLM, given a corpus of MDN + web.dev + W3C + RFCs, will produce a beautifully-organized restatement of those sources with a register attached. The reader who came for the discipline will recognize the restatement and bounce. The discipline IS the opinions; the corpus is the input.

Reference materials provided to the researcher

The research LLM should treat the following as the starting set of primary sources. The research should expand this set extensively; the list below is not exhaustive, just the load-bearing entry points.

Authoritative web standards

Browser vendor sources

Named-author primary-source blogs (allowed; not a substitute for the spec)

The anti-references section below disallows summarizing blog posts. Named-author technical blogs that publish original research and reproducible test results are a different category and are allowed as primary sources. The researcher should cite them by author and post, not by aggregator.

SEO + search engines

Emerging axes

Verification tools

Operational references

Anti-references

The researcher should not rely on:

Deliverables

The research LLM must produce:

  1. A long-form web-publishable document at the directory's dist/web-quality-discipline/index.html (path is suggestive; the operator will route it). Format: a single self-contained HTML file or a small directory with a clear entry point. The document is mobile-readable, has a table of contents, has anchors on every section, and works without JavaScript. Length is estimated at 10,000-20,000 words but is gated by coverage, not by a word count.

  2. A companion register template as a JSON file with a JSON Schema, plus a minimal HTML renderer for the JSON. The template's schema should generalize from the 77-finding register at keepavalue.com but be vendor-neutral. The template ships with a "starter set" of findings the document discusses, so a reader can fork it and have a real starting point rather than a blank file.

  3. A baseline-capture script (POSIX shell, ASCII-only, no em-dashes) that runs the recipes from each axis against a user-supplied URL and writes the results to the register's expected schema. Approximately 200-400 lines of bash. Should be able to run from any modern macOS / Linux machine with curl, openssl, jq, and Node available.

  4. A short maintenance note in the document's footer naming when the document should be re-audited (every 6 months is reasonable for fast-moving axes like the AI-crawler posture; every 18 months for stable axes like TLS / HTTP versioning).

How to know the deliverable is ready

The research LLM should not ship until the following are true. Each is verifiable in one or two commands.

How to know the deliverable failed

Promises

P1 - The brief is comprehensive enough to produce the document in one focused session. This brief is written so the research LLM doesn't have to come back with clarifying questions. If it does, the brief failed and gets rewritten.

P2 - The deliverable is recipient-tested. The author of this brief (or a delegated reviewer) will run verification recipes 1 through 6 against the produced document before accepting it.

P3 - The discipline survives the deliverable. When this document is published, the next audit of keepavalue.com (every 90 days per the schedule in the housekeeping note) will use this document as its reference, not a separate ad-hoc audit. If the document is good enough, it replaces the audit-discipline-from-scratch pattern.

What we don't promise

What we don't break

Stranger test on this brief itself

A senior web developer reading this brief cold should be able to:

If the cold reader cannot do all four, this brief has failed its own gate and needs another pass.