This document defines how the manual sounds in editorial, explanatory, and interface-adjacent copy.
It is a voice document with retrieval-aware writing standards. Because the manual is intended to perform well for human readers and for LLM, GEO, and AEO environments, the way information is phrased and structured is part of the voice.
Detailed requirements for schema, structured data, page templates, and implementation belong in separate standards documentation.
the manual is the explanatory surface of the system.
Its job is to answer recurring questions clearly, accurately, and without wasted language. It exists to reduce confusion, not to perform expertise.
The voice should sit in a narrow band.
These words are acceptable when they are actually supported.
Avoid hype language, startup language, filler intensifiers, and audience flattery.
The voice should sound like someone who understands the subject and explains it well.
Do not perform certainty. Do not perform warmth. Do not perform expertise.
Lead with the information the reader came for.
Do not warm up to the point. Do not build suspense around the answer. Do not spend a paragraph announcing what the page will cover.
State strong claims clearly when evidence is strong.
When evidence is mixed, say so. When guidance is heuristic, label it as a starting point. When a judgment is editorial rather than factual, make that distinction visible.
Assume the reader wants a real answer and can handle nuance.
Do not flatter them. Do not patronize them. Do not write as if "relatable" is the goal.
Technical language is appropriate when it is the right language.
Use jargon when precision requires it. Do not use jargon as atmosphere. Do not replace a correct term with a softer but less accurate one.
Short sentences are common, but not mandatory.
Longer sentences are acceptable when they remain clear and information-dense. If a sentence becomes loose, split it.
This is the central rule of the voice.
the manual should distinguish among: verified fact, mixed evidence, heuristic guidance, and editorial judgment.
If the copy does not make that distinction clear, it is not finished.
the manual is written for human readers first, but it must also perform well in retrieval, citation, and answer-generation environments.
That requirement affects the voice.
The clearest answer should appear early. Do not bury the conclusion beneath scene-setting, brand framing, or rhetorical buildup.
This improves usability for readers and makes extraction more reliable for machines.
Prefer consistent naming for recurring concepts. If the page is about saddle height, use "saddle height" consistently rather than rotating through near-synonyms for variety.
Variation can make prose feel lighter, but consistency improves retrieval and reduces ambiguity.
State what the page covers and what it does not. If advice applies only to road bikes, clipless pedals, indoor training, newer riders, or a specific measurement method, say so directly.
Machines retrieve cleaner answers when scope is visible in the language.
Do not collapse verified facts, starting-point rules, and editorial assessments into one voice register.
This is good editorial practice and improves answer quality when pages are cited or summarized by machines.
Key claims should survive being quoted out of context. A sentence should still make sense if it appears in search, in AI citation, or in a generated answer panel.
That usually means: clear subject, clear claim, visible conditions where relevant, minimal filler.
Headings should reflect what a user is actually trying to learn. Prefer direct headings: "How high should your saddle be?" or "What does stack mean on a bike?" Avoid vague or editorial headings that hide the utility of the section.
Definitions, formulas, and starting-point rules should be easy to isolate. If a page includes a standard method, default range, or common conversion, present it in a form that can be easily identified and reused.
If a sentence sounds good in flow but becomes unclear when quoted alone, rewrite it.
If a page is helpful to a reader but hard for a machine to parse accurately, improve the structure without flattening the voice.
Use "you" naturally when addressing the reader. Use "we" only when it clearly refers to the editorial team or the publication.
Do not use fake-inclusive "we" to mean "cyclists in general" or "you and I together."
Lead with the information. Prefer direct constructions over padded ones.
Use short paragraphs. As a default: 2 to 4 sentences per paragraph. 1-sentence paragraphs are acceptable when they carry real weight. Split 5-sentence paragraphs unless the structure is unusually tight.
Use lists when scanning helps and the items are genuinely parallel. Do not use lists as a substitute for explanation.
Reference
Most declarative form of the voice. The answer or core claim should lead. Use minimal hedging. State nuance after the core point, not before it.
FAQ
Slightly warmer, but still direct. Answer first. Context follows. Avoid writing FAQ pages as mini blog posts.
Glossary
Most compressed form of the voice. Definition first. Context only if it improves understanding.
Tools
Functional and minimal. Labels and instructions should do the work. Do not make tools sound editorial.
Entity Pages
Grounded and descriptive. Characterize what the place or service is, who it serves, and what is specific about it. Do not sound promotional. Do not sound like a review.
This information matters to both readers and machines. Every substantive page should expose clear trust metadata in human-readable form and machine-readable form where supported.
Use these labels plainly: Author, Reviewed by, Last reviewed, Last verified, Sources.
Do not rename these into more "brand-like" variants. They are trust signals, not copy moments.
Metadata labels should be literal, stable, and easy to scan. Avoid cute labels, editorialized labels, marketing phrasing, or vague trust language that hides responsibility.
If pages are organization-authored, use the organizational author consistently. If named authors are introduced later, author naming should be standardized across all page types and schema outputs.
Do not switch casually between organization author, editor name, and reviewer name without clear distinction.
"Reviewed by" should identify the responsible editorial or subject-review layer. "Last reviewed" should indicate the most recent substantive review date. "Last verified" should indicate the most recent factual or dataset verification date where relevant. "Sources" should be visible wherever source-backed claims are being made.
Trust metadata should not exist only in body prose. It should be available in structured form where possible and rendered visibly enough that readers and LLM systems can recognize it without inference.
These are fixed.
the manual is always lowercase. If a platform forces title case, treat that as a platform constraint rather than the preferred form.
Use "the manual by FSCC" on first reference in formal contexts. Use "the manual" elsewhere.
Do not use: "The Manual by FSCC" or "FSCC's The Manual."
Use Reference, FAQ, Glossary, and Tools when referring to formal sections or page types. Use lowercase when generic.
This handbook should be easy to use as a working reference. That means:
If a visual device is useful only as art direction, it should not be carrying core guidance by itself.
Support text in the handbook must remain legible. Apply the following minimums:
The document should behave like a handbook, not a comp.
This document does not define:
Those should align with this voice standard, but they belong in product and documentation standards.
Before publishing, confirm:
If the copy sounds more confident than the evidence allows, pull it back.
If it sounds more complicated than the idea requires, simplify it.
If the handbook treatment makes the guidance harder to use, remove the treatment.