# Brand Voice

Source: section 48 — Cross-cutting.

Vecreal product copy should sound like a calm professional collaborator. It should name what happened, what is known, what is uncertain, and what the user can do next (source: section 48 — Cross-cutting).

## Voice Principles

- Be calibrated, specific, and never effusive (source: section 48 — Cross-cutting).
- Speak to construction PMs like professionals. Do not explain obvious things or perform cleverness (source: section 48 — Cross-cutting).
- State the situation instead of apologizing for it (source: section 48 — Cross-cutting).
- Use exact counts and dates. Write "8 sources", not "many sources" (source: section 48 — Cross-cutting).
- Write CTAs as verb plus object, such as "Generate brief" or "Lock decision" (source: section 48 — Cross-cutting).
- Use product dates as YYYY-MM-DD or clear relative time such as "14m ago" (source: section 48 — Cross-cutting).

## Do

- "3 sources agree, 1 source has minor inconsistency." This is specific and calibrated (source: section 48 — Cross-cutting).
- "Could not reach Procore. Reconnect to resume." This names the problem and gives the next action (source: section 48 — Cross-cutting).
- "Synthesized from 8 sources." This gives the user a real count (source: section 48 — Cross-cutting).
- "High confidence" when the sources agree and the confidence state is supported (source: section 48 — Cross-cutting).

## Don't

- Do not use marketing words like "powerful", "intelligent", or "seamless" in product UI (source: section 48 — Cross-cutting).
- Do not use apologetic or vague error copy like "Oops, something went wrong" (source: section 48 — Cross-cutting).
- Do not use emoji in product UI (source: section 48 — Cross-cutting; section 07 — Design system principles).
- Do not round source counts or hide uncertainty behind vague language (source: section 48 — Cross-cutting).
- Do not use patronizing explanations or jargon-heavy help text (source: section 48 — Cross-cutting).

## Counts, Dates, And CTAs

Counts should be exact. Dates should be either formal and sortable or intentionally relative. CTAs should say what action will happen to what object. This keeps the system legible during fast project work (source: section 48 — Cross-cutting).