One Pipeline, Four Subjects

"Four subjects that look like four apps are really one app wearing four coats."

The Shared Spine

Portrait, pose, hand, and object look like four different tools, but underneath they run the identical four-step pipeline: fit the landmarks, construct the geometry, project it back onto the photo, and emit a numerical readout. Detect, build, draw, measure — every subject follows that exact spine. Recognizing the spine is what stops the engine from fracturing into four unrelated codebases that happen to sit in one repo.

Where They Specialize

Only one step actually differs between subjects: construct. The portrait constructs a rigid Loomis head via solvePnP. The figure constructs articulated volumes — boxes and limb frustums — in pixel space. The hand constructs a palm box and phalanx frustums. The object constructs a human-controlled box that claims no orientation. Same fit before it, same projection and readout after it; the subject-specific knowledge lives entirely in the middle step. One interface, four implementations.

This Is Polymorphism, Concretely

Put plainly, there is an abstract idea — a construction — with four concrete kinds. This is exactly the object-oriented lens Dad sees the world through: not a coding trick, but a way of naming what varies and what stays the same. Add a fifth subject someday — feet, drapery, an animal — and you implement only its build step; the fit, the projection, the overlay, the save path, and the grader are all inherited unchanged. The pipeline is open for new subjects and closed against rewrites, which is why the engine grew from portrait to four tracks without ever tearing up its own spine.

Sessions Carry a Track

The subject isn't a hidden mode toggle — it's a first-class dimension. Every analysis session is tagged as portrait, pose, hand, or object, and older sessions from before the split load as portrait by default. Making the track an explicit property (rather than something inferred or special-cased) is what lets one storage layer, one UI shell, and one grader serve all four subjects without a pile of if-statements. The polymorphism goes all the way down to how a session is stored.

Code

One pipeline shape; the construct step is the only specialization·python

# One pipeline, four specialized constructions. Only `build` differs.
class Construction(Protocol):
    def build(self, landmarks) -> Geometry: ...   # the ONLY subject-specific step

PIPELINE = {
    "portrait": PortraitConstruction(),   # rigid solvePnP -> ball, planes, box
    "pose":     PoseConstruction(),       # articulated -> boxes + limb frustums
    "hand":     HandConstruction(),       # palm box + phalanx frustums
    "object":   ObjectConstruction(),     # human-controlled box, no claimed orient
}

def analyze(photo, track):
    landmarks = detect(photo, track)               # shared: FIT
    geometry  = PIPELINE[track].build(landmarks)   # SPECIALIZED: CONSTRUCT
    return project_and_readout(geometry)           # shared: PROJECT + READOUT

# Add a 5th subject -> implement build(); inherit fit, project, overlay, grade.

Exercise

Find a place in a system you know where three or four things are almost-but-not-quite the same — export formats, notification channels, payment providers, chart types. Separate the shared spine (the steps identical across all of them) from the one or two steps that actually vary. Sketch how you'd refactor it into a single pipeline plus a specialized step, and name what adding a fifth variant would then cost.

Hint

The smell is near-duplicate blocks that differ in the middle. The fix names an interface for the varying step and routes the shared steps through it once. Done well, a fifth variant is 'implement one method,' not 'copy and edit the whole thing' — exactly the difference between Loomis adding a track and rewriting itself.