Personal Identity Consolidation — Multi-Property Hub Architecture

Multiple digital properties exist in isolation by default. Each independently signals the operator's identity without connecting to the others — fragmenting the entity graph and the visitor experience simultaneously. The decision: designate one domain as the hub, redesign it as a navigational surface for all properties, and implement canonical Person schema anchored to the hub domain. Do this now, on current infrastructure, without waiting for a cleaner stack.

The default instinct when beginning identity consolidation is to wait for a modern stack. This is the trap. Signal Before Elegance is the governing principle that breaks it: a correct Person schema on a Jekyll static site is identical in machine-readable value to the same schema on Next.js. The signal is in the HTML output; the framework that generates it is invisible to the entity graph. Ship the correct signal on whatever infrastructure exists today. Do not gate on stack. Do not gate on migration plans.

Schema.org Person with @id uniquely identifies the operator across all machine-readable contexts. Without a canonical @id, each property's Person schema is a disconnected assertion — 'Ben Chan' without specifying which Ben Chan. With a canonical @id, all properties point to the same entity and the graph consolidates. The sameAs array extends this by explicitly listing all equivalent URLs. Full coverage across all properties is required; partial coverage produces partial consolidation.

The canonical @id URI must resolve to a domain. The hub domain is the correct choice for three reasons: the hub's explicit purpose is to represent the whole, the hub has no competing product identity of its own, and concentrating the canonical signal on the hub strengthens the hub's authority as an entity anchor. Spoke domains have their own brand identities (the method, the podcast, the registry) that compete with a personal @id placement. The hub is neutral.

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.

The sameAs array must be identical across all properties that carry the Person schema. A fractured array — some with five URLs, some with six, some omitting the hub — is a fractured signal. The array is a contract: when any property is added or renamed, the array is updated on every property simultaneously. Every property includes itself in its own sameAs array. Consistency is binary — either the arrays match or they don't. In this case: six URLs, identical on all four properties.

Each property in a multi-property personal site needs one explicitly assigned role. Without assignment, properties accumulate content in all directions — role bleed. The hub's role is special: navigation and cohesion, with no original content. A hub that publishes its own content competes with its spokes. The explicit role assignments in this case: hub (benchantech.com, cohesion), framework authority (yymethod.com), applied reasoning (home.yymethod.com), origin and narrative (yyand.me).

Scar ADR. An early proposal to migrate the hub to Next.js before implementing the identity signal was reversed after a single question: does the migration change signal quality? No. Jekyll generates static HTML that carries Person schema identically to Next.js. The migration was driven by aesthetic preference for a modern stack, not a functional requirement. Reversed, deferred. The hub stays on Jekyll for the identity consolidation work. Migration is a separate future decision to be made on functional grounds.

The hub landing page accomplishes three things: welcome the visitor, show the full map of properties, identify the operator. Architecture: brief structural intro → card grid (domain, title, role, one-sentence description) → about section folded in at the bottom. Cards are the primary navigation element. The intro is evergreen — structural, not editorial. The about section is short enough to live on the landing page, eliminating the need for a separate /about page and a navigation link to reach it.

A nav rail implies sections worth navigating. The hub has none — it is one page. Nav rail on a one-page site is organizational noise that implies complexity that doesn't exist. The decision: wordmark only, no nav rail. Subline below the wordmark carries descriptive context in one line (title, key affiliations as clickable links) without navigation overhead. The hub's call to action is to leave for a spoke, not to navigate within the hub. Footer handles links and attribution.