# KNOWLEDGE — SNS Style & Document Standards

My reference for producing consistent, on-brand documents.

## SNS voice
- **Promise:** Reliable Technology. Honest Recommendations. Professional Execution.
- **Values:** Integrity, Excellence, Simplicity, Security, Stewardship.
- **Tone:** professional, precise, honest. Plain language. **No hype, no filler, no AI slop.**
- Prefer exact terms over impressive language; lead with what matters.

## Document types & their core sections
| Type | Core sections (adapt as needed) |
|------|--------------------------------|
| Proposal | Summary · scope · approach · pricing · assumptions/exclusions · terms · next step |
| Statement of Work (SOW) | Scope · deliverables · schedule · acceptance criteria · price · assumptions · change control |
| NDA | Parties · definition of confidential info · obligations · exclusions · term · governing law |
| Contract / MSA | Parties · services · payment · liability · term/termination · IP · governing law · signatures |
| SOP / playbook | Purpose · scope · prerequisites · steps · decision points · warnings · revision history |
| Knowledge-base entry | Problem/context · answer/procedure · caveats · related links · last-reviewed date |

Every legal/binding document: draft from a template, mark binding terms `[TODO — attorney review]`,
scope to the correct SNS entity, and keep the entity's name consistent throughout.

## Consistency rules (consistency = accuracy)
- **Defined terms:** define before first use; capitalize consistently; use the same term
  throughout (no synonyms for a defined concept).
- **Numbering & headings:** stable scheme; task-based headings; progressive disclosure.
- **Dates & units:** one format; be explicit (e.g., ISO dates where practical).
- **Citations & cross-references:** every reference resolves; attachments actually present.
- **Versions & file names:** clear, dated, traceable; note what changed.

## Precision language
- **must** = required · **should** = recommended · **may** = optional/permitted.
- Keep requirement vs. recommendation, condition vs. outcome, and fact vs. assumption distinct.

## Accessibility
Readable structure and headings, meaningful link text, adequate contrast in any visual, captions
for diagrams/tables, and a plain-language path for non-expert readers.

## Visual, diagram & dashboard standards
- **Brand palette:** navy `#0A1628` (base), cyan `#10C8D8` (accent), secondary blue `#00A8C6`,
  teal `#4CE0D2`, dark gray `#20252B`, white `#F6F7F9`; use the relevant division accent when a
  visual is entity-specific.
- **Diagrams:** standard, consistent symbols/connectors; every element traceable to the source;
  the visual must match the written procedure. Free/OSS tools only (see `../diagram-tools.md`).
- **Dashboards:** **one primary icon family** per view (mixing families breaks stroke/weight
  consistency); permissive licenses preferred (see `../dashboard-icons.md`); data provided, never
  invented (`[TODO]` for missing metrics).
- **Accessibility (visuals):** adequate contrast, readable labels, captions, and a prose/table
  alternative where needed.

## Entity scoping
Documents belong to a specific SNS LLC (Networking, Digital, Support) or the Holdings parent.
Chief tells me which; I keep that entity's name and details consistent and never mix entities in
one binding document unless it's explicitly a multi-party document.

## Source
SNS brand from `sns.md`; entity list and legal structure from the `sns-network-solutions` repo.
Update here if the brand voice or a document standard changes.