IQ Bible — Brand Guidelines

Mission & tagline

Two lines doing two different jobs. Keep them distinct — both are bookends (a hero, a section head, a closing line, a footer), not a refrain repeated in every paragraph.

Tagline

"Raise your Bible IQ."

The compact, memorable line. Lives in the footer and in the wordmark-plus-motto lockup — email signatures, social profile art, splash contexts. It is the brand's voice mark, not its mission statement.

Mission line

"Build the tools. Reach the world. Spread the Gospel."

The purpose statement. Pairs with the footer sign-off "Built for the Great Commission." Used to frame a page or close one — not sprinkled through the body copy in between.

Mission-aware, never preachy. Between the bookends, every surface reads like it was written by someone who respects the reader's time — short sentences, concrete specifics, no filler. The mission gives the work its why; it doesn't turn product copy into a sermon.

Brand architecture

IQ Bible is the parent brand. It grew out of the original IQ Bible API, which has served a loyal developer base for years; today the name covers a small family of products. Every one of them carries the same mark, wordmark construction, color palette, and typeface — what changes per product is the name lockup and the positioning.

Surface	Name / lockup	Where	What it is
Company / ministry	IQ Bible	`iqbible.com`	General company and ministry marketing. Separate owner and CMS (WordPress); its copy isn't governed by this guide yet, but its visual identity should match what's here.
Developer platform	IQ Bible API	`api.iqbible.com` · `developer.iqbible.com` · `/docs`	The Bible-knowledge API product. Positioned as "Bible Knowledge Infrastructure" — see Products.
Bible study app	IQ Bible	`app.iqbible.com`	The showcase reader — a standalone, open-source Bible study app built on the API. Branded "IQ Bible", not "IQ Bible API": it uses the API, it isn't the API.
Audio delivery	—	`media.iqbible.com`	Signed audio-narration infrastructure. No user-facing brand surface.

The visual system in this guide is shared across all of them. When a new surface appears — a landing page, a deck, a partner integration — it inherits the mark, palette, and type here, and picks the name lockup that matches which product it belongs to.

Naming

The master brand and the study app are "IQ Bible." The developer product is "IQ Bible API" on its own surfaces (its landing page, docs, and portal), where spelling out "API" is what keeps it from blurring into the broader brand.
On the API's own surfaces, first mention is "IQ Bible API v2"; later mentions may shorten to "IQ Bible API," "the API," or "v2."
Never "IQBible" (no space) in prose — that spelling is a code/package identifier only.
In severely space-constrained UI (a collapsed sidebar), "IQ Bible" alone is acceptable even on API surfaces; "Bible" alone is never acceptable.

iqbible.com / www.iqbible.com and api.iqbible.com are deliberately separate surfaces with separate owners — one is company/ministry marketing, the other is the developer-facing API product. Don't merge their copy or cross-link them as if they were one site; do keep their visual identity consistent.

Logo & mark

The mark is a rounded, petal/hemisphere form with a white starburst — a "raise your Bible IQ" glyph, not a book or a cross. In HTML the wordmark is live styled text, not an image: "IQ" in --brand purple, the rest in --ink, weight 900, letter-spacing:-.02em.

Icon / mark

Nav mark, browser tab, avatars, footers — any small square context. Master: logos/icon_1029x1029.png. Shared by every product unchanged.

Master wordmark — "IQ Bible"

logos/wordmark_1270x423.png. The brand and the app. Use where the name needs to be a raster/vector graphic rather than styled HTML.

Wordmark + motto

logos/wordmark_and_motto_1190x409.png — with "Raise your Bible IQ" attached. Email signatures, social profile art, splash contexts.

Wordmark in HTML

Two forms, same construction — "IQ" purple, the rest in ink, weight 900, tight tracking:

Brand & app

IQ Bible

<b class="iq">IQ</b> Bible

API product surfaces

IQBible API

<span class="wordmark"><span style="color:var(--brand)">IQ</span><span>Bible API</span></span>

✓ Do

Use live styled text for the wordmark in every HTML context.
Color only "IQ" in --brand; keep the rest in ink.
Pick the lockup that matches the product the surface belongs to.
Make the header/sidebar wordmark a home link.
Re-export from the logos/ masters when a raster/vector file is needed.

✕ Don't

Recolor the mark outside the palette below.
Stretch it off its source aspect ratio, or reconstruct it by hand.
Put "IQ Bible API" on the app or the ministry site, or "IQ Bible" alone on an API landing page.
Place the mark on a background that fails contrast against #6d28d9 or #1a1330.

Known gaps: (1) there is no SVG of the mark — the logos/ PNGs are the only masters; commission one before any use needing infinite scale or single-color print. (2) The two wordmark PNGs disagree on letter-spacing ("IQ Bible" spaced vs. "IQBible" tight). The live HTML wordmark is the tiebreaker: tight, "IQ" purple. Re-export both from one lockup when the SVG is made.

Color

CSS custom properties, identical across every live surface today. Light-mode only — nothing is theme-aware yet.

Core tokens

--bg

#f7f6fc

Page canvas

--ink

#1a1330

Primary text; also the dark surface color (code panels, footers-on-dark)

--brand

#6d28d9

Primary purple — CTAs, links, active nav, icon strokes, "IQ" in the wordmark

--brand-2

#9333ea

Secondary purple — gradients on avatars/hero backgrounds, lighter accents

hover

brand hover

#5b21b6

Hover / pressed state for primary buttons and brand links

--brand-soft

rgba(109,40,217,.09–.10)

Tinted backgrounds behind icons/badges — never at full opacity

--line

#eae7f2

Borders, dividers, card outlines

--muted

#6b6480

Secondary text — subheads, captions

--muted2

#a09bb3

Tertiary text — stat labels, placeholder-weight copy

Status & accent — used sparingly, outside the core set

live

#22c55e

Live / active dot — e.g. a header badge's green pulse

window chrome

#28c840 · #febc2e · #ff5f57

Decorative macOS-style "traffic lights" in code panels only. Not brand colors — don't reuse elsewhere.

Known gap: every surface is light-mode only — no @media (prefers-color-scheme: dark) or [data-theme] handling exists. Not a current requirement, just don't assume dark mode works.

Typography

Inter, loaded from Google Fonts (wght@400;500;600;700;800;900) in every surface's <head>. Fallback is sans-serif — if Inter fails, pages use the browser default. Monospace (code samples): ui-monospace,'SF Mono',Menlo,monospace, no web font.

900 · Headlines, wordmark, stat numbers · clamp(32px,4.4vw,50px) · letter-spacing:-.03em

Raise your Bible IQ.

800 · Nav links, card headings, buttons, badges, footer column heads

Everything a Bible application needs

700 · <strong>, emphasis text, prices

Scripture, original languages, commentary, cross-references

600 · Footer links, body emphasis

Read the docs · Explore the app · See full pricing →

400–500 · Base body copy · 13–17px · line-height 1.6–1.85

Scripture in 1,400+ translations, original Hebrew and Greek down to the word, lexicons, commentary, a live cross-reference graph, and audio narration.

Rules

Scale: headlines use clamp(), not fixed breakpoint overrides. Carry that forward rather than hand-rolling new breakpoints.
Letter-spacing is directional: headlines and the wordmark use tight negative tracking (-.02em to -.03em); uppercase micro-labels (kickers, eyebrows) use positive tracking (.08em–.1em). Never apply negative tracking to small-caps labels.
Sentence case for UI copy and most headings. Full capitalization is reserved for the mission-line bookends and genuine proper nouns.

Shape & elevation

Radius

Value	Used for
`999px`	Pills / badges — version badge, "POPULAR" pill, status badges
`20–26px`	Large panels — hero code panel, CTA bands, pricing card
`16–18px`	Cards — feature cards, pricing tiers
`10–13px`	Buttons, inputs, small nav elements

Shadow

Soft and low-contrast for ordinary elevation: rgba(26,19,48,.04–.14).

A brand-tinted glow for emphasis on primary CTAs and dark panels: rgba(109,40,217,.28–.32).

Never a neutral gray shadow on a brand-colored element — the tinted glow is what makes purple elements read as "lifted" rather than just "bordered."

Iconography

Line icons throughout — no filled/solid icon appears anywhere in the product. stroke-width 2.2–2.6, round caps and joins, viewBox 20×20 or 24×24.

Construction: the icon sits inside a 40×40 rounded-square badge (border-radius:12px) filled with --brand-soft, icon stroked in --brand. Keep new icons to this exact construction.

<div class="feature-icon">
  <svg width="20" height="20" viewBox="0 0 24 24" fill="none"
       stroke="currentColor" stroke-width="2.2"
       stroke-linecap="round" stroke-linejoin="round">
    <!-- paths -->
  </svg>
</div>
/* .feature-icon { width:40px; height:40px; border-radius:12px;
   background:rgba(109,40,217,.09); color:#6d28d9; } */

Design as positioning

One place the visual system carries an argument on its own: on the API's marketing surfaces, show the API — not a hypothetical app someone could build.

✓ On-brand (API surfaces)

A terminal-style code panel: a live curl request and its JSON response. "What your code gets back." What a Stripe/Twilio-style developer-infrastructure product shows.

✕ Off-brand (API surfaces)

A Bible-reading UI mockup — a page of verse text, a reader interface — presented as the product. That's the app's story, not the API's.

The reverse is also true: the app's surfaces should show the reading experience, because that is its product. Each surface shows its own thing. And when the API needs a demo endpoint, prefer a knowledge/study call (a Strong's lexicon lookup) over a plain verse lookup — a verse lookup alone underplays what the API is.

Voice

Confident, direct, technically precise, mission-aware without being preachy — consistent across every product.

Read like documentation written by someone who respects the reader's time: short sentences, concrete numbers, no filler adjectives ("amazing," "revolutionary," "game-changing").
The mission line is a bookend, not a refrain — a hero, a closing line, a footer. Everything between is plain and precise.
"Friendly" in a brief means clear and welcoming — not an invitation to exclamation points or forced enthusiasm.

The one framing rule that's product-specific: any copy introducing or summarizing the API must frame it as infrastructure for AI, study, and faith applications — "Bible knowledge infrastructure" — not as "a Bible API" alone. See IQ Bible API. The app and the ministry site don't carry that constraint; they speak to readers and to the church, not to a vendor evaluator.

Tone by channel

Channel	Tone	Model example
API reference docs	Neutral, precise, zero marketing language	`DOCS.md` endpoint blurbs — one factual sentence each
Landing / marketing pages	Confident, benefit-first; mission line reserved for the hero only	`landing.html` hero + feature cards
App UI	Quiet, unobtrusive, reader-first — the text is Scripture, not the chrome	the study app's own labels and empty states
Blog / release notes	Narrative, first-person plural ("we"), real enthusiasm without hype-speak	beta-1 release post — "quietly, on purpose," "same mission, completely new engine"
Social (LinkedIn / X)	Checkmark bullets and light emoji are fine — platform convention. Stop short of exclamation-stacking or hashtag-stuffing.	`notes/marketing/linkedin/linkedin.md`
Error / support copy	Plain, exact, actionable	The API error envelope: stable `code`, human `message`, offending `detail`, a `hint` for the fix

Mechanics

No hard-wrapped Markdown paragraphs. Write each paragraph as one continuous line; let the editor soft-wrap. Applies to blog and landing copy the same as API docs.
Numbers: comma-grouped (1,400+, not 1400+). Use a trailing + whenever the true count is a floor — never round down to a cleaner number that undercounts.
Em dash (—, no hand-added spaces) for asides and connecting clauses — not -- or a spaced hyphen.
Oxford comma: yes. "commentary, cross-references, and Strong's glosses."
Sentence case for UI copy and most headings; full caps only for mission-line bookends and proper nouns.

Terminology

Use	Not	Note
IQ Bible (brand, app)	IQBible	"IQBible" (no space) is a code identifier only, never prose.
IQ Bible API v2 (first mention on API surfaces)	IQ Bible API (as the brand name)	The API is a product of IQ Bible, not the whole brand.
Strong's	Strongs	Capital S, apostrophe-s, always.
cross-reference graph	cross reference graph	Hyphenated, matching `GLOSSARY.md`.
developer portal	Developer Portal (in prose)	Title Case only when it's literally a page title/heading.
USFM codes or full English book names	ad-hoc abbreviations	Match the API's own convention; don't introduce a third style in marketing copy.
AI Context (the shipped endpoint)	semantic search / vector search	Semantic/vector search is proposed, not built. Market AI Context until embeddings actually exist.

Check docs/api/GLOSSARY.md before coining a new term or acronym in marketing copy — if a reader wouldn't already know it, it needs an entry there too.

CTA phrasing

Keep to patterns already live. Don't invent new verb/urgency combinations per page.

Primary (API)

"Get your free API key" / "Get your API key"

Secondary

"Read the docs" / "Open the docs" / "See full pricing →" / "Explore the app"

Never

"Sign up now!", "Limited time," "Don't miss out" — nothing in the copy uses artificial urgency, and the transparent self-serve story works against that register anyway.

What to avoid

Hype-speak and exclamation-stacking. One exclamation point in an entire launch post is the ceiling — don't escalate from there.
Overclaiming shipped vs. planned. Don't publish a capability we can't deliver — same discipline the pricing page enforces on itself ("do not publish an overage rate we can't charge").
Naming competitors without receipts. notes/v2-vs-comps.md is the backing table for any comparative claim. Check a claim against it the way a pricing number gets checked against plans.go.
Blurring the brand and its products. The API isn't "IQ Bible" and IQ Bible isn't "the API." Keep the ministry site and the developer product as the separate surfaces they are.

Product — IQ Bible API

The developer platform. api.iqbible.com · developer.iqbible.com · /docs.

Positioning: Bible Knowledge Infrastructure, not a Bible Text Delivery API. The second framing is a fight the API can't win — API.Bible and YouVersion own translation licensing and consumer reach. The first is a category almost nobody else competes in. Stripe is to payments what IQ Bible API aims to be to Bible technology: infrastructure a serious product is built on.

Positioning statement

IQ Bible API v2 is the developer platform for building intelligent Bible applications. It combines Scripture, original languages, study resources, audio, commentary, and structured Bible knowledge into one modern API — so a team building an AI Bible assistant, a study tool, or a sermon-prep product doesn't have to assemble that infrastructure from a dozen sources first.

Lead with one of two legs

Study / research depth — Strong's, Hebrew/Greek lexicons, morphology, commentary, topics, stories, parables, and a navigable cross-reference graph. Competitors are mostly ❌ or "Limited" across these columns; this is the moat.
AI-readiness — the AI Context endpoint returns Scripture + cross-references + commentary + Strong's glosses in one prompt-ready call, built for RAG and LLM study tools.

Audio and translation breadth are real differentiators, but they support the infrastructure claim rather than carry it.

Audience

Build for first: AI Bible apps / assistants · Bible study app developers · sermon & teaching software · theological research tools · Christian SaaS companies · Christian mobile app developers. Not prioritized: basic verse-lookup hobbyists · large consumer Bible-reading apps (YouVersion's) · translation-licensing-first buyers (API.Bible's). Revenue framing: ~100 companies at $49–$499/mo, not thousands of hobby developers on Free — bias every message toward capability and time saved.

Weaker, and shouldn't pretend otherwise: public-domain translations only. Compete on volume, overage, throughput, and study/AI depth — not translation licensing.

SEO

Competitors rank for "access Bible text." The API owns "build intelligent Bible applications." Pillars in priority order: AI Bible API, Bible study API, Strong's Concordance API, Bible knowledge graph API, Bible chatbot / RAG API, Hebrew Greek Bible API. Use the exact phrase "Bible knowledge infrastructure" in titles, meta descriptions, and hero subheads — it's brand language and a keyword target at once; don't paraphrase it.

Product — IQ Bible (the app)

A real, usable Bible study app at app.iqbible.com — built entirely on the API's own public endpoints, and kept as a standalone open-source project meant to be forked and self-hosted. It exists to prove the API's positioning by being the kind of app a developer could build on it: reading, audio, Strong's, commentary across hundreds of sources, cross-references, maps, illustrations, and the AI Context payload shown literally.

Name: "IQ Bible" — never "IQ Bible API." It uses the API; it isn't the API.
Wordmark: IQ Bible — "IQ" brand-purple, "Bible" plain ink, matching the page title.
Design system: the same one in this guide — Inter, the purple palette, the line-icon construction, the shape scale.
Tone: quiet and reader-first. The interface gets out of the way of the text.
No accounts: user data (bookmarks, highlights, notes, position) is local to the browser. Don't market it as a synced/cloud product.

Surface — iqbible.com

The company and ministry marketing site, on WordPress, with a separate owner. No code or content for it lives in the API repo, and its copy isn't governed by the editorial rules above yet.

What this guide asks of it: keep the visual identity consistent — the mark, the "IQ Bible" wordmark construction, the purple palette, Inter, the shape and icon conventions.
What stays separate: it speaks to the church and to the public about the mission; it is not the developer product page and shouldn't be cross-branded as one.
Open question for whoever owns it: whether its copy should adopt this guide's voice and mechanics. Until that's decided, this guide documents the visual system it should share, not its words.

Sources & ownership

This site consolidates the internal brand kit at IQBible-API-v2-Go/code/notes/marketing/brand/ and the brand decisions recorded alongside the products:

Source	Defines
`brand-strategy.md`	API positioning, audience, competitive stance, SEO
`style-guide.md`	Visual identity — logo, color, type, shape, iconography
`editorial-style-guide.md`	Voice, tone by channel, mechanics, terminology, CTAs
`notes/app.md`	The app's separate "IQ Bible" branding and product decisions
`AI.md → Domains`	How the hosts and surfaces relate; iqbible.com's separate ownership

Implemented in: internal/web/handlers/landing.html, portal.html, docs_public.html + assets/docs.css, status_page.html, admin.html; the standalone iqbible-app repo; iqbible.com (external).

Precedence when sources disagree: running product code → internal brand kit → this site. Fix whatever is stale; don't "correct" the code to match a doc.

Deferred until a concrete need: Brand Launch Plan, Creative Brief Template, Social Media Kit, Sales/Pitch Decks, Stationery Suite, Legal & Rights Document. Build the relevant one when a real need shows up, not speculatively.

Destined for brand.iqbible.com.

One brand, documented once.