On this page
An article can have impeccable sources and an image taken from the wrong place. It is an easy mistake and a hard one to spot: the photo from the original story looks perfect for illustrating the story, and one link in a tag is enough to use it. That is why AndroidLab has a check that runs before upload and asks a single question: is this image ours, or does it come from a source?
What the script checks
The check is the script androidlab_image_policy.py. It reads the article’s image manifest and accepts an image only if three conditions hold.
- The declared provenance is one of five owned categories: owned, generated, screenshot, diagram or illustration.
- The publishable field is explicitly true. If it is missing, the image fails.
- The file exists locally and carries no external source metadata, such as the address of the original image or of the page it came from.
A second check looks at the HTML: it rejects any image embedded from an external address. Links to source pages stay free, while image files may only come from the site’s own domain.
Six tests, nothing published
On 8 November 2026 I ran the script by hand with a test file and minimal manifests, without creating any article. These are the results.
- Generated image, publishable, no external metadata: accepted.
- The same image with an external page address as its origin: rejected, because an owned asset must not carry source metadata.
- Provenance declared as a source image, even with publishable set to true: rejected, because source images remain reference only.
- Generated image with publishable set to false: rejected.
- HTML with an image loaded from an external domain: rejected, with the address reported in the error.
- HTML with an image hosted on the site’s own domain: accepted.
In the rejected cases the script exits with code 2 and a message naming the manifest entry that caused the problem. The block is clear-cut, so there is no room for a “let it through anyway”.
After the check, the human work
The script verifies how the image is described, not what it shows. The editorial procedure adds steps that no automatic check replaces. A generated cover is opened and looked at before it is marked publishable: relevance, rendering at article width, and the absence of invented logos or fake screenshots all matter. The androidlab.it signature is applied after generation by a deterministic program, not requested from the model, and the signed copy is reviewed too, to make sure it hides no details.
There is also a distinction the manifest alone cannot enforce. A generated illustration explains a concept, but it does not prove an execution, a performance figure or an app’s compatibility. Documenting an interface takes real, unmodified screenshots. OpenAI’s guide to image generation describes how the tool works, but it does not settle what a site may present as evidence.
The limits of this check
- It trusts the declaration. If someone writes “generated” for a copied image, the script cannot know.
- It does not verify usage rights. Owned provenance is not legal advice, and a generated image does not grant exclusive rights just by being generated.
- It cannot see visual errors: a device with too many keys or an impossible detail passes if the manifest is in order.
- It checks the HTML body for embedded images, not what the site theme adds after publication.
That is why the check works best paired with visual review and clear rules about what an illustration may show. The general limit of automatic checks is covered in AI Lab: the guard checks form, not truth.
In brief
- The script accepts only images declared as owned and publishable, and rejects those carrying source metadata.
- It also rejects images embedded from external domains, while links to sources remain allowed.
- In six manual tests on 8 November 2026 it accepted two regular cases and rejected four irregular ones, publishing nothing.
- It does not replace visual review or a rights assessment: it checks the form of the declaration, not its truth.