# MEA Gap Analysis — What rSpace Needs to Add

> Components from the MEA spec not currently covered by rSpace-Online,
> with implementation complexity estimates and suggested approaches.

---

## Gap 1: Exchange Gradient Engine (High Priority)

**MEA Requirement:** Transactions between participants are priced according to
relational distance. L0↔L0 (same pod) = 50% rate; each level of separation adds
10%, up to 100% for L0↔L5 interactions.

```
rate = min(1.00, 0.50 + 0.10 * counterparty_level)
```

**What's Missing:**
- Graph-distance calculation service (shortest path between two participants across the pod hierarchy)
- Rate-application middleware that intercepts exchange/payment flows
- Rate display in transaction UX ("you're paying 60% because you're 1 hop away")

**Suggested Approach:**
- New module `rGradient` or extension to `rExchange`
- Maintain a materialized view of the pod relationship graph (updated on membership/relationship changes)
- Expose a `getRate(participantA, participantB)` function consumed by rExchange and rWallet
- Complexity: **Medium** — the formula is trivial; the graph traversal at scale needs caching

---

## Gap 2: Pod Mitosis Protocol (High Priority)

**MEA Requirement:** When a pod exceeds its effective size (12 for L0), it must
divide into two pods. This is biological — growth through division, not expansion.

**What's Missing:**
- Mitosis trigger detection (member count exceeds threshold)
- Mitosis governance flow (vote to divide, select split)
- Automated pod creation (new Space, member reassignment, relationship inheritance)
- Post-mitosis relationship establishment between the two new pods

**Suggested Approach:**
- New module `rMitosis` that monitors pod membership counts
- When threshold is reached: surface a governance proposal via rVote
- On approval: execute the split (create new Space, move members, establish inter-pod relationship)
- Preserves Automerge history in both resulting pods
- Complexity: **Medium-High** — the governance flow exists; the automated split logic is new

---

## Gap 3: Pod Level Taxonomy & Member Caps (Medium Priority)

**MEA Requirement:** Pods have typed levels (L0 through L5) with specific
member caps: L0 = max 12, L1–L5 = max 8 each. Different levels serve
different functions (L0 = primary creative, L1–L5 = functional aggregation).

**What's Missing:**
- Pod level type field on Spaces
- Enforced member caps per level
- Level-specific behavioral rules (what an L3 pod can/cannot do vs an L0)

**Suggested Approach:**
- Add a `meaPodLevel` metadata field to the Space schema
- Enforce member caps in the Space membership admission flow
- Level-specific rules as module configuration
- Complexity: **Low** — mostly configuration on existing primitives

---

## Gap 4: Relationship Capacity Constraints (Medium Priority)

**MEA Requirement:** Pods have limited relationship slots. L0 pods can maintain
max 5 inter-pod relationships. This ensures the network stays intentionally sparse.

**What's Missing:**
- Relationship count enforcement per pod
- Relationship slot management (which relationships to maintain/dissolve)
- Visibility into remaining capacity

**Suggested Approach:**
- Extension to rNetwork: add `maxRelationships` config per Space type
- Reject new relationship requests when at capacity
- Dashboard showing relationship slots used/available
- Complexity: **Low** — validation logic on existing rNetwork connection flows

---

## Gap 5: Anti-Gaming / Rate Limiting (Medium Priority)

**MEA Requirement:** The protocol includes anti-gaming measures: transaction volume
caps, burst detection, relationship cycling detection, and Sybil resistance.

**What's Missing:**
- Per-participant transaction volume caps (daily/weekly)
- Burst detection (unusual transaction patterns)
- Relationship cycling detection (forming/dissolving relationships to game the gradient)
- Sybil resistance (one-person-many-pods exploitation)

**Suggested Approach:**
- New module `rIntegrity` or extension to rGradient
- Transaction volume tracking with configurable thresholds
- Anomaly detection on relationship graph changes
- Sybil detection via EncryptID's device-binding (one passkey = one device = one identity signal)
- Complexity: **Medium** — the rules are specified; the detection heuristics need tuning

---

## Gap 6: Pod Lifecycle State Machine (Low Priority)

**MEA Requirement:** Pods have formal lifecycle states:
`forming → active → dividing → dissolved`

**What's Missing:**
- State field on Spaces
- State transition rules (who can trigger, what conditions)
- Dissolved state handling (archive, read-only access to history)

**Suggested Approach:**
- State field in Space metadata
- Transition validation in Space management flows
- Dissolved = read-only mode (Automerge doc frozen)
- Complexity: **Low**

---

## Gap 7: Native Mobile Shell (Low Priority for MVP)

**MEA Requirement:** Mobile-first UX designed for low-bandwidth, small-screen
environments (the "Dharavi standard").

**What's Missing:**
- rSpace is currently web-first (responsive but not native mobile)
- No offline-capable mobile app wrapper

**Suggested Approach:**
- Capacitor or React Native wrapper around the existing web app
- Service worker for offline caching (partially exists)
- SQLite adapter for Automerge (replacing IndexedDB on mobile)
- Complexity: **High** — but not blocking for web-based MEA pilot

---

## Implementation Roadmap Suggestion

### Phase 1: MEA Configuration Layer (1–2 weeks)
- Pod level taxonomy (L0–L5 type field)
- Member caps per level
- Relationship capacity constraints
- Pod lifecycle state machine
- *All low-complexity, configuration-level changes*

### Phase 2: Exchange Gradient (2–3 weeks)
- Pod relationship graph materialization
- Distance calculation service
- Rate calculation function
- Integration with rExchange / rWallet payment flows
- Rate display in transaction UX

### Phase 3: Mitosis Protocol (2–3 weeks)
- Threshold monitoring
- Governance-triggered division flow
- Automated pod split (new Space creation, member reassignment)
- Post-mitosis relationship establishment

### Phase 4: Integrity & Anti-Gaming (2–3 weeks)
- Transaction volume caps
- Burst / anomaly detection
- Relationship cycling detection
- Dashboard / alerts

### Phase 5: Mobile Shell (4–6 weeks, can run in parallel)
- Capacitor wrapper
- Offline-first optimizations
- Low-bandwidth UX adaptations

---

## Effort Summary

| Gap | Priority | Complexity | Estimated Effort |
|---|---|---|---|
| Exchange Gradient Engine | High | Medium | 2–3 weeks |
| Pod Mitosis Protocol | High | Medium-High | 2–3 weeks |
| Pod Level Taxonomy & Caps | Medium | Low | 2–3 days |
| Relationship Capacity | Medium | Low | 2–3 days |
| Anti-Gaming | Medium | Medium | 2–3 weeks |
| Pod Lifecycle States | Low | Low | 1–2 days |
| Native Mobile Shell | Low (MVP) | High | 4–6 weeks |

**Total new development: ~8–12 weeks** to bring rSpace from current state to
full MEA protocol compliance, with the first usable MEA pilot possible after
Phase 2 (~4–5 weeks).