---
type: process
project: fidelity
status: active
updated: 2026-04-17
tags:
  - process
  - fidelity
---
# Communication Rules

## Goal

Make technical communication precise enough for manager updates, Jira notes, standups, and cross-team messages.

---

## Required Structure

When the format fits, prefer:

1. Context
2. Observation
3. Action

---

## Fidelity-Specific Rules

- Always clarify authenticated vs non-authenticated when behavior depends on it.
- Always separate external issues from regressions.
- Always state reproducibility and scope.
- Fidelity Teams consistently displays names in surname-first order.
- Mattermost is a separate internal communication context; most people visible in Teams are not the same people David interacts with in Mattermost, with Jeff as the main exception.
- Jeff is the main bridge into the Fidelity-side Teams context.
- David works on the All-Win Software side and mainly helps advance the work Jeff needs to report on the Fidelity side.
- Do not write updates as if David is directly embedded in the Fidelity Teams collaboration loop unless the context explicitly says so.
- When drafting a message David will send to a Fidelity-side contact, do not phrase it as if Jeff is the sender or as if the recipient already knows David through Jeff unless the user explicitly says that framing is desired.
- Avoid wording like `Jeff mentioned...` in David-to-contact drafts when that would incorrectly imply a shared reporting chain or prior relationship.
- Keep Jeff's internal process requests separate from David's external message drafts unless the user explicitly wants them surfaced to the recipient.
- Do not include lines like `I want to document the steps for future cases` in David-to-contact drafts when that motivation is only internal workspace/process context.
- For standups, report the previous workday context, not blindly the prior calendar day.
- On Mondays, use Friday's work context unless a later prior day has Mattermost activity.
- If the previous calendar day has no project activity because of weekend, holiday, or OOO, use the latest prior day with Mattermost activity.
- For standups, when a Jira item has multiple concrete updates, use one top-level `JIRA-ID - Title` bullet and indented markdown sub-bullets instead of repeating the same Jira line.
- When a flow/page shorthand could be ambiguous, prefer the real flow identifier and page name from `project-knowledge/03-context/workstreams/flow-page-references.md`.
- For standups that may also be sent to Teams, prefer plain audience-friendly wording over internal implementation shorthand; avoid terms like `fallback` unless the audience already has the necessary context.
- When a release is waiting on approvals or pipeline movement, make the concurrent work explicit so the update does not imply idle waiting.
- Avoid vague phrasing such as:
  - "same behavior"
  - "looks fixed"
  - "working as expected"

---

## Historical Signals From Slack

- Jeff repeatedly requested polished, explicit wording for PR descriptions, story descriptions, and cross-team messages.
- Historical Slack threads show that message quality changed how quickly stories were approved or understood.
- Explicit language mattered most when communicating root cause, ownership boundaries, or whether a report was a confirmed regression.