Unattended Works · Standards
Standards
These are the rules the products are built against. They are published first so that a claim made by any product can be checked against a written standard rather than against a mood.
Standing rules
The rules every product is held to
Artifact or silence
A finding exists only if an artifact proves it. Screenshots, response headers, console entries, computed styles, and DOM assertions are artifacts. Inference is not. A candidate finding whose artifact is missing is dropped from the report rather than softened into a suggestion.
Scope is recorded before evidence
What was examined, and what was deliberately not examined, is written into the report before collection begins. A report that cannot say what it skipped is not finished.
Severity by rubric, not by tone
Severity is assigned from a published rubric with stated definitions. No finding is escalated because it sounds serious, and none is buried because it is awkward.
No composite scores
Unrelated evidence is never averaged into a single number. Reports end in an ordered list of work.
Reproducible output
Two runs of the same audit definition against the same unchanged input produce the same findings. Versions of the runner, the browser engine, and the audit definition are recorded in every report.
Limits stated in the same breath as results
Each evidence domain publishes what it does not cover, and each report repeats it. Automated accessibility checking in particular covers a minority of WCAG 2.1 criteria, and a clean automated result is never presented as conformance.
Output belongs to the buyer
Reports are not aggregated, benchmarked, resold, published, or used as case-study material. There is no telemetry in a report.
Evidence methodology
An audit is a recording followed by a derivation.
The recording stage loads each in-scope route in a real browser engine at fixed viewports and captures raw observations: full-page screenshots, the complete request ledger with initiators, cookies and storage written on load, the console transcript, resolved computed styles for contrast pairs, the accessibility tree where the engine exposes it, and the geometry of the document and its elements. Nothing is judged at this stage.
The derivation stage runs rules over the captured artifacts. Because the rules never touch the live site, a report can be re-derived from its own artifacts after the fact — which is what makes a finding defensible three weeks later when somebody disputes it.
The two stages are versioned separately. A rule change alters the derivation version and can be re-run against archived artifacts; a capture change alters the runner version and requires a fresh run.
Accessibility posture
Automated checking finds a minority of WCAG 2.1 issues, and the majority requires a person with assistive technology. Every product here states that in the report itself, next to the results, rather than in a footnote.
What is checked automatically: heading structure, landmark structure, skip-link resolution, accessible names, alternative text, computed contrast against resolved backgrounds, visible focus at every keyboard stop, language and title attributes, and reduced-motion handling. What is not: screen-reader output quality, cognitive load, content comprehension, and anything that requires judgement about meaning.
No Unattended Works product issues a conformance statement, and no report should be quoted as one.
Privacy posture for reports
A report is a file. It contains no analytics, no beacons, no remote fonts, and no external requests — it opens with the network switched off. The same rule applies to this site: see the privacy contract.
This site is held to its own standard
The standards above apply to the products. The site you are reading is built against the same accessibility and privacy rules, and its repository carries a test suite that fails the build if a tracker, an external font, a published email address, or a fabricated claim appears in the source.
Sample report schema · v1 · published-and-implemented
The output format, published before the product
The machine-readable half of a report is a single JSON document. Its shape was published here before the code existed, so the shipped product could be compared against what was promised. The derivation engine is held to it by a test that derives a real report and checks every required field below. A change to this schema gets a version bump and an entry in the launch log.
| Field | Type | Required | Description |
|---|---|---|---|
| schema_version | integer | yes | Version of this document schema. Increments on any breaking change. |
| report_id | string | yes | Opaque identifier for the run, unique per audit. |
| generated_at | string (RFC 3339) | yes | UTC timestamp at which the run completed. |
| target | object | yes | The audited origin, the entry URL, and the resolved route list. |
| runner | object | yes | Browser engine name and version, runner version, and audit definition version. |
| scope | object | yes | Crawl budget, viewports used, routes visited, and routes deliberately excluded. |
| domains | array of object | yes | One entry per evidence domain, each carrying its own findings and limits. |
| findings | array of object | yes | Flat list of every finding, referenced by the remediation ledger. |
| remediation | array of object | yes | Ordered remediation ledger. |
| artifacts | array of object | yes | Every screenshot, transcript, and ledger produced, with a content hash. |
| not_covered | array of string | yes | Explicit list of what this run did not examine, and why. |
| summary | object | no | Finding and remediation counts, and counts per severity. Derived from the lists below; carried so a reader does not have to recount them. |
| Field | Type | Required | Description |
|---|---|---|---|
| id | string | yes | Stable within a report; referenced by remediation entries. |
| domain | string | yes | One of the nine evidence domain identifiers. |
| severity | string | yes | One of the severity levels below, assigned by rubric. |
| title | string | yes | One line stating what was observed, not what it implies. |
| observed | string | yes | The measurement or event exactly as recorded. |
| expected | string | yes | The rule that was applied, and where that rule comes from. |
| routes | array of string | yes | Routes on which the finding was reproduced. |
| selector | string | no | CSS selector for the element, where the finding is element-scoped. |
| artifact_ids | array of string | yes | Artifacts proving the finding. A finding with none is not emitted. |
| verified_by | string | yes | machine — every published finding is machine-verified. |
| check_id | string | no | Namespaced identifier of the rule that produced this finding, as domain.check. Stable across reports; use it to track one defect over time. |
| status | string | no | One of the status values below. Defaults to reproduced. |
| viewports | array of string | no | Viewports the finding was reproduced at, where it is viewport-specific. |
| action | string | no | What to change, stated as an outcome. Repeated on the remediation entry that groups this finding. |
| needs_human_review | boolean | no | True when the finding records something a machine cannot judge — a third-party origin that may be intended, a cookie that may be necessary. |
| Field | Type | Required | Description |
|---|---|---|---|
| rank | integer | yes | Position in the ledger, ascending. |
| finding_ids | array of string | yes | Findings resolved by this item; grouped by shared cause. |
| severity | string | yes | Highest severity among the grouped findings. |
| affected_routes | integer | yes | Count of routes on which the grouped findings appear. |
| action | string | yes | What to change, stated as an outcome rather than as a patch. |
| needs_human_review | boolean | yes | True when the item cannot be closed by a machine check alone. |
| group_key | string | no | The shared cause that grouped these findings. Two symptoms with one key are one fix. |
| artifact_ids | array of string | no | Every artifact cited by the findings this entry groups. |
Severity rubric
Severity is assigned from these definitions. No finding is escalated because it sounds serious, and none is softened because it is awkward.
- blocking
- Observed behaviour prevents a documented task from completing at all for some visitors — a keyboard trap, an unreachable control, a 5xx on a route linked from the entry page.
- serious
- Observed behaviour degrades a documented task or violates a stated contract — a WCAG 2.1 AA failure, a broken internal link, an asset that does not resolve, an uncaught exception on load.
- moderate
- Observed behaviour is incorrect but has a working path around it — a redirect chain, a duplicated title, a missing canonical URL.
- minor
- Observed behaviour is inconsistent with the site's own conventions and carries no known user-facing impact.
- informational
- Recorded for the ledger with no defect asserted — a third-party origin inventory entry, a redirect that behaves as intended.
Finding status values
- reproduced
- Observed on every attempt within the run.
- intermittent
- Observed on some attempts; attempt count is recorded.
- not_reached
- In scope but unreachable — authentication, rate limit, or timeout.
- excluded
- Deliberately outside the run's stated scope.
Hard automation boundaries
What the runner is never allowed to do
These limits are enforced in the runner, not promised in prose. Anything on this list occurring during a run is a defect, and would be reported as one.
The runner never authenticates.
No credentials are accepted, stored, or used. Anything behind a login is out of scope and is reported as not reached, never as passing.
The runner never performs a state-changing request.
No form submissions, no purchases, no uploads, no account creation, no requests outside safe HTTP methods against the audited origin.
The runner never writes to your infrastructure.
No files, no DNS records, no repository commits, no configuration changes. The audit reads and reports; you decide what to change.
A finding without an artifact is not published.
Every entry in the report references the screenshot, header, console line, or DOM assertion it came from. If the artifact is missing, the finding is dropped rather than described.
Severity comes from a published rubric.
Severity is assigned by rule, not by how alarming a finding sounds. The rubric is published in the standards page and versioned with the report.
No single overall score is produced.
Composite scores compress unrelated evidence into one number that cannot be acted on. The report ends in an ordered list of work instead.
Audit output is never sold, aggregated, or published.
Reports belong to the buyer. Nothing from a run is used as a case study, a benchmark, or training data without a separate written agreement.
The runner never load-tests, floods, or brute-forces.
Requests are rate-limited and bounded by a stated crawl budget. The audit is designed to be indistinguishable from a careful visitor.
The runner never probes for vulnerabilities.
No injection attempts, no path traversal, no credential testing. This is an evidence audit, not a penetration test, and it is not a substitute for one.
Where a person is still required
An unattended product that pretends to cover these would be lying by omission. Each is named in the report itself, next to the results.
Accessibility conformance statements.
Automated checks find a minority of WCAG 2.1 issues. A conformance claim requires manual testing with assistive technology; this product does not make one and neither should a report derived from it.
Legal and regulatory interpretation.
The privacy domain records observed behaviour. Whether that behaviour complies with any given regulation is a question for a lawyer.
Content quality and editorial judgement.
Whether a page says the right thing to the right reader is not a machine question and is not answered here.
What to fix first, commercially.
The ledger orders by evidence and breadth. Only you know which route earns the revenue.
The fixing itself.
No code is written, patched, or deployed on your behalf as part of an audit.