Prometheus + Matrix

Why this exists

Where we are today. The LINX backend works — but it is static. Trust scoring runs on fixed, hand-chosen numbers. The recommender matches on similarity alone. Nothing in the system learns from what actually happens: a booking that converts, a referral that lands, a memory that gets created all pass through without making the next recommendation any smarter.

Why that's a problem. A static backend treats every assumption as permanent. Our trust weights are educated guesses frozen in code; our matching can't understand a plain-English dream; our data accumulates but never compounds into intelligence. That is fine for getting started — and fatal for a future sustainable company, because the one thing that should become our deepest moat, the data, sits inert.

The solution — and why this exists. Two systems are being designed to make the backend learn: MATRIX (the trust graph) and PROMETHEUS (the continuously-learning intelligence layer over it). These are ideas for the future scalable LINX backend — the North Star this document describes. This is the picture.

1The problem a static backend can't solve

Every generic startup bolts AI onto its data as an afterthought. The model is the product, the data is exhaust. That company gets rewritten every time the AI vendors change — and they change every few months.

LINX inverts that. The data is the moat. The model is a replaceable part.

Concretely, today:

• Our 18 trust-edge weights (how much a booking counts vs. a completed trip vs. a review) are hardcoded guesses in Kotlin. Educated, but guesses.
• Our recommender matches profiles by similarity. It can't take a plain-English dream ("adventurous but five-star, warm, on the water") and find the right experience.
• Nothing in the system gets smarter from a booking that converts or a referral that lands.

A static backend treats every guess as permanent. The future backend treats every guess as a hypothesis the system improves on its own.

2The one-sentence bet

Couple to the substrate. Decouple from the vendor.

The substrate = the append-only log of everything that happens (a referral, a booking, a memory, a correction) + open data formats + clean contracts. That compounds for a decade.

The vendor = whichever LLM or embedding provider is best this quarter (Anthropic, OpenAI, Google, whoever). Those are swappable config lines.

Anything coupled to a 2026 model is rewritten by 2028. Anything coupled to the substrate compounds through 2036. This is the Renaissance Technologies pattern — one event log, one data pool, survived 30+ years while competitors who fragmented their data eroded.

3MATRIX — the moat (the "who vouched" layer)

Matrix is the LINX Trust Graph. It is the part competitors cannot copy.

They can copy our UI, our referral links, our 10% pitch, our operator listings, even our math. What they cannot copy, because it takes years to accumulate and is verified by operators themselves:

• Years of real, verified memories
• Operator-confirmed booking provenance (the operator says "yes, this booking happened, this person drove it")
• Relationship-specific trust paths (who actually trusts whom, for what kind of trip)
• Curator credibility by context (great for heli-skiing ≠ great for safaris)
• User-corrected taste profiles
• The full Dream → Memory loop history

Matrix's own doctrine says it bluntly:

"The moat is the graph, not inventory."

Two things people get wrong, that you should not:

• The founder network — 100+ high-end operators globally — is go-to-market, not the moat. It seeds the graph. The graph compounds it.
• The math (Shapley, Markov, attribution formulas) is not the moat either. It's algorithms applied to the moat. The moat is the verified, typed, consented graph of who-causes-what. (We go deep on exactly how that math works in Part 2 §4 — because the how matters.)

4PROMETHEUS — eyes, judgment, and forethought

If Matrix is the moat, Prometheus is what makes it intelligent. The clean metaphor from the framework: Prometheus gives the trust graph eyes, judgment, and forethought.

• Eyes (embeddings): every person, operator, experience, and memory gets a mathematical "meaning" vector, so the system can match a plain-English dream to the right experience by meaning, not just tags. This is the direct fix to "the backend is pretty static."
• Judgment (LLM evaluations): an LLM scores every new trust edge for quality, anomaly, and confidence — instead of a hardcoded number.
• Forethought (the overnight learner): a sandboxed agent runs nightly. It looks at what actually happened (inquiry → booked → completed → reviewed), checks whether our trust weights predicted it, and proposes better weights — then runs the full test suite and Slacks Stein an approval card. Every night the backend gets measurably smarter, on its own. That is the opposite of static.

5The two-rail picture — why LINX feels different from Netflix and Instagram

Here is how Matrix and Prometheus combine on a single recommendation. When a traveler asks for something, the system runs two rails in parallel:

Give Netflix and Instagram their due: they are two of the most sophisticated recommendation engines ever built. Billions of dollars and some of the best machine-learning talent on the planet have made them extraordinary at one thing — predicting what will hold your attention. Netflix is the number-one streaming platform in the world for a reason. We are not trying to out-taste them at their own game; Rail 1 stands on the shoulders of everything they pioneered.

What LINX adds is a dimension their model structurally does not have: Rail 2, a verified human trust rail. A LINX recommendation can say "this came to you because Doug, who you trust for polar trips, did it last season." Netflix knows what people like you watched; Instagram knows what people like you engaged with. Neither can tell you that a specific person you actually trust did this specific thing and vouched for it — because they don't have an operator-verified, consented trust graph underneath. That sentence — the verified human reason — is the product. It is why people join, and it is impossible to fake without the graph.

6Why this IS the network effect, in code

This is the most important idea in the document, so we give it room — and an interactive graph to make it concrete.

The trust graph is not a metaphor for the network effect. It is the network effect, written as a data structure.

• Every invite adds a node (a new member) and a typed edge (a real trust relationship) to the graph. More nodes and edges → denser graph → better recommendations and stronger attribution → more reasons for the next person to invite. That loop is the compounding moat.
• The value of a network does not grow with the number of members — it grows with the number of connections between them. This is Metcalfe's Law: a network of n members has on the order of n² possible connections. Double the members, and you roughly quadruple the value. LINX's value lives in the edges, not the headcount.
• The companion / invite graph (the "invite your friends on this trip" feature) is where new nodes enter the graph. Each invite is not a CRUD row — it is a growth event that makes the entire graph more valuable.
• The principal client inviting their own friend group is the strongest signal of all: it creates a cluster of high-trust edges at once — and each new member can seed their own cluster. That is how a trust network goes from linear to exponential.

This is why understanding the network effect matters for building, not just for pitching. If you build the invite graph as a plain table, it works mechanically and is strategically dead. If you build it as typed, provenanced edges in the trust graph, it compounds — and compounding is the whole game.

1The 8 layers + the self-improving Ring

Prometheus is 8 layers. The substrate (bottom) is sovereign; everything above it is swappable.

The Ring (the self-improving loop):

Every cycle leaves the substrate measurably smarter.

2The 8 Laws (constraints, not best practices)

"'Best practices' is what you say when you're not sure. Laws are constraints — all or none." Each law names the failure it prevents and a real example:

1. Substrate sovereign — couple to data + open formats, never the vendor.
2. Event log is append-only & immutable — projections recompute from it.
3. Held-out golden set, forever — a set of judgment cases that NEVER enters training, so the model can't game it. (Chatbot Arena was gamed and destroyed in 2025 for lacking this.)
4. Provenance on every output — model version, timestamp, payload hash, all logged.
5. Capability contracts — business logic talks to interfaces, never vendor SDKs. (Voyage got acquired by MongoDB Feb 2026 — contracts make that a config change, not a rewrite.)
6. Failover stays warm — quarterly real cutover drills, not theater.
7. Eval gate before merge — no learned change ships without passing the golden set.
8. Privacy at the vendor edge — ZDR signed per vendor or the adapter refuses to start at runtime.

3MATRIX data model — the spec an engineer treats as law

The binding contract is GRAPH_CONTRACT.md (Matrix owns the meaning, Poseidon owns the DDL — "Matrix does not write DDL; Poseidon does not change semantics without a Matrix ticket"). Below is the model made interactive — click any node or edge to see what it is and the rule that governs it.

The strict hierarchy — the only path from behavior to money

1. Event — raw, immutable, append-only. Always log if useful + permitted.
2. Signal — derived, with context + a confidence score.
3. Inference — model output. Never stored as fact (marked_inferred: true until a user correction graduates it).
4. Edge — materializes only on a defined product action + an identified subject. Stores a provenance_ref that explains why it exists.
5. Credit — only after operator-confirmed or policy-confirmed outcome. CommissionCredit requires a Plutus co-signature.
6. Decision — versioned; a policy change writes a new row with a supersedes pointer, never an update.

The rule to tattoo on the wall: No edge materializes from system seeding, anonymous opens, or an AI guess. Anonymous opens create events, not trust edges.

The pieces (engineering-relevant)

• Entities: User (UUID v7), AnonymousSession, Experience (immutable once published, versioned), Operator, Curator (Free/Pro/Elite), ShareCode, InquiryLock (30-day TTL), Memory.
• Edge types include: INVITED_BY, REFERRED, SAVED_FROM, BOOKED_VIA, CREATED_MEMORY, TRAVELED_WITH, EXPERIENCED_WITH, TRUSTED_FOR_CONTEXT, GEO_CONTAINS, GEO_ADJACENT_TO. Each has a strict materialization rule (e.g. TRAVELED_WITH requires operator confirmation OR two memories on the same experience-date).
• Multi-axis embedding: every node/edge carries 8 sub-vectors — taste × trust × context × occasion × relationship × geography × time × verified_outcome (D=16 per axis, a Phase-1 hypothesis). Storage: pgvector on Postgres through Phase 2; native graph store (Neo4j/Dgraph) is a deferred decision, only when p95 trust-path > 1.5s at scale or > 50M nodes. "Moving early is a kill."
• Decay: edge weight decays exponentially — weight(t) = weight_0 × 2^(−t / half_life). Half-lives (all hypotheses to validate): view 7d, DreamSaved 90d, MemoryShared 180d, Booking 730d, verified Memory 1825d, INVITED_BY indefinite (structural). Decay is applied at query time via a canonical DSL: query(root, depth, min_confidence, valid_on, …). The valid_on param enables history replay — "what did Matrix know on April 1?" — for dispute reproduction and audit, as a parameter, not a rebuild.
• Gate rules: a record can touch commission, consent, or ranking only if claim_status == production_eligible AND confidence ≥ 0.7 AND its evidence has ≥1 element at source-tier ≤ 2 (Tier 1 = operator-direct, Tier 4 = AI-inferred). Lower-tier data is display-only.
• Ingest is transactional: batches stage in pending/, pass four gates (Structural → Semantic → Cross-reference → Manifest), commit whole or discard whole, with first-class rollback. Evidence files are never deleted.
• Co-signs & boundaries: Matrix ↔ Plutus (no payout without both signatures; tier-first dispute resolution settles ~70% automatically); Matrix ↔ Poseidon (semantic vs. storage); Matrix ↔ Nomos (six consent classes; "zero banners" is retired as false — one honest onboarding screen + glass-box visibility; inferred wealth/family/health is forbidden by default, only stated preferences are allowed).

4The attribution math — Shapley & Markov (the how)

When a booking happens, several people influenced it: the curator who first recommended the experience, the friend who co-signed it, the operator who delivered it. A naive system gives 100% of the credit to the last click. That is wrong, and it is how you lose curators. LINX uses two world-leading multi-touch attribution (MTA) models, both operating over the trust graph, to distribute credit fairly. Here is exactly how they work.

4.1 Markov chain attribution — the "removal effect"

Model the traveler's journey as a directed graph of probabilistic states: touchpoint → touchpoint → … → conversion. The Markov property: the probability of the next state depends only on the current state.

To value a single node (say Curator B), compute the network's overall conversion probability with the full graph, then remove B's node entirely and recompute. The drop is B's value:

If removing Curator B drops network conversion from 15% to 2%, B's removal effect is enormous — credit follows how catastrophic the graph's collapse is without that node. Conversion probability of any single path is the product of its transition probabilities; total conversion is the sum over all paths into the absorbing "converted" state.

4.2 Shapley value attribution — fair coalition credit

From cooperative game theory (Lloyd Shapley, 1953; Nobel 2012). Treat the touchpoints as a coalition of players that jointly produce a conversion, and distribute credit by each player's average marginal contribution across every possible ordering of the coalition:

Where:

• φ_i — the credit assigned to player i (e.g. Curator A)
• N — the set of all touchpoints (players); |N| = how many
• S — every subset of touchpoints that does not contain i
• v(S) — the value (conversion probability / outcome) of coalition S
• v(S ∪ {i}) − v(S) — i's marginal contribution: how much conversion likelihood rises when i is added to coalition S
• the factorial weight — the fraction of orderings in which i joins exactly after the members of S

Shapley evaluates the journey against every permutation of touchpoints (A, A+B, B+C, A+B+C, …), which is what lets it isolate synergy: it can prove a curator is weak alone but a powerful multiplier when combined with someone else's trust signal. It is the unique credit scheme that satisfies four fairness axioms simultaneously — efficiency, symmetry, null-player, and additivity.

4.3 How LINX phases this in (the discipline)

This math is powerful and easy to misuse, so it is gated — never shipped raw:

• Phase 0 (0–500 users): last-click only, via the linx_ref first-party cookie. Deterministic. Shapley/Markov are not in production.
• Phase 1–2: Shapley and Markov run in shadow mode — computed and logged, scored against the deterministic baseline, but not paying anyone.
• Phase 3: they earn production only after shadow accuracy agrees with exact computation within 10% at P95 over 500 decisions, and only behind a human dispute panel + the Matrix ↔ Plutus co-sign on every payout.
• Compute reality: exact Shapley is factorial — tractable only for small coalitions (N ≤ 15; ~250 ms at N=15, ~30 ms at N=10). Above that, Monte Carlo sampling (~5,000 samples) approximates it, with an error monitor that reverts to exact computation for a decision class if error exceeds 15%.
• The cardinal rule: never multi-level chain commission. Credit is for genuine marginal contribution, not for link volume.

Why this is the moat in motion: LINX is, mathematically, a multi-touch attribution engine for human taste. Every booking lets us recompute the marginal contribution and removal effect of every person, place, and theme in the graph — and that calculation gets sharper with every outcome. Competitors don't have the graph to run it on.

5The two-rail composition — the hard rules

The §5 two-rail picture has non-negotiable rules so the taste rail never erases the trust:

1. Vector candidates MUST pass through Matrix decay before the union — or the recommender resurfaces stale operators Matrix correctly down-ranked. (A raw vector index has no concept of decay.)
2. The LLM ranker MUST carry attribution context per candidate ("referred by Y, degree-2 from user, shared 3 weeks ago") — or recommendations go attribution-blind.
3. Taste is downstream of trust. Phase 1 is vector + graph, no taste model. Resist building taste-modeling first.

6Sequencing discipline — build order when we DO build it

Build the trust composition first; layer the vector recommender on top. Never the reverse.

• The vector recommender is commodity (~$170/mo on pgvector on the existing RDS — not OpenSearch Serverless, which is 50–100× the cost at our scale). Cheap, anyone can do it.
• The trust-graph composition is the moat. Build the moat-shaped thing first; the cheap thing bolts on.
• Taste-model inference is Phase 2/3, after 6–12 months of real usage data. Building taste before data is guessing.
• Cold start is inverted for us: vector-only is the correct fallback for a brand-new graph-less user; two-rail kicks in once they're connected.

7Build toward the North Star

This is the point of the whole document. As you build the backend, every decision should be made with this vision in view. You are not just building features — you are building toward this backend. Each schema choice, each edge, each vector, each endpoint should be made knowing what it grows into.

• Think about how today's work implements into this model, and plan for it. A decision made blind is a decision you pay to undo.
• The trust/invite graph especially — node identity, pending-shell users for not-yet-joined invitees, invite-edge states, attribution carry — is the literal network-effect engine and is expensive to migrate later. Build it knowing it has to last at least ten years.
• The single integration seam between today and this future is createEdgeWithScoreEvent() in TrustGraphService.kt. That one method is where Prometheus eventually hooks in. Keep it clean.

The discipline is simple: measure twice, cut once, and always know what you are building toward.

8Spec vs. shipped — the honest line (read this twice)

What is actually in linx-core today:

• A production v1 Trust Graph: V3__create_trust_infrastructure.sql → trust_edges (typed edges, weight DECIMAL(4,2), metadata JSONB) + trust_score_events.
• TrustGraphService.kt enforcing 5 hard rules (no duplicate edges, no self-edges, fixed per-type weights, score clamped [0,1], max negative delta −0.30).
• createEdgeWithScoreEvent() as the atomic edge+score primitive. 18 edge types. 906 tests at 98% coverage. Flyway through V51.

What is spec / vision (this whole document, mostly): multi-axis embeddings, confidence×claim-status duality, source-tier evidence, geography edges, read-time decay DSL, transactional 4-gate ingest, force-graph compute, the consent-class system, Shapley/Markov attribution, Matrix↔Plutus co-sign, the Wiki-Link Link Grammar, and all 8 Prometheus layers. Matrix v2 is ~4,200 lines across ~25 files, five-gate reviewed, story-certified — and never invoked in production. Prometheus v1 is a locked framework with ~22 code stubs and a 15-PR sequence — not running.

The shipped graph is a typed-edge table with hardcoded weights and a score-event log. The spec is a far richer, self-learning system. The shipped service is the starting point; the spec is the destination. Prometheus is the proposed bridge that learns the spec's weights from real outcomes over the production graph.

Two known issues an implementer resolves before writing DDL: (a) the confidence_basis enum is 3-valued in the binding GRAPH_CONTRACT (EXTRACTED / INFERRED / AMBIGUOUS) but 4-valued in the doctrine prose (EXTRACTED / INFERRED / DECLARED / VERIFIED) — the contract governs; (b) the multi-axis D=16 and all decay half-lives are hypotheses requiring Phase-1 validation against minimum sample sizes before they harden.

9The horizon

Prometheus is designed on an 11-Star ladder (Chesky): Year 1 → investor-grade, Year 3 → category-creator, Year 10 → an open standard ("the PROMETHEUS architecture" enters the vernacular). The moat at the top is eight stacked layers — Data, Contracts, Golden set, Relationships, Reliability, Ecosystem, Brand, Foundation. We don't need to believe the Year-10 artifact to act. We need to build Year 1 so that Year 10 becomes inevitable — and the way you do that is to build the trust graph like it lasts.