# Carlo Hennsa | Technical Document Style

Version 1.1 · 13 October 2026

## Purpose

Use this as the default visual reference for technical reports, discovery reviews, proposals, feasibility assessments, stakeholder decision documents and architecture handovers across any project, unless a different client-approved brand is required.

**Reference implementation:** `examples/technical-review.html`.

This is an **independent blue editorial theme**, not an official document and not intended to imply sponsorship or affiliation. Do not add client logos, seals or official letterhead without authorization.

## Brand palette

| Design token | Hex | Typical use |
|---|---|---|
| Navy | `#113A66` | Navigation emphasis, headings, selected states |
| Deep navy | `#082A4D` | Title cover and high-contrast table headers |
| Blue | `#145E97` | Links, section numbers, overlines |
| Bright blue | `#1C79B7` | Highlight accents and navigation state |
| Light sky | `#E6F1F8` | Light-blue emphasis panels |
| Off-white blue | `#F2F7FA` | Subtle section backgrounds |
| White | `#FFFFFF` | Report surface |
| Primary text | `#243647` | Main paragraphs |
| Muted text | `#647687` | Supporting text and metadata |
| Rules and borders | `#DBE5EC` | Tables, separators and controls |
| Gold accent | `#C5A355` | Restrained visual punctuation, no broad gold fills |
| Risk red | `#9F4451` | High-severity callouts and labels |
| Pale risk red | `#FAEFF1` | High-severity label backgrounds |

CSS variables, all responsive layout rules and print styles are included in `Carlo_Document_Theme.css`.

## Layout conventions

1. **A substantial dark-navy title cover**, with a large white title, pale-blue emphasis, a discreet oversized chapter number and a narrow gold/blue accent bar.
2. **Sticky narrow top bar** with a neutral document symbol, type label and a Print / Save PDF control.
3. **Persistent left contents navigation** on desktop, collapsible on mobile; every major section is numbered and has an anchor.
4. **White paper-like main surface**, spacious margins, clear sectional breaks and strong editorial typography. Use Segoe UI / Arial for a self-contained report without additional font requirements.
5. **Compact evidence components**: decision/issue tables, two-column comparison panels, question lists, numbered steps and diagrams only when they add information.
6. **Colour is functional**. Use blue for hierarchy, gold sparingly for focus, and muted red for actionable risk. Avoid decorative colour boxes around conclusions.
7. **Independent, direct tone**: clearly distinguish verified facts, document claims, assumptions and professional assessment. For personally authored correspondence, use **I / my**, not we / our. Keep decision ownership explicit.
8. **Author identity**: in formal technical documents, identify the author as **Carlo Hennsa** (default) or **M.C. Hennsa** (formal or academic-style alternative). Never shorten the author credit, cover byline, document control or signature to just “Carlo”.
9. **A4 print-ready** with page counters, repeated table headers where appropriate, consistent typography and sensible page breaks.

## Author naming and voice

- **Default name:** Carlo Hennsa.
- **Optional formal/academic byline:** M.C. Hennsa.
- Apply this consistently to title pages, author metadata, headers/footers, prepared-by fields, approval/signature blocks, and document properties when supported.
- When writing a personal technical assessment, use first-person singular where necessary (I, my). Do not use “we” or imply a team or employer authored the document unless explicitly instructed.
- The *style name* “Carlo Technical Document Style” is only a shorthand for this design and is not an acceptable replacement for the full author name.

## Recommended content structure

- Cover: document title, project, author, date, version, audience and purpose.
- Executive position: the conclusion and what decision is required.
- Evidence base: which documents, versions and observations support it.
- Findings: a numbered and severity-ranked issue/decision register.
- Detail: one section per functional theme, each with specific questions or actions.
- Delivery or implementation implications: dependencies, constraints, risks and assumptions.
- Recommended actions: owners and concrete next decisions.
- Document control: version history and prepared-by attribution.

No need to force all these sections into short documents. Preserve the hierarchy and style, but match length to substance.

## Reuse in future projects

In a new conversation or project, say:

> Use my Carlo Technical Document Style, based on the attached `Carlo_Document_Style_Guide.md`, with a navy cover, numbered sections, side navigation, compact issue tables, restrained blue and gold colours, and A4 PDF export. Credit the author as **Carlo Hennsa** (or **M.C. Hennsa** when specifically requested), and use **I / my** for personal assessments.

Keep the guide in a central personal document/template repository or attach it to projects that need it. ChatGPT Memory may help recover the preference when available, but the guide and stylesheet are a more dependable, version-controlled reference.

## Production checks

- Use fully self-contained HTML if it must render offline, with CSS and any JavaScript embedded or distributed beside the HTML and no externally loaded images/fonts.
- Check at desktop and mobile widths; hyperlinks, navigation, and print buttons must work.
- Export a matching PDF with A4 pages, backgrounds enabled and page-break rules. Confirm that content is not clipped or split awkwardly.
- Check signature and perspective before distribution: author name “Carlo Hennsa” or “M.C. Hennsa”, no solitary “Carlo” as the author, and no accidental plural first-person voice.
- Revise title, content, dates, document IDs and section labels for each project; do not reuse project-specific details as generic placeholders.