The Standing Rules Behind Every Build
Every build here is held to an internal design system — a running record of real mistakes, what caused them, and the rule each one produced. Most of it stays internal because it's just engineering notes. These 27 are the ones that matter most broadly, published for the same reason the incident log is public: it's easier to trust a standard you can actually read.
The Core Standard
A verified 100/100/100/100 means exactly 100
99 is treated as an unfound bug, not a rounding artifact. Any page carrying the standard's claim gets re-investigated until the real cause is found — checked against sibling pages that already hit 100, not accepted as "close enough."
Every claim needs a same-sentence evidence link
Not a link somewhere else on the page — in the same sentence as the claim itself. This is the single largest factor in whether an AI system chooses to cite a claim versus ignore it, confirmed by live citation testing across four AI engines.
If you can't show your work, don't claim the result
Applies equally to performance scores, accessibility compliance, SEO structure, and our own mistakes. A screenshot from launch day is not proof; a live, re-runnable link is.
Never claim what you can't currently verify
A badge from the day a site briefly hit the standard means nothing three years later if nobody re-checked. The standard is a practice, not a certificate — it has to be re-earned continuously, not claimed once.
Verification Discipline
AI grading tools are unreliable for schema — verify before trusting
Multiple AI systems (Gemini, Perplexity, ChatGPT) have independently fabricated schema-related critiques by reading rendered visible text instead of parsing the actual script block. Confirmed across seven or more separate grading sessions. Any AI-reported schema issue gets checked against the real source file before anything is changed.
Treat every automated finding as a lead, not a verdict
Accessibility scanners, AI graders, and schema validators all produce false positives and false negatives. In one real case, an AI-proposed "fix" would have deleted working functionality — a focus-management system and an auto-updating banner — had it been applied without checking the actual code first.
Diff before merging any externally-reviewed file
Before accepting any "here's the merged file" claim — from another AI, another session, or another person — diff it against the current live version and categorize every difference. Accepting it wholesale risks silently reverting real, same-day work.
Documentation of intent and the shipped artifact can drift apart
A written record saying a fix was made is not proof the fix exists. Check the actual file directly, every time, even when a detailed log says otherwise.
Verify a shared UI element's current full state before extending it
Adding to a shared nav, header, or component without checking what's already there has produced duplicate content and undetected sizing bugs more than once. Check the whole element, not just the piece being added.
Performance & Accessibility
Reserve layout space for anything that loads or changes after first paint
Any element that updates its own content via client-side JavaScript after initial render needs its space reserved in CSS from the start, sized for the largest realistic content it will ever show — not just the placeholder. An auto-updating banner shipped without this caused a real, same-day Cumulative Layout Shift regression that dropped a page from a verified 100 to 97.
Never restate a live count in more than one place
Every number that can change over time — incident totals, audit counts, platform counts — has exactly one canonical page that states it. Every other page links to that page instead of repeating the number. A number that's sometimes wrong is worse for trust than a number that's always right but one click away.
Accent colors need a text-safe variant, computed, not eyeballed
Light or mid-tone brand colors are fine for borders and backgrounds but frequently fail WCAG contrast as text color on light backgrounds. Compute the real ratio before approving any brand color for text use.
Any link styled by color alone needs an explicit underline
Color-only links with no other visual distinction fail WCAG 1.4.1. This applies everywhere a link's only difference from surrounding text is its color.
No horizontal scrolling, checked proactively on every build
Tables and wide content default to a responsive stacked pattern below 600px rather than being caught after the fact.
AI Search & Structured Data
FAQ schema and the visible FAQ ship together, every time
Adding a new FAQ answer to the visible page without adding the matching entry to the FAQPage schema block (or vice versa) is exactly the kind of drift between what a page shows and what it claims that undermines the whole point of structured data.
Locate the specific schema block before scripting an edit
On any page with multiple JSON-LD script blocks, a generic "first closing bracket" pattern will silently corrupt the wrong block. Find the specific @type marker first, then that block's own boundaries — verified by parsing every block with a real JSON parser afterward, not by trusting a script's own success message.
A direct-answer opening beats a claim built up slowly
AI systems extract answers most reliably from content that states the core fact plainly and early, then elaborates — not from a page that builds toward its point across several paragraphs.
Client-side JavaScript computation is not a substitute for correct static content
Some AI crawlers don't execute JavaScript. If a page's raw HTML states one number and a script silently corrects it to another for real browsers, a non-JS crawler sees — and may cite — the wrong one. The fix for a stale number is architectural (one canonical source), not a client-side patch.
Content Integrity
Published entries are never edited after the fact
Whether it's an incident log entry, a dated blog post, or a transcript of a real conversation, the record reflects what was actually true when it was published. Editing it later to match a current number would falsify history — the fix is to note the drift, not erase it.
A private page is still a reference
Standing exclusions (like specific case studies removed from the public portfolio) apply to internal tools too, not just public pages. Building a private tracker that references excluded content still violates the exclusion.
Don't supply unstated assumptions that make a request seem safer than it was written
When building anything involving a real, named, identifiable person, get their consent before publishing rather than assuming a well-intentioned surprise is welcome — especially where a professional or licensing context is involved.
Client accuracy over portfolio size
Pages describing an outreach target as a client get corrected the moment it's confirmed they never actually became one, even if that means removing polished, published work from the portfolio.
Process & Delivery
Grep the whole site for a number before shipping any change to it
A stale price, count, or claim rarely lives in exactly one place — the visible page text, the meta description, the Open Graph tags, and a structured data block are four separate locations that can each drift independently.
Session close means the incident log gets updated first
Every work session ends with the incident log reflecting what changed, before considering the session done.
New pages get submitted for indexing, not just uploaded
A newly created page needs to be personally submitted to Google Search Console and Bing Webmaster Tools — uploading it to the server alone doesn't make it discoverable.
Deliver as one consolidated package, sized to the actual changes
Once an initial full upload has happened, later deliveries include only what was actually touched that session — not the entire site every time — to keep uploads practical on a phone-only workflow.
Ordered lists take new entries at the top
Consistent placement so the most recent addition is always the first thing seen, not buried at the bottom of a growing list.