Isoline guide
How Isoline researches and maintains its guides
This methodology defines who is accountable for Isoline guides, how evidence is checked, where AI may assist, and what changes qualify as substantive updates.
Scope and accountability
General Isoline guides help readers understand browser isolation, privacy, security, testing, and team workflows. Each guide must answer a distinct reader need and add original synthesis beyond a source summary. We do not publish pages to meet an arbitrary word count or to cover minor keyword variations.
The byline “Isoline editorial team” names an organizational publishing function, not a fictional person. It provides one stable point of accountability while Isoline is in development. A guide must state whether it covers general education, accepted design intent, shipped evidence, or a clearly separated mix of those scopes.
Research and source selection
Research begins with specifications, browser and platform documentation, source repositories, release artifacts, and authoritative security guidance. Sources are selected because they support a specific statement, not because they repeat a preferred conclusion. Every source record includes a descriptive title, publisher, URL, access date, and a note explaining what it supports.
Mutable technical facts are checked again before a substantive update. Vendor-published statements can establish what a vendor documents, but they are not independent proof of security, reliability, adoption, or outcomes. Missing public evidence is recorded as an unknown, not treated as proof that a capability does not exist.
Fact-checking and product status
An editor checks factual statements against the cited material and reviews the complete rendered page for context, links, dates, limitations, and claim status. Automated checks reject missing evidence, duplicate routes, broken internal links, hidden indexing directives, extra page-level headings, and prelaunch product claims that exceed the recorded evidence state.
Isoline is in development. General education must not be presented as hands-on product evidence. Accepted design intent must be labelled as intent and linked to its supporting decision record or public product-status source. Shipped claims require public, reproducible evidence and cannot be published while the project remains in Foundation.
AI assistance
AI tools may assist with source discovery, outlining, language cleanup, consistency review, and validation. They are not treated as sources. They must not invent experience, users, measurements, quotations, screenshots, product availability, or source conclusions.
Each guide carries an AI-assistance disclosure, including when no AI was used. Material AI work does not remove editorial accountability or lower the sourcing and fact-checking requirements.
Corrections
Readers can report a guide correction by email. A useful report includes the page URL, the exact passage, the proposed correction, and supporting evidence. Do not send passwords, cookies, proxy credentials, two-factor secrets, profile data, or other sensitive information.
A material correction is recorded on the article, updates the substantive modification date, and is checked wherever the same claim appears. Minor spelling, formatting, or accessibility fixes do not receive a false freshness date.
Publication and substantive updates
The publication date records when a guide first becomes part of the public route set. The modified date changes only when a visible conclusion, explanation, limitation, recommendation, source-dependent fact, or correction changes meaningfully. A build timestamp is never used as an editorial date.
Before publication, a guide must have a concise summary, useful heading structure, descriptive links, limitations, an editorial scope note, accessible source presentation, and contextual related reading where it helps the reader. Draft, review, and retired entries are excluded from public routes, feeds, and sitemaps.
Localization
English is the shared source. A stable language-neutral page ID joins localized versions, while each locale may reuse the source slug or define its own reviewed slug. A translated route is published only when the entire article, metadata, source context, disclosures, and interface text have been reviewed for that language. Missing translations are omitted rather than replaced with an English fallback page.
Editorial note
- AI assistance
- AI assisted with source discovery, drafting, consistency checks, and validation design for this methodology. The organizational editorial identity remains accountable for every published statement.
- Editorial review
- Isoline editorial team
Sources
Each source is linked to the statement group it supports. Access dates record when the editorial team checked the cited material.
- Creating helpful, reliable, people-first content Google Search Central
- Supports
- Authorship, process transparency, original analysis, and substantive date practices used in this methodology.
- Accessed
- Google Search guidance on generative AI content Google Search Central
- Supports
- Accuracy, relevance, quality controls, and contextual disclosure for AI-assisted publishing.
- Accessed
- Article structured data documentation Google Search Central
- Supports
- Visible and machine-readable author, publication date, and substantive modification date conventions.
- Accessed
- Headings in accessible page structure W3C Web Accessibility Initiative
- Supports
- Descriptive, nested heading structure that supports navigation and comprehension.
- Accessed