Why architecture decisions should not stay in DMs

A direct message can change a system without changing the team's understanding of it. One engineer asks another team for a new data feed, the request is accepted, and the implementation proceeds. Everyone else later sees a dependency that appears to have no origin.

Direct answer: Use DMs for sensitive or fast coordination, but move any decision that affects shared architecture into a durable team-visible record. Summarize the outcome in the relevant channel, update the current diagram, and link the change to the shared message. Do not expose private details; preserve only the information the affected team needs.

The invisible-dependency problem

Architecture is a shared model of how the system behaves. When a dependency is negotiated privately, the model and reality diverge. The code may be correct, but ownership, operational expectations, and downstream constraints remain unclear.

This becomes expensive during incidents. Responders discover a call or data flow that no one in the channel remembers approving. The two original participants may be unavailable or gone.

DMs also weaken review

A channel gives affected people a chance to challenge assumptions. A DM narrows the review group by default. That is useful for preliminary questions but risky for final decisions involving security, reliability, data contracts, or service ownership.

The rule should not be "never use DMs." It should be "a DM cannot be the final system of record for shared architecture."

A safe promotion workflow

When a private conversation reaches a decision:

1. write a sanitized one-sentence summary;

1. post it in the relevant project or architecture channel;

1. identify affected teams and owners;

1. update the diagram or ADR;

1. request confirmation where the impact is material.

Sensitive information can remain private. The shared record should contain the technical consequence, not the private conversation.

Example: instead of copying a DM about a customer incident, post, "The notification service will now consume redacted risk events from the fraud topic; security review approved the schema in ticket SEC-214." Then update the data-flow diagram.

Make the shared message actionable

A vague post such as "FYI, we changed the flow" does not solve the problem. State what changed, why, and what reviewers should do. Attach the current diagram or make the message trigger a diagram update.

The shared artifact should make the new dependency visible immediately.

Where Arialine fits

Arialine can turn a shared Slack summary into a diagram change and preserve the source message in the decision ledger. That creates a clean boundary: private coordination stays private, while the architecture consequence becomes visible and versioned.

It also avoids copying entire DM histories into public channels.

FAQ

What if the architecture decision contains confidential information?

Publish only the consequence appropriate for the audience. Link to an access-controlled ticket or document for restricted details.

Should the original DM participants approve the summary?

For high-impact or sensitive decisions, yes. A quick confirmation prevents accidental misrepresentation.

Can an app read private DMs to capture decisions automatically?

That raises serious scope, privacy, and trust concerns. Prefer explicit user-driven promotion of selected decisions.