# Systemnamn-genomgång — Öppna tickets
> Pausad 2026-06-04 12:16 UTC. Erik fortsätter senare.
> Syfte: spika kanoniska definitioner av varje system, ett i taget.
> Fullständig kontext: `memory/2026-06-04.md`

## ✅ KLART (definitioner fastställda)
- **AAMOS** = huvudsystemet (som Microsoft). Nivåer: gratis → Pro → Ouroboros.
- **Homo Deus** = agentlager-TILLÄGG. Förtjänas genom användning, aktiveras per process.
- **Prismodell** = revenue-share-logik genom alla nivåer. Pro med lågt golv (300–500 kr/mån). Värdeestimat alltid källangivna.
- **quiXzoom** = "Uber för foton". Fristående brand, drivs internt via Ouroboros, betalar avgift uppåt till plattformen (beslut B).

---

## 🔴 TICKET #1 — quiXzoom avgiftsbas (GMV vs nettoomsättning)
**Status:** Väntar på Eriks beslut. Bernt rekommenderar B.
**Ramverk:** Klassisk marketplace-redovisning — agent vs principal (IFRS 15 / ASC 606).

**Fråga:** quiXzoom betalar plattformsavgift uppåt — på vilken bas?
- **(A)** 0,15% av GMV/total transaktionsvolym (hela flödet, 100 kr)
- **(B)** 0,15% av quiXzooms egen nettoomsättning = provisionen (15 kr)

**Magnitud:** Uppdrag 100 kr → A=0,15 kr (1,0% av quiXzooms intäkt) · B=0,0225 kr (0,15%). A ≈6,7× dyrare.

**Bernts utvärdering → rekommendation B:**
1. KONSEKVENS: Erik sa "behandlas som alla andra". Alla betalar på bokförd nettoomsättning. quiXzooms korrekta nettoomsättning ÄR provisionen (85 kr = pass-through, agentredovisning). A kräver specialregel.
2. IMPLEMENTERING: B sker automatiskt via SIE4-läsning (noll specialkod). A kräver separat GMV-läsare, bryter "bara din nettoomsättning"-löftet.
3. SKALBARHET (viktigast): Regeln blir mall för alla framtida marknadsplatser. En 3%-take-rate-marknadsplats på 0,15% GMV = 5% av verklig intäkt → dödar marketplace-adoption. B rättvist oavsett take rate.
4. MOTARG (A): infra-kostnad är volym- ej marginaldriven (fotolagring S3 tung). MEN löses av GOLVET, ej av A. Golv = kostnadstäckningsmekanism.

**Rekommendation (URSPRUNGLIG, B):** B + Ouroboros-golv. — REVIDERAD nedan.

### ERIK 2026-06-04 20:11 UTC — PRINCIPSKIFTE TILL FLÖDE (lutar A)
Erik: "Omsättningen avspeglar flödena genom plattformen och dess dataanvändning
tydligare än modellen som fokuserar på vinst. Systemet ska hantera serviceföretag
där vinstutfallet inte alltid går att garantera p.g.a. mänskliga faktorer som inte
finns vid mjukvaruförmedling."

**Eriks insikt (validerad av Bernt — starkare än ursprungligt B-argument):**
- FLÖDE + dataanvändning = sannaste proxyn för plattformsvärde/kostnad, INTE marginal.
- Samma logik som AWS/Stripe/Twilio: usage-based, ej vinst-based.
- KONSEKVENS-VÄNDNING: serviceföretag betalar 0,15% på hela flödet (100 kr) även om
  vinst bara 5 kr. Om quiXzoom bara betalar på 15 kr → quiXzoom behandlas MILDARE än
  serviceföretaget. A är alltså MER rättvist, inte mindre.
- Vinst oppålitlig bas (mänskliga faktorer). Flöde ärligt + universellt + manipuleringssäkert.

**REVIDERAD REKOMMENDATION: Flöde som universell bas (A-principen vinner).**
1. Standardbolag: omsättning = flöde → 0,15% (oförändrat, SIE4)
2. Marknadsplatser: mät GMV/transaktionsvolym (flödet), med KALIBRERAD sats så
   bördan blir rättvis oavsett take rate (löser lågmarginal-problemet utan att
   överge flödesprincipen — justera SATSEN, ej BASEN)
3. Riktning framåt: öppnar för ren data-/resursbaserad prissättning på sikt.

**Take-rate-känslighet (enda kvarvarande spänning):**
0,15% på GMV = 1,0% av revenue vid 15% take, men 5,0% vid 3% take → prohibitivt för lågmarginal.

### 🔴 NY ÖPPEN FRÅGA (Ticket #1b) — marknadsplatssats
För marknadsplatser, välj:
- (a) samma 0,15% rakt på GMV (enklast, hårdast mot lågmarginal)
- (b) lägre kalibrerad marknadsplatssats på GMV
- (c) uttalad transaktions-/datakomponent (per uppdrag + per GB lagrad foto)

### ERIK 2026-06-04 20:xx UTC — "DET SKA INTE MÄRKAS, SOM STRIPE, REALTID"
Avgiften ska dras kontinuerligt + osynligt UR flödet (som Stripe application_fee),
INTE summeras + presenteras som faktura. Avgiften lever I transaktionen.
=> #1b a/b/c handlar inte längre om SATS utan om LEVERANSMEKANISM.
quiXzoom = perfekt första fall: betalningar passerar redan vår Stripe-rail.
Impl: aktivera application_fee_amount i payments.mjs. Ett Stripe-anrop:
  85 kr zoomer / 14,85 kr quiXzoom / 0,15 kr Wavult (application_fee, auto).
quiXzoom ser bara nettoinsättning — plattformsandelen fanns aldrig på deras konto.

### ERIK 2026-06-04 21:01 UTC — HYBRID-BESLUT (LÅST)
"Vi måste bygga en hybrid. Låta folk ha sina egna system men vill att de ska
mer och mer in i plattformen."

**Två prismekanismer, samma flödesprincip:**
1. ON-PLATFORM (pengar passerar vår rail): realtids osynligt mikrodrag via
   Stripe application_fee. "Märks inte." quiXzoom + alla som betalar genom AAMOS.
2. OFF-PLATFORM (eget banksystem/eget Stripe): omsättnings-avläsning via SIE4
   (batch, märks mer). Serviceföretag med egen fakturering.

**Strategisk riktning:** Tvinga ingen (som Stripe). Gör on-platform-railen så
smidig att off-platform känns dumt. Gradvis migration in i plattformen = gradvis
övergång från "märks" till "märks inte". Själva prisupplevelsen blir en
uppgraderingsmotor (mindre friktion + lägre/osynlig avgift on-platform).

### 🔴 KVARVARANDE FRÅGOR (Ticket #1c)
- On-platform mikrodragssats: 0,15% rakt, eller kalibrerad per flödestyp?
- Är on-platform-avgiften LÄGRE än off-platform (explicit morot att migrera in)?
- Lagringstung komponent (per GB foto) — separat rad eller inbakat?
- Golv: gäller golvet även rena on-platform-mikrodrags-kunder?

**Varför det spelar roll:** Mall för ALLA framtida produkter/marknadsplatser +
styr hela prissättningsfilosofin (usage/data-based, hybrid on/off-platform).
Påverkar payments.mjs (application_fee), aamos-ledger billing, revenue-sync, SIE4.

---

## 🟡 TICKET #2 — LandveX definition
**Status:** Ej påbörjad
**Att spika:**
- Vad är LandveX i Eriks egna ord? (en mening, som "Uber för foton")
- Fristående brand eller modul? Egen affär eller del av annat?
- Vem är kunden? (kommuner/stat/infrastrukturägare antaget men ej bekräftat)
- Drivs den internt via Ouroboros som quiXzoom, eller säljs den ut?

---

## 🟡 TICKET #3 — Relationen LandveX ↔ quiXzoom
**Status:** Ej påbörjad
**Att spika:**
- LandveX detekterar anomali → skapar quiXzoom-uppdrag. Bekräfta att detta är rätt flöde.
- Betalar LandveX för quiXzoom-uppdragen, eller är det LandveX-kunden som betalar?
- Vem äger relationen mot slutkunden — LandveX eller quiXzoom?
- Ekonomiskt: hur delas intäkten när ett LandveX-triggat uppdrag utförs av en zoomer?

---

## 🟡 TICKET #4 — Återstående system att definiera
**Status:** Ej påbörjad. Spika ett i taget, samma metod.
- **AAMOS Platform** (teknisk term) — behålla internt eller skrota? (frågan ställd, ej besvarad)
- **LandveX** undervarumärken? (sett i Route53: landvex-gov.eu, landvex-secure.com, landvex-intelligence.eu, landvex-infrastructure.eu — är dessa separata produkter eller bara domän-skydd?)
- **VYRA** — nämnd i gammal memory som "fysisk FPS-plattform". Fortf. aktuell? Definition?
- **AAMOS Pro vs Ouroboros modul-gränser** — vilka moduler låses upp på vilken nivå?

---

## 🟢 TICKET #5 — Uppdatera MEMORY.md efter genomgång
**Status:** Görs när alla definitioner är spikade
**Att göra:**
- Skriv om produktarkitektur-sektionen i MEMORY.md med de NYA kanoniska definitionerna
- Ta bort/korrigera gamla felaktiga beskrivningar (Homo Deus som "ISO-regelverk", Ouroboros-def m.m.)
- Uppdatera ekonomisk karta (`economic-flow.html`) med korrekt quiXzoom-avgiftsbas
- Uppdatera system-status-presentationen med korrekta definitioner

---

## Metod (så vi kör konsekvent)
1. Ett system i taget
2. Erik beskriver i egna ord → Bernt speglar tillbaka
3. Bernt ställer skarpa följdfrågor på oklarheter (särskilt ekonomi/gränser)
4. Logga beslut i `memory/YYYY-MM-DD.md` direkt
5. När allt klart → uppdatera MEMORY.md + kartor + presentationer

---

## 🎯 AI-ORKESTRERING #1c (2026-06-04 ~22:00 UTC, Bernt = dirigent)
3 oberoende modeller via AAMOS-router. **FLAGGA: Grok slut på krediter — fyll på XAI_API_KEY.**
- PROGNOS: o3 · OMVÄRLD: Perplexity sonar-pro · KREATIV: gpt-4o (gpt-5.5-pro hängde >20min, ej använd)

**KONVERGENS — alla röster överens på alla 4 frågor:**
1. **On-platform-sats:** Fast 0,15% standard (o3: enkelhet + EU-DMA-risk slår differentiering). Kalibrera endast vid bevisat behov.
2. **On-platform LÄGRE än off:** JA (enhälligt). 0,12% on / 0,15% off (~20% rabatt). o3-prognos: +240 MSEK 10-års NPV, on-platform-andel 57%→74%.
3. **Lagring:** SEPARAT GB-rad (enhälligt). ~0,09 SEK/GB-mån. Skyddar flödesprincip, möjliggör AWS volume-deals.
4. **Golv:** SLOPA för rena on-platform-kunder (enhälligt). Behåll off-platform/hybrid. Ersätt med minsta-debit/tx. o3: +110 MSEK NPV (småkunder växer IN i golvet).

**o3 central prognos (Flow+-modell):** plattformsandel 10%→78% (2035), ARR 45→690 MSEK, bruttomarginal 57%→66%, värdering ~6,9 md SEK (2035).

**KREATIVA HÄVSTÄNGER (gpt-4o, utöver #1c):**
- **Embedded Capital-as-a-Service** — realtids cash-flow-syn → rörelsekrediter/factoring. Marginal >2% = 10-20× större än 0,15%. STÖRSTA outnyttjade möjligheten.
- **Flow Credits** — avgift → credits inlösbara i nya moduler = säljdrivande, sänker churn.
- **Data Gravity** — rabatterad lagring så länge data stannar i AAMOS; premium vid bulk-export.
- **"AAMOS Tax"** på 3:e-parts-marknadsplats (som AWS-tax) = svår att replikera.
- gpt-5.5-pro nyckelinsikt: "inte avgiftsnivån utan VAR i flödet avgiften tas ut — små ändringar i konvertering/timing/flödesdefinition multipliceras över hela volymen."

**DOLDA RISKER (gpt-4o):**
- Ultralågmarginalhandel: 0,15% kan vara >10% av nettovinst → marginalkänslighetsfilter (auto-nedväxling <3% bruttomarginal).
- Flow-maskering i bokföring → triangulera bank-feed+moms+Peppol + ToS-penalty.
- Regulatorisk: realtids application_fee kan kräva PI/EMI-licens i EU → EMI-partner/sandbox.
- Vertikal bypass (fotograf bygger egen Stripe Connect) → bind hårt till AI/lagrings-API.

**STATUS:** Beslutsunderlag komplett. Väntar Eriks slutgiltiga ja på #1c (1-4).
Fullständiga utlåtanden: /tmp/fast_two_results.json + /tmp/orchestrate_results.json