Logo Protocol

Requirements for supplied marks and rules for creating new logo systems.

Documentation for BrandBuilder 3.0.1. Official release and exact skill asset.

Image generation is for ideation. The exact approved production source is what ships.

This is the single rule that separates a kit from a mess. Everything below follows from it.

The boundary

PhaseToolOutput
Explore the concept spacefrontier image generation, encouragedconversation, mood, direction
Understand a supplied conceptpotrace, Inkscape trace, palette extractionreference geometry, never shipped
Construct the production candidatethe agent composes glyphkit primitives in build/mk_paths.pythe exact candidate offered for canonical approval
Approve canonical sourcesource-bound continuity packetowner decision over production geometry, palette, framing, renderer, and proofs
Prove the marktemplates/validate_glyph.pya pass or a numbered failure
Exportrsvg-convert, resvg, Inkscape, Node resvg, oxipng; ImageMagick only for ICO assemblyrasters derived from the vector master

Generated images are how the operator and the agent agree on direction. They are nonbinding input to a conversation, not an approval gate. After direction selection, the agent builds clean production geometry and presents that exact source through the Gate 1 canonical approval packet before promotion or derivatives. Gate 2 then reviews provisional assembled fundamentals, including the distinct social share image and exact approved copy, before final kit compilation. Silence is never approval at either gate.

Never trace a diffusion output into shipped artwork. Never rasterise a large logo down at runtime to produce a favicon.

Never switch construction methods after canonical approval. Promotion copies the approved source bytes. If the helper, source binding, path arrays, framing, palette, topology, renderer setting, or governed proof changes, invalidate the approval and present a new canonical candidate.

Construction

The applicable source-mode procedure lives in 08-glyph-construction.md. A newly constructed mark uses a parametric build/mk_paths.py against templates/glyphkit.py; an authoritative supplied master binds its approved source bytes and forbids that helper. templates/validate_glyph.py applies the checks appropriate to the declared provenance. Zero failures is the stopping condition.

Every mark is built on a declared square grid, stated in the kit README. fragcap uses 512 units. Pick one and write it down; a grid that lives only in the agent's head is not a grid.

Declare, in the README, as numbers:

  • The grid size
  • The clear-space unit, expressed as a grid measurement and as a percentage of artwork width (fragcap: one terminal, 34 of 512 units, roughly 9 percent)
  • Minimum size per lockup, in pixels
  • The threshold below which the reduced mark takes over

Geometry rules

  • Filled paths, never strokes. Stroked lettering resolves differently across engines, breaks currentColor fills, and does not survive expand-to-outlines in print, vinyl, or font tooling. Convert final strokes to filled outlines and verify the resulting silhouette before delivery.
  • No live text. A shipped SVG must never depend on an installed font. Run inkscape --export-text-to-path before anything ships, then assert it.
  • Geometry inside the viewBox. Verify that every visible path fits the declared canvas with intentional and balanced transparent padding. Reject clipped crossbars, strokes, or counters before export.
  • currentColor where the mark is single-ink, so it inherits whatever semantic token its container sets.

Lockups

Four, minimum:

LockupUse
Horizontalheaders, repository artwork, wide surfaces
Stackedsquare compositions, title pages
Mark aloneapp icons, favicons, avatars, compact controls
Wordmark aloneonly where something nearby already establishes identity

Plus single-ink black and white variants for reproduction that supports one ink, and a reduced mark for small sizes.

Optical alignment. In every lockup the wordmark's ascender and baseline should bracket the mark's principal form, so the two share an optical top and bottom. fragcap had to re-align its lockups in 1.1.0 because they did not.

The reduced mark

At and below roughly 32px, fine detail collapses into noise. Ship a genuinely separate simplified master with its own file, and use it for the small favicon entries. Do not downscale the full mark and hope.

fragcap's reduced mark drops the four reticle corners and keeps the F with its terminals. That is the right shape of decision: remove whole elements rather than thinning everything.

Favicons

The pipeline, in order:

  1. SVG favicon from the full mark
  2. PNGs at 16, 32, 48, 256 via rsvg-convert from the appropriate master (reduced at and below 32, full above)
  3. Apple touch icon at 180
  4. Android icons at 192 and 512
  5. A genuine multi-resolution .ico carrying 16, 24, 32, 48, 64, 128, 256
  6. site.webmanifest

Then assert that the ICO entry count and dimensions match the declared list.

Keep an opaque brand background in the small icons. It protects fine detail across light and dark browser chrome.

Prohibited treatments

Universal, inherited by every sub-brand:

  • No rotation, skew, stretch, outline, bevel, or glow
  • No recolouring individual elements of the mark
  • Never set a wordmark in live text or a substitute typeface
  • Never place the logo over busy imagery
  • Never combine the parent ShruggieTech mark and a product mark into one lockup

Domain-specific prohibitions are a sub-brand's own and belong in its README. fragcap's rule against skulls, weapons, controllers, shields, and crosshairs is the model, and note how it is written: with the actual argument (moderators triage on appearance long before they read a manifest) rather than a slogan.

Handling a supplied concept

When the operator brings a logo idea:

  1. Look at it and describe back what is load-bearing about it in words. If the operator disagrees with the description, the redraw would have been wrong.
  2. Extract its palette for reference. It informs the accent proposal and it does not override any brand system check.
  3. Rebuild the geometry on the declared grid. Trace output is a measuring tool.
  4. Show the rebuild next to the original at three sizes and discuss whether the character survived. This selects a direction only and does not constitute Gate 1 approval.
  5. Construct and present the complete production proof matrix before asking for canonical approval.

Handling an authoritative supplied master

An approved master is not a concept. Declare its identity role, contained source path, media format, SHA-256, color-profile status, license or usage status, and approved transformations before generation. Logo bindings accept portable non-interlaced RGBA8 PNG or passive SVG. A bound PNG additionally records an owner-approved alpha or luminance mask, current source hash, approver, and approval date. Preserve the original bytes and SVG path data exactly. Do not trace, normalize, reconstruct, or silently replace it. Full and Reduced bind independently; the Full source approves lockup placement even when the wordmark is generated from typography.

Palette analysis of an authoritative master produces review evidence only. A color becomes canonical only after a human approval record binds the exact source hash and selected candidate, followed by the ordinary accessibility gates. Any hash drift makes the approval stale.

Approval and derivative boundary

Read identity-continuity.md before requesting approval. Canonical approval requires the real production Full and Reduced masters, complete palette qualification, exact renderer settings, and all 32 size-and-surface proofs. Gate 2 may approve lockups, wordmarks, icons, and publication surfaces derived from that promoted source. It cannot first reveal, reconstruct, or modify the production master.

What verify asserts

CheckFails when
svg-no-live-textany shipped SVG contains a <text> element or a font dependency
glyph-geometrya newly constructed mark violates absolute M/L/C/Z or measured geometry rules; imported and legacy constructed paths retain their provenance-specific warning boundary
svg-viewboxany path geometry falls outside its own viewBox
logo-filled-pathsa wordmark ships as strokes rather than filled outlines
ico-entriesthe ICO carries fewer entries than declared
raster-dimensionsan exported PNG is not the size its filename claims
reduced-mark-presentsmall favicon entries were made from the full mark
logo-provenancea source binding, passive SVG payload, rendered placement, derivative PNG, or approved raster mask changes
icon-source-mastersa favicon, platform PNG, ICO frame, or ICNS frame differs from its declared Full, Reduced, or monochrome master

Preflight checklist

Review the generated proof and verifier results for these recurring defects:

  • Wordmark shipped as strokes rather than filled outlines
  • Wordmark clipped by its own viewBox
  • Social preview built with live text, so the shipped PNG rendered its tagline in Arial instead of Geist, with subpixel colour fringing baked in
  • Type specimen declaring bare font families with no fallback and no embedded font, rendering in the default serif on any machine without the fonts
  • Brand guide PDF referencing a non-embedded Helvetica and embedding only one Space Grotesk weight
  • ICO carrying one real entry instead of seven
  • Lockups not optically aligned

Use the current source-mode rules and generated measurements rather than an older kit as authority.

Review recognition before revision

When an operator supplies an established mark, record which features people already recognize, which source files are authoritative, and what concrete defect motivates a change. Distinctive-asset research supports asking that question; it does not require a new hue for every sibling brand. The Gate 1 proof and byte-bound source rules above decide whether the exact mark can ship. A designer may propose a new direction, but it is a new owner decision, not an automated cleanup of supplied path data.

On this page