← Case Studies/Case #006/C6-005
C6-005DecidedIdentityDerived2026-04-05

Identity Decoupled from Infrastructure

The @id URI is a logical address — it identifies a person, not a stack. The hub domain may migrate from Jekyll to Next.js, from GitHub Pages to Vercel, without changing the @id URI. Identity decoupled from infrastructure means the consolidation work is durable. It does not expire on migration. The stack migration can proceed on its own timeline, for its own reasons, without any identity-related urgency or sequencing dependency.

Freshness
Permanent

Permanent. The principle that identity outlasts infrastructure is a durable architectural constraint.

Dependencies
← C6-002: Signal Before Elegance — Ship Canonical Signals on Current Infrastructure← C6-003: Canonical Person Entity — One @id Across All Properties← C6-004: @id URI Belongs to the Hub Domain
#identity-durability#infrastructure-independence#migration-proof#logical-address#permanent-principle

Capture

The @id URI is a logical address. It identifies a person, not a technology stack. The domain it resolves to may change its underlying technology — from Jekyll to Next.js, from GitHub Pages to Vercel, from one CMS to another — without requiring the @id URI to change.

This is the architectural property that makes the consolidation work durable. The identity signal does not expire when the stack migrates. The schema does not need to be rebuilt. The canonical URI persists.

Why

Coupling identity to infrastructure creates a fragile architecture. If the canonical @id were expressed as an infrastructure-specific URL pattern — a path created by a CMS, a URL shaped by a routing convention, a subdirectory generated by a build system — then a migration that changes the infrastructure pattern could silently break the identity signal. The @id would stop resolving, and the entity graph would fragment.

Domain-based @id URIs resist this failure mode by design. The domain is the only requirement. As long as the domain resolves, the @id is valid. The document at that URL can change structure, framework, or content without affecting the identity signal.

This also means the decision to migrate the hub stack is fully independent of the identity signal work. The stack can migrate on its own timeline, for its own reasons, without any identity-related urgency. The identity signal does not accumulate debt against migration.

Why-Not

Why not delay the @id until after migration? This is the failure mode this ADR exists to prevent. An @id implemented after migration is identical in quality to one implemented before migration — but it accrues no compounding benefit during the delay. The migration does not improve the @id; it only defers it. See C6-002.

Why not use a URL pattern tied to the current CMS or routing convention? Infrastructure-specific URL patterns create coupling between the identity signal and the build system. A future migration that changes the routing convention would require either preserving the old URL pattern (technical debt) or updating the @id (entity graph disruption). Domain-based @id URIs eliminate this trade-off.

Why not implement both — a current-stack @id and a plan to update it after migration? Two @id values for the same entity is not a plan — it is fragmentation. The entity graph consolidation depends on a single, stable @id. Planning to change it introduces an unnecessary disruption. Design for durability on the first implementation.

Commit

Decision: The @id URI is domain-based and infrastructure-agnostic. Stack migrations change the delivery layer, not the identity signal. No migration creates a reason to change the @id.

Confidence: High. This is an architectural principle that eliminates an entire class of future rework.

Timestamp

2026-04-05

← C6-004C6-006 →