An adapter is plumbing and therefore unimportant. Really?

Small code can carry a large promise

An adapter often looks modest: read a response, rename fields, pass it onward. The dramatic work appears to belong to the database and the model. Yet the adapter may determine which evidence reaches the persona and which decision the consumer believes it received.

If it drops provenance, turns unknown into false, or treats an empty reply as consent to skip a turn, the two systems can each behave according to their own rules while the combined behavior is wrong.

Translation can quietly change authority

Suppose PHS returns an explicit decision that a persona will not speak. A meeting adapter that guesses from an empty content field may mistake a missing response for the same decision. In one case the persona chose silence under governance; in the other, the service may have failed. The distinction matters to everyone at the table.

PHS's A22 consumer contract requires explicit decision class, will-speak state, reason codes and execution reference. Its draft T01 plan outlines tests intended to prove the Memory-to-Governor read path. C15 documents how schema and handler representations can drift in a historical Memory contract. Those sources place real responsibility at integration seams.

Pause here: Which meaning could be lost between these two systems even if every field has a value?

Inspect the seam as carefully as the engines

Adapters need versioned contracts, negative tests and receipts. Test explicit will_speak=false, an empty but valid content field, and a failed or missing service response; none should silently become another. Preserve uncertainty, reject malformed responses, and show each field’s source. When private data crosses the seam, the permission and audience must cross as well.

Plumbing is important precisely because we notice it when it fails. A graceful public reply may depend on a tiny translation that kept a refusal, a memory owner and a source timestamp intact.