Skip to content
C.W.K.
Stream
Lesson 05 of 05 · published

Decide Which Side Pays

~12 min · cost, boundaries, asymmetry, design-rules

Level 0Cold Workshop
0 XP0/35 lessons0/12 achievements
0/100 XP to next level100 XP to go0% complete

The Rule Underneath All of It

Everything in this track — the prohibition, the typed pointer, the missing return path — is one rule applied to a repository boundary: cost is absorbed downstream. The side that owns a capability pays for all of it, so the side that calls stays ignorant and cheap.

Cost here is not runtime. It is everything that accumulates around a capability: the knowledge required to work on it, the dependencies it drags in, the tools it needs installed, the failure modes somebody has to understand, the documentation it demands, the tests it justifies. All of that lands on one side, permanently, on purpose.

Why Splitting It Is the Failure Mode

The instinct in most teams is to share cost, because sharing sounds fair and cooperative. Applied to a boundary it is corrosive. A boundary where both sides pay a little means both sides must understand a little, which means both sides must be updated when the domain changes, which means the boundary is not a boundary — it is a seam that requires coordinated deployment, which is the thing boundaries exist to prevent.

Asymmetry is what makes the boundary load-bearing. When one side pays everything, the other side's ignorance is a guarantee rather than a temporary state. You can rewrite the paid-for side completely and the free side does not care, because it never knew enough to be broken by the change.

Reading the Rule From the Line Count

There is a cheap diagnostic for whether the rule is holding. Look at how much code lives on the calling side and ask whether it has grown. Here it is under a hundred lines and it is expected to stay there forever — not because a hundred is a magic number, but because there is nothing for it to legitimately grow into. Any growth would be video knowledge arriving where it does not belong, so the line count works as an alarm.

That is worth stealing as a technique. Pick the side of a boundary that should stay ignorant, write down roughly how big it is today, and treat unexplained growth there as a design event rather than normal progress. Boundaries almost never fail loudly; they fail as a slow accumulation on the side that was supposed to stay small.

An unfair boundary is a working boundary. Fairness is a property of how you treat people, not of how you allocate architectural cost. When you draw a line, name the side that pays — and then be strict about it, because the version where everybody contributes a little is the version that requires everybody to be consulted.

Code

The ledger, made explicit·text
capability: turning material into a finished video

absorbed by the workshop (forever):
  video vocabulary          scenes, beats, plates, segments, timing
  media tooling             encoders, font stacks, image libraries
  provider integrations     speech synthesis, image generation
  failure modes             glitched takes, desync, cache staleness
  measurement               durations, loudness, stream layout
  the format doctrine       what an episode IS

paid by the caller:
  one button
  one optional line of text
  one endpoint that emits {pipeline, pointer, why}

# The asymmetry is not an accident of who wrote what.
# It is the mechanism that keeps the left column replaceable.

External links

Exercise

Pick a boundary between two components you maintain and write the ledger explicitly: two columns, listing what each side must understand about the other's domain. If both columns have real entries, the boundary is currently split. Choose which side should absorb everything, then identify the single largest item on the wrong side and write down what it would take to move it.
Hint
Look for shared model or type definitions imported by both sides. A shared type is the most common way cost gets split without anyone deciding to split it — it looks like eliminating duplication, and what it actually does is make both sides depend on the same evolving vocabulary.

Progress

Progress is local-only — sign in to sync across devices.
Spotted a bug or have feedback on this page?Report an Issue

Comments 0

🔔 Reply notifications (sign in)
Sign inPlease sign in to comment.

No comments yet — be the first.