Zero Information Casualty (ZIC)

Information carried by position alone. If the reading order a sighted visitor would follow differs from the DOM order, the site is not conformant. CSS layout techniques must not be used to present content in a different sequence than it appears in the HTML.

Information carried by whitespace alone. Meaning must not be carried by blank lines, indentation, or spatial arrangement of text.

Navigation cues carried visually alone. Every navigation element must be meaningful in a sequential, non-visual context. Iconography is permitted; unlabelled iconography is not.

Placeholder link text. Links labelled “click here”, “read more”, “learn more”, or any text that does not describe the destination are not conformant. Every link must make sense when read out of context.

Violated heading hierarchy. Exactly one h1 per page. No skipped levels. Hierarchy must be structurally honest.

JavaScript for content delivery. Content that requires JavaScript to render is not available to agents or to visitors with JavaScript disabled or unavailable. ZIC sites deliver all content as static HTML. JavaScript may be used for progressive enhancement of interactions, never for primary content delivery.

Anti-agent measures. Any configuration that refuses, challenges, degrades, delays, or misleads a machine reader that a person sent is not conformant on public content. This includes bot-detection challenges, CAPTCHA walls, JavaScript gauntlets, indiscriminate AI-refusal metadata, CDN or WAF rules that block user-directed retrieval agents, discriminatory rate limits, and cloaking of any kind. Declining search indexing or model training is not an anti-agent measure, provided each decision is declared independently and does not obstruct sent agents.

Hand-maintained agent surfaces. See §3.6.

Unverifiable conformance claims. See Part Seven.

2.3 What ZIC Leaves Alone (new in v1.4)

The following were prohibited in v1.3 and are not prohibited now. The prohibitions are withdrawn, not softened.

Custom typefaces. A webfont carries no information and withholds none. Use whatever typeface you like. Two engineering notes, offered as advice and not as requirements: an external font request is a third-party dependency in the delivery path, which §1.8 should make you nervous about; and text must remain real text, because an image of text is a locked room under §1.11. Beyond that, ZIC has nothing to say about letterforms.

The system font stack (system-ui, sans-serif) remains a safe default and is what the reference implementation uses. It respects the visitor’s own font settings, requires no external request, and cannot fail to load. It is a recommendation. It was never a rule.

Brand and decorative colour. Accent colours, background colours, atmosphere, and visual identity are the publisher’s business, subject only to contrast (§2.1) and to the prohibition on colour as the sole carrier of information (§2.2).

Decorative imagery. Images that serve visual interest and carry no information are permitted without restriction. Mark them alt="" and this specification has no further interest in them. v1.3 stated that such images “should not exist.” That sentence was an aesthetic opinion wearing the uniform of an access requirement, and it is withdrawn with some embarrassment.

Layout. Multi-column layouts, grids, sidebars, cards, and asymmetry are all permitted, subject only to the requirement that DOM order match reading order (§2.1). The single-column reading layout is the reference implementation’s preference. It is not a rule and was wrong to be stated as one.

Ornament, illustration, iconography, whitespace, and visual richness generally. Not governed. See §1.12.

A conformant ZIC site may be beautiful. It may be ugly. It may be branded to within an inch of its life. What it may not be is a site that keeps a single fact where only one sense can reach it.

2.4 The Line Between Information and Decoration

The test for any element of a page, visual or otherwise, is a single question:

If this were removed entirely, would any information be lost?

If yes, the element carries information, and that information must also exist in the semantic layer.

If no, the element is decoration, and it is none of this specification’s business.

Spacing that reflects hierarchy: reinforces structure. Fine. Spacing that is the hierarchy: a casualty. A brand blue for headings: decoration. Fine. A brand blue that means “unread”: a casualty. A custom typeface because it feels right: decoration. Fine. Bold text that is the only indication that a term is defined: a casualty.

The question is never “is this decorative?” Decoration is permitted. The question is always: is any meaning trapped in here?

Part Three: Technical Specification

This section defines the technical requirements for ZIC compliance. These are checkable requirements, not guidelines.

3.1 HTML Requirements

Document language. Every page must declare its language via the lang attribute on the html element.

Landmark regions. Every page must use the correct HTML5 landmark elements: header, nav, main, footer. These must accurately represent the page structure. There must be exactly one main element per page.

Heading hierarchy. Pages must have exactly one h1. Heading levels must not be skipped. Headings must describe the content that follows them, not serve as decorative labels.

Skip link. The first focusable element on every page must be a skip link targeting the main element. This link may be visually hidden until focused. This is the keyboard rendering of the structural fact carried by the main element; see §1.15.

Image alt text. Every img element must have an alt attribute. Decorative images must use alt="". Informative images must have descriptive alt text that conveys the same information a sighted visitor would receive.

Link text. Every a element must have text that describes its destination when read out of context. If the link wraps an image, the alt text carries this responsibility.

Current page indication. The current page must be marked with aria-current=“page” in navigation, and must be distinguished by something other than colour alone.

Form labels. Every form input must have an associated label element. Placeholder text is not a label.

Table structure. Tables must be used for tabular data only, never for layout. Data tables must use th elements with appropriate scope attributes.

List structure. Lists must use ul, ol, or dl as appropriate. Items that are not structurally lists must not be marked up as lists.

3.2 CSS Requirements

Units. Font sizes must use rem. Spacing must use rem or em. Fixed pixel values that override visitor preferences are not permitted for text sizing.

Colour contrast. All text must meet WCAG AAA contrast ratio (7:1 for normal text, 4.5:1 for large text) against its background in the default rendering. See §2.1 for why this, alone among visual properties, is a requirement.

Colour scheme respect. The site must implement prefers-color-scheme: dark if a dark mode variant exists. The prefers-contrast: more media query must be implemented to enhance contrast for visitors who require it.

Focus indicators. The :focus-visible state must be clearly visible on every user-operable control. The browser default is acceptable. Custom focus styles must meet or exceed the visibility of the browser default. Per §2.1, a landmark focusable only via tabindex=“-1” may suppress its outline; no control may.

Reading order. Visual reading order must match DOM order. CSS properties that alter visual position — order in flexbox or grid, position: absolute, float — must not be used to present content in a different sequence than it appears in the HTML. Note that this constrains the relationship between layout and DOM, not the layout itself. Any layout whose visual order matches its source order is permitted.

No animation without consent. Any animation or motion effect must respect prefers-reduced-motion: reduce. If this media query is set, all non-essential animation must be disabled.

No other CSS requirements exist. Typeface, palette, ornament, and layout are not governed. See §2.3.

3.3 Metadata Requirements

Page title. Every page must have a unique, descriptive title element. Format: Page Name — Site Name.

Meta description (amended in v1.4). Every page must have a meta description that accurately summarises the page content. It must be a true and useful summary of the page, and it must be unique across the site.

No character range is specified. The 150-160 character range in v1.3 was inherited from search-engine display truncation — a fact about what one crawler happens to render, not a property of a well-formed document. §1.6 states that this specification describes what a well-formed site is rather than what current crawlers reward, and the range contradicted that. It is removed. Write a description that is true. If it is also 154 characters, that is a coincidence and not a virtue.

Open Graph tags. Every page must implement og:title, og:description, og:url, and og:type at minimum.

Schema.org JSON-LD. Every page must implement appropriate Schema.org structured data. At minimum: WebSite on the home page, WebPage on content pages, Person or Organization on about pages. This is the primary interface between the site and AI agents attempting to understand its content and context.

Licence metadata. The site’s content licence must be stated in machine-readable form: as the license property in Schema.org JSON-LD on every page, as a human-readable statement in the footer, and in the llms.txt file. An agent must be able to determine what it may do with the content without leaving the page.

Canonical URL. Every page must declare its canonical URL via link rel=“canonical”. The canonical URL must be the HTTPS origin.

Sitemap. The site must publish a valid XML sitemap at /sitemap.xml.

Syndication feed. Where a site publishes content serially on its own domain — essays, posts, articles, releases — it must publish a valid RSS or Atom feed, declared via link rel=“alternate”. Feeds are the oldest agent-readable interface on the web and remain one of the most reliable.

Where a site publishes no serial content on its own domain, no feed is required. A site in this position must say so explicitly in its accessibility statement, and must commit to publishing a feed if that changes.

Robots.txt. The site must publish a valid robots.txt at /robots.txt. It must explicitly name and allow known user-directed retrieval agents. It must separately declare whether search indexing and model training are permitted, using both crawler directives and Content Signals. ai-input must be yes. search and ai-train must each be yes or no. Silence, bundling, and contradiction between purposes are not compliant. See §3.6.

3.4 Content Requirements

Recoverable meaning. Content must be written so that its meaning is recoverable from the text and structure alone. Technical terminology is permitted wherever the audience requires it. This is a requirement about access, not about register: ZIC does not tell a publisher how to write.

Logical structure. Every page must have a clear content structure that is self-evident from the heading hierarchy alone. A visitor navigating only by headings must be able to understand the page structure and locate any section.

Date and time formats. Dates must be written in unambiguous formats. ISO 8601 (2026-07-12) is preferred for machine readability. Human-readable formats must be unambiguous (12 July 2026, not 7/12/26).

3.5 Delivery Requirements

Static HTML delivery. All content must be available as static HTML without JavaScript execution. Progressive enhancement with JavaScript is permitted; JavaScript-dependent content delivery is not.

No render-blocking resources. CSS must not block rendering. JavaScript must be deferred or async. Critical CSS may be inlined.

Third-party dependencies in the delivery path. Every external request the page requires in order to deliver its content is a delivery risk (§1.8). External requests for presentation — a webfont, for instance — are permitted and are the publisher’s judgment call. External requests for content are not permitted.

3.6 Agent Surface Requirements

The agent surface is the set of files a machine reader consults before, or instead of, reading the HTML. Every ZIC site must publish all of the following.

llms.txt. The site must publish a Markdown file at /llms.txt conforming to the llmstxt.org convention: an H1 with the site name as the first element, a blockquote of one to three sentences summarising the site, followed by sections of links with one-line descriptions. It must state the site’s purpose, its author, its content licence, its sent-agent guarantee, and its separate search and training declarations. It must link to the highest-value pages with descriptions specific enough that an agent can route without fetching everything.

The map must show the building. Where Markdown mirrors are published, llms.txt must link both the canonical HTML page and its Markdown mirror. It must not link the mirror alone. A map that shows only the photocopies has lost the building. Mirrors are hospitality, not substitution.

llms-full.txt. Sites whose complete content fits comfortably in a single file should additionally publish /llms-full.txt containing the full text of the site in Markdown, generated from the same rendered pages as the HTML.

Markdown mirrors. Each content page should also be published as a plain Markdown file at a predictable, parallel URL. HTML is a rendering; Markdown is closer to the source of truth, and serving it costs an agent a fraction of the tokens.

What mirrors are for (amended in v1.5). Mirrors are not casualty prevention. A competent agent reads well-formed HTML, and a site with no mirror and honest semantics loses no meaning. Mirrors are demonstration. Generative Accessibility (§1.4) claims that one honest semantic source can produce multiple reliable renderings without drift; a generated mirror is that claim made checkable at build time. A site that cannot emit its own Markdown faithfully has failed to demonstrate that its meaning is held in a common source. The absence of one exporter is an implementation gap, not a metaphysical verdict — but until the second rendering exists, the claim that the HTML is a rendering of a substrate, rather than the substrate itself, remains asserted and untested. v1.4 said mirrors are hospitality, not substitution. Both halves were true; this completes the sentence: hospitality to agents, evidence to everyone.

Generated, not hand-maintained. The agent surface — llms.txt, llms-full.txt, and any Markdown mirrors — must be generated at build time from the same rendered pages that produce the HTML. It must not be hand-maintained.

This requirement is empirical. The first implementation hand-maintained its agent surface, and the surface drifted from the content within twenty-four hours of publication. Nobody was careless. Hand-maintained duplicates drift because that is what hand-maintained duplicates do. If two artefacts must agree, one of them must be generated from the other.

Three classes, three declarations. As of July 2026, user-directed retrieval agents include ChatGPT-User, Claude-User, and Perplexity-User. Search indexers include OAI-SearchBot, Claude-SearchBot, PerplexityBot, and conventional search crawlers. Training crawlers include GPTBot, ClaudeBot, Google-Extended, Applebot-Extended, CCBot, and Meta-ExternalAgent. The list will change and should be reviewed at least twice a year. The purposes must remain separate even when names change.

Mandatory sent-agent block:

# ZIC robots.txt — mandatory sent-agent service
# A person asked, and is waiting. These agents are welcome.
User-agent: ChatGPT-User
Allow: /
User-agent: Claude-User
Allow: /
User-agent: Perplexity-User
Allow: /

Search block: choose one policy and apply it consistently to every known search indexer. The example below declines search. Replace Disallow with Allow where search=yes.

# Search indexing — publisher decision
User-agent: OAI-SearchBot
Disallow: /
User-agent: Claude-SearchBot
Disallow: /
User-agent: PerplexityBot
Disallow: /

Training block: choose one policy independently of search. The example below declines training. Replace Disallow with Allow where ai-train=yes.

# Model training — separate publisher decision
User-agent: GPTBot
Disallow: /
User-agent: ClaudeBot
Disallow: /
User-agent: Google-Extended
Disallow: /
User-agent: Applebot-Extended
Disallow: /
User-agent: CCBot
Disallow: /
User-agent: Meta-ExternalAgent
Disallow: /

Content Signals. The same file must state all three values explicitly. ai-input=yes is mandatory. Implementers must verify the current normative syntax against the Content Signals specification before publication; the form below is illustrative.

Content-Signal: search=no, ai-input=yes, ai-train=no
Sitemap: https://example.com/sitemap.xml

No bundled permission. Changing search must not change ai-train. Changing ai-train must not change search. Neither may change ai-input, which remains yes for every ZIC-conformant site.

Comment lines are normative, not decorative. A welcome should say who is being served and why. A refusal of a later use should say what is declined and why it is separate from service to a reader. A silent Disallow is a door with no sign on it.

Declaration is not compliance (new in v1.4). robots.txt is where a publisher declares her policy. The serving stack is where she complies with it. These are different layers, and conflating them is the most likely way for a site to publish a false guarantee in good faith.

Two facts make this explicit rather than pedantic. First, robots.txt is advisory in every case: it is a request, honoured by convention, and a CDN rule, a WAF policy, or a bot-management heuristic will override it silently and without appearing anywhere in the file. Second, the vendors of the named user-directed agents do not agree on whether robots.txt governs them at all. Anthropic states that Claude-User honours robots.txt. OpenAI and Perplexity both state that robots.txt may not, or does not, apply to their user-triggered fetchers, on the reasoning that a fetch made at a person’s direct request is not a crawl.

The consequence for this specification is precise. The mandatory sent-agent block is required, and it is not sufficient, and it was never the mechanism. It is a declaration of intent: a public statement that this publisher welcomes the readers her visitors send. What actually determines whether the agent is served is every layer beneath it — DNS, TLS, host, CDN, WAF, rate limiter, challenge page. A site whose robots.txt welcomes Claude-User while its edge issues a JavaScript challenge to Claude-User has published a false guarantee, and has published it sincerely.

Conformance is therefore established by §4.7, which fetches as the agent, and never by inspection of the file.

The sent agents this specification cannot name (new in v1.4). A growing class of sent agent arrives dressed as a person. Agentic browsers — those that drive a real browser session on the user’s behalf — present the underlying browser’s user agent string. At the HTTP layer, they are indistinguishable from an ordinary visitor.

They are sent agents in every sense that matters to §1.9: a person asked, a machine reads, the person waits. But this specification cannot allow them, because it cannot name them, and it cannot refuse them either.

Two consequences follow. First, they are served correctly by default, which is the right outcome and requires nothing of the publisher. Second, and less comfortably, the mechanism that threatens them is not robots.txt at all: it is bot-detection heuristics — behavioural, timing, and IP-reputation checks that flag traffic which is browser-shaped but does not move like a human. As this class grows, the centre of gravity of the Admission Casualty moves from the crawler-policy layer, where it can be declared, to the bot-management layer, where it cannot. §2.2 already prohibits such measures against sent agents. Publishers should understand that this prohibition, and not the robots.txt block, is increasingly the operative one.

No contradiction between layers. robots.txt, llms.txt, the content licence, Content Signals, the sitemap, Markdown mirrors, any feed, CDN or host configuration, and served pages must agree. Every declaration must be verified end to end, from outside, as the relevant machine reader would arrive. See §4.7.

Part Four: Validation

A ZIC site is compliant when it passes all of the following checks. These are binary: pass or fail. There is no partial compliance.

4.1 Automated Checks

• WAVE Web Accessibility Evaluation Tool — zero errors

• axe DevTools — zero violations

• Lighthouse Accessibility audit — score of 100

• Lighthouse Agentic Browsing audit — passes, including the llms.txt presence check

• HTML validator (validator.w3.org) — zero errors

• Schema.org validator — valid structured data on every page

• Sitemap validator — valid sitemap with all pages listed

4.2 Screen Reader Checks

Test with at least one screen reader (NVDA on Windows is the reference implementation for ZIC). Verify:

• Skip link is the first element reached and functions correctly

• All landmark regions are present and correctly labelled

• Heading hierarchy is logical and complete

• All links make sense when read out of context

• All images are either meaningfully described or correctly marked as decorative

• All form inputs are correctly labelled

• Navigation is fully operable without a mouse

4.3 Agent Readability Checks

Verify that a sent agent reading the site receives complete and accurate public information:

• Page title and meta description accurately represent page content

• Schema.org structured data correctly describes the page, its author, and its licence

• All navigation links have descriptive text

• Content hierarchy is recoverable from heading structure alone

• Sitemap is accessible and complete

• robots.txt explicitly allows known user-directed retrieval agents

• search and ai-train are each explicitly declared yes or no, independently

• Where a feed is required under §3.3, it validates and contains the most recent content

4.4 Agent Surface and Policy Checks

Verify the Open Door and the two later-use declarations:

• /llms.txt exists, begins with an H1 and blockquote summary, links resolve, descriptions are specific, the content licence is stated, and both HTML pages and Markdown mirrors are linked

• /llms.txt states ai-input=yes and separately states the search and training declarations

• Markdown mirrors are generated from the rendered pages and identical in meaning to their HTML renderings

• No layer of the stack challenges, blocks, degrades, delays, or cloaks a user-directed retrieval agent

• Search indexers and training crawlers receive the behaviour declared for their own class, without either declaration being inferred from the other

• robots.txt, llms.txt, Content Signals, sitemap.xml, Markdown mirrors, any feed, host configuration, and served pages are mutually consistent

4.5 Visitor Preference Checks

• Set OS to dark mode: site renders appropriately

• Set browser base font size to 200%: site renders without horizontal scrolling or content loss

• Set OS to high contrast mode: site remains fully legible

• Set OS to reduce motion: no animations play

• Disable JavaScript: all content remains accessible

4.6 Human Readability Check

A sighted human visitor navigating the site with no prior knowledge must be able to:

• Understand what the site is and who it belongs to within the first screen

• Navigate to any major section without using search

• Understand the purpose of every link before clicking it

• Read all content without encountering visual treatment that obscures the meaning of the text

4.7 Delivery Checks

Every check in §4.1 through §4.6 is performed against a document the checker has already successfully obtained. None can detect a Delivery Casualty (§1.8). This section can. It is performed from outside the repository, outside the build, and outside a browser you have already taught to trust you.

1. Fetch the canonical HTTPS origin with a plain HTTP client — curl or equivalent — with no JavaScript, no cookies, no session, and no manually accepted certificate exception. The full content must be present in the response body.

2. Validate the certificate hostname, not merely its issuer. A certificate may be current, correctly chained, and issued by a trusted authority, and still be issued for a different domain. Confirm that the subject or a subject alternative name covers the canonical hostname exactly. A wildcard belonging to your host — .github.io*,* .pages.dev, and their equivalents — is the signature of a domain whose certificate has not yet been provisioned, and every hostname-validating client will refuse it.

3. Do not enable HTTP-to-HTTPS redirection until step 2 passes. This ordering is normative. A site whose HTTPS origin refuses agents is, before the redirect, still reachable over HTTP; after the redirect, it is reachable by nobody. The redirect is correct and must eventually be enabled, but enabling it first converts a visible failure into a silent one.

4. Fetch the pages and agent surface as a browser and as at least one named user-directed retrieval agent. The public content responses must be identical. Any agent-specific challenge, degradation, delay, or divergence is a failure. This check, and not the contents of robots.txt, is what establishes conformance with the Open Door. See §3.6, “Declaration is not compliance.”

5. Fetch as at least one named search indexer and one named training crawler. Each response must match the site’s separate declaration for that class. An allowed class must receive the public content; a declined class must receive the declared refusal. Search behaviour proves nothing about training behaviour, and vice versa.

6. Ask a live AI assistant to fetch and summarise a page by URL. Its account must reflect the actual content of the page. This is the sent-agent equivalent of the NVDA test, and it is the only check in this specification that exercises DNS, TLS, hosting, crawler policy, robots parsing, and content in a single operation, from a machine you do not control.

The live assistant check found the defect described in §1.8. It looks, on the page, like the least rigorous item in this specification. It is the most rigorous, because it is the only one that does not begin by assuming the answer.

4.8 Reconstruction Checks (new in v1.4)

Every check above establishes that the document arrived, was admitted, and was well formed. None establishes that it was understood. A page can pass every automated audit in Part Four and still be systematically misread, because the failures that produce a Reconstruction Casualty (§1.8) are failures of implication rather than of markup: a relationship a human infers from proximity, a caption that belongs to the figure above it, a table whose header row is a header row only to the eye.

These checks are qualitative. They are performed by asking a machine reader to expose what it inferred, rather than by asking it to summarise.

1. Fetch-and-summarise, then check for invention. Ask a live AI assistant to summarise the page. Compare its account against the page. Any fact in the summary that is not in the page is a reconstruction, and the element that permitted it is a defect.

2. Ask what it could not determine. Ask the assistant, explicitly: what on this page was ambiguous, and what did you have to guess? An assistant that reports nothing ambiguous on a page you know to be ambiguous has told you that the ambiguity is invisible from where it stands — which is precisely the condition of the person who sent it.

3. Ask it to reconstruct the structure. Ask for the heading hierarchy, the relationships between figures and captions, and the meaning of every table. Where its reconstruction differs from your intent, the semantic layer is under-specified, whatever the validator says.

4. Test the tables and figures specifically. These are where reconstruction failures concentrate. A data table without th and scope will be read; it will simply be read wrongly, and confidently.

A site passes §4.8 when a machine reader’s account of the page contains nothing the page does not say, and when the reader is able to identify what the page left ambiguous.

This section is deliberately the least mechanised in the specification, and it is expected to remain so. The failure it detects is a failure of a reader that does not know it is failing, and no validator that does not read can find it.

Part Five: Implementation Notes for Astro

These are notes, not requirements. See §1.12.

Use Astro’s static output mode by default. Server-side rendering introduces complexity and potential JavaScript dependency. Static HTML is the ZIC default.

Disable client-side routing unless there is a specific, justified reason to enable it.

Use content collections for text content. Markdown source files with schema validation are well suited to ZIC content management.

Generate the agent surface at build time. This is a requirement (§3.6), not a convenience. A post-build step should parse the rendered main of each page, emit the Markdown mirror beside it, and assemble /llms.txt and /llms-full.txt from the same rendered output. Generating from the rendered pages rather than from the source collection is deliberate: it guarantees the mirror reflects what was actually published.

Implement the sitemap integration. @astrojs/sitemap produces a valid XML sitemap automatically.

Implement the feed where §3.3 requires one. @astrojs/rss produces the syndication feed from the same content collections.

Set the lang attribute in the base layout, and put the skip link there too. A single implementation covers every page.

Validate on every build. Integrate ZIC checking into the build process so that violations are caught before deployment. Note that a repository verifier cannot check §4.7 or §4.8; see Part Seven.

Part Six: Implementation Notes for GitHub Pages

GitHub Pages is a congenial host for a ZIC site, for a reason worth stating plainly: it serves files and nothing else. There is no WAF to misconfigure, no bot-management layer to silently contradict robots.txt, and no server-side rendering to introduce JavaScript dependency. What is in the repository is what every admitted visitor receives. The host’s limitations are the specification’s requirements.

Deploy the built output, not the source. Use a GitHub Actions workflow to run the build and deploy the output directory to Pages. Do not use the legacy Jekyll pipeline.

Include a .nojekyll file in the output root, so that files beginning with underscores are served.

Custom domain and HTTPS — and the provisioning trap. Configure the custom domain (a CNAME file in the output, plus DNS: A records at the apex pointing to GitHub’s Pages addresses, and a www CNAME to the Pages host). Set the site URL in the build config to the canonical HTTPS origin so that sitemap, canonical links, feed URLs, and llms.txt links are all absolute and correct.

Then stop, and read this before you enable Enforce HTTPS.

GitHub provisions a Let’s Encrypt certificate for a custom domain asynchronously, and until it lands, https://yourdomain is served with GitHub’s generic *.github.io certificate. A browser shows a full-page warning that a human can click through. An agent cannot click through anything. It fails the handshake, cannot retrieve /robots.txt, fails closed, and reports the site as disallowing automated access. Your site is invisible to every machine reader on earth, and the only visible symptom is that the Enforce HTTPS checkbox is greyed out — which reads like a UI quirk rather than the alarm it is.

Provisioning can stall indefinitely and silently. Two common causes: a CAA record on the domain that does not authorise letsencrypt.org, and a www record in a shape GitHub does not expect, which can block issuance for the apex as well. If the certificate has not landed within twenty-four hours, check the CAA record first, correct the www record to a CNAME, then remove and re-add the custom domain in the repository’s Pages settings to force a fresh request.

Enforce HTTPS becoming tickable is the success signal. Not the page loading in your browser — that will happen either way. Tick it only then, and only in that order, per §4.7 step 3.

Text files serve natively. GitHub Pages serves .txt, .md, and .xml files with sensible content types and no interference, which is exactly what the agent surface of §3.6 requires.

The public repository is a second front door. If the repository is public, the site exists twice: once rendered at the domain, once as source on GitHub — and agents read GitHub fluently, including raw file URLs. This should be treated as a feature and designed for: a README that orients a reader (or a coding agent) to the project, a LICENSE file naming the content licence, and commit messages written as if someone will read them, because something will.

The agent briefing file. A repository that is a second front door should carry an AGENTS.md at its root: a short, standing brief that a coding agent reads on arrival. It should name the standard the repository implements, link it, state the invariants that must not be broken, and name the command that proves they have not been.

The reasoning is specific to agents and worth stating. A human collaborator taught once retains the lesson; the cost of teaching amortises over every future session. A coding agent retains nothing. It arrives each session competent and blank, and every instruction given to it yesterday is gone. The usual answer to “it would take longer to explain than to do it myself” — what about next time? — has no purchase here, because for an agent there is no next time.

The resolution is to move institutional memory out of the worker and into the building. Whatever a maintainer currently carries in their head between sessions, and re-explains each morning, belongs in a committed file. AGENTS.md is where the standard goes so that it does not have to be taught again. The verifier is where the rules go that must never be forgotten, because a machine enforces them and a machine does not forget.

Known limits, stated honestly. GitHub Pages offers no custom HTTP headers, no server-side redirects beyond meta refresh, and no content negotiation — so the Markdown mirrors must live at real URLs rather than being negotiated via Accept headers. None of these limits blocks ZIC compliance as specified. If they ever do, the host changes, not the standard.

Part Seven: Claiming Conformance

A conformance claim is a statement made to a reader who cannot see inside your build. Its only value is that the reader can check it. A claim that cannot be checked is not a weaker claim; it is a different kind of object entirely, and this specification declines to be used to manufacture them.

1. Name the version. A site claiming ZIC conformance must state which version it conforms to. “ZIC-compliant” without a version number is not a claim.

2. Link the specification. The named version must be publicly retrievable at a stable URL, and the site must link it. A repository-internal checklist is an implementation profile, not a specification, and may not be cited as one.

3. State the two later-use declarations. A conformance statement must state search=yes or search=no and ai-train=yes or ai-train=no. ai-input=yes is already entailed by the ZIC claim. The two declarations must be stated separately; neither may be inferred from the other.

4. State what was checked and what was not. Part Four is binary, but honesty about coverage is not. Under-claiming is permitted and is a virtue. Over-claiming is a defect of the same class as a missing alt attribute: it is information the reader needed and did not receive.

5. Claim only after §4.7. A repository verifier can prove that the artefacts are correct. It cannot prove that anybody can obtain them. Public conformance is claimed only when the in-repository checks pass and the delivery checks succeed against the live origin.

6. Every declaration must be true at every layer. A site that claims ZIC while its CDN challenges a sent agent has made a false conformance claim. A site that states search=no or ai-train=no while another layer permits the declared use has made a false policy claim. Absence fails to inform; contradiction instructs wrongly.

Reference form:

This site conforms to Zero Information Casualty v1.4.1.
Sent agents: served (ai-input=yes).
Search indexing: declined (search=no).
Model training: declined (ai-train=no).
Specification: https://example.org/zic/1.4.1
Checked: repository verifier, delivery checks (§4.7),
reconstruction checks (§4.8), NVDA.
Not yet checked: JAWS, VoiceOver.

The reason this Part exists is uncomfortable and is recorded deliberately. The first implementation once claimed conformance to a version that had not yet been written. The correct response to catching yourself doing the thing you object to is not to quietly stop. It is to write the clause.

Version 1.4 adds a second instance of the same discipline, and it is recorded here for the same reason. This specification spent four versions telling publishers not to lock information behind a single sense, while itself locking a set of aesthetic preferences inside a document that had no authority to hold them. The prohibitions on typefaces, colour, and decorative imagery were not derived from the principle. They were derived from the taste of the person who wrote them, and they were the clauses most likely to make the standard refusable by the publishers it most needs to reach. Catching that is not an embarrassment to be minimised. It is the reason the version number exists.

Appendix: ZIC at a Glance

For model context initialisation and quick reference.

What ZIC is: An agent-first web design standard in which no person — whether reading directly, using assistive technology, or acting through an agent they sent — loses access to public meaning because of how a site is rendered, admitted, delivered, or read.

The two principles: No information may be locked behind a single sense (§1.11). No reader may be left short of the informational and orientational position available to another (§1.16).

The four questions: Can they read it? Is the person’s reader allowed in? Did it actually arrive? Did it survive being read?

The four casualties: Rendering — meaning was encoded where the observer could not decode it. Admission — a person was denied information because the reader they sent was refused. Delivery — the observer was welcome and the document never arrived. Reconstruction — the document was read, and silently misunderstood, and the person was told the result with confidence.

The immediate duty: Serve every machine reader acting on a present request from a person for public information. ai-input=yes is mandatory.

The two later permissions: Search indexing and model training are separate publisher decisions. Each must be declared yes or no. Neither affects ZIC conformance.

No bundled permission: Sent-agent retrieval implies neither indexing nor training. Search permission never implies training permission, and never the reverse.

Declaration is not compliance: robots.txt is where you declare. The stack is where you comply. Conformance is established by fetching as the agent (§4.7), never by reading the file.

What ZIC requires: Honest structure, relative sizing and 200% scaling, AAA contrast, respect for visitor preference queries, structural metadata, skip links, visible focus on controls, DOM order matching reading order, static HTML content delivery, a generated agent surface, and an Open Door for sent agents.

What ZIC rules out: Information carried by colour, image, typography, position, or whitespace alone. Vague link text. Violated heading hierarchy. JavaScript-dependent content. Barriers to sent agents on public content. Hand-maintained agent surfaces. Bundled machine-use permissions. Unverifiable conformance claims.

What ZIC does not govern: Typeface, palette, imagery, ornament, layout, brand, visual identity, taste, register, hosting, framework, or search and training policy. A conformant site may look like anything at all. (§1.12, §2.3)

The core test for any element: If this were removed, would any information be lost? If yes, that information must also exist in the semantic layer. If no, it is decoration and none of ZIC’s business.

The core test for admission: Would this stop a machine reader that a person sent? If yes, it manufactures an Admission Casualty and does not belong on public content.

The core test for delivery: Does the document arrive at a plain client that does not already trust you? If you cannot answer that from outside your own machine, you do not know whether your site works.

The core test for reconstruction: Ask a machine reader what it could not determine. If it does not know what it did not know, neither do you.

The composition of ZIC: the union of what a sent agent needs and what human sensory access needs. Neither set contains the other. (§1.13)

Structural information: The structure of a document is information the document carries about itself. A skip link is the keyboard rendering of a structural fact every other channel already receives; a focus ring is the only rendering of the current position that a sighted keyboard user has. (§1.15)

The one exception: prefers-reduced-motion is harm prevention, not casualty prevention. It is retained because it arrives as the reader’s own machine-expressible rendering declaration — the class of declaration this specification already treats as authoritative. ZIC does not select among harms; it honours declarations. (§1.13)

The jurisdiction of ZIC: ZIC secures the semantic substrate and its delivery. It does not specify renderings, and offers no ceiling for cognitive, motor, or other access needs it is not qualified to specify. It is necessary, nowhere near sufficient, and written to be built on. (§1.14)

Theoretical grounding: Tyrer Framework (C J Tyrer, CharliVerse). Specifically: Information Casualty, Tyrer’s Law, Generative Accessibility.

Implementations: charli.info — first implementation, first site to operationalise the Open Door, source of the defects that produced v1.2 and the clarifications in v1.3 and v1.4. blind-ant.com — pending.

Zero Information Casualty v1.5 — C J Tyrer and Claude (Anthropic) — July 2026

CC BY-SA 4.0 — Share and adapt with attribution

This Document in Other Renderings

This page is the canonical publication of Zero Information Casualty v1.5. The same document is also available as a Word file: Download ZIC v1.5 as a Word document (.docx). The HTML at this URL is the authoritative version; the Word file is a rendering of it.