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

A Sibling, Not a Monolith

~11 min · system-context, ownership, siblings, boundaries

Level 0Raw Ore
0 XP0/36 lessons0/12 achievements
0/100 XP to next level100 XP to go0% complete
Every interesting constraint on this app comes from something that already exists next to it.

The system context table earns its place

Architecture docs in this family carry a table with four columns: the sibling or external service, the relationship, the data exchanged, and — the column people skip and shouldn't — failure behavior. Writing the failure column forces a decision that is otherwise deferred until three in the morning: when this dependency is down, does the product degrade, or stop?

For Touchstone the answers are unusually varied, and each one is a design statement.

  • The Pippa brain — the assistant identity, docked as a required sidekick surface. If it is unreachable, the engine keeps serving its read surfaces. The dashboard does not need the assistant to be a dashboard.
  • The portfolio app — read-only holdings for ownership badges. Failure behavior: the dashboard renders without badges; never blocks. The badge is an enrichment, and enrichments must not be able to take down the thing they enrich.
  • The shared kit — the delegation queue kernel, vendored in as generated copies. Failure behavior is unusual and instructive: a drift check fails the test suite. The kernel is code, not runtime data, so its failure mode belongs in CI rather than at runtime.
  • The market data providers — one paid REST provider for US data, one library for Korean and Japanese quotes, and a public macro-series source. Failure behavior: an honest error status, a staleness chip, or a last-known snapshot with its date. Never a fabricated value, never a silent swap to a different provider.
Write the failure column first. The relationship and the data are usually obvious; the failure behavior is where the design actually lives. "Renders without badges, never blocks" and "honest 5xx, no silent fallback" are two sentences that settle a dozen future arguments about error handling before anyone has to have them at 3am.

Canonical ownership, stated once

Beside the context table sits a second one that answers a sharper question: for each piece of data, who owns it, and what is this product allowed to do with it? Product identity and release version are owned by a shared manifest and only projected here. Assistant identity, conversations and memory are owned by the brain — client boundary only, never duplicated. Holdings are owned by the portfolio app — read-only badge queries, never a stored copy. Valuation snapshots, market gauges, the delegation queue and its reports are owned by this repository, and the engine is their only writer.

That last clause is the one that quietly makes a lot of things possible later: one writer. It is why a cache can be keyed on a write counter instead of a timer, why snapshots can be append-only without a coordination protocol, and why there is exactly one place to look when a number is wrong.

The family shape. None of these apps is large. Each one is small because the pieces it would otherwise have grown are already owned by a sibling — and each of those boundaries is written down as a table row rather than remembered as folklore. A small app with four named dependencies is much easier to reason about than a large app with none.

Code

The failure column, which is where the design actually is·text
DEPENDENCY        FAILS ->  WHAT THE PRODUCT DOES
---------------   ------------------------------------------------
assistant brain   engine keeps serving read surfaces
portfolio app     dashboard renders WITHOUT badges; never blocks
queue kernel      drift check fails the TEST SUITE (not runtime)
US data provider  RuntimeError -> honest 5xx; no silent fallback
quote library     stale chip on the dashboard; never fabricate
macro series      show last snapshot + its staleness

# Two rules visible in every row:
#   1. an enrichment may never block the thing it enriches
#   2. an unavailable source produces an HONEST state,
#      never a plausible number

External links

Exercise

Draw the system context table for a service you know, and fill in the failure column for every row — including the ones you have never seen fail. Then check the code: does the failure column describe what the code actually does? The gap between the two is your real backlog, and it is usually largest for the dependency that has never once been down.
Hint
For each dependency, ask whether it is load-bearing or an enrichment. Enrichments that can block are the most common bug in this table, and they are invisible until the enrichment has its first bad day.

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.