# Concept 3: Fractal Seed Scope — What Moves, What Stays

**Status:** Canonical spec v1  
**Date:** 2026-05-20  
**Purpose:** Define the identity boundary, content envelope, and propagation model for Fractal Seeds

---

## The Problem

The SOP calls Fractal Seeds "compressed contextual truth about who you are" and "peer-to-peer context compression." But the scope is undefined. A seed could be:

- **A signal** — a lightweight tag that compresses emotional/contextual state, readable without sender's lattice
- **A node** — a partial copy of the sender's lattice structure, carrying cart patterns and ring state
- **A cascade** — a propagating artifact that moves through the recipient's rings like a resonance event

Each scope produces a completely different product. Right now Cascade has all three loaded into one concept. We need to choose.

**Security context added:** AI vibe-coded P2P file sharing is a liability. Raw uploads moving peer-to-peer create vectors for malicious content injection (SVG XSS, polyglot files, deserialization attacks). Any Cascade file transfer must be Cascade-processed — the raw payload never reaches the recipient. Cascade is the relay, not the pipe.

---

## The Three Scope Options

### Option A: Seed as Signal

The seed is a lightweight, self-contained data unit. It carries only:
- What the sender was experiencing when they shared it (type + brief text)
- The cart item or ring position it references
- A temporal marker (when it was shared)
- A decay rule (auto-deletes after X days)

**What it does NOT carry:** Any piece of the sender's lattice structure. The recipient reads the signal; the sender's constellation is irrelevant.

**Analogy:** A handwritten note. The note is self-contained. The sender's desk (lattice) is not in the envelope.

**Pros:** Simple. No identity boundary issues. No propagation complexity.
**Cons:** Not fractal — just a message with extra metadata. Doesn't earn the "seed" name.

---

### Option B: Seed as Node (Partial Lattice Copy)

The seed carries a partial copy of the sender's lattice — specifically the resonance patterns around the thing being shared.

For example: if you share a restaurant from your cart, the seed carries:
- That restaurant item + its cart neighbors (the 2-3 items you added around the same time)
- The resonance field that item has generated (who it has resonated with, at what strength)
- The hex position it occupied in your lattice (R2, R3, etc.)

**The recipient receives a partial constellation.** When the seed enters their lattice, it arrives as a node that fits into their existing structure — not as a raw data blob.

**Analogy:** A cutting from a plant. The cutting carries the genetics (cart patterns) and some of the parent plant's structure (ring position), but grows differently in new soil (recipient's lattice).

**Pros:** Actually fractal — seeds carry lattice DNA that expresses differently in each recipient's constellation.
**Cons:** Identity boundary is unclear. Does the seed carry any PII? How much of the sender's graph is in the package?

---

### Option C: Seed as Cascade Event

The seed is not an artifact — it's a resonance event that propagates through the recipient's rings.

When you send a seed, it enters the recipient as a signal in their R1 (if bonded) or R3 (if vector-matched). From there it propagates outward based on how it resonates with their rings. If it reaches R4+ resonance threshold, it surfaces to them organically.

**The seed is a catalyst, not a container.** It doesn't carry your lattice — it triggers pattern-matching in theirs.

**Analogy:** A song playing in a café. The song has an origin (sender), but what matters is how it lands in the room (recipient's context). It doesn't persist as an object — it creates a resonance event that may echo.

**Pros:** Truly emergent. No identity boundary issues. Matches Cascade's resonance-first philosophy.
**Cons:** Hard to implement. Hard to debug. Users can't see "what happened to the seed I sent."

---

## The Decision

**Option B is the right scope — Seed as Node, relayed through Cascade infrastructure.**

Here is why:

- **"Signal" (Option A) is just a message.** Doesn't earn "fractal." Doesn't differentiate from email or DM.
- **"Cascade event" (Option C) is too opaque.** Users need to be able to see what they sent and what it triggered.
- **"Node" (Option B) is actually fractal** — the seed carries lattice DNA that expresses differently in each recipient's structure, which matches the product's own architecture.

**The relay architecture closes the security gap.** The seed is not a raw payload. It is a structured signal object that enters Cascade's processing layer and exits as a Cascade-generated visual artifact. The sender's raw content (photos, files, SVGs) never reaches the recipient. Cascade processes, sanitizes, and renders. The recipient receives the artifact, not the payload.

The SOP says: *"The same seed, different resonance in each lattice. Like how light refracts differently through different prisms."* That is Option B. The seed is not a message — it is a partial constellation that propagates through a controlled relay layer.

---

## What a Seed Carries — Canonical Envelope

A Fractal Seed carries exactly this:

### Layer 1 — The Core Signal

| Field | Type | Description |
|-------|------|-------------|
| `seed_id` | uuid | Unique identifier |
| `sender_id` | uuid | Who sent it (not optional — bidirectional bond required) |
| `seed_type` | enum | `cart_item` \| `pattern_note` \| `longing_map` \| `emotional_tag` \| `relationship_moment` |
| `primary_content` | string | The thing itself — item name, note text, emotional label |
| `normalized_content` | string | System-normalized form for matching |
| `context_note` | string (optional) | Sender's brief context — "their spicy ramen is transcendent" |
| `created_at` | timestamp | When shared |
| `asset_ref` | string (optional) | Cascade-assigned asset ID for any uploaded media. The raw file stays on Cascade's servers; only the ref travels with the seed. |

**Security: raw content never travels with the seed.** If the seed references a photo, the photo is uploaded to Cascade, validated, processed, and stored. The seed carries only the `asset_ref`. The recipient receives the `asset_ref` plus a Cascade-generated rendering of the asset — never the raw file.

### Layer 2 — Lattice Position (Partial)

| Field | Type | Description |
|-------|------|-------------|
| `source_ring` | int | Which ring this item/pattern occupied in sender's lattice (R2-R6) |
| `resonance_strength` | float | Current resonance score (0-1) — how strongly this node has been resonating |
| `neighbor_items` | array (1-3 items) | The 1-3 closest cart items by addition time — partial context of surrounding lattice |
| `vector_tags` | array | Any active vectors on the sender that overlap with this item |
| `decay_profile` | enum | `passive` (decays at 90d) \| `anchored` (decays when R1 bond changes) \| `preserved` (never decays unless user deletes) |

### Layer 3 — Propagation Metadata

| Field | Type | Description |
|-------|------|-------------|
| `propagation_depth` | int | How many recipients have re-seeded this (max 3) |
| `propagation_path` | array (uuids) | The chain of recipients — visible only to original sender |
| `recipients_count` | int | Total unique recipients |
| `recipients_visible_to_sender` | bool | If true, sender can see who received (R1 recipients only) |

**What a seed does NOT carry:**
- No other person IDs (recipient sees sender's ID + their own position, not other recipients)
- No raw cart data beyond the 1-3 neighbor items
- No ring contents of sender's constellation
- No behavioral data beyond the specific shared item

---

## The Identity Boundary

This is the core question: how much of the sender's identity is in the seed?

**The boundary: the seed carries pattern, not person.**

- The seed carries the **shape** of the sender's relationship to the thing — what ring it's in, how long it's been resonating, what surrounds it. That shape is the identity signal.
- The seed does NOT carry the sender's **graph** — other people in the constellation, R1 identities, R2 archetype assignments.
- The recipient's lattice reads the **shape** and integrates it into their own structure. The sender's graph is irrelevant to the recipient.

**The recipient sees:**
- The thing (item/note/moment)
- Its lattice position in the sender's world (ring + resonance strength)
- Its neighbor context (1-3 items)
- The sender's ID (so they know who sent it)
- The sender's vector tags at time of sharing

**The recipient does NOT see:**
- Who else is in the sender's constellation
- What rings the sender has filled or dim
- Any other person's data

**This is what makes it peer-to-peer and not a social graph export.** The seed is a bounded data package — it cannot be combined with other seeds to reconstruct the sender's full lattice.

---

## Propagation Model

When a recipient receives a seed:

### Step 1 — Intake
The seed enters the recipient's lattice at the appropriate depth based on bond strength:

| Recipient Has | Seed Enters At |
|---------------|----------------|
| Sender is R1 (mutual bond) | R2 — Archetypes (full context visible) |
| Sender is R2 (user is in sender's R2) | R3 — Longing (vector-matched surfacing) |
| Sender is R3 (vector overlap) | R4 — Echo (partial context, pattern-matching) |
| Sender is R4+ | R4+ — Echo (ambient resonance, reduced signal) |

### Step 2 — Integration
The seed's pattern is matched against the recipient's lattice:
- Does the seed's primary_content overlap with any of the recipient's cart items? (Hearts signal)
- Do the seed's vector_tags overlap with the recipient's active vectors? (R3 match signal)
- Does the neighbor_items set create complementary rhythm with the recipient's cart? (Moons signal)

### Step 3 — Notification
The recipient sees the seed as a signal, not a push notification:
- If the seed creates resonance (any pattern match), it surfaces as a gentle notification — "A resonance from [Sender] arrived"
- The notification shows: the thing, the sender, the match type found
- The recipient chooses whether to engage

### Step 4 — Re-seeding
The recipient can propagate the seed to their R2 (with their own neighbor context attached):
- **This is the "fractal" property** — the seed carries partial lattice structure and can regenerate partial structure in the next lattice
- Re-seeding requires: recipient is R1 or R2 of sender AND seed's `propagation_depth < 3`
- Re-seeded seeds carry the recipient's 1-3 neighbor items appended to the original, not replacing

**Propagation depth is capped at 3** — after that the seed is local to the original sender's constellation. This prevents fractal seeds from becoming spam vectors.

---

## What "Fractal" Means — Precisely

The SOP calls it "fractal context compression" and says "same seed, different resonance in each lattice." Here is what that actually means operationally:

1. **The seed carries the sender's local structure** — their cart, their ring position, their neighbors. This is the "fractal seed."
2. **When the seed enters a new lattice, that structure is read against the new context** — the seed's pattern either matches, complements, or creates resonance with the recipient's existing structure.
3. **The outcome is different in each lattice** because each lattice has a different cart, different rings, different resonance history. The seed's DNA expresses differently.

**Fractal = self-similar structure at every scale.** The seed is a miniature lattice. When it lands in a new lattice, it creates a miniature version of the same pattern (cart + ring + neighbors) in that new context. This is why seeds propagate and why they don't need the sender's full graph — the pattern is in the seed, not in the sender.

---

## What This Enables

1. **Cascade-relayed media** — photos move sender → Cascade → recipient. The raw file is validated, processed, and rendered server-side. The seed that travels with the photo carries the photo's context (where it was taken, what it depicts, the sender's cart ring position) without the file itself. The recipient receives a Cascade-generated visual artifact, not a file transfer. This is how Cascade handles P2P data sharing securely.

2. **Context that ages** — seeds decay. A seed shared 90 days ago surfaces differently than one shared today. The decay is visible: old seeds show as dim hexes, not deleted.

3. **Propagation without graph export** — a user can re-seed to their R2 without giving them access to the sender's full constellation. Each recipient gets a partial structure.

4. **Anti-gaming through bounded structure** — a seed cannot be combined with other seeds to reconstruct the sender's graph. The envelope is intentionally limited.

---

## Security Architecture — Cascade as the Relay Layer

### Threat Model

AI vibe-coded P2P file sharing is the most common source of catastrophic security failures in social apps. The specific threats Cascade avoids:

| Threat | Attack Vector | Cascade Mitigation |
|--------|--------------|-------------------|
| **SVG XSS** | Malicious SVG uploaded as avatar/cart image; executes JS in recipient's browser | All uploads processed server-side; SVG rendered to `<canvas>` output; original never stored or served |
| **Polyglot file bombs** | ZIP/image polyglots bypass MIME type checks | Files decoded and re-encoded; content-type forced by actual rendered output |
| **Deserialization injection** | Seed payload constructed to exploit `JSON.parse` or object deserialization in client | Seeds are flat JSON objects; no nested deserialization of untrusted structures |
| **Graph reconstruction** | Multiple seeds combined to reconstruct sender's lattice graph | Bounded envelope: 1-3 neighbor items, no other person IDs, propagation depth capped at 3 |
| **Content poisoning** | Adversarial cart items crafted to manipulate who gets surfaced to whom | Cascade normalizes and scores content; pattern anomalies flagged for review |

### The Core Rule

> **All raw content submitted by users is processed by Cascade's infrastructure. The recipient receives a generated artifact, never a raw file.**

This applies to: cart item images, avatar uploads, Fractal Seed attachments, any user-submitted media. The Cascade relay is not a convenience feature — it is the security perimeter.

---

## Open Questions — Resolved

| Question | Resolution |
|----------|-----------|
| How much identity moves with the seed? | Pattern, not person. Ring position + resonance strength + 1-3 neighbors. No graph. |
| Does the seed carry PII? | No. Sender ID is included, but no other person IDs, no R1/R2 contents. |
| Does the seed propagate recursively? | Yes — up to depth 3, only through R1/R2 of each recipient. |
| What triggers re-seeding? | Recipient chooses. Must be in sender's R1 or R2. Propagation depth < 3. |
| What happens to seeds over time? | Decay at 90 days (passive) or when R1 bond dissolves (anchored), or preserved indefinitely (preserved). |
| Can seeds be used to reconstruct the sender's graph? | No — envelope is bounded. Partial lattice copy, not full graph export. |

---

## What This Does NOT Solve

1. **Complement map visualization** — "Seed carries complement signals" is defined, but the UI for showing the recipient "this seed fills a gap in your cart" is not. That's a separate UX problem.
2. **Root/Spark/Drift spending on seeds** — The SOP says "Send a fractal seed (care package)" costs a Root token. The mechanics of what tokens unlock are not in this document.

---

*Next: Concept 4 — Cart Pattern Recognition implementation details*