info-tech-canon/infospace/assimilation/orwell-logging-diagnostics/source/orwell-logging-diagnostics-candidate.md

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.