The approved architecture diagram is in the ticket, attached as a PNG. Six months later, a teammate asks whether customers can keep an export download link for seven days instead of one. The picture says "Download link: 24 hours." It does not say whether that limit was a casual default, a security decision, or a promise made to another team.

This is a fictional handoff, but the missing information is concrete. The drawing survived. The reason for the 24-hour limit did not travel with it.

What the image gets right

Imagine a customer data export flow. The browser asks Export API to start a job. Export API puts a request on a queue and records a job ID. A worker reads the request, builds a file, and places it in object storage. The browser polls Export API for status; when the job completes, Export API supplies a download link. In the approved diagram, a note beside that last arrow reads "24 hours."

The PNG is useful precisely because it is fixed. A reviewer can attach it to a decision record, put it in a slide, or compare it with a later version without wondering whether someone moved a box after approval. It gives everyone the same visible snapshot. If the question is "What did we show in that review?", the export may be the best artifact to open.

But the new request asks a different question. Does "24 hours" describe the link's validity, the file's retention in storage, or both? Does the worker delete the file, or does storage enforce expiry? If a link expires, can the customer request a new one without rebuilding the export? The PNG may show a box labeled "object storage" and an arrow labeled "download," yet it cannot answer those questions unless someone recorded them on or alongside the diagram.

Lycana proposes "the dead pixel trap" as a metaphor for this gap. It is not a research term or a measured industry problem. Pixels preserve the appearance of an explanation. They do not, by themselves, preserve the elements and decisions needed to revise that explanation.

The handoff needs more than a source file

Suppose the original author finds the editable diagram. They can change the link label, add a separate file-deletion path, and export a new image without painting over the old one. An editable source also lets them inspect what the author drew separately from the pixels in the approval attachment.

It still cannot tell the team why the limit was set. In this example, the review might have chosen 24 hours to reduce the time a forwarded link remained useful. Or the team might simply have copied a default from an earlier feature. Those histories lead to different seven-day decisions. The author may also have labeled a planned policy that the service never implemented. Keeping the source file does not turn an old drawing into evidence of the running system.

The team therefore needs a short decision record next to the source. For this handoff, it could say that the signed download link expires after 24 hours, while the file is deleted after a separate retention period; name who accepted those limits; and link the security or product requirement that motivated them. If the choice was provisional, the record should say what was left to verify. The next engineer can then propose a seven-day link with the actual constraint in view. They still need to inspect current code, configuration, and operating behavior before claiming what production does.

The Software Engineering Institute's Views and Beyond collection describes architecture documentation as relevant views plus information that applies across them, including the reasons for design decisions. That guidance supports keeping rationale with a diagram; it does not claim that saving a particular file format makes a design understandable or current.

Which version did everyone approve?

Now imagine the team finds three editable files, each titled "Export flow," and the ticket still holds only the PNG. Even with a decision note, they need to know which source produced the approved image. That is a provenance problem: where the artifact came from, when it was made, and which decision it belongs to.

A practical handoff can keep the approved PNG, its editable source, and the decision record under the same change or review ID. Record the date and owner, identify the source revision that produced the export, and link the approval discussion. If the diagram covers only the download path, say so; otherwise a later reader may treat omitted authentication, audit, or cleanup paths as deliberate absences. These details do not need a heavy documentation system. A few reliable links can spare the next engineer from guessing which of several plausible files was reviewed.

This package has a cost. Someone must keep the links intact and update the record when a decision changes. For a disposable sketch used in one conversation, that effort may be wasteful. For a diagram that will travel across teams or support later approvals, a PNG alone shifts the work onto whoever inherits it. They may have to reconstruct an editable version, recover the decision, and establish whether the picture still matches the system.

For the seven-day request, the next useful move is to locate the approved snapshot and its source, read the reason for the 24-hour limit, and check the deployed behavior. If the team is revising the flow in Lycana, they can speak or type the change to the diagram while keeping the approval record in a separate review document. The editable drawing still cannot supply the missing reason for the old limit. Those checks give the team a basis for deciding whether to extend the link, allow renewal, or keep the original limit and explain why.