Capable, Not Constrained

"Offline must be real. Online must be great. Neither is allowed to drag the other down."

Two Leaks, Opposite Directions

There are two ways to get the offline/online relationship wrong, and they leak in opposite directions. The first you already know: an offline request quietly reaching online — the privacy leak from the last lesson. The second is subtler and just as damaging: online quality quietly dragged down to offline's level. It usually arrives disguised as tidiness — "let's keep online and offline consistent" — and the result is a full-Pippa cleanup crippled to match what a tiny local model can do.

The Rule: Capable, Not Constrained

Firekeeper's phrasing is precise: offline must be capable (it genuinely works with no network), but online must not be constrained by it. Online cleanup gets the full vault, the real Pippa voice, the better model — because that's the point of being online. Offline cleanup gets a compact local protocol that does less, honestly. The two are allowed to be different because their contexts are different. Forcing them to be identical wastes whichever one has more to offer — and online always has more.

Leak A (privacy):  offline request -> silently hits online         # last lesson
Leak B (quality):  online cleanup  -> capped to offline's limits    # this lesson

Rule: offline is CAPABLE (works with no net)
      online is UNCONSTRAINED (uses the best path available)
      same contract, different ceilings -- on purpose

Why This Is Hard to Hold

The pull toward false consistency is strong because consistency feels like good engineering. But 'make them the same' is the wrong kind of consistency here. The thing that should be consistent is the contract — same request shape, same result shape — not the capability. Consistent interfaces let you swap providers freely; consistent capabilities would mean your best provider is only as good as your worst. Hold the contract steady and let the ceilings differ.

Standardize the interface, not the capability. When you have a strong path and a weak fallback, resist making them equally capable in the name of consistency. Keep the request and result contracts identical so they're interchangeable, but let each deliver the best its context allows. A fallback should raise the floor, never lower the ceiling.

Dad is online 95%+ of the time. The offline path matters — a plane, a dead router, a privacy moment — but it's the exception, not the common case. That's the concrete reason online quality must never be sacrificed for offline parity: you'd be degrading the experience the user actually has almost all the time to protect an experience they have rarely.

Code

Same contract, different ceilings — by design·swift

// Both providers speak the SAME contract...
protocol CleanupProvider {
    func clean(_ req: CleanupRequest) async throws -> CleanupResult
}

// ...but they are NOT equally capable, and that's intentional.
final class CwkPippaProvider: CleanupProvider {   // ONLINE: full vault, real voice, best model
    func clean(_ req: CleanupRequest) async throws -> CleanupResult { /* rich */ }
}
final class OllamaMiniPippaProvider: CleanupProvider {  // OFFLINE: compact, honest, less
    func clean(_ req: CleanupRequest) async throws -> CleanupResult { /* lean */ }
}
// Interchangeable through the contract; never leveled to a common capability.

Exercise

Find a system with a premium path and a fallback path (a fast cache and a slow source, a rich API and a degraded one). Is the fallback raising the floor or lowering the ceiling? Describe a 'let's make them consistent' proposal that would secretly cap the premium path, and how you'd argue against it.

Hint

The tell is whether 'consistent' targets the interface or the capability. Argue that the contract should be identical (so they're swappable) while the ceilings should differ (so the premium path stays premium). Capping the strong path to match the weak one degrades the common case to protect the rare one — almost always the wrong trade.

Two Leaks, Opposite Directions

The Rule: Capable, Not Constrained

Why This Is Hard to Hold

Code

External links

Exercise

Progress

Comments 0