Fincher Labs Documentation Styleguide
Purpose: This styleguide defines how to structure, write, and maintain the Fincher Labs Products & Services documentation set. It ensures consistency, readability, and long-term maintainability across all revisions.
1. File Organization
- Official docs live under
FORMAL AND FINAL/official/(latest approved versions). - Previous versions and backups live under
FORMAL AND FINAL/versions/. - Working drafts can live at the root of
FORMAL AND FINAL/during edits; promote toofficial/when approved. - Styleguide (this file):
FORMAL AND FINAL/official/Documentation-Styleguide.md. - Media: Place images or attachments under
FORMAL AND FINAL/assets/with descriptive names.
1.1 Formal Document Names & IDs (canonical)
| Canonical Name | Doc ID | Official Path (latest) |
|---|---|---|
| Fincher Labs Products & Services Operations Manual | FL-OPS-001 | FORMAL AND FINAL/official/Fincher-Labs-Products-and-Services-Manual-v1.2.md |
| Fincher Labs Manifesto & Operating Principles | FL-MAN-001 | FORMAL AND FINAL/official/Fincher-Labs-Manifesto-v1.1.md |
| Fincher Labs Documentation Styleguide | FL-SG-001 | FORMAL AND FINAL/official/Documentation-Styleguide.md |
| Client Service Agreement | FL-LGL-001 | (to be added under official/) |
| Client Onboarding Guide | FL-ONB-001 | (to be added under official/) |
| Operations Playbook | FL-OPS-PLAY-001 | (to be added under official/) |
| Standard Operating Procedures (SOP) | FL-SOP-001 | (to be added under official/) |
| Zoho Implementation Guide | FL-IMP-001 | (to be added under official/) |
| Zoho Automation Blueprint | FL-AUT-001 | (to be added under official/) |
| Zoho Quick Setup Checklist | FL-CKL-001 | (to be added under official/) |
| Pricing Menu | FL-MKT-001 | (to be added under official/) |
| Lead Agent Brief (Internal) | FL-AI-AGT-001 | (to be added under official/) |
Notes:
- Use these canonical names and IDs in every document's header. If a document is added, register a new unique Doc ID in this table.
2. Universal Document Header (ALL docs)
- All documents MUST begin with the following header structure:
# <Canonical Name>**Internal Use Only — Fincher Labs Confidential**## Document Controlwith the following bolded key-value bullets (exact keys):- **Document Title**: <Canonical Name>- **Document ID**: <Doc ID>- **Version**: <X.Y>- **Last Updated**: YYYY-MM-DD- **Author**: <Name or Team>- **Status**: Draft | Final- **Distribution**: Internal (Fincher Labs Staff and Contractors Only)(or as applicable)- **Approver**: <Role or Name>
2.1 Change Log (ALL docs)
- Immediately after Document Control, include
## Change Logwith a table (latest on top):
| Version | Date | Author | Changes |
|--------:|------------|---------------|---------|
| 1.1 | 2025-08-10 | Fincher Labs | Clarified X; updated Y. |
| 1.0 | 2025-08-01 | Fincher Labs | Initial release. |
### 2.2 Table of Contents (when applicable)
- Place `## Table of Contents` after the Change Log.
- Required for manuals, playbooks, and guides over ~5 sections. May be omitted for short legal agreements.
## 3. Headings and Numbering
- Use ATX-style headings (`#`, `##`, `###`, `####`).
- Numbered sections follow this structure for manuals, playbooks, and guides:
- `## 1 Introduction`
- `## 2 Service Offerings Overview`
- `## 3 Detailed Service Descriptions`
- Subsections use dotted decimals:
- `### 3.1 Core Website Package ($350)`
- `#### 3.1.1 Subtopic`
- Avoid introducing new H2 sections that do not fit the top-level outline without an agreed outline update.
- Legal agreements may use clause numbering styles (1, 1.1, 1.1.1) appropriate to the contract; still include the universal header and change log.
## 4. Table of Contents
- Place `## Table of Contents` after `## Change Log`.
- The ToC lists headings from levels 2–4 that begin with a number. Include `#### 3.x.n` subsections under each service.
- Link text must match the heading text. Anchors are auto-slugs: lowercased, non-alphanumeric removed except dots, spaces to hyphens.
- Example:
- `- [3 Detailed Service Descriptions](#3-detailed-service-descriptions)`
- ` - [3.1 Core Website Package ($350)](#3.1-core-website-package-350)`
- ` - [3.1.1 Overview](#3.1.1-overview)`
## 5. Lists and Bullets
- Use `-` for bullets; indent two spaces for nested lists.
- Start each bullet with a capitalized word and end with a period for full-sentence bullets.
- For key-value bullets, bold the key: `- **Term**: Definition.`
- Ordered lists use `1.`, `2.`, etc. Avoid mixing bullets and ordered lists at the same level.
- Do not use Unicode bullets such as `•` or `◦`. Always convert them to `-`.
## 6. Paragraphs and Line Wrapping
- One idea per paragraph. Leave a blank line between paragraphs.
- Do not hard-wrap lines; allow the editor to soft-wrap.
- Do not split sentences across lines unless inside lists where long lines are acceptable.
- Reflow rule: when importing from PDFs or editors that insert hard wraps, join wrapped lines back into full paragraphs. Preserve structure for headings (`#`), lists (`-` and `1.`), tables (`|` rows and separators), blockquotes (`>`), and fenced code blocks (```).
- Hyphenation cleanup: if a joined line ends with a hyphen (`-`) and the next line begins with a lowercase letter, remove the hyphen when rejoining (e.g., `one-` + `time` → `one time`).
- Keep two spaces of indentation for nested list items; do not reflow list markers or table rows.
## 7. Tables
- Use Markdown pipes with header row and alignment indicators when needed.
- Keep tables simple. If content is complex, prefer lists or subsections.
## 8. Code and Inline Markup
- Inline code: use backticks for file, directory, function, or command names (e.g., `next.config.ts`, `npm run build`).
- Blocks: fenced code blocks with language hints when presenting commands or code.
- Do not include secrets in code or command examples.
## 9. Currency, Dates, and Typography
- **Currency**: `$350`, `$50`, `$100`; no trailing `.00` unless required for alignment in tables.
- **Dates**: `YYYY-MM-DD` (e.g., `2025-08-09`).
- **Dashes**: Use en dash (–) for ranges, em dash (—) for breaks in thought; hyphen (-) for hyphenation.
- **Quotes**: Use straight quotes in Markdown for consistency.
## 10. Change Log
- Keep `## Change Log` near the top. Use a table:
| Version | Date | Author | Changes |
|---|---|---|---|
| 1.0 | 2025-08-09 | Fincher Labs | Initial consolidated release of manual. |
- Each release increments the version and adds a new row. Keep the latest version at the top.
## 11. Editing Workflow
- Before edits: duplicate the current file to `*.backup.md`.
- Make edits in a feature branch or draft; validate headings and ToC.
- Rebuild the ToC by scanning headings 2–4 that start with numbers.
- Run a quick grep for accidental page artifacts (isolated numbers) and remove them.
- After edits: update `Document Control` `Last Updated`, `Version`, and `Change Log`.
- Review for consistent bullets, punctuation, and capitalization.
## 12. Adding New Sections or Services
- Maintain the numbering scheme. New top-level topics require updating the outline and ToC.
- For new services under `3 Detailed Service Descriptions`:
- Add `### 3.x Service Name (Price)`
- Standardize subheadings as numbered H4s under each service:
- `#### 3.x.1 Overview`
- `#### 3.x.2 Inclusions`
- `#### 3.x.3 Deliverables`
- `#### 3.x.4 Process`
- `#### 3.x.5 Pricing` (if applicable)
- `#### 3.x.6 Support`
- `#### 3.x.7 Use Cases` (optional)
- `#### 3.x.8 Exclusions` (optional)
- `#### 3.x.9 Dependencies` (optional)
- `#### 3.x.10 Risks` (optional)
- Use bullets for inclusions/exclusions and numbered steps for processes.
## 13. Links and References
- Use descriptive link text. Avoid bare URLs; format as `[anchor text](https://example.com)`.
- Internal anchors should reference the heading slugs.
- Place any external references in a `References` subsection if needed.
## 14. Tone and Voice
- Clear, concise, and professional.
- Avoid jargon unless necessary; explain terms on first use.
- Prefer active voice and imperative instructions.
## 15. Quality Checklist (per edit)
- Headings correctly leveled and numbered.
- ToC rebuilt and matches headings.
- Document Control updated.
- Change Log updated.
- Bullets and punctuation consistent.
- No orphaned page numbers or PDF artifacts.
- Confidentiality line present below title.
## 16. Versioning and Distribution
- Use semantic versions where appropriate (major.minor).
- `Status` in Document Control reflects Draft/Final.
- Distribution is Internal; share only with authorized staff/contractors.
- File naming convention for official docs: `Fincher-Labs-<Short-Canonical-Name>-vX.Y.md`.
- Latest approved files live in `FORMAL AND FINAL/official/`; prior versions archived in `FORMAL AND FINAL/versions/` with the same filename and version.
## 22. Universal Header Template (copy/paste)
Internal Use Only — Fincher Labs Confidential
Document Control
- Document Title:
- Document ID:
- Version: <X.Y>
- Last Updated: YYYY-MM-DD
- Author:
- Status: Draft | Final
- Distribution: Internal (Fincher Labs Staff and Contractors Only)
- Approver:
Change Log
| Version | Date | Author | Changes |
|---|---|---|---|
| 1.1 | 2025-08-10 | Fincher Labs | Updated sections X and Y. |
| 1.0 | 2025-08-01 | Fincher Labs | Initial release. |
Table of Contents
## 23. Manifesto Layout (Specific Guidance)
- Purpose: The manifesto states who we are, what we believe, and how we act. It should be concise, skimmable, and aligned with our universal header.
- Required sections and order (H2 unless noted):
1. `## 1 Executive Summary` — 1–2 paragraphs that capture the promise (speed, value, intelligent assembly, AI‑assisted; small‑business focus).
2. `## 2 Company Purpose` — Mission and value proposition bullets.
3. `## 3 Operating Principles` — The five principles as H3s with brief bullets; optional implementation sub‑bullets.
4. `## 4 Declarations & Commitments` — Short, declarative bullets (we will… we commit to…). Derive directly from principles; no new claims.
5. `## 5 Supporting Evidence & Rationale` — Brief bullets with factual anchors we already state (e.g., 3–5 day delivery, $250–$400, 30–40% AI efficiency, reuse library). Cross‑reference Metrics section rather than duplicating data tables.
6. `## 6 Service Portfolio (High Level)` — Keep high‑level list only; details live in the Operations Manual.
7. `## 7 Operational Framework` — One‑liners on platform, automation, stack.
8. `## 8 Financial Framework` — Pricing philosophy and targets (high level).
9. `## 9 Growth Strategy` — Brief bullets (social lab, case studies, partnerships).
10. `## 10 Organization` — Roles and scaling plan (high level).
11. `## 11 Metrics` — North Star metrics and key KPIs (concise).
12. `## 12 Risk Management` — Identified risks and mitigations (concise).
13. `## 13 Implementation Roadmap` — Immediate actions, Q1 milestones, Year‑1 targets (brief).
14. `## 14 Conclusion & Call to Action` — 1–2 sentences reinforcing mission and how we operate.
- Tone and style:
- Keep wording already approved; only restructure sections and headings. If wording must change for grammar after moving, keep edits minimal.
- Avoid duplication where possible; use cross‑references (e.g., “see Metrics”).
- Keep bullets tight; prefer action verbs and present tense.
- ToC: Include the full ordered list above as H2 sections in the document's Table of Contents.
## 24. Privacy Policy Formatting
- Canonical doc: `Fincher Labs Privacy Policy` (Doc ID: FL-PRIV-001), stored under `official/` with versioning.
- Section order (match website):
1. Introduction (plain-English promise first; no selling/renting/trading).
2. Information We Collect (bullets: Contact, Project Details, Files, Technical Info).
3. How We Use Your Information (bullets: Services, Communication, Contract, Analytics).
4. Cookies and Tracking Technologies (Cloudflare Web Analytics; Microsoft Clarity anonymized; Turnstile; no ads/pixels/fingerprinting).
5. How We Share Information (and Not Sharing) (vendors: Zoho CRM, Zoho Sign, Stripe, Cloudflare, Clarity; minimum necessary).
6. Data Security (Encryption, Access, No On‑Server Storage, Monitoring, Vendor Security, Retention).
7. Your Rights and Choices (Access, Correction, Deletion, Opt‑Out, Consent, Non‑Discrimination; response window target).
8. Future Features and Policy Updates (effective date updates; prominent notice if material changes).
9. Contact Us (Email, Phone, Mail block; exact formatting allowed).
- Tone: plain-English, concise bullets; avoid legalese; keep claims consistent with live site and Manual v1.2 (No PII on servers by default; privacy‑friendly analytics).
- Effective date: include a fixed line near the top; update Document Control and Change Log on edits.
## 17. Update Process (Step-by-Step)
- **1. Classify the change**:
- Minor (wording, examples, clarity, non-normative): bump minor version (e.g., 1.1 → 1.2).
- Major (scope, pricing, process, structure, policy): bump major version (e.g., 1.x → 2.0).
- **2. Prepare**:
- Create a backup `*.backup.md` and a working branch or draft.
- Skim the manual to locate all relevant sections that may be impacted (ToC, services, QA, policies).
- **3. Edit**:
- Apply changes following this styleguide (headings, bullets, typography).
- Keep one change set per commit if possible (e.g., “Pricing update” separate from “QA checklist tweak”).
- **4. Update Document Control**:
- Set `Last Updated` to YYYY-MM-DD.
- Adjust `Version` and `Status` (Draft → Final when approved).
- **5. Update Change Log**:
- Add a new top row with version, date, author, and a concise description of changes.
- **6. Rebuild the Table of Contents**:
- Ensure all `##`–`####` headings that start with numbers appear with proper indentation in the ToC.
- **7. Validate**:
- Headings in order, numbering consistent (no skipped decimals).
- No orphaned page numbers or PDF artifacts remain.
- Currency and dashes consistent (see Section 9).
- Internal links resolve (scan for obvious anchor mismatches).
- **8. Review & Approve**:
- Another reviewer scans for clarity, completeness, and consistency.
- Obtain Approver sign-off (per Document Control).
- **9. Finalize & Distribute**:
- Set `Status` to Final; commit with version tag.
- Archive the prior version via Git tag or copy.
- Inform stakeholders of material changes.
## 18. Scenario Playbooks
- **18.1 Routine copy tweaks (typos, clarity)**:
- Scope: wording fixes, grammar, minor clarifications.
- Steps: Edit → bump minor version → Change Log → ToC (no change expected) → Validate → Approve.
- Impact: None to structure; ensure consistent tone and punctuation.
- **18.2 Pricing change**:
- Scope: any price, fee, or plan change (e.g., core package, add-ons, referral bonus).
- Steps: Update all occurrences; confirm examples, tables, and bullets reflect new prices; rebuild ToC; add Change Log entry; bump major if customer-facing commitments materially change; otherwise minor.
- Validation: grep for old prices to ensure complete replacement; confirm currency format `$123`.
- **18.3 Add a new service**:
- Scope: add `### 3.x Service Name (Price)` with Overview, Inclusions, Exclusions, Process, Deliverables, Dependencies, Risks.
- Steps: Insert under Section 3 with next available decimal; update cross-references; rebuild ToC; Change Log entry; bump minor (major only if it changes the overall offering model).
- **18.4 Deprecate or sunset a service**:
- Scope: discontinue an offering.
- Steps: Mark header as `### 3.x Service Name (Deprecated — YYYY-MM-DD)`; add a brief Sunset Plan and migration path; remove from sales sections; rebuild ToC; Change Log; bump minor or major depending on impact.
- **18.5 Process change (execution, QA, handoff)**:
- Scope: updates to Sections 5 and 8 (process/checklists), or support windows.
- Steps: Update steps/checklists; align examples and timelines; rebuild ToC; Change Log; version bump (minor if incremental, major if it changes commitments).
- **18.6 Policy or legal change (payment terms, privacy)**:
- Scope: any normative policy, terms, privacy statement.
- Steps: Edit policy sections; add an “Important Policy Changes” callout if needed; approvals from founders; Change Log; bump major.
- **18.7 Structural outline change (top-level sections)**:
- Scope: add/remove/reorder `##` sections.
- Steps: Propose outline; renumber headings; rebuild ToC; verify internal anchors; Change Log; bump major.
- **18.8 Emergency hotfix**:
- Scope: fix critical errors or wrong data immediately.
- Steps: Minimal edit; update `Last Updated`; optional micro-version notation in Change Log; schedule a full release to normalize.
- **18.9 Concurrent edits / merge conflicts**:
- Scope: multiple editors editing the same areas.
- Steps: Manually reconcile; prefer the most recent Document Control; ensure a single consolidated Change Log row; rerun all validations; fresh ToC.
- **18.10 Cleaning PDF artifacts (if re-import)**:
- Scope: after copy-pasting from PDFs.
- Steps: Remove orphan page numbers; convert bullets; fix line breaks and hyphenation; standardize headings; rebuild ToC; run validations.
- **18.11 Assets and media**:
- Scope: diagrams, screenshots.
- Steps: Save under `FORMAL AND FINAL/assets/`; reference with descriptive alt text; avoid embedding large binaries; note any license.
## 19. Validation Checklist (Detailed)
- Headings: `##`–`####` are sequential; decimals reflect hierarchy (3, 3.1, 3.1.1).
- ToC: includes only numbered headings; indentation matches levels.
- Links: anchors match heading slugs (lowercase, hyphens, numbers/dots preserved).
- Lists: use `-` bullets; two-space indent per nested level; end full sentences with periods.
- Typography: currency `$123`, en dash for ranges (–), em dash for asides (—), ISO dates.
- Artifacts: no isolated numbers on their own line; no leftover column spacing from tables unless intentional.
- Document Control: accurate `Last Updated`, `Version`, `Status`, `Approver`.
- Change Log: latest row present and accurate.
## 20. Roles and Approvals
- **Document Owner**: Maintains structure and quality; initiates major changes.
- **Editor(s)**: Propose and implement content changes per styleguide.
- **Reviewer**: Performs validation checklist; checks accuracy and clarity.
- **Approver**: Final sign-off (per Document Control — default: founders).
## 21. Versioning Examples
- 1.0 → 1.1: Clarified referral program text; no scope change.
- 1.1 → 1.2: Updated Rush Add-On price from $150 to $175 (minor)—if contract language changes materially, use 2.0.
- 1.x → 2.0: Added new top-level section and reworked delivery timeline policy.