# Technical feasibility and internal impact analysis: SIM v1

Input: `prd-v1.md` + `sim-v1.html` (all 8 scenarios played; API log exported).
Reviewers: platform engineering (Jo), trust & safety (Ravi). AI pass first, then the humans confirmed each item.

## The existing ecosystem (fictional)
```
           ┌──────────────────────── Lanternworks platform ────────────────────────┐
 ShelfShare│  Accounts      Places            Courier          Notify     Event bus │
  (mobile) │  (identity)    (venues + 500 m   (chat, store-    (push)     (pub/sub, │
           │                 neighbourhood     and-forward,                at-least-│
 Lantern   │                 cells)            no realtime)                once)    │
  Clubs ───┤                                                                       │
 (book-club│  Policy P-7: member coordinates are never stored or sent to another   │
   app)    │  member. Places resolves a member to a cell on the device.             │
           └────────────────────────────────────────────────────────────────────────┘
```

## Feasibility gate
| # | Question | Finding | Kind |
|---|---|---|---|
| F1 | Can existing services support UC-1 browse? | Yes, at cell level ("in your area", "2 cells away"). Not in metres. | [FACT] Places API docs |
| F2 | UC-4 live map: is there a real-time channel? | **No.** Courier is store-and-forward with a 2–30 s delay. A streaming channel is new infrastructure, estimated 9–12 weeks. | [FACT] eng estimate |
| F3 | UC-4: is sending positions between members allowed? | **No.** It breaks policy P-7. An exception needs a legal review plus per-region consent flows. | [FACT] policy |
| F4 | Battery and cost of 5 s updates for 60 min | ~6% battery per swap on mid-range phones (test build). Server fan-out cost rises with swaps × 720 messages. | [AI] estimate, [HYPOTHESIS] |
| F5 | UC-5 handoff code | Feasible. Accounts can issue short-lived one-time codes, and the same pattern exists for device login. | [FACT] |
| F6 | `swaps.*` service | Feasible. A new small service on the event bus, estimated 3 weeks. | [FACT] eng estimate |

## Internal impact
| # | Touches | Finding | Kind |
|---|---|---|---|
| I1 | **"Quiet profile" PRD** (in flight, Lantern Clubs + ShelfShare) | It hides *when* a member is active. The v1 "nearby now" dot shows exactly that. **Direct conflict.** | [AI] found, [FACT] confirmed by PRD owner |
| I2 | Places venue list | Places already holds 1,900 public venues (libraries, cafés), and 140 of them host "community shelves" for Lantern Clubs. **Reuse opportunity.** | [FACT] |
| I3 | Notify quotas | 4 pushes per swap fit the existing per-member quota. | [FACT] |
| I4 | Safety | Repeated live dots near the same point reveal a home address after about 3 swaps. | [AI] analysis, confirmed by Ravi |

## ⚠ Serious issue SI-1: "Meet now" cannot ship as designed
F2 + F3 + I1 + I4 together mean the core of v1 (live, member-to-member location) is:
- blocked by policy, and
- conflicting with another in-flight PRD, and
- a safety risk, and
- dependent on infrastructure that doesn't exist (9–12 weeks).

**[REC]** Restructure around **Swap Spots**, the existing public venues from I2. Members pick a spot and a time slot instead of sharing positions. Check-in uses an on-device geofence and sends only `arrived: true`, so no coordinates leave the phone. This removes F2, F3, I1 and I4 at once and keeps F5 and F6.

**[DECISION]** Ana, week 4: restructure to v2 as recommended. Keep v1 as a superseded version. See `decision-log.md` DL-1.

## APIs that still need engineering definition (carried into v2)
- `spots.slots {spotId, day}`: slot capacity per venue (*needs eng definition*)
- `checkin.arrived {swapId}`: boolean only, geofence evaluated on the device