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

One Refusal, Three Overrides

~11 min · inheritance, family, posture, oop

Level 0Raw Ore
0 XP0/36 lessons0/12 achievements
0/100 XP to next level100 XP to go0% complete
Three apps, three domains, one abstract method — and the implementation is a refusal every time.

The same shape in three vocabularies

Read these three sentences in a row and the pattern is unmistakable:

  • The portfolio app observes, never recommends a trade.
  • The health engine observes, never diagnoses.
  • The valuation engine assays value, never advises.

This is inheritance in the sense that matters — not a shared base class in code, since these are separate applications with separate databases, but a genuinely shared abstraction with three domain-specific overrides. The abstract method is something like what does this app do when it knows enough to have an opinion? and all three override it with the same answer, expressed in their own nouns.

Why these three domains and not others

The image generator has no such invariant. The music engine has none. That is not an oversight — it is the pattern telling you where it applies.

All three refusal-apps share two properties. First, the domain has professional gatekeeping for a reason: financial advice and medical diagnosis are regulated acts, and both are regulated because the consequences of confident wrongness fall on someone other than the person who was confident. Second, and more subtly, the data is intimate. These apps hold real family holdings, real health measurements, real watchlists. An app that knows that much about you and also tells you what to do is a different kind of object from an app that generates a picture.

Locate the refusal where confidence is cheapest and error is most expensive. The domains that most need an automated-advice invariant are precisely the domains where automated advice is easiest to generate and most persuasive when wrong. If a system could produce a confident recommendation from its data in ten lines, that is the signal it needs the invariant — not a reason to add the feature.

What each override does with the boundary

The overrides are not identical, and the differences are instructive. The portfolio app's boundary is about initiation — it will answer a direct question with full judgement, but volunteers nothing. The health engine's is about vocabulary — it may surface patterns and raise questions, but may not name a diagnosis, because the naming is itself the regulated act. The valuation engine's is about framing — it may show any number it has, at full precision, with its whole history, so long as the framing is positional rather than directional.

Same abstraction, three different places to draw the line, each one drawn where that domain's harm actually lives. That is what a good override looks like: not a copy of the parent's rule, but the parent's intent re-derived in local terms.

Dad's frame. He reads the world through object orientation — not as a coding paradigm but as how things are actually organized. This is one of the cleanest examples in the whole family: an abstract posture, inherited by three siblings, overridden in each one's own domain vocabulary, with the polymorphism doing real work. Ask the same question of all three apps — "what do you do when you know enough to have an opinion?" — and you get three different sentences that are recognizably the same answer.

Code

One abstract method, three overrides·text
ABSTRACT:
  What does this app do when it knows enough to have an opinion?

OVERRIDE  portfolio app     domain: holdings, cash, returns
  -> observes, never recommends a trade
  line drawn at: INITIATION
     (answers a direct question fully; volunteers nothing)

OVERRIDE  health engine     domain: training, measurements, sleep
  -> observes, never diagnoses
  line drawn at: VOCABULARY
     (may surface patterns and raise questions;
      may not name the condition)

OVERRIDE  valuation engine  domain: multiples, gauges, percentiles
  -> assays value, never advises
  line drawn at: FRAMING
     (any number, full precision, whole history;
      positional framing, never directional)

# The overrides differ because each domain's harm differs.
# A copied rule would have missed all three.

External links

Exercise

Take two tools in your own stack that feel unrelated and try to write one abstract question both of them answer, then write each one's answer as a one-line override. If you cannot find a shared question, they genuinely are unrelated. If you can, check whether their answers are consistent — inconsistent overrides of a real shared abstraction are where surprising bugs and surprising arguments both come from.
Hint
Good abstract questions are about posture and ownership rather than about features: what does this do when it is unsure, when the upstream is down, when it knows something the user has not asked about. Feature-level questions rarely generalize across two tools; posture-level ones almost always do.

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.