Boundaries Are Features

"A boundary is complete when ownership and failure behavior are both named."

Separate need from ownership

A product boundary is often described as what an app lacks. In a family system, it is also what keeps change cheap: one brain owner, one voice owner, one chrome owner, and one writing orchestrator.

Shape the crossing

Write an ownership map with request direction, data authority, retry responsibility, and failure behavior. Inkwell owns entry and job state; siblings own their capabilities; references cross boundaries instead of duplicated canonical data.

The duplication temptation

Vague sharing produces orphan failures: each side assumes the other retries, stores, or deletes. Over-owning duplicates systems. Under-owning leaves no one accountable. The boundary must name both the handoff and the return path.

Family invariant. A boundary is complete when ownership and failure behavior are both named.

Let requests and references cross

Audit “Boundaries Are Features” beyond code imports. Trace which request reaches which owner, whether the result is a value or managed reference, and who explains failure and retry. Credentials, canonical history, or a voice catalog copied into Inkwell are a second system, not a convenient integration.

Write the boundary table

Create an ownership table for every Inkwell dependency, including who retries and who exposes failure. Include timeout, stale output, sibling unavailability, and schema mismatch. Any blank where both sides assume the other will act is the owner of the next incident.

Owning less makes the product more itself

Inkwell's identity is not another brain or voice engine. It composes original-first flow, penless review, handwriting UX, and late-result landing into one experience. Boundaries are features that make that composition possible.

Code

A compact ownership map·json

{
  "inkwell": ["entries", "job ledger", "landing guards", "writing UX"],
  "cwkPippa": ["brain routing", "souls", "conversations"],
  "bellows": ["speech synthesis", "voice catalog", "audio artifact creation"],
  "siblingKit": ["family chrome", "shared presentation primitives"],
  "crossing_rule": "typed request out; provenance-bearing reference back"
}

Separate need from ownership

Shape the crossing

The duplication temptation

Let requests and references cross

Write the boundary table

Owning less makes the product more itself

Code

External links

Exercise

Progress

Comments 0