Who owns the documentation?

INCIO Research Team is the organizational byline used for product documentation and research guidance published by INCIO LLC. It does not imply an independent newsroom or anonymous panel of outside experts. The team is responsible for comparing public claims with the current product build, source code, tests, release artifacts, and applicable primary documentation before publication.

Source hierarchy

Sources are selected according to the type of claim. Product behavior is verified against the current extension code, manifest, automated tests, export schema, and release package. Platform requirements are checked against official Chrome, Google, Amazon, or other provider documentation. Legal pages are reviewed as operating documents for INCIO LLC, but they are not presented as legal advice to readers.

Claim typePreferred evidenceWhat is avoided
Extension capabilityCurrent code, manifest, tests, and packaged releaseRoadmap features described as available
Export field or limitSchema constants, exporter tests, and release UICompetitor descriptions or old screenshots
Chrome policyOfficial Chrome Web Store and Chrome developer documentationUnverified forum summaries
Research methodTransparent reasoning, reproducible steps, and explicit limitationsUnsupported universal thresholds
Privacy statementActual data flow, permissions, storage behavior, and policy textBroad labels such as “anonymous” without technical support

Rules for factual and research claims

  • Describe only functionality present in the current public or release-candidate build.
  • State limits next to benefits when the limit changes the user's decision.
  • Distinguish configured marketplace access from verified compatibility.
  • Separate observed review counts from population-level rates or causal claims.
  • Label examples and downloadable datasets as synthetic when they are not real exports.
  • Do not invent benchmarks, customer results, ratings, adoption numbers, or expert endorsements.
  • Use organizational authorship rather than fabricating personal author biographies.
  • Explain uncertainty where source visibility, pagination, localization, or third-party behavior can vary.

Editorial review process

  1. Define the search intent. The page must answer a real product-research or product-usage question.
  2. Verify product facts. Fields, limits, workflows, privacy statements, and supported states are checked against the current build.
  3. Write for a decision. Guidance includes steps, evidence requirements, limitations, and a next action.
  4. Check consistency. Page copy, structured data, machine-readable files, legal pages, and the extension UI must not contradict one another.
  5. Run technical QA. Metadata, canonical URLs, internal links, sitemap entries, mobile layout, accessibility basics, and production builds are checked.
  6. Record the release. Material site changes are versioned so the previous deployed version can be restored.

Use of AI in content production

AI tools may assist with drafting, restructuring, test-case generation, and consistency checks. They are not treated as factual sources. Product claims must still be checked against the project files or an authoritative external source, and published examples must not expose private user data.

Update policy

Technical pages are reviewed when a release changes product limits, fields, data handling, permissions, supported entry points, marketplace status, or error behavior. Editorial pages are also reviewed when an important external platform change makes the workflow inaccurate. The visible updated date describes the current page review, not the age of every underlying concept.

Corrections and feedback

If a page conflicts with the current extension or omits a material limit, send the URL and the disputed statement to support@incio.us. INCIO will investigate the product source, correct confirmed errors, and update connected machine-readable documentation when necessary. Product issues can also be reported through the support page.