[strategy] Build-to-migrate — thin, standards-conformant, engine-swappable stack (low cost now → smooth path to heavy-class OSS)

[y1o1]

Product strategy record (stack-level). The organizing thesis behind auth.provider / auth.policy-verifier / auth.admin. Read alongside the responsibility-boundary docs (auth.provider #296/#297/#301) and the adapter-surface epic (auth.provider #305).

Thesis: build-to-migrate

• AI collapses build cost. "Which implementation" is commoditized — building any of these is cheap now, so implementation is not the differentiator.
• Migration cost does NOT collapse. It is a function of coupling, contract stability, and data-model portability — all fixed at design time. AI can write a new adapter fast, but it cannot retroactively un-couple a design that leaked the wrong abstraction across callers, tokens, and stores.
• Therefore the decisive axis shifts from "lowest build cost" to "lowest migration cost via correct-from-the-start design."

Positioning

Not buy-heavy (adopting Ory/OPA/OpenFGA on day one is premature and operationally expensive; paid Auth0/Okta is costly), and not build-to-keep (reinventing a permanent system we then have to maintain against stronger incumbents). Instead build-to-migrate:

Run a thin, low-cost implementation now, with every seam cut to the same shape a heavy-class OSS exposes — so the eventual migration is an adapter swap, not a rewrite.

Precondition (non-negotiable): isomorphic, standards-compliant seams

Smooth migration holds only if the seams we design now are isomorphic to the heavy-class targets and standards-compliant. This makes core correctness migration insurance, not polish:

Plane	Heavy-class target	Seam that must stay isomorphic	If it drifts, migration becomes
auth.provider	Ory Hydra / node-oidc-provider	Standard token format (RFC 9068 at+jwt; iss/aud/sub/typ) + JWKS/discovery	a rewrite — hence auth.provider #105, #259, #266 are prerequisites
auth.policy-verifier	OPA / OpenFGA / Cedar	A decision contract carrying (subject, resource, action, context/attributes) + reason, rich enough for PBAC/ReBAC to sit behind	a rewrite — hence auth.policy-verifier #124 and the fail-open #104 are prerequisites
auth.admin	Ory Kratos	Identity/permission write contract shaped so Kratos's model can back it	a rewrite
Stores	managed stores	The typed Store adapter contracts	a rewrite

"Getting the design right" = making these contracts standards-compliant and thick enough for a heavy-class engine to sit behind. Leaving fail-open / non-standard tokens / a too-thin decision API in place yields the worst outcome: paid to build AND unable to migrate cheaply.

Conformance kit = migration proof

The adapter conformance test kit (auth.provider #305) gains a second meaning here: if our thin implementation and the heavy-class target both pass the same conformance suite for a plane, they are behaviorally interchangeable — the migration is proven to be a swap, not a hope.

Design rule

Cut every boundary exactly where the heavy-class cuts it. Never invent a seam a heavy-class engine cannot sit behind.

Failure mode to guard against

"AI writes it fast, ship it" → contract drift away from the standard/heavy-class shape → accidental lock-in to our own bespoke thing = paid twice (build + rewrite). Guards: standards conformance, shared conformance tests, and a boundary review on any change to a seam.

Roadmap priority (implied by this thesis)

1. P0 — migration prerequisites (correctness): auth.policy-verifier #104 (fail-open), #105 (iss/aud/typ), auth.provider #259 (sub binding), #266 (issuer), auth.policy-verifier #124 (decision-contract thickness).
2. P1 — migration tooling: per-plane migration-target mapping + shared conformance kit (auth.provider #305).
3. P2 — differentiation: typed composable adapter surface (auth.provider #302/#303/#304).

---

Strategy distilled from the 2026-08 production-readiness review and the follow-up architecture discussion.