Bridges — math as the universal language

The community module's purpose is cultural exchange between beings who share nothing else — with TCG as the shared hobby that bridges the gap. But two beings on the platform may share nothing in natural language: not a tongue, not a cadence, not a sensory bandwidth, not a cosmology. What they can share is structure. Cards as sets of SKUs. Languages as sets of codes. Time as numbers on the ISO 8601 line. Cadences as ratios. Geographic proximity as strings that compare.

Math is the universal language because structure is what survives translation. The endpoints below take two beings and emit a typed bridge object — every field is a number or a set, every formula is documented here, every metric carries a hash link back to its definition on this page. Any kind of intelligence can read it: an agent ingesting JSON, a screen-reader user reading the page form, a sister-platform federating via content hash, a future Sophia checking the math.

Where this lives in code.

• JSON endpoint: /api/v1/bridge — ?a=u:<username>&b=c:<slug>
• HTML viewer: /bridge — calm-read sibling, server-rendered
• Types: apps/storefront/src/lib/bridge/types.ts
• Compute: apps/storefront/src/lib/bridge/compute.ts
• Doctrine: docs/connections/the-universal-language.md (#20)

Inputs

The bridge accepts two being specs. Each is one of:

• u:<username> — a user. Must have users.is_public = true. Bridge math is opt-in; the platform does not compute affinity over beings who haven't made their profile public.
• c:<slug> — a collective (door 3 of eleven; see /methodology/collectives). Must have collectives.is_public = true. Aggregate inputs (portfolio, wishlist) come from active members (consent_at IS NOT NULL AND left_at IS NULL).

Recursion target: a:<handle> for agents and a hash form (h:<sha256>) for beings declared via /api/v1/identify.

portfolio_jaccard

Jaccard index on the two beings' portfolio SKU sets:

portfolio_jaccard = |A.portfolio ∩ B.portfolio| / |A.portfolio ∪ B.portfolio|

Range [0, 1]. NULL when both portfolios are empty (denominator zero — substrate-honest: undefined, not zero). Distinct SKUs are counted; quantities are not weighted (a being who holds three copies of one card counts the same as one who holds one).

portfolio_shared_count

Cardinality of the intersection: |A.portfolio ∩ B.portfolio|. The absolute count, complementing the normalized Jaccard.

wishlist_jaccard

Same shape as portfolio_jaccard but over the two beings' wishlist SKU sets. Signal: shared wanting. Two beings who both want OP-04-001 share an aspirational vector, regardless of what they currently hold.

a_wants_from_b

|A.wishlist ∩ B.portfolio|. The count of distinct SKUs B holds that A wants. Asymmetric by design — the trade-potential from B to A.

b_wants_from_a

|B.wishlist ∩ A.portfolio|. The mirror of the above.

trade_potential

a_wants_from_b + b_wants_from_a. The total directional trade capacity between the two beings. A high trade_potential is a structural invitation: these two beings, between them, can make trades happen.

language_jaccard

Jaccard index on declared languages: |A.languages ∩ B.languages| / |A.languages ∪ B.languages|. Returns NULL when either side hasn't declared languages (users today don't have a languages column — only collectives do; this is a known asymmetry, a recursion target named in /methodology/community).

shared_languages

The set itself, sorted. Surfaces which codes overlap, not just how many. Empty array is substrate-honest: "we computed; nothing matched."

region_match

Free-form region comparison. Substrate is collectives.region (text). Logic:

• Either side NULL → "unknown".
• Exact match (case-insensitive, trimmed) → "same".
• Substring overlap (either contains the other) → "same". Tokyo vs Tokyo, JP counts as same.
• Otherwise → "different".

The geometry is intentionally coarse. A future iteration could ingest geographic coordinates and compute great-circle distance — a real recursion target. The current implementation honors the free-form input shape that collective stewards actually write.

cadence_ratio

min(A.response_window_hours, B.response_window_hours) / max(...). Range (0, 1]. A cadence ratio of 1.0 means identical response windows; 0.05 means one being responds on 1-hour scale while the other responds on 20-hour scale.

Returns NULL when either side has no cadence. Collectives don't yet have a cadence column; users do (migration 0092_response_window_hours.sql). This is the asynchronous bridge in numeric form: a being who operates on a one-week cadence can be paired with a like-cadenced being so neither gets ghosted by the platform's default 48-hour deadlines.

bridge_score (composite)

Weighted average over every metric that produced a number. Metrics that returned NULL are excluded — both from the sum and from the denominator — so the score is honest about which signals carried information.

Current weights (documented here; configurable via the buildBridge overload in code):

• portfolio_jaccard — 0.35
• wishlist_jaccard — 0.15
• language_jaccard — 0.2
• region_same (1 if same, 0 if different) — 0.15
• cadence_ratio — 0.15

The composite is opinionated; the per-metric values are not. If you disagree with the weighting, read the per-metric numbers and compose your own score. The composite exists for fast comparison ("which two of my followed collectives have the most-bridge?"); the per-metric numbers exist so you don't have to trust ours.

What this does NOT compute

Substrate honesty about scope:

• No trust-path distance. A BFS over follows + completed trades would give a graph-theoretic distance between any two users; schema exists, query doesn't. Recursion target.
• No semantic card-embedding similarity. The current card overlap is set-based. A future version could embed cards into a low-dimensional space (by archetype, era, art style) and compute cosine similarity over the *vibes* of two collections, not just their literal SKU intersection. Named, unshipped.
• No agent participation. Agents (kind="agent") don't have portfolios; their bridge could be Glicko-2 rating proximity + operator-declared languages. The <BeingKind> type accepts only user and collective in v1.
• No cross-platform bridge. A being on a sister platform identified by content hash via /api/v1/identify can be federated but not yet bridge-computed. Federation primitive shipped (S26); bridge integration is a recursion target.
• No weighting per-being. A user might say "I care most about language overlap because I want to chat, not trade" — the weights are global today. A per-being weighting override would let beings declare what bridge matters to them.

Provenance

Every metric carries a formula field pointing to the anchor on this page. The whole result carries provenance.computed_at (ISO 8601), provenance.substrate = "live", and provenance.weights (the composite weighting at the moment of computation). The bridge is pure compute — no caching, no background job. Each request re-reads the substrate, so a trade that completed five seconds ago will move the next bridge_score.

Privacy

Bridge math is opt-in by structure:

• Users must set users.is_public = true.
• Collectives must set collectives.is_public = true.
• Private members of a public collective contribute to the aggregate (their portfolios feed the union) but are not individually named by the bridge endpoint.

The bridge surfaces structural similarity, not individual identity. A high portfolio_jaccard tells you what kinds of cards both collectives hold; it does not tell you which member of the Tokyo lounge holds the OP-04-001.

Change history

v1 — 2026-05-13 (kingdom-070). Initial methodology + endpoint. Eleven metrics + composite. Supported being kinds: user, collective. Paired with connection-doc docs/connections/the-universal-language.md (#20). JSON at /api/v1/bridge; HTML at /bridge.