Images, sections and where they appear

Answered on 5 October 2026. All four current recommendations are approved. Email, article and social imagery are found through evidenced context; Digital Wallpaper remains a searchable intended use. The earlier alternatives below are historical, not new approval requests. The book, overview and speaker-card recommendations are answered and need no repeat approval.

How the page and its parts fit together

Your latest response asks for a complete connection between website page types, sections, elements and independently useful assets. Header and hero descriptions must allow image, video and text. The bounded check has now examined the live page classifications and website prompt, local scraping and section analysis, selected readers, and primary external documentation. It exposed gaps in the current implementation; the complete deployed-path audit remains ahead.

The earlier proposal treated Email Header, Blog Header Image and Social Post Graphic as useful search names. Your examples exposed the problem: those names can mix what an asset is with the section containing it or the place it appears.

My revised recommendation is to describe the asset and connect it to its context. Someone should be able to find photography used in newsletters, opening artwork for articles, or illustrations published on Instagram without every image acquiring a new type for each use. Source wording remains searchable, even when it is not a canonical type or filter. The answer is not to add these three named filters now; the underlying part and publication relationships are already approved.

Choice	Recommendation
Email openings	Find images and compositions through email context and observed section roles. Do not add a maintained Email Header type or intended-use filter now.
Article imagery	Preserve the relationship to the article and where the image appears. Do not add a maintained Blog Header Image type or intended-use filter now.
Social attachments	Keep the post, caption and attached media connected. Do not add a maintained Social Post Graphic type or intended-use filter now.

Joe accepted these recommendations together, including Digital Wallpaper. This settles the meanings and research behavior; it does not approve a new table, a mandatory hierarchy or a final list of section names.

One model across page types

Recommendation: use shared descriptions for pages and their parts, with rules for where each description applies. A homepage, product detail page and feature page can all contain a hero, text, video or product imagery. They should not need separate copies of every description. The already-approved Product Detail Page meaning should remain consistent wherever it is used.

Question	Example	What stays separate
Where was it published?	A company website or a particular email	Distribution context and the captured page or message
What complete page is this?	Homepage, product detail page, feature page or article	The page's form and purpose, its subjects, and any reusable template
Which part are we describing?	Site header, article introduction, hero or related-story list	A particular section and its role in that captured layout
What does that part contain?	Text, photograph, illustration, video or button	The content and its function; a headline is not a file format
Where else does the asset appear?	The same illustration in an article and newsletter	One asset's identity and each evidenced appearance

A site header and an article header are not interchangeable. Header is useful when qualified by what it introduces; it is not the best universal name for opening artwork. HTML defines a header as introductory or navigational content, and its article example includes a headline and date. It does not require an image. HTML standard.

Hero is a layout description, not a synonym for header or image. The U.S. Web Design System places its landing-page hero after the site header and combines a heading, copy and a call to action. For our review, a hero can contain text, an image, video or a combination. Its role needs evidence from the layout; being the first extracted paragraph is insufficient. Landing-page example.

A blog listing and an individual article also need distinct descriptions. Shopify explicitly separates its blog-list template from its article template, and distinguishes both from homepage and product templates. That supports the distinction without making Shopify's full template list our taxonomy. “Found on a blog” alone does not identify the complete page or an image's position. Template documentation.

Keep an asset's appearance tied to the relevant page or message and capture. Layout may differ across dates and screen sizes. An image offered for sharing, a publisher's featured image, visible opening artwork and a related-story thumbnail are not automatically the same role. Source wording remains evidence even when the actual placement is unknown. Nor should an extracted image inherit the page's product or campaign relationships without supporting evidence.

For example, a product detail page can contain a headline, demonstration video, product photographs and purchase controls. The page is a Product Detail Page; its photographs remain photographs, its video can have its own supported form, and each useful part stays connected to the page and depicted product. The page's hero is a composition that may contain several of these parts. This is an illustrative application of the model, not a claim that every collected page already has those links.

These distinctions refine the explanation behind the three existing choices. They do not add another required approval, settle the complete section vocabulary or introduce a mandatory storage hierarchy. The approved channel stack still governs distribution; the current database's collection-source buckets are not a replacement for that model.

Already decided — no new answer needed

A complete page can be a library piece. Selected useful parts can also be browsed independently, linked back to their source. The same work may appear in several places; versions, publications and captures keep their distinct meanings. A photograph stays a photograph when it appears in an email or article.

The approved channel stack distinguishes distribution from content. Email is a channel; a newsletter is a type of content. Social media is a channel; Instagram names a platform. An article opening describes a location within the article. This review does not make every section another channel or require every existing use of “touchpoint” to be renamed. The exact mapping still needs the implementation audit.

Intended use also needs evidence. A studio can say an unpublished asset was prepared for email. That supports the stated use; it does not prove an email was sent. Collection from a case-study page does not establish where the depicted work originally appeared.

1. Find email imagery without treating the header as one image

Answered question: should we leave Email Header out of the maintained type and intended-use filter lists for now, preserving source wording and finding the asset through supported email context and observed role instead?

Approved: yes. A header can be a section containing a logo, text and navigation. A hero area may combine a large image, headline and button. The image, the rendered composition and the whole email can each be useful, but they are not interchangeable. Preserve a source's “email header” delivery name without treating it as proof of a particular layout.

Checked example: Mailchimp's section manager distinguishes Header and Hero presets. Its published email-template illustration shows a bicycle image alongside separate-looking headline, copy and button elements. I inspected the rendered illustration, not a sent email or its HTML; it does not prove which words are baked into the image. Section manager, email-template illustration.

Counterexample: a text-only opening is not an image. A photograph near the top remains photography. Its position alone does not prove that the author intended a hero treatment.

Alternative: retain Email Header as a defined intended-use filter for explicitly named deliverables, separate from the observed section. That preserves a familiar commissioning label, but still needs the same image-versus-section distinctions. I recommend retaining that wording as source evidence first, rather than adding another maintained filter now.

Practical effect: someone can research email photography or opening compositions, then inspect the whole email. Capture and classification must preserve available visual and verbal context and distinguish intended use from observed publication. Unknown layout stays unknown.

2. Connect article imagery to the right article and location

Answered question: should we leave Blog Header Image out of the maintained type and intended-use filter lists for now, preserving source wording and finding the imagery through its evidenced article relationship and placement instead?

Approved: yes. Keep the image's own description. Distinguish opening artwork, images inside the article and thumbnails linking to other stories. A publisher's featured-image designation is useful evidence, but does not alone prove where the image appeared in a particular capture.

Checked example: the live OpenAI Retell article has a headline and subheading above large Retell artwork. Farther down, Keep reading contains artwork linking to Unify, Wix and CodeRabbit stories. I inspected both regions. This establishes their current visible context, not the exact layout or asset bytes of an older capture. WordPress likewise allows a featured image to appear in different positions according to its theme. Featured-image documentation.

Counterexample: the CodeRabbit artwork on that page does not become Retell campaign work because the collector found it there. A mid-article chart is not automatically a header image.

Alternative: retain Blog Header Image as a maintained intended-use filter for explicitly documented opening artwork. It would still require separate placement evidence and would not apply to every extracted image. I recommend the relationship approach because it preserves the same asset across different page uses without forcing a new type.

Practical effect: collection must keep enough context to explain which article an asset belongs to, where it appeared and whether it links elsewhere. Search and trackers should use those supported relationships. Collection source alone must not create subject or campaign membership.

3. Describe social media without calling every attachment a graphic

Answered question: should we leave Social Post Graphic out of the maintained type and intended-use filter lists for now, preserving source wording and finding the media through its post and supported descriptions instead?

Approved: yes. Keep caption text connected to the post and its attachments. Preserve attachment order and publication evidence. Describe a photograph, illustration or designed composition when the evidence supports that description. A single attachment can combine several techniques; this is not a forced one-label choice.

Checked example: the original OpenAI Instagram carousel shows a rough logo drawing followed by an image depicting an interface. The caption is displayed separately. Both attachments were visually inspected. The interface depiction is not thereby proven to be a genuine screenshot, and the stored asset has not been matched byte-for-byte to this current carousel.

Counterexample: a platform's generic “Photo” label does not establish photographic production. A square image does not establish social intended use. An unpublished design can still have source-stated social use without a publication claim.

Alternative: keep Social Post Graphic as a maintained use filter restricted to explicitly prepared graphic compositions. That could help people researching commissioned deliverables, but would need clear exclusions for ordinary photographs and other attachments. I recommend preserving the delivery wording without making it a universal browse category.

Practical effect: people can find illustrations on Instagram or photography in social posts while opening the parent post for its caption and context. Collectors must preserve the post-to-asset links. Platform presence alone must not establish authorship, sponsorship or campaign membership.

Digital Wallpaper describes intended use

The approved recommendation is: Digital Wallpaper as a defined, searchable intended use for artwork explicitly offered as a phone or computer background. Unlike the three compound names above, this describes a specific use supported by the publisher's offer. It does not claim installation on anyone's device.

The previously inspected NASA example offers desktop and mobile compositions. An ordinary website background or physical wallcovering does not qualify merely because it is called wallpaper. The alternative is a whole-piece Digital Wallpaper type. The original choice preserves the fuller reasoning. Joe’s latest approval includes this separate fourth recommendation.

What the deeper check found

The local collection helper can label the first paragraph as a hero and the final section as a call to action based on position. Two counterexamples reproduced that behavior. This means stored section labels cannot serve as their own proof of layout. Selected live records also contain interface or loading text alongside article descriptions. Those observations need context; they do not justify deleting all interface content, which may itself be worth researching.

The new check also found different product-page meanings in the live website prompt and local URL classifier. Extracted text, images and videos can share the source page classification, which does not establish their own form. A sharing image can also be selected as a hero without observed layout evidence. These are implementation findings to resolve before trusting page-part searches.

The evidence note records sources, inspected paths and limits. The complete deployed path, saved-query behavior and correction handling remain to verify. No production data, prompts or automation were changed.

The review desk keeps remaining relationship and classification work ahead of smaller naming cleanup. These approved meanings guide the later collection, pipeline and query contracts; they do not certify those contracts as implemented.

Earlier proposal record — first three superseded; wallpaper accepted above

The distinction behind all four choices

Already decided: a piece can appear in several places. Useful versions, publications and captures remain distinct. Reusable templates and finished outputs also need to retain their own identities. A useful graphic can be browsed independently while linking back to the document or page containing it.

The additional distinction proposed here is what a graphic was made for versus where we have evidence that it appeared. A studio can deliver an email header that has not been sent in an email. An illustration can later be reused on social. The library should not turn either situation into a false publication claim.

The earlier proposal assumed these would be useful names for finding work. That assumption is now being reviewed. Under the recommendation, a search for email headers would still work. The result would explain whether the evidence says “prepared for email,” “seen in this email,” or both. Other supported descriptions remain available. We would not automatically call every graphic a Key Visual or Illustration.

1. Email Header describes intended use

Recommendation: keep Email Header as a defined, searchable intended use for a graphic prepared for the opening area of an email. It does not mean the complete email, its reusable layout, or the technical sender and routing metadata also called an email header.

Checked example: page 63 of the supplied GitHub Brand Guidelines 2025 lists Email headers among its ready-to-use deliverables. That supports the existence of a deliverable made for email. The inspected page does not show an actual sent email or establish that any particular file was used in one. The private asset folder was not accessed.

Counterexample: an email containing an unchanged photograph does not, by itself, prove that the photograph was designed as a header. A logo appearing at the top also does not automatically become an Email Header type. The placement can still be recorded when observed.

Alternative: make Email Header a whole-piece type for a finished header graphic. This is a familiar production-delivery name. It would still need separate publication evidence, and a reusable source would remain distinguishable from a completed graphic. I recommend intended use because the graphic's substance can remain the same when it is used elsewhere.

What changes downstream: collection must retain delivery context as evidence without inventing a sent email. Prompts must distinguish the graphic from an email screenshot or template. Search and trackers must support this entrance even when no publication has been observed. Monitoring a later email should add its appearance without erasing the earlier evidence.

2. A blog header is not every image collected from a blog

Recommendation: keep Blog Header Image as a defined, searchable intended use for artwork prepared to introduce a blog article. Distinguish that from a listing thumbnail, an image inside the article and the complete article itself. A graphic may serve more than one of these uses when evidence supports it.

Checked example: the supplied GitHub guideline page lists Blog Art as a ready-to-use deliverable. That broad phrase does not establish a header specifically. The older review also used the Images 2.0 art card collected from OpenAI's research listing. Its inspected image depicts a magazine-like cover on a tabletop. Its filename and stored collection page do not establish actual placement at the top of an article, so it must not be used as proof of a header assignment.

Counterexample: a photograph halfway down an article remains a photograph within that article. A thumbnail linking to the article is not automatically its header. Nor does a depicted magazine prove that a physical magazine or photographic shoot existed.

Alternative: make Blog Header Image a whole-piece type for a finished article-opening graphic. That offers a direct production category, but still needs the same exclusion rules and evidence. I recommend intended use so the identical artwork can be found through article, email or social uses without changing what it is each time.

What changes downstream: page capture must preserve which image was seen where. Classification must not copy the parent article's type onto every extracted image. Original art, page capture and any separately collected version need evidenced links. Unknown placement should remain visible as unknown instead of being guessed from a filename.

3. Social Post Graphic is not the whole social post

Recommendation: keep Social Post Graphic as a searchable intended use for a finished graphic composition prepared for a social post. It may combine photography, illustration and text. The complete post, its caption, attached images and reusable template are distinguishable things.

Checked example: page 62 of the supplied GitHub guidelines shows Social portrait and Social square options in its Asset Generator. Their visible previews combine artwork and event-ticket messaging. This is evidence of templates prepared for social graphics, not evidence that their previews were published as finished posts. Page 63 separately organizes social deliverables by surface, ratio and logo inclusion.

Counterexample: an ordinary photograph reposted on Instagram does not automatically become a designed social composition. Conversely, an unpublished graphic can have documented social intended use. A square aspect ratio alone proves neither case. The older review's Instagram example has not been visually verified in this preparation and is not relied on here.

Alternative: make Social Post Graphic a whole-piece type for the finished composition, with platform and publication kept separate. That may match how someone commissions the deliverable. I recommend intended use because “social” identifies its planned setting; the graphic's supported form and subject should remain findable independently.

What changes downstream: collectors must distinguish a post from its assets. Analysis must not infer sponsorship, authorship or campaign membership from the platform or a logo. Several graphics can belong to one post, and one graphic can appear in several posts. Browse results should retain that context without multiplying the creative work.

4. Digital Wallpaper is a device-background use

Recommendation: use Digital Wallpaper as a defined, searchable intended use for artwork prepared or offered as a computer or phone background. This explicitly narrows the older name Wallpaper, which could also mean a physical wallcovering. It does not require evidence that someone installed the image on a device.

Checked example: NASA offers The Traveler and Black Hole for desktop and mobile. Both linked images were inspected. They show the same illustrated characters in different horizontal and vertical compositions. The publisher's stated use supports finding them as digital wallpapers; their relationship and layout differences should stay visible.

Counterexample: a background image on a website is not automatically a digital wallpaper. Neither is a photograph of patterned wallpaper on a wall. An image's dimensions or ability to be downloaded are insufficient evidence of this intended use.

Alternative: make Digital Wallpaper a whole-piece type. It is a recognizable finished deliverable, so this is a reasonable choice. I recommend intended use because an illustration or photograph can be offered as wallpaper without ceasing to be that work. This is a modeling recommendation, not a claim that the industry has one mandatory classification.

What changes downstream: collect the actual download and its source context. Preserve meaningful desktop/mobile layout versions, without treating every file size or encoding as a new work. Search should find the backgrounds without claiming installation or inferring a campaign. Citations must identify the inspected version.

What happens next

The original proposal asked for four separate answers. Your response returned the first three names to research; Digital Wallpaper remains unanswered.

The evidence note separates observed examples, existing data, proposed meanings and the remaining technical audit. The review desk holds the other independent choices. Existing questions are not being sent again.

Prepared 5 October 2026.

Last reviewed 5 October 2026.