How we make this: sourcing, AI assistance and review

This page explains where the information on Portal Ready comes from, how AI is used, and how pages are checked. It applies to every page on the site.

Sources we accept

Portal requirements, revenue shares, limits and policies are taken only from the portal’s own developer documentation, terms, or official SDK repositories. Browser behaviour comes from MDN, the Chrome for Developers and web.dev documentation, or the relevant specification. Engine behaviour comes from the engine’s official documentation (for example docs.godotengine.org). AdSense details come from Google’s AdSense Help Center and developer documentation.

We do not use blog posts, forum threads, aggregator sites or AI-generated summaries as sources for facts. When a forum post is the only place a behaviour is described, we leave the claim out.

What every page records

Inline links to the official page for each non-obvious claim.
A Sources list at the end, with the date each source was accessed.
A “Sources checked” date in the page header: the last date someone opened the sources and compared them with the page.
“Not published” wherever the official documentation does not state a value. We do not estimate missing numbers, and we do not fill gaps with figures that circulate in developer communities.

On the portal comparison, every cell carries its own source link and verification date, because portal pages change independently of each other.

How AI is used

Drafts are written with the help of an AI model. The model is given the official pages and asked to paraphrase them; it is not treated as a source. After drafting:

every number, limit, method name and policy statement is checked against the linked page;
the example code in the SDK guides is saved as files in the site’s repository, bundled with esbuild, and checked by a test to match what the guide shows, so syntax errors and wrong imports fail that build; shorter snippets elsewhere are not part of that build;
the site owner reads the page before it goes live (tracked with a reviewed flag in each page’s source file; unreviewed pages are not published).

AI assistance does not replace testing. Where a guide describes behaviour we could not verify from documentation, it says so.

What we do not do

We do not publish experiences we did not have (“we tested”, “in our game”). The build-logs section will only contain real experiments by the site owner, each tied to evidence such as dashboard exports.
We do not publish metrics, revenue figures, player counts or review outcomes unless they come from those experiments.
We do not accept payment for coverage.
We do not backdate pages. A page’s published date is the day it went live; it is set by a script at publication time.

Corrections

If a portal changes a requirement, we update the page, change its “Sources checked” date, and add an “Updated” date. Report errors through the contact page with a link to the official source.

Why this approach

Google’s guidance for site owners asks for content that is written for people, shows first-hand expertise where it claims any, and is clear about how it was produced, including when automation is used (Google Search Central; guidance on AI-generated content). Portal requirements are also a fast-moving target, so a page is only as useful as its link to the current official document.