Icons and components — evidence and limits

Meaning update, 5 October 2026: both recommendations are approved. The evidence below retains its original bounded preparation scope; no implementation completion is claimed.

History and previous answers

The original spreadsheet separately names App Icon within logo applications, Icons & UI within mobile design, and Buttons, Forms and Navigation within interface components. The later identity extraction combines the mobile rows into App Icon Suite and says the component rows fold into web and app systems. That extraction is a proposal, not approval of every entry.

The original recorded August ratification reply approves individual content types while reserving concerns about their headings. The original list in Git includes Icon System. That type name carries forward without another question. The current review does not use that approval to invent a detailed definition or declare physical storage complete.

Approved source-versus-subject, useful-part and source-versus-interpretation relationships also carry forward. The digital-system and responsive-rule meanings were approved separately. The icon/component answers do not settle the remaining visual-element vocabulary or complete its implementation audit.

Inspected primary sources

• Apple App icons: rendered text and the top illustration inspected during the preceding evidence checkpoint. The guidance concerns application identity and platform-specific masks and appearances. No motion example was classified.
• Apple Icons: rendered primary text inspected. Interface symbols and app identity have different uses. This supports a distinction, not a mandatory database layout.
• Carbon Button guidance: current primary text inspected for named variants, labels, states and interactions. Its warning about some examples not being production-ready was also read. No live interaction was tested, and no claim is made that a particular captured product uses the component.

The review compares retaining a broad digital-icon description with a specific app-identity description; it also compares prose-only component detail with searchable component kinds. The more explicit descriptions are recommended because they support distinct research questions. They do not imply a new type for every visible fragment.

Selected system evidence

The repository receipt icon-identity-preflight.json preserves selected live schema and record results, thirteen hashed local excerpts and the historical type-list hash. It records Iconography as a craft, a visible element and a guideline section in different contexts. Those are different questions, not proof that a second craft tree is needed. Eight sampled element assignments were read as records, not visually certified.

One selected published Apple guideline says the same rounded shape applies across all platforms. Current primary guidance explicitly varies the platform masks. This is a confirmed text mismatch, with authoring, effective date and all consumers still to investigate before repair. Two selected published icon sections have no source URL in that field; that does not prove evidence is absent elsewhere.

The local element prompt and writer separate a visible component from craft. The selected writer normalizes vocabulary and performs its analyzer deletion and upsert in separate calls; the shown payload does not carry an evidence label. The inspected query filters the element relationship. The guideline hook selects published sections, and iconography uses a specimen gallery. These local observations do not prove the deployed path or the origin of the sampled rows.

The inspected guideline-authoring prompt can use training knowledge when extracted text is absent; its seed function writes unpublished sections. The actual path that produced and published the two sampled rows is not established. No model run, production write, migration, prompt change or automation change was performed.

What the full audit still owes

Trace collection and capture conditions through source evidence, composed prompts, validation, writes, publication, retrieval and the interface. Distinguish an original asset, a documented component, an observed instance, an identifying product relationship and a governed system. The same symbol can appear in several components or products; a component can have several documented versions. Those relationships require evidence rather than a match on appearance or company name.

Verify human corrections, duplicate handling, withdrawal, permissions and stable citations. Check physical keys, data types, required values, junctions, constraints, indexes and query behavior before specifying storage changes. Monitoring should retain changing source/version context rather than silently replacing the evidence behind earlier answers. Scheduling and cost controls remain part of that complete audit.

Prepared 5 October 2026.