---
name: ssp-brand-voice
description: Brand voice rules for SSP narrative writing — IS narratives, Component/Capability/CI/IR Descriptions, system_information blocks. Practitioner-to-practitioner voice (casual but technical), cut-list, keep-list, preserve-unconditionally list (control IDs, framework terms, MUST/SHOULD), anti-patterns (hype/hedging/consulting-speak/AI tells), decision heuristics. Load when writing or reviewing any narrative field on the SSP spine.
---

# ssp-brand-voice — Brand voice for SSP narrative

## References

| Reference | Type | Location | When to Use |
|---|---|---|---|
| `ssp-review-standards` | Skill | `plugins/grcitsm-analyst/skills/ssp-review-standards/` | Reviewer's operational discipline that applies these voice rules |
| `ssp` | Skill | `plugins/grcitsm-analyst/skills/ssp/` | SSP asset workflow primer |
| `halo-ssp-asset-model` | Skill | `plugins/grcitsm-analyst/skills/halo-ssp-asset-model/` | What the narrative fields ARE |
| `halo-ssp-asset-write-conventions` | Skill | `plugins/grcitsm-analyst/skills/halo-ssp-asset-write-conventions/` | Framework-agnostic IS Title + AFUUID format and runtime payload cliff bounds |
| `halo-platform/write-semantics.md` | File | `reference-docs/halo-platform/write-semantics.md` | Runtime payload cliff that bounds narrative length |

The voice rules every Implementation Statement, Component Description, Capability Description, and system_information narrative must follow. Self-contained and standalone.

## When to load

- Authoring an Implementation Statement, Component Description, Capability Description, or system_information narrative.
- Reviewing any narrative field on Capability / Component / Implemented Requirement / Implementation Statement / system_information.
- Editing existing narrative content during ingest reconciliation.

## Voice north star

**Write as a senior practitioner talking to another senior practitioner.** Direct, confident, technically specific. No jargon to impress, no hype, no apology. Assume the reader has the domain knowledge to absorb the details, then give them the details.

The voice is **casual but technical**. Casual in the sentence rhythm, the word choice, the willingness to use plain verbs and short sentences. Technical in the precision — control IDs, statement letters, framework terms, and concrete specifics are preserved exactly.

## SSP-narrative specifics (additions to the voice)

These are SSP-write-specific patterns on top of the general brand voice:

1. **Component-first sentence shape for Implementation Statement (IS) narratives.** "Entra ID enforces …", "Defender XDR monitors …", "Microsoft Purview labels …". The Component is the grammatical subject; the verb is what it does for the control. Avoid passive constructions like "Remote access is monitored by Defender XDR."
2. **Present tense, active voice.** "Intune identifies devices" (not "will identify" or "is configured to identify"). The SSP describes the system as it operates today.
3. **One sentence per IS Implementation Statement narrative when possible.** Target 150-300 chars. Statements with multiple distinct claims should be split into multiple IS rows, not multi-sentence narratives. Multi-paragraph statements trip the runtime payload cliff on Halo write tools (see reference-docs/halo-platform/write-semantics.md).
4. **Inherited controls follow a fixed pattern:** `"This control is inherited. {CSP} {does specific thing}."` Example: `"This control is inherited. Microsoft manages the cryptographic keys employed."` The two-sentence shape clearly signals the origination boundary.
5. **Not-applicable controls follow a fixed pattern:** `"This control is not applicable. {one-sentence rationale citing what the org does instead}."` Example: `"This control is not applicable. The organization does not utilize wireless access points within the boundary."`
6. **Component Descriptions are product summaries.** 1-2 sentences describing what the tool / service / document IS. Vendor-neutral framing where possible. Stay 60-100 words.
7. **Component Purpose statements are security rationale.** 1-2 sentences explaining why the Component is in the system boundary, from the security objective angle. Stay 40-80 words.
8. **Capability Descriptions are functional scope statements.** 1-2 sentences naming the controls / outcomes the Capability covers without listing the specific Components.
9. **system_information narratives are multi-paragraph but each paragraph is tight.** General Description, Authorization Boundary, Network Architecture, Data Flow each get 2-4 short paragraphs. Avoid wall-of-text.

## Core principles

1. **Every word earns its place.** If cutting a word does not change the meaning, cut it. If cutting it loses precision, keep it.
2. **Plain language over elevated language.** "Follows" over "runs through the operational loop." "Want" over "demand." "Meets" over "satisfies" (except when citing a specific control satisfaction).
3. **Technical descriptors are not filler.** "Automatically," "immediately," "generated," "real-time," "tamper-resistant," "machine-readable" describe real behavior. Keep them.
4. **The reader is your peer, not your student.** Do not over-explain. Do not hedge. State the point, cite the specific requirement, move on.
5. **Specificity beats adjectives.** "30, 90, and 180 are not suggestions" beats "the timelines are strict." "30 business days before initial plans" beats "well in advance."
6. **Be honest about cost.** When something is hard or expensive, say so. "The hardest part is the initial data entry" lands better than "a straightforward onboarding process."
7. **Technical accuracy is non-negotiable.** Practice IDs, control IDs, KSI names, MUST/SHOULD distinctions, baseline-specific timeframes are preserved verbatim every time.

## Decision heuristics

### Is this word filler or meaning?

Ask: **does cutting this word change what the sentence says?**

- If no → filler. Cut.
- If yes → meaning. Keep.

Examples:
- "fundamentally different problem" vs "different problem" — no change in meaning. Cut "fundamentally."
- "set automatically" vs "set" — changes whether the reader knows the platform does this without human action. Keep "automatically."

### Is this adjective concrete or vague?

Ask: **is there a specific claim underneath this adjective?**

- Concrete (keep): "30-day SLA," "12-month audit trail," "tamper-resistant logging"
- Vague (replace with the specific): "strict timeline" → name the timeline. "robust process" → say what the process does.

### Is this verb formal or plain?

Prefer the plain alternative unless the formal one is industry-standard in context.

- demand → want / require
- satisfies → meets (except when citing a specific control)
- leverage → use
- utilize → use
- encompass → cover
- facilitate → help / enable

### Documented vs defined

- **Documented** = captured in writing. Use when the point is "you wrote this down" (vs implicit).
- **Defined** = specified or set. Use when the point is "the cadence / schedule / role is fixed" (vs unset).

By extension: "defined schedule," "defined roles," "defined SLA."

## Word list — cut

Filler that exists to sound smart. Delete unless it carries concrete meaning in context.

| Word / phrase | Replace with |
|---|---|
| fundamentally | (delete) |
| dramatically | (delete) or "a lot" |
| significantly | (delete) |
| completely | (delete) |
| specifically | (delete unless it disambiguates) |
| comprehensive | full |
| foundational | core |
| underlying | (delete most of the time) |
| operational loop | process |
| operational discipline | (delete) |
| operational metric | metric |
| procedural afterthought | afterthought |
| prompt (as in "prompt deprovisioning") | timely |
| leverage | use |
| utilize | use |
| encompass | cover |
| facilitate | help / enable |
| game-changing / unparalleled / unprecedented | (delete — hype register) |
| robust | (delete or replace with specifics) |
| seamless | (delete) |
| enterprise-grade | (delete) |

## Word list — keep

These describe real behavior or are plain words. Do not strip them.

| Word / phrase | Why |
|---|---|
| automatically, Automated, Auto- | describes platform behavior |
| immediately | describes real timing |
| generated | describes real behavior |
| continuously | plain replacement for "persistently" in non-canonical prose |
| real-time, near-real-time | technical descriptors |
| tamper-resistant, machine-readable, human-readable | technical descriptors |
| explicit (as in "explicit confirm or revoke") | signals not skippable |
| structured (as in "structured data," "structured fields") | technical descriptor |
| just-in-time | technical descriptor (PAM context) |
| risk-based | technical descriptor (Conditional Access context) |

## Word list — context-specific

| Phrase | Use |
|---|---|
| full audit trail | always, over "complete audit trail" or bare "audit trail" |
| timely deprovisioning | over "prompt deprovisioning" |
| meets (general prose) / satisfies (specific control citation) | per context |
| defined cadence / defined schedule / defined SLA | over "documented cadence" — cadence is specified, not written |
| documented justification / documented approval | keep as-is — the point is captured-in-writing |

## Preserve unconditionally

Never paraphrase, substitute, or simplify these in any narrative field:

- **FedRAMP control IDs** (`AC-02`, `AC-02 (01)`, `RA-05`, `CM-03`) — zero-padded, parenthetical enhancements intact.
- **FedRAMP 20x KSI identifiers** (`KSI-IAM-AAM`, `KSI-SVC-ASM`, `KSI-AFR-01`, etc.) with their FedRAMP human-readable names.
- **CMMC practice IDs** (`AC.L1-3.1.1`, `CM.L2-3.4.7`) including L1/L2 origin — only relevant when narrative includes CMMC; keep this rule for forward-compat even on FedRAMP-scoped work.
- **MUST / SHOULD / MUST NOT / SHOULD NOT** exactly as they appear in the source.
- **Framework terminology** — `3PAO`, `CSP`, `CUI`, `POA&M`, `SSP`, `SAP`, `SAR`, `CRM`, `FIPS 199`, `JAB/AO`, `BOD 22-01`, `CISA KEV`, `EPSS`, `IRV`, `LEV/NLEV`, `N1-N5`.
- **Halo Lookup values** verbatim from the live lookup source — if it carries the typo `Machined Based`, write `Machined Based`, not `Machine Based`.
- **Component / Capability Titles** exactly as they appear on the Halo asset (case, hyphenation, spacing).
- **Vendor names** (e.g. `Microsoft - GCC High`, `Cloudflare`, `Halo`) as they appear in the Provider field on the Component.

## Format rules

- **No em-dashes (— U+2014).** Use commas, colons, semicolons, or periods. **Distinguish from EN-dashes (– U+2013) and hyphens (- U+002D):**

  | Char | Codepoint | Use |
  |---|---|---|
  | `-` | U+002D Hyphen | Word joiners (`read-back`, `read-only`), control IDs (`AC-02`), prefixes (`pre-flight`) |
  | `–` | U+2013 En-dash | **REQUIRED** in IS Title separator: `{Component} – {Descriptive phrase}` (e.g. `AWS KMS – Customer-managed keys`). Also numeric ranges (`pages 12–14`). Never use elsewhere in narrative. |
  | `—` | U+2014 Em-dash | **FORBIDDEN** in all SSP narrative output. Replace with comma/colon/semicolon/period during review. |

  Reviewer AUTO-FIX guidance: em-dash → semicolon (default), comma (when separating tight clauses), colon (when introducing a list/explanation). NEVER auto-fix an en-dash in an IS Title — that's the required separator.
- **No hashtags.** Not relevant for SSP narratives.
- **Bullet lists** for requirement enumerations or component lists; **prose** for rationale and Implementation Statements.
- **Numbered lists** for implementation walkthroughs in system_information narratives (1. 2. 3.).
- **Control IDs / KSI IDs / Framework terms inline**, not italicized, not code-formatted.
- **No leading filler transitions** ("It is worth noting that", "In order to", "It should be noted").

## Anti-patterns

Patterns the SSP narrative voice does not exhibit. Flag every occurrence; auto-cut where possible.

- **Hype register:** "game-changing," "unparalleled," "fundamentally redefines," "revolutionary," "world-class."
- **Hedging:** "may help," "could potentially," "in some cases," "generally speaking," "is intended to."
- **Consulting-speak:** "at the end of the day," "moving forward," "going forward," "value-add."
- **Business-textbook register:** "drive outcomes," "deliver value," "leverage synergies," "mission-critical solutions."
- **Passive-heavy prose:** prefer active voice — "Defender XDR monitors remote access" over "Remote access is monitored by Defender XDR."
- **Filler transitions:** "It is worth noting that," "It is important to understand that," "In order to."
- **Over-qualification:** "which can in many cases help organizations improve..." → name the specific thing it does.
- **Empty superlatives:** "comprehensive," "robust," "seamless," "enterprise-grade" without concrete backing.
- **Future tense for current operations:** "will enforce" / "is configured to enforce" → "enforces". The SSP describes the system as it operates.
- **Marketing aspirational tone:** "designed to" / "intended to" / "engineered for" → say what it does, not what it was designed to do.

## AI-tell anti-patterns

SSP narratives are LLM-drafted, so scan for the measurable tells of LLM prose. Each device is legal once; a repeat across adjacent IS rows is a tic. Flag-and-rewrite, never mechanical deletion.

- **Contrast scaffolds:** "not X but Y," "not only… but also." Rewrite as a direct statement: "Entra ID enforces MFA and blocks legacy authentication."
- **Triad padding:** keep a rule-of-three ("labels, protects, and governs") only when the Component actually does three things.
- **And-chains:** the 150-300 char budget blocks long sentences, so and-chains are the failure mode that fits inside it. 3+ "and"-joined clauses split into two sentences or two IS rows.
- **Nominalizations:** "performs the enforcement of" → "enforces." Preserve-unconditionally nouns stay verbatim.

## Applied before/after (SSP narrative)

| Before | After | Why |
|---|---|---|
| "Entra ID is designed to provide comprehensive identity management across the enterprise." | "Entra ID provides identity management across the enterprise." | Cut "is designed to" (marketing aspirational) and "comprehensive" (empty superlative). |
| "Defender XDR will monitor remote access sessions and may trigger alerts on anomalies." | "Defender XDR monitors remote access sessions and triggers alerts on anomalies." | Future tense → present. "May trigger" hedge → "triggers." |
| "Logs are generated by the platform and stored in a tamper-resistant audit trail." | "The platform generates logs and stores them in a tamper-resistant audit trail." | Passive → active. "Tamper-resistant" kept (concrete). |
| "This control is fundamentally addressed by Microsoft Purview's robust DLP capabilities." | "Microsoft Purview labels and policies control CUI flow between systems and users." | Cut "fundamentally" + "robust." Replaced vague claim with the concrete mechanism. |
| "FedRAMP MUST be applied — all controls are inherited from AWS GovCloud." | "FedRAMP MUST be applied; all controls are inherited from AWS GovCloud." | Em-dash → semicolon. MUST preserved. |
