Graphics and intended use — evidence

Bounded review preparation, 5 October 2026. The original assessment below is retained as history; the revised assessment at the end supersedes its recommended use labels. This covers the four remaining parts of B-06. No answer, physical schema or record correction is approved by the recommendation.

History and scope

Read the original B-06 card, current Brand & Identity proposal, current Content guidance and the August 16 source request. The original card recommended excluding seven names together. Its examples and claims about what exists were recommendations and dated observations, not an approval. Its original text is preserved.

The current Books, overviews and speaker-card review covers the other three children. Template existence, useful document parts, evidenced version/publication/capture distinctions and separate source/subject browsing already have decisions. These four questions do not reopen them. Focused searches of the ruling and answer records did not locate an individual approval for the four names. This is a bounded recovery result, not a claim to have accessed every prior conversation.

The proposed distinction between intended use and observed publication is explicit. It must not be silently treated as an already implemented field. The current Content chapter's source-derived channel explanation does not establish intended use for an unpublished deliverable, or prove which slot an extracted image occupied. Its full collection and distribution claims remain part of the comprehensive audit.

Inspected sources

The supplied archive/reference/brand-guidelines-ref/github/GitHub Brand Guidelines 2025.pdf, pages 62–63, was rendered and visually inspected. The first page shows social and wallpaper template previews. The next lists ready-to-use deliverables, including Blog Art and Email headers, and distinguishes complete key art from assets. Its folder example distinguishes surface, ratio, logo inclusion and export scale. No private Drive or Figma source was accessed. The previews do not prove a published finished graphic.

The old Images 2.0 source image was visually inspected. It depicts a magazine-like object with a chameleon on its cover, placed on a tabletop. That does not prove a physical magazine, photographic production, Key Visual status or article-header placement. The old Instagram example remains uninspected and is not evidence for the recommendation. The original card's confident interpretation of it is not carried forward as a verified fact.

NASA's wallpaper page explicitly offers desktop and mobile files. Both linked images were viewed: the illustrated characters appear in different horizontal and vertical compositions. This is a primary example of publisher-stated intended use, not a library record or evidence of anyone installing it. Source URLs and observation limits are in placement-graphics-preflight.json.

Selected system checks

graphics-use-live-evidence.json preserves the schema-query text, selected observed columns, and literal results of three read-only queries. It is not a schema export or a constraint audit.

The two original image examples still return image media with blog_post and social_post content types. Their scalar values do not establish their actual form. The selected registry query returns those content-type values; Social Post's description says text, while the selected row is an image. That is a compatibility question to trace, not proof of its cause or authorization to relabel it. Illustration appears as an active element and in retired registry entries; those entries do not establish an approved whole-piece Illustration type.

Exact-name checks for the proposed header, social-graphic and wallpaper tokens returned no matching registry or alias rows. This is limited to the queried tokens and stores. It does not establish that the concepts are absent everywhere, nor that any addition is cost-free.

Selected local consumers were inspected: backend/services/post_processor.py handles scalar updates and separately loads vocabulary and approved aliases; frontend/src/lib/build-content-query.ts applies content-type filters. This is a local trace only. No deployed writer, complete page extraction path or live saved-filter behavior was certified. The full audit must identify how source-derived defaults, analysis, validation and later updates produced the sampled assignments.

Independent architecture assessment

Retaining the older blanket exclusion is too broad. The source mixes intended deliverables, reusable tools and output variants. Adding every source label as a type is also weak: it can duplicate distribution descriptions and turn a repeated publication into an apparent new kind of work.

The recommendation preserves all four browse names as intended uses. That can express an unpublished deliverable without inventing a publication. A whole-piece type remains a legitimate alternative for each name. Functional type boundaries are a product-model choice; no universal standard makes the answer automatic. The separate Speaker Card proposal concerns a communicative form, whereas these names primarily describe a setting or use. Joe can choose differently for any individual name.

The implementation audit must examine the complete path: source context and bytes → work/version/capture identity → classification inputs and composed prompts → validation → writes → publication evidence → queries, trackers and citations. Inspect relationship direction, multiplicity, required values, uniqueness, junctions and indexes against actual consumers before choosing storage.

Exercise an unused email header, a listing thumbnail distinct from an article header, a speaker graphic used in email and social, a post containing several graphics, a wallpaper with recomposed device versions, and a photograph of physical wallcovering. Preserve uncertain links rather than guessing. Reanalysis must retain human corrections; later monitoring may add publication evidence without erasing the original intended use. Permission and withdrawal behavior must preserve truthful saved references and citations. Scheduling and cost controls remain under their existing gates.

Completion boundaries

Each B-06 child keeps its own answer and dependency record. Preparing these four choices does not close the original bundle, approve identity-element lists or certify database behavior. No production schema, data, prompt, public API or automation setting changed. Full Docs reconciliation, architecture verification, repairs and product acceptance remain separate milestones.

Prepared 5 October 2026.

Revision after Joe's response — 5 October

Joe approved the separate book, overview, speaker-card, podcast and brand-story recommendations, but challenged the email/blog/social names and their underlying classification. Digital Wallpaper remains unanswered. Exact reply and per-choice mapping: docs/reference/2026-10/2026-10-05/graphics-podcasts-books-joe-response.txt and its answers JSON. The earlier assertion that these were useful search names is now a hypothesis to test, not a ratified browse contract.

Recovered internal model

Read the current Content pillar and ratified channel-stack page, then followed the explicit historical reference into docs/reference/2026-07/2026-07-09/secondconvoref.md around its page-section discussion. That discussion separates whole-asset facets, prose synthesis and sub-asset section descriptions. It records a rename from msft_records to section_detail, with compatibility work still outstanding at that historical point. Its old counts are not reused as current truth.

Fresh local inspection found the same distinction represented in code: backend/services/classification_schema.py provides section and element descriptions; text and image analyzer routes mirror validated records into both keys; selected post-processor consumers prefer the section-detail key. frontend/src/types/analysis-result.ts and selected detail and showcase consumers still use the older key. These are local observations, not deployed-file parity evidence.

The prompt itself needs scrutiny: it tells text-only articles to use Hero Banner for the top headline and lede. Its element list combines role and substance, including Hero Image, Background Image, Headline Copy and CTA Copy. Its section records also retain campaign/purpose language under the old publisher-specific content-type name. This can bias the output before the interface shows it. Merely changing a display label would not repair that semantic path.

A fresh schema probe preceded the live queries. The selected undeleted-content query returned 9,060 records with the legacy JSON key, 113 with the new key, all 113 carrying both with equal payloads. It returned zero non-null scalar section and element values. Literal SQL and results are in graphics-section-live-evidence.json. These counts describe key presence, not correct classification or an absence of all other section relationships. No record was changed.

External comparison

Microsoft's email content-block documentation distinguishes elements, sections that retain layout, and full email templates. A section can contain visual and verbal elements. Headers and footers are examples of reusable section blocks. This supports testing section identity separately from image identity; it does not prescribe our vocabulary.

Microsoft's Hero web part combines images, text and links in several layouts. That is a counterexample to treating every hero as one image. Mailchimp's image guidance explains the limitations of putting text inside images. It supports retaining actual text separately where available, while preserving the rendered composition. These sources do not establish that Header and Hero are synonyms, or that people search for Social Post Graphic.

Next bounded examination

Compare retaining the proposed use labels, composing discovery from supported form plus context, and keeping a small number of explicitly defined delivery names. Inspect a real email header versus hero section, article image versus listing thumbnail, and social post with photograph versus designed composition. Include text rendered in an image and the same wording as a separate element. Trace source capture and element location through classification, validation, storage, publication relationships and search. Check the full consumer set before proposing changes; the observations above are only a preflight.

No new fields, whole-piece types, mandatory hierarchy, data migration, prompt changes or automation settings are approved here. The next user review should settle only the residual meanings exposed by that examination. Existing document-part, version and source/publication decisions remain authoritative.

Revised evidence and assessment

The revised review replaces the first three recommended use labels with separately answerable proposals for asset descriptions and evidenced context. Digital Wallpaper remains pending. It does not create fields, retire production values or approve data cleanup.

Primary examples inspected

• Mailchimp's section-manager screenshot lists Header, Body and Footer; its documentation separately offers Header and Hero presets. Its rendered email-template illustration combines a bicycle image with headline, copy and button-like elements. This is a template illustration, not a sent email or inspected HTML. It cannot settle which words are baked into source pixels.
• The live Retell article separates its headline and large artwork from the later Keep reading cards. The latter link to Unify, Wix and CodeRabbit articles. Current visible placement does not prove historical capture layout, byte identity, authorship or campaign membership.
• The original Instagram carousel was now visually inspected. Its first attachment is a rough logo drawing; its second depicts an interface. Caption text is separately displayed. The platform's generic Photo wording is not evidence of photographic production. The depiction is not proven to be an unmodified screenshot. The earlier stored ordinal has not been matched against current source bytes.

Primary links are on the revised reader page. Exact observations and limits were appended to the existing docs/reference/2026-10/2026-10-04/placement-graphics-preflight.json, under unit158. The earlier statement that Instagram had not been inspected applies only to the original preparation.

Local mechanism and narrow live sample

Fully read backend/services/section_hint_parser.py. The keyword-based helper falls back to hero_banner for the first heading, cta_section for the final heading when there are at least three, and feature_section otherwise. With no headings, an opening paragraph becomes a hero hint. Local reproductions assigned hero_banner to an ordinary paragraph and cta_section to a final Limitations heading. No LLM call was involved.

Selected landing/newsroom ingestion paths store these hints. The text analyzer route adds compact section/text hints to its input and asks for alignment where possible; their source and offset are omitted. Selected validation requires values and flags unknown names but does not establish visual layout. Selected persistence mirrors section_detail and msft_records, and detail readers display section/element labels. This supports an upstream mechanism requiring investigation, not proof of the cause of any historical record. Deployed parity is not established.

A schema-first live query inspected two undeleted article records. Their section arrays contain 24 and 21 records. Selected entries include Accept all and Loading... as copy, and both samples contain an unknown CTA Section warning. The sample is not a prevalence estimate. Global interface, temporary capture state, authored material and related-story recommendations need distinguishable context; an interface element can itself be relevant research evidence.

Literal results, query text, file hashes and local reproductions are preserved in graphics-section-path-live.json and graphics-section-path-inspection.json under docs/reference/2026-10/2026-10-05. Exact-key inventory located 107 lines in 24 local files. That coverage and selected path inspection do not certify every runtime consumer.

Alternatives and compatibility

Retain the compound names as use filters: preserves commissioning language, but Header stays ambiguous and Social Post Graphic needs exclusions. Compose discovery from the asset and context: recommended, because one asset can support different research paths without changing identity or forcing a designed-graphic classification. Add selected delivery names later: possible where a specific user need and definition justify a maintained filter. Source wording remains evidence in every option; it is not automatically promoted into a canonical type or filter.

The current Content pillar and ratified channel stack already separate distribution, content form, useful document parts and source versus publication. The proposed choices apply those rules to the disputed names. They do not reopen complete-page membership, make a section a channel, require every useful part to be a standalone work, or replace the channel vocabulary. Product Detail Page was already accepted; a lingering open-status sentence in the earlier relationship review is corrected in this publication.

Before implementation, inspect all writers and consumers, correction retention, permissions, available capture structure and the query behavior needed for these research paths. Any revised prompt or extraction rule needs representative positive and negative examples, migration compatibility and rollback evidence. The decision pass can proceed without treating a detected implementation defect as another product-meaning question.

Website, page and section audit — 5 October

Joe requested the broader ecosystem check and pointed to REVISED-PIPELINE.md. This bounded pass followed that specification into website ingestion, asset classification and routing references, then inspected the live schema before naming storage. Literal queries and responses: docs/reference/2026-10/2026-10-05/page-section-audit-live.json. The earlier counts above remain dated observations; they were not recounted here.

Fresh system evidence

• content_item and its content_items view expose nullable text page_type, section_type, element_type, channel and source_type. The exact active enum-name query for page_type, section_type and element_type returned no rows in schema_enums. Code has preferred lists; this limited query does not establish that definitions are absent everywhere.
• The live route.website prompt calls a single-product page product, a family hub product_group, and a capability page feature. The local URL classifier assigns /products to product and /products/name to product_detail. It also maps a blog listing and a blog article to the same value. This is a contract mismatch, not evidence that the approved PDP meaning should be reopened.
• The selected live source clusters contain text, screenshot, image and video rows sharing the source page's scalar classification. The release-notes cluster uses product_detail; the selected ChatGPT and Sora story clusters use blog. Those assignments do not establish actual page purpose or each extracted asset's form. Source URLs and returned rows are preserved in the receipt.
• Live derive_content_channel prefers the linked source's channel, then maps website sources by page type to website, blog or newsroom. The ratified channel stack describes a conceptual distribution model; these source buckets do not prove that model is implemented. Page types also occur on social rows, so the existing field cannot be assumed to describe only website templates.
• The selected scheduler defaults have their own page-type list. This creates an additional consumer to reconcile: correcting descriptive page classifications must not accidentally change collection cadence. No scheduler or automation gate changed.

Local path and root-cause candidates

backend/services/landing_ingest.py derives a source cluster from its canonical URL and copies the URL-derived page type onto its extracted rows. Its metadata also uses page_type for a collection kind. _inject_hero puts an Open Graph or Twitter sharing image first; _build_rows calls the first eligible image hero_image and a viewport screenshot page_screenshot_hero. These are extraction labels, not independent visual proof of authored hero placement. The Open Graph protocol defines og:image as an image representing the graph object, not a page-location declaration. Primary specification.

backend/services/section_hint_parser.py adds positional hero and closing-CTA hints. pipeline_analyze_text.py sends compact section/text hints without their source or offset. The selected classification schema mixes section roles and element roles with media descriptions; its text-only guidance assigns the headline and lede to HeroBanner. The inspected live prompt's section-record fields do not provide per-record section identity or direct asset references. This does not prove no other structure exists.

The selected _backfill_page_type path in post_processor.py prefers URL classification, then analyzer output and legacy category inference. Selected readers differ: frontend/src/lib/content-view.ts groups by the scalar page type, while frontend/src/hooks/useEntityClusters.ts reads the metadata collection kind. All consumers, deployed-file parity, historic causation and human-correction protection remain unverified. These are candidate repair contracts, not permission to patch one reader or rename the field in isolation.

Recommendation and alternatives

Retain and clarify existing page/section distinctions, while separating complete-page purpose, observed section role, contained content and asset appearances. Use shared vocabulary with applicability rules rather than an independent ontology for each template. Preserve the approved channel stack and PDP meaning; reconcile overlapping physical fields only after the complete consumer audit. A section can contain several elements, and a reused asset can occur in several sections or pages. Unknown placement remains unknown.

Keeping the three compound asset labels would preserve familiar commissioning terms but still require all these distinctions. Adding a separate taxonomy per page type would multiply equivalent descriptions and make cross-page research harder. The narrower recommendation is to keep source wording and compose discovery through supported descriptions and context. The three graphics choices remain unapproved; Digital Wallpaper remains a separate fourth choice.

Primary references checked: the HTML header definition, USWDS landing-page example, and Shopify template documentation. They support distinctions, not one mandatory BrandTrackers vocabulary.

Before repair, verify capture/version identity, element-to-asset evidence, original versus related-story imagery, responsive layouts, precise product links, human corrections, saved filters and tracker equivalence. Trace every writer and reader and provide compatibility and rollback. No production data, schema, prompt, public API or automation changed in this pass.