Applications
The brand presents consistently regardless of channel. Every downstream document (Media Book, Game Brand Documentation, Talking-Head Brand Documentation) applies this book’s Foundation, Voice & Tone, Logo & Mark, and Color System exactly as defined here — each adds only the specific application rules its own medium needs.
- Any new channel or product surface starts from this book’s canonical facts, not from a fresh interpretation of the brand.
- Where a medium-specific document needs a rule this book doesn’t yet have an answer for (e.g. exact color hex, typography), it states the same “not yet determined” status — it does not invent an answer locally.
Do not use
Section titled “Do not use”- Do not let a channel-specific document (Media, Game, Talking-Head) introduce a brand fact — a color, a tagline, a voice trait — that doesn’t already exist in this book. If a genuinely new need arises, it belongs in this book first, then gets cited.
Application rules — real status per named format (checked directly, not assumed)
Section titled “Application rules — real status per named format (checked directly, not assumed)”“No rendered mockup exists” and “no rule exists at all” are two different things — several formats below (Social/Avatar, Community/event, and part of Web) already have a real, sourced rule, cited from where it’s actually owned, even though no rendered template/mockup exists yet for any of them. The table below distinguishes RULE (does a real policy already exist, and where) from EXAMPLE (does a rendered/produced asset exist). No rendered example is fabricated to fill a gap, and no format’s real maturity is rounded up.
| Format | Rule | Example exists? |
|---|---|---|
| Web | Mixed, not uniformly CANON: the base rule (mascot silhouette is the sole mark, every favicon variant is a presentation of it) is CANON, inherited from Logo & Mark. The 2 existing live favicon assets are real (digital-surfaces.md §Resolved) but one is flagged legacy/unauthorized/off-canon-color there, not a clean resolution. The broader favicon-form and Open Graph system is RECOMMENDED, digital-surfaces.md’s own real status label — but that document is explicit this isn’t an open owner-approval question awaiting a decision: “Per direct owner instruction, that framing is withdrawn” (quoted verbatim). The gap is one of this book’s own status vocabulary (RECOMMENDED, not yet elevated to CANON), not a pending yes/no. (Source: digital-surfaces.md, this book — cited, not duplicated here.) |
No rendered full-page mockup; the 2 favicon assets themselves are real and live (one CANONICAL, one legacy/unauthorized). |
| Social (Discord/Twitter/Telegram) | CANON — per-platform allowed usage already named: Discord (role names, sticker set, bot avatars, channel icons, event announcements), Twitter/X (profile avatar and header, meme/GIF/reaction posts, announcements, engagement replies), Telegram (sticker pack, reaction GIFs, bot avatar, announcement posts). (Source: Mascot Book — Usage, “By channel” — owned by Mascot Book, cited here, not re-derived or duplicated.) | No rendered social template/banner exists for any platform. |
| Avatar | CANON, partial — Twitter/X profile avatar and Discord/Telegram bot avatars are named real use cases in the same Mascot Book usage list above. | No cropped/sized avatar asset has actually been produced yet — a real production gap, not a documentation one. |
| Community / event | CANON — Media Book already documents this in detail: community-site usage (onboarding, rules/mechanics guides, rank-progress visualization, event announcements) and a confirmed gamification-activity table (Treasure Hunt, Meme Battles, Quests, Trading Contests, Mini-games, Charity Events, each with the mascot’s specific role), plus a seasonal “Treasure Hunter” role. (Source: Media Book — Social, “Community site usage” / “Community gamification activities” — owned by Media Book, cited here, not re-derived or duplicated.) | No rendered event-graphic template exists yet. |
| UI | NOT APPLICABLE to this book — community.solme.me’s own docs-site UI (Starlight framework) uses its own built-in navigation-icon component, unrelated to SOLMAMY brand iconography (see Imagery Principles — Iconography) — owned by the Community Docs surface, not this Brand Book. |
N/A |
| Mobile | NOT YET DETERMINED | No |
| Presentation | NOT YET DETERMINED | No |
| Partner / press | NOT YET DETERMINED for a real partner/press relationship (none exists pre-launch), but one thin, PROPOSED-status piece of related material exists: Mascot Book’s Event-specific costume variants table ties a “Business/formal” variant to “Partnership announcements” and a “Travel” variant to “Partnership/expansion announcements” — both explicitly labeled “proposed, not yet owner-confirmed” in their own source, not a settled rule. (Source: Mascot Book — Costume & Design System, “Event-specific variants.”) | No |
| Campaign | NOT YET DETERMINED — no campaign has been run yet; premature to mock one | No |
| Merch / print | CANON, partial — “Community merch, if produced” is a named real allowed-use case. (Source: Mascot Book — Usage, “Additional allowed usage.”) No merch has actually been produced, and no print-specific rule (materials, sizing, CMYK) exists yet. | No |
| Documents | NOT YET DETERMINED | No |
Producing a rendered example for any format where the rule already exists (Web, Social, Avatar, Community/event, Merch/print) is real visual-asset work, out of scope for a documentation-only pass — recorded here so the gap is explicit rather than silently absent. Formats with no rule yet stay open; none is filled with an invented policy.
What a real application example looks like, once one is produced
Section titled “What a real application example looks like, once one is produced”Not a current SOLMAMY example — a sourced principle for future production, so a real mockup isn’t designed from a blank assumption when the time comes. Discord’s own brand page ends its Logo/Color/Clearspace sections with a real, downloadable banner asset (“for discussing Discord across digital channels”) — an illustrated application of the brand, not a bare logo file. Separately, fewer, load-bearing elements — each carrying a stated use-rule — reads as more professional than a dense page. Together: a future rendered application example should (a) show the brand actually applied in context, not a bare asset dump, and (b) carry its own one-line stated use-rule, the same discipline already applied to the Social/Avatar rules above.
Cross-references
Section titled “Cross-references”- Web favicon/Open Graph rules:
digital-surfaces.md, this book - Per-channel usage rules (Discord/Twitter/Telegram), avatars, merch allowance: Mascot Book — Usage
- Event-specific costume variants (partnership/campaign-adjacent occasions, all PROPOSED): Mascot Book — Costume & Design System
- Community-site and gamification-activity usage: Media Book — Social
- Character-specific presentation: Mascot Book
- Media/video/social/news application: Media Book
- In-game brand application: Game Brand Documentation
- Talking-head/presenter application: Talking-Head Brand Documentation
Part of the SOLMEME Brand Documentation System. Content status (Canonical/Proposed/Open/etc.) is this book’s own axis; ownership/rights are separate — see OWNERSHIP_AUTHORITY.md at the documentation system’s root.