# Concept 2: R3 Vector System — Declaration Replacing Inference

**Status:** Canonical spec v1  
**Date:** 2026-05-20  
**Replaces:** R3 auto-fill logic in `00-OVERVIEW.md` (inference model)  
**Supersedes:** `07-RING3-VECTORS.md` (promotes from proposal to canonical)

---

## The Problem

The current R3 specification says: *"auto-fills from R2 circulation — the system guesses what you're reaching for based on your graph."*

This is a black-box inference dressed in poetic language. Users will not trust a system that claims to know their longing better than they do. The fix is surgical: replace inference with declaration.

---

## The Core Shift

| | OLD — Inference | NEW — Declaration |
|--|----------------|-------------------|
| How R3 fills | System analyzes cart + circulation, guesses | User explicitly declares 1-3 Vectors |
| How matches surface | Algorithmic recommendation | Transparent vector-filtered discovery |
| Emotional register | "Here is who we think you want" (passive, opaque) | "Here are people reaching toward what you're reaching toward" (active, transparent) |
| Cold start | Needs history to infer | Declare immediately, matches surface from day 1 |
| Ghost hex content | Person's identity | Your own declared vector only |

---

## What Is a Vector?

A **Vector** is a lightweight, ephemeral declaration of what you're currently reaching for in one of three domains.

**Properties:**
- **Intentional** — you choose it, it's not inferred
- **Transparent** — matches surface because of your declared vector, not hidden signals
- **Temporally bounded** — shifts as your life shifts; free to update anytime
- **Bidirectional** — a match surfaces when two declared vectors overlap or complement
- **Not a commitment** — declaring a vector doesn't obligate you to pursue anyone who surfaces

### Vector Types

| Type | User Prompt | Maps To |
|------|-------------|---------|
| **Activity** | "What are you reaching for in your activities?" | Cart: Activities |
| **Food** | "What are you reaching for in food?" | Cart: Food |
| **Habitat** | "What are you reaching for in your space?" | Cart: Habitat |
| **Perspective** | "What perspective are you missing?" | Emergent |
| **Skill** | "What skill are you building toward?" | Emergent |
| **Free** | "Anything else you're reaching toward?" | Emergent |

The first three types map to Cart categories — this creates coherence between "what you tend" (cart) and "what you're reaching for" (vector). The last three are emergent and open the system to signals the Cart can't capture.

---

## Vector Schema

```json
{
  "id": "uuid",
  "user_id": "uuid",
  "vector_type": "activity | food | habitat | perspective | skill | free",
  "value": "string (user-declared text)",
  "normalized_value": "string (system-normalized for matching)",
  "created_at": "timestamp",
  "decays_at": "timestamp (default: created_at + 90 days)",
  "status": "active | paused",
  "edit_count": "number"
}
```

**normalized_value** is the system-generated canonical form of the user's free text — used for matching without losing the user's original phrasing.

---

## Onboarding

At the end of onboarding (after claiming R1 anchors and adding first cart items):

```
You're at the center of your constellation.

What's calling to you right now?

You can declare up to 3 vectors — things you're reaching toward.
These shift as you shift. They're not promises. They're directions.

Examples:
• "Someone to climb with"
• "People who are into fermentation"
• "A different perspective on my work"
• "Someone who lives by water"
• "A skill I want to learn"

You can skip this. Declare vectors later from your profile at any time.
```

Vectors are **optional, not forced**. Skipping doesn't block onboarding.

---

## How R3 Populates

Ring 3 is populated by three mechanisms, in priority order:

### 1. Vector Overlap (primary)

Users in your R2 circulation whose declared vectors match yours exactly or near-exactly.

**Matching rules by type:**

| Type | Overlap Rule | Example |
|------|-------------|---------|
| **Activity** | Normalized activity tags overlap | "rock climbing" matches "climbing partner" |
| **Food** | Normalized food tags overlap | "sourdough baking" matches "bread making" |
| **Habitat** | Normalized habitat tags overlap | "urban garden" matches "apartment growing" |
| **Perspective** | Semantic similarity via keyword extraction | "philosophy of place" matches "sense of location" |
| **Skill** | Skill tag matches (shared learning goal) | "learning Japanese" matches "Japanese practice" |
| **Free** | Semantic similarity, lower weight | User text matched against user text |

### 2. Vector Complement (secondary)

Users whose vectors are the inverse or natural complement of yours.

**Complement pairs detected when:**
- Vector types are different but semantically related
- Together they form a complete action pattern

| Your Vector | Complement Vector | Why Complementary |
|-------------|------------------|-------------------|
| "Someone to climb with" | "Someone to belay me" | Direct complement — same activity, different role |
| "A cooking collaborator" | "Someone who eats what I cook" | Creator + recipient |
| "A perspective I lack" | "I want to share my perspective" | Offer + request |
| "Skill: Japanese" | "Skill: teaching Japanese" | Learner + teacher |

**How complement detection works:**
- Pairs are identified by vector type + normalized semantic relationship, not by user identity
- Complements are surfaced with a "complement notice" — "You're reaching for X. This person is reaching for Y — which together would form Z."
- The user sees both the person AND the framing of the complement

### 3. Temporal Proximity (tertiary)

Users who declared the same vector within 14 days of you get a recency bonus in ranking.

**Ranking is not a score — it is chronological discovery filtered by vector.** The frame is: *"Here are people in your constellation who declared this vector, ordered by who declared it most recently."*

No score displayed. No rank displayed. Just discovery.

---

## Bidirectional Confirmation

R3 confirmation is **bidirectional** — both parties see each other in their R3 if:
1. User A is in User B's R2 circulation
2. User A has a declared vector that matches User B's declared vector
3. User B has a declared vector that matches User A's declared vector (or A's vector is a complement of B's)

**The constellation is emergent, not directed.** You can reach toward someone. Whether they reach back is their own act. If only one party reaches, the hex is **unilateral** — visible to the one reaching, not to the one being reached toward.

---

## Ghost Hexes — The Longing Record

When a R3 person exits (vectors change, match dissolves, the other person leaves Cascade), the hex becomes a **dim hex**.

**R3 dim hexes record the vector, not the person.** This is the critical distinction from R1/R2:

| Ring | Dim Hex Records |
|------|----------------|
| R1 | "This anchor relationship existed" (person identity preserved) |
| R2 | "This archetype slot was filled" (person identity preserved) |
| R3 | "I was reaching for this thing" (vector preserved, no person ID) |

The R3 dim hex is about **your longing**, not the person who briefly filled it. When you see a dim hex in R3, the system shows you the vector that was active: *"You were reaching for: a climbing partner (Dec 2025 — Feb 2026)."* The person's identity is not preserved.

**Why this matters:** R3 dim hexes normalize the emotional experience of longing evolution. "Your longing shifted" is not "you failed to keep this person." The hex is a record of a gap you reached into, not a record of a gap that closed.

---

## Vector Decay

Vectors decay after **90 days** by default.

**On decay:**
- Vector no longer surfaces new matches
- The R3 hex it occupied becomes a dim hex
- User can re-declare the same vector or a new one

**Decay prevents R3 from fossilizing** into "I used to want this." Life shifts; the longing shifts; the constellation shifts with it.

**User-controlled decay:** Users can set a shorter decay window (30 or 60 days) or pause a vector manually at any time. Pausing preserves the vector without surfacing it.

---

## Anti-Gaming

**Problem:** Users could declare popular vectors to get surfaced more often and expand their reach.

**Solution:** Vector popularity is **visible to the user** — but not as a score or rank.

When declaring a vector, the user sees:
- "12 people declared this vector this week" — raw frequency, no ranking
- "This vector has been active for 847 days" — longevity, not popularity score

No algorithmic penalty for being in a popular vector. No suppression. Just transparency: *you declared X, and here is how many others have declared it recently.*

**Additional anti-gaming:**
- Burst detection — if a user adds 3 new vectors in <7 days, flag as potential manipulation
- Same-vector repeat limit — cannot re-declare the exact same vector text more than 3 times without a 30-day gap (prevents farming the same direction)
- Complement abuse prevention — a user cannot declare a vector specifically to complement a specific person (complement detection is system-side, not user-declared)

---

## R4+ Extension

The vector system is **R3-exclusive by design.** Here's why:

- **R4+ surfaces people through sustained signal, not declared intent.** Echoes are confirmed through creative output resonance, not declared longing.
- **Extending vectors to R4+ would create pressure to declare vectors for matching purposes, which undermines the "vectors are honest, not performative" principle.**
- **R4+ users have already been in the system long enough that cart + creative output is a richer signal than self-declared vectors.**

Vectors serve R3 because R3 is the ring of *active wanting* — where declaration is honest and useful. R4+ is the ring of *sustained resonance* — where behavior is more honest than declaration.

---

## R3 Confirmation Mechanics

R3 nodes have a **monthly confirmation window.**

Each month, the system asks:
1. "Is this vector still active?" — if no, the hex goes dim
2. "Is this person still resonant?" — if the other person's vector has changed or they've left R2 orbit, the hex goes dim

**If neither is confirmed, the hex → circulation.**

A user in R3 circulation can re-enter R3 if their vector changes back to overlap with someone in their R2.

---

## Open Questions — Resolved

| Old Question | Resolution |
|-------------|-----------|
| **Complement vectors** | Complements detected by vector type + semantic relationship. User sees the complement framing explicitly. Not gameable — system-side, not user-declared. |
| **Vector limit** | 3 max. Provides enough directional signal without degrading to noise. |
| **R3 dim hexes** | Record vector only. No person identity preserved. Emotional frame: "your longing evolved." |
| **R4+ extension** | Vectors stay R3-exclusive. R4+ uses behavioral signal (cart + creative output), which is richer than declared intent for sustained resonance. |
| **Anti-gaming** | Popularity transparency, burst detection, repeat-declaration limits, no user-declared complements. |

---

## What This Enables

1. **Cold start solved** — User declares vectors on day 1. R3 surfaces matches immediately from R2 circulation. No waiting for inference.
2. **R3 is honest** — The system surfaces people matching YOUR declared direction, not its guess at your direction. Trust preserved.
3. **Longing is visible to self** — R3 dim hexes show your own longing evolution over time. The dim hex is a self-portrait of changing desire.
4. **Complement discovery** — Natural complement pairs surface with the framing of why they're complementary. "You're reaching for X. They're reaching for Y. Together that's Z."

---

*Next: Concept 3 — Fractal Seed scope decision*