Trust Is a Dependency. Design It Out.

In software, a dependency is something your system needs from outside itself in order to run. Experienced engineers treat every dependency as a question: what happens when this thing isn't there?

Now look at the standard co-parenting arrangement. "We'll figure out summer as it gets closer" depends on future goodwill. "Just let me know about expenses" depends on judgment matching. "We'll be flexible" depends on both people feeling generous on the same day. Every one of these is an arrangement with trust as a dependency — and trust is precisely the resource a separated family has the least of, at exactly the moments it needs the most of.

An arrangement that requires trust to function is an arrangement designed to fail on schedule: it works in the easy weeks and collapses in the hard ones, which is to say it works exactly when you don't need it and fails exactly when you do.

Here is the reframe, and it comes from an unexpectedly relevant industry. I spent my career building software for freight rail — a world where valuable cargo moves reliably, every day, between parties who do not particularly like or trust each other. Railroads interchange cars with competitors. Shippers hand irreplaceable goods to carriers they will never meet. None of it runs on trust. It runs on rules written down in advance: who is responsible at which point, what happens when something is late, what the default is when a message goes unanswered. The system was designed so that trust, while pleasant, is not load-bearing.

Children deserve at least the reliability we routinely engineer for freight.

Designing trust out does not mean assuming the worst about the other parent. It means building arrangements that produce the same result in both worlds — the one where they come through and the one where they don't. Watch the difference:

• Trust-dependent: "He'll get the gear back to us when he can." Trust-free: "Gear that travels is listed; anything on the list returns at the next exchange; anything missing is flagged in writing within 24 hours."
• Trust-dependent: "She'll answer when she sees it." Trust-free: "Responses within 48 hours; no response means the existing schedule stands."
• Trust-dependent: "We'll be reasonable about costs." Trust-free: "Shared expenses require notice in the app before commitment; receipts by month-end; reimbursement by the 5th."

Notice that in every pair, the trust-free version is also kinder to the trustworthy. If the other parent is reliable, the rule costs nothing — it simply confirms what would have happened anyway. If they are not, the rule catches what trust would have dropped. You lose nothing in the good case and you are protected in the bad one. Engineers have a name for this shape: it is just good design.

And something worth knowing, observed in family after family: trust sometimes returns under these systems — precisely because it stopped being required. When no exchange depends on faith, every completed exchange quietly deposits a little evidence. Rules do not replace trust forever. They carry the load while it is gone, the way a cast carries a broken leg. You do not throw away the cast because you hope the bone knits.

Audit your arrangement for the sentence "that shouldn't be a problem, as long as—". Everything after "as long as" is a dependency. Design it out.

---

Chapter 3 of Conflict Surfaces makes the full argument, and the rest of the book is the engineering: rules, defaults, and processes that run on paper instead of faith.