# Corporate Illustrations Specification **Conformance target:** Original flat-vector product illustrations that read as their concept at thumbnail size and ship license-clean **Audience:** Designers, engineers, and PMs producing or commissioning illustrations for onboarding, empty states, marketing pages, decks, and help content **Scope:** Multi-element scene illustrations built from a hero object, an action, and an outcome. The "corporate" style: sparse, calm, flat-vector product scenes. Distinct from `illustrations/flat-art-illustrations-spec.md`, which governs single-object monochrome icon-family art. **Companion specs:** `illustrations/flat-art-illustrations-spec.md`, `visual/visual-language-spec.mdx`, `visual/style-guide-design-spec.mdx`, `accessibility/WCAG-AAA-spec.md`, `equity/design-for-low-literacy-spec.mdx`, `equity/bias-audit-spec.mdx`, `equity/gender-bias-spec.mdx`, `equity/financial-concept-framing-spec.mdx` **Implementation home:** `general-icons/` holds the working grammar, the archetype and per-concept recipes, the generation protocol, and the shipped library (`docs/undraw-style-requirements.md`, `docs/undraw-generation-protocol.md`, `outputs/manifest.json`). This spec states the rules that must hold and how to check them; the recipes live there and are not restated here. Terms **MUST**, **SHOULD**, and **MAY** follow [RFC 2119](https://www.rfc-editor.org/rfc/rfc2119). **The core claim:** these illustrations fail on semantics, not on style. An asset can be flat, sparse, on-palette, and correctly proportioned and still be worthless because a viewer says "finance" instead of "money is being sent to a family member". So the gate is a stated one-line read, verified at thumbnail size by someone who was not told the answer, and every style rule below is subordinate to it. **Out of scope:** Single-object monochrome icon art, photography, character illustration as a subject in itself, animation, and data visualization. --- ## 1. Purpose and conventions | Field | Content | |---|---| | **Rule** | Every illustration MUST be commissioned and accepted against a written one-line target read plus the named wrong reads it must not produce. Style review happens only after the read passes. | | **Why** | The recurring failure mode across the existing library is style-first production: assets that looked correct and communicated a category rather than an event. Named wrong reads ("generic banking app", "checklist", "finance dashboard") are what make the failure detectable, because the generic read is always plausible in isolation. | | **How to verify** | Show the 240 px thumbnail to someone who has not seen the brief and ask what it shows. Their phrase must match the target read, not a named wrong read. One reviewer is enough to fail it; passing needs two. | Each section below uses the same Field/Content table format and lists **MUST / SHOULD / MAY** rules. The unit of work is one **illustration**: one canvas, one concept. --- ## 2. Semantic construction: hero, action, outcome | Field | Content | |---|---| | **Rule** | Every illustration MUST fill three named semantic roles before any drawing starts: one **hero** object, one **action** cue, one **outcome** object or state. The outcome MAY be `none` only for a single integrated symbolic object whose meaning is complete in itself. | | **Why** | Drop the action and the asset degrades into a noun icon. Drop the outcome and it degrades into generic product UI. Both degradations pass a style review and fail a user. | | **How to verify** | The asset's record must carry the three filled-in roles. Point at the element serving each role in the artwork. If a role has no element, or two elements compete for hero, the asset is not conformant. | **MUST** - Pick exactly one composition archetype from the implementation grammar and state it in the record. - Keep the hero unambiguous: one dominant object, secondary cues subordinate in size and weight. - Make directional movement visible when the concept is movement. A symbol of money is not a picture of money moving. **MUST NOT** - Ship three equally weighted objects, symmetric icon diagrams, decorative token chains, multiple arrows, full room scenes, or a dashboard with no action. - Substitute a status marker for an action. A checkmark means approved, not sent. --- ## 3. Palette: one accent, mostly neutral | Field | Content | |---|---| | **Rule** | Use exactly one accent hue against neutral fills, in the documented balance: roughly 65-80% white or very light gray, 10-20% dark structural shapes, 5-12% accent, and no decorative secondary colors unless explicitly requested. | | **Why** | One accent is what makes a library of independently produced assets sit together on a slide or a page, and it keeps the accent meaningful: it marks the thing that matters rather than decorating the canvas. Multicolor treatment reads as generic fintech stock art. | | **How to verify** | Extract fill colors and their area shares from the SVG. Every color must appear in the documented palette, and the four area bands must be within the stated ranges. Any off-palette hex is a blocking defect. | **MUST** - Take the accent, dark, neutral, and skin values from the implementation palette rather than sampling them from an existing asset. - Keep the asset working on white, on transparent, and on a light tinted background. Verify all three, not just the one it was designed on. - Meet a minimum 3:1 contrast ratio against every intended background for any shape that carries meaning: the hero silhouette, the action path, the outcome marker. Light-neutral-on-white surfaces are the usual offender; compute the ratio from resolved colors rather than trusting the palette name. **SHOULD** - Spend the accent on the action or the outcome, so the eye lands on the part that carries the concept. **MUST NOT** - Use gradients, glossy highlights, bevels, or simulated lighting to create depth. Depth comes from perspective and overlapping planes. - Scatter accent dots or confetti. Accent used as filler is a symptom of a weak read. - Rely on hidden white shapes that only work on one background. --- ## 4. Canvas, geometry, and viewpoint | Field | Content | |---|---| | **Rule** | Default to a square canvas with a square-feeling occupied silhouette (bounding-box aspect ratio 0.85-1.18), a minimum outer margin, and a three-quarter view on every hero object showing visible top and side planes. Dead-on front and orthographic views are rejection conditions. | | **Why** | The library ships into square slots (cards, slides, grids), and a wide composition on a square canvas leaves the object tiny in the slot. Three-quarter view is what makes a flat asset read as dimensional without gradients, and it is the property that drifts first in generative production. | | **How to verify** | Compute the artwork bounding box from the rendered asset: aspect ratio inside 0.85-1.18, no pixels inside the outer margin, hero footprint inside the documented width and height bands. Confirm by eye that a top plane and one side plane are visible on the hero. | **MUST** - Anchor the composition near the visual center, with optional pale grounding beneath the hero. - Keep the hero stable. Reserve slight rotation for secondary cards, documents, tiles, and status tags. - Hold the documented size bands for hero, secondary object, and action path so assets sit at comparable scale across the library. **MUST NOT** - Default to landscape or portrait. A non-square crop is an explicit request, recorded as such. --- ## 5. Object grammar and stroke discipline | Field | Content | |---|---| | **Rule** | Build objects from filled vector shapes with one corner-radius system, one line-weight system, and one shadow strategy per illustration. Strokes are for checkmarks, arrows, small outlines, capture frames, dividers, and lock or shield detail, inside the documented weight range. | | **Why** | Cartoon outlines around every element and mixed radius systems are what make independently produced assets look like they came from different libraries. Filled shells behind white interiors give the same structural read without the outline weight. | | **How to verify** | Enumerate corner radii and stroke widths in the SVG. More than one radius family or more than one non-structural stroke weight is a defect, as is a stroke above the documented heavy-outline threshold on anything other than a device shell or major structural object. | **MUST** - Keep UI content abstract: bars, pills, cards, icons, amount tiles. Simplify iconography to familiar signs. - Reuse shape families within an illustration and across the library. **MUST NOT** - Render literal text beyond a short currency symbol or an essential number. Text does not localize, does not scale down, and does not survive translation review. --- ## 6. People | Field | Content | |---|---| | **Rule** | A human figure is optional and MUST earn its place by adding agency, care, support, collaboration, or scale that an object-only composition cannot carry. When present, the person performs one readable action and the product surface stays the hero unless human service is the concept. | | **Why** | Figures are the highest-risk element in this style: they consume the most craft, they fail most visibly when the anatomy is off, and they pull attention away from the product action. They also carry representational choices that a decorative figure has no justification for making. | | **How to verify** | Name the action the figure performs and the thing the illustration would lose without it. If either answer is vague, remove the figure. Then check the set against `equity/bias-audit-spec.mdx` and `equity/gender-bias-spec.mdx`: who is depicted as the helper and who as the helped, across the whole library rather than per asset. | **MUST** - Hold the documented figure proportions: compact hair silhouette, small head relative to torso, visible neck and shoulder transition, tapered torso, slim angular limbs, simple legs and shoes. - Keep the figure's height inside the documented share of hero height when the archetype includes a person. - Review skin tone, dress, gender presentation, and role distribution across the whole library, not one illustration at a time. **MUST NOT** - Include a decorative figure that poses rather than acts. - Add facial features unless the concept genuinely requires them. - Depict surveillance framing, hacker stereotypes, debt-collection framing, or piles of documents. See `equity/financial-concept-framing-spec.mdx` for the framing rules these illustrations inherit. --- ## 7. Production pipeline and vector craft | Field | Content | |---|---| | **Rule** | SVG is the final asset. Geometric product and UI scenes are authored SVG-first. Organic or silhouette-critical subjects MAY be resolved as raster first, then rebuilt as clean semantic vector groups. Auto-tracing a raster into a production SVG is prohibited. | | **Why** | Traced paths produce accidental detail, unpredictable node counts, and assets nobody can edit six months later. But authoring a wing or a hand as vector before its silhouette is settled wastes the craft on a shape that will be thrown away, so the two-pass raster route exists for exactly those subjects. | | **How to verify** | Open the final SVG. It must carry `` and `<desc>`, grouped readable sections, consistent coordinates, and roughly 40-100 meaningful shapes rather than a single opaque path blob. Where a raster underlies the asset, the manifest must record that. | **MUST** - Record every asset's type in the library manifest, distinguishing true vector from embedded raster, along with dimensions, paths, and hashes. - Keep drafts out of the finished directories, and keep filenames matching across the SVG, white-background PNG, and transparent PNG outputs. - When the raster route is used, run it as two passes: a recognition pass that settles subject, proportions, and silhouette, then a flatness pass that edits that accepted image in place to strip gradients, bevels, and gloss. Do not regenerate from scratch after the recognition pass succeeds, since a fresh generation reintroduces the anatomy failure that was just fixed. **SHOULD** - Provide an accessible name at the point of use. The illustration's `<desc>` is not a substitute for the alt text the surface needs, and a decorative illustration must be marked decorative rather than announced. --- ## 8. Provenance and third-party source boundary | Field | Content | |---|---| | **Rule** | Illustrations MUST be original work produced from this grammar. Third-party illustration assets MUST NOT be traced, remixed, rebuilt, path-copied, or used as training, fine-tuning, validation, test, similarity, or reconstruction input, absent a written permission record. | | **Why** | The permissive-looking licenses on popular illustration libraries commonly permit ordinary use in projects while explicitly excluding AI and ML development, including evaluation. A checked license date and a written boundary is the only defensible position, and "in the style of X" as a prompt is how the boundary gets crossed by accident. | | **How to verify** | Every asset's record names its author or model, its prompt or source of construction, and asserts no third-party asset intake. Legacy reference files in the workspace must be marked as such and must not grow. Re-check the relevant licenses and record the date. | **MUST** - Run the license gate before generation and record it, including the date each license was checked. - Describe targets in this grammar's own terms. Never brief a target as "clone X" or "in the style of X". - Fix weak output by sharpening the read and the brief, never by ingesting more third-party artwork. **MUST NOT** - Scrape, batch download, crawl, embed, vector-analyze, similarity-index, or compile a local dataset of third-party illustration assets. - Copy path data from any third-party asset. --- ## 9. Acceptance | Field | Content | |---|---| | **Rule** | An illustration is accepted only after the thumbnail read passes with two independent reviewers and the asset is scored against the rubric, with concept read weighted above every style dimension combined. | | **Why** | Weighting the rubric this way is what stops a beautiful asset with the wrong read from shipping, which is the failure this library has actually had. A single reviewer who knows the brief cannot judge the read, because they cannot unsee the answer. | | **How to verify** | Pick any three shipped illustrations at random. Each must resolve to a record with its target read, named wrong reads, archetype, the three semantic roles, palette and geometry check results, reviewer phrases from the thumbnail test, rubric score, and the license-gate assertion. If it cannot, the library is not conformant. | **MUST** - Review new illustrations against the shipped library in a grid, not in isolation, so palette balance, scale, and viewpoint drift is visible. - Revise the concept before polishing style when the thumbnail test fails. Polish does not fix a read. - Keep the rubric, its weights, and the passing threshold in the implementation home so the score means the same thing over time. **MUST NOT** - Accept an asset on the author's own read. Self-review is not the thumbnail test.