*Gap samples / Gap 12 - Documentation standards*

# EULER documentation style guide (first draft)

Short on purpose: the rules that prevent the inconsistencies found across the help center, each with the instance that prompted it. A style guide earns its keep by being checked against, so every rule here can be tested on a page in under a minute.

**Gap:** 12 of 13 · **Reader:** Anyone who writes help center, API or in-app text · **Status:** Draft for product and engineering review

## Why this page needs to exist

The job post asks for a style guide. The help center shows why: the same product name, partner tool and acronym are spelled differently from page to page. Each one is small. Together they make search miss pages and make the help center read as if no one owns it.

## 1. Names

| Write | Not | Where it appears today |
| --- | --- | --- |
| **EULER** **[CONFIRM]** | Euler | eulerhq.com, the help center header, the API and MCP references use EULER. Many articles and the Change Log use Euler. The nav lists both "Euler Pay Partner Guide" and "EULER Pay Fees Explained". |
| **HubSpot** | Hubspot | "Configure Hubspot for Partners" and "Hubspot Charges" sit beside "HubSpot Data Scopes in Euler". |
| **Pipedrive** | PipeDrive | eulerhq.com/integrations and the Reward page. |
| **DealFlow AI** | Deal Flow AI | The eulerhq.com footer. |
| **PAM AI**, **POPS AI**, then PAM, POPS | Pam, Pops | Consistent today. Keep it that way. |
| **Market Development Fund (MDF)** **[CONFIRM]** | Marketing Development Fund | Forms 2.0 and eulerhq.com say Market. The MCP reference says Marketing. |

## 2. Titles

- **Task pages:** verb plus object. "Approve a fund request", not "Fund Requests".
- **Concept and reference pages:** a noun. "Referral statuses".
- **Sentence case** for titles and headings.
- **No separators in titles.** The MCP articles end in " l MCP", a lowercase L used as a divider, which screen readers read as the letter. Put the audience in the collection name instead: "MCP for customers".

## 3. The first screen of every page

- One sentence on what the reader will have when they finish.
- Who the page is for, and what they need first.
- What can go wrong, before the steps, not after.

## 4. Procedures

- One action per step, starting with a verb.
- Every step ends with a **Check:** line saying what the reader should see.
- UI labels in bold, exactly as the product shows them. If a label is wrong in the product, report it rather than correcting it in the docs. Example: Forms 2.0 quotes a tab called "Basic Informations".
- **Shall** for what the procedure depends on. **Should** for a recommendation. Never swap them for variety. The convention comes from [RFC 2119](https://www.rfc-editor.org/rfc/rfc2119).
- One labelled wrong example per page, with why it fails.

## 5. Page furniture

- The "Still Have Questions?" block appears once, added by the template. It appears twice on Forms 2.0 and on the Slack Apps Product Guide.
- Internal links use the current URL pattern (`/en/c/...`). Some articles still link to `/en/articles/<number>-...` addresses. **[CHECK THEY REDIRECT]**
- Nav labels match page titles: the nav says "Release notes", the page says "Change Log". Pick one.
- Every page shows an updated date. Release notes carry the date of the change, not of the edit.

## 6. Examples and data

- Fictional companies only, on `.example` domains, which [RFC 2606](https://www.rfc-editor.org/rfc/rfc2606) reserves for documentation.
- No real API keys, tokens or passwords, even fake-looking ones that match a real format.
- Numbers in examples say they are examples.

## 7. Accuracy

- A behavior is written only once someone has seen it, in the product or in a source. Otherwise it is a question for engineering.
- Questions to engineering are statements answered yes, no, or correct me. No open-ended meetings.
- When a feature changes, the pages that describe it change in the same release as the feature.

## Check a page against this guide

- Names match the table in section 1.
- Title is a verb plus object, or a noun, in sentence case, with no separator.
- First screen says result, reader and what can go wrong.
- Every step ends with a Check.
- One wrong example. Fictional data only.
- Updated date shown, and every link resolves.

## Confirm with product

1. The product name is written EULER in all documentation. Yes / no.
2. MDF stands for Market Development Fund. Yes / no / correct me.
3. "Release notes" and "Change Log" are the same page, and should share one name: [name]. Correct me.

### Related documentation

- [Google developer documentation style guide](https://developers.google.com/style)
- [Microsoft Writing Style Guide](https://learn.microsoft.com/en-us/style-guide/welcome/)
- [RFC 2119](https://www.rfc-editor.org/rfc/rfc2119) (the source of shall and should as requirement words)
- [RFC 2606](https://www.rfc-editor.org/rfc/rfc2606) (why examples use .example domains)

### Next

- Start: [All 13 gaps](01-overview.md). Back to the full list of gaps.
- Gap 13: [Docs update runbook](14-runbook.md). Where these checks run when a feature ships.

---

*Independent writing sample by Bachtiar Widyantoro (bachwidy.site), November 2026. Not published or endorsed by EULER. Free to reuse and edit. Customer names in examples are fictional. Anything marked [VALIDATE ...] or [CONFIRM ...] is not settled by a public source and needs checking before publishing.*