Editorial process

Every page on OpenPWA carries a publication date, a byline, and a named reviewer. This page explains what those labels mean and what stands behind them.

Who publishes OpenPWA

OpenPWA is published by OpenPWA Editorial, the editorial function of this project. Every entry is bylined and reviewed under one editorial pen name, Carey Gill, rather than under individual writers’ names, because an entry’s facts are maintained over time by whoever next revisits the topic rather than owned by whoever first typed it. The pen name is the accountable signature on each page’s byline and in its structured data; the editors page explains what the review step behind it covers.

How an entry is produced

1. Topic selection. Topics come from a coverage matrix of the installable-web surface (manifest, service workers, installation, capabilities, storage, notifications, performance, platforms) plus observed search demand. Nothing is published because it is easy to write.
2. Sourcing. An entry stands on primary sources — specifications, browser-vendor documentation and release notes, bug trackers, store and platform policy pages. Every evergreen entry declares at least two independent sources in its frontmatter; a news article declares at least three. Citing another aggregator’s summary in place of the primary document is not permitted.
3. Authoring, with AI assistance — disclosed. Drafts are produced with the assistance of large language models, working from the sources gathered in step 2 and from a written authoring contract that fixes the structure, the depth standard, and the sourcing rules. This is stated plainly rather than buried: AI assistance is part of how this reference is produced at the breadth it covers.
4. Deterministic fact-check and gates. Before anything is published, a set of automated, LLM-free gates run and must all pass. They check that every cited source is reachable, that browser-compatibility rows agree with the browser-compat-data they cite, that the entry answers the full depth standard for its kind, that both the English and Chinese versions exist, and that the entry’s publication metadata is complete and internally consistent. A failing entry withholds the whole publish; there is no override flag.
5. Human review. A named reviewer is recorded on every entry. Review is a human judgement on whether the entry’s claims are supported by the sources it cites and whether its framing is fair — not a rubber stamp on the gates, which are checked separately and automatically.
6. Staleness watch. Each entry carries a lastVerified date. Facts about the installable web move: store terms and platform policies change without notice, and browser support changes every release. Entries age against their verification date and are re-checked on a schedule, with policy-bearing pages on a shorter horizon than specification-bearing ones.

Corrections policy

When an entry is wrong, the correction is made visible rather than quietly overwritten.

• A substantive correction is appended to the entry as a dated Correction (YYYY-MM-DD) section stating what was wrong and what it now says.
• The entry’s lastVerified date is bumped.
• The entry’s publication date is never changed. It is write-once, enforced automatically against the date first recorded in the repository’s history, so a correction can never be made to look like fresh reporting.
• Typographical and formatting fixes that do not change meaning are made without a correction note.

If you believe something here is wrong, the fastest route to a fix is to say which page and which claim, with a source. See Report a problem.

What OpenPWA does not do

• It does not accept payment for coverage, placement, or ranking in any list on this site.
• It does not republish vendor announcements as reporting. A vendor’s own framing is a source, not a conclusion.
• It does not generate images, charts, or data to illustrate a claim it cannot source.

← Back to the About overview. See also Methodology for the verification detail.