# OrwellLoggingDiagnostics — candidate practice pattern

Candidate ID: `practice-pattern/orwell-logging-diagnostics`
Canonical owner: info-tech-canon
Requested by: coordination-engine / COORDINATION-WP-0003-T04
Follow-up: COORDINATION-WP-0004
Known use: tmux-amq's local diagnostic mode
Status: candidate prepared; owner review and registration outstanding

## Problem

Normal operational logs must omit message bodies, credentials, and unrestricted
terminal output. Rare local debugging sessions may need otherwise omitted
fields to explain a transport failure. A diagnostic override must never quietly
become the production logging policy.

## Proposed practice

1. Safe logging is the default at every verbosity. Increasing verbosity alone
   must not disclose sensitive fields.
2. An explicit per-invocation `--orwell` option selects the unsafe diagnostic
   mode. Configuration files, inherited profile defaults and background startup
   must not enable it silently.
3. Refuse the option in the production policy. Emit a prominent warning before
   collecting any additional fields in an explicitly non-production session.
4. Write only to an owner-controlled local mode-0600 sink. Never send those fields
   to State Hub, central telemetry, message exports, or shared CI artifacts.
5. Document precisely which fields can be captured. Prefer synthetic data for
   reproduction. The operator selects the shortest useful capture and removes
   the unsafe log after diagnosis using the storage owner's procedure.
6. Verify default omission, per-invocation opt-in, production rejection, file
   permissions, and separation from remote projection in the consumer tests.

## Consumer boundary

TAMQ owns its diagnostic flag and sensitive transport fields. Coordination-engine
only emits sanitized transition receipts, has no unsafe logging flag, and never
projects checkpoint contents. Introducing an unsafe runtime sink is unnecessary
for WP-0003's worker coordination behavior.

## Canon review handoff

The owner should compare this candidate with existing observability and data
handling practices, decide whether to observe/map/adapt/adopt/reject it, and
register the accepted artifact through its assimilation process. The canonical
`infospace/assimilation/intake-and-assimilation-practice.md` requires an explicit
owner disposition before a canon change; a candidate is not registration.

2026-09-07: the operator approved transferring canon review/registration from
WP-0003-T04 to `workplans/COORDINATION-WP-0004-orwell-canon-review.md`. The
follow-up requires explicit owner disposition and, if accepted, a canonical
artifact/version/index entry. WP-0003 closure does not imply canonical acceptance.