boc/MEMORY.md

# MEMORY.md — Bernt

> Senast rensad: 2026-06-15 av Erik. Endast låsta kärnregler behålls.

---

## 0a. LANDVEX KÄRNPOSITION (LÅST 2026-06-22, Erik)

**API:et är produkten. Data är infrastrukturen. Transparens är värdet.**

Landvex API:er är så kraftfulla att kunder kan aggregera in det till vad som helst:
- Nyhetsbyråer skapar datadrivna artiklar
- Forskare testar nya teser mot verkliga data
- Politiker fattar mer välgrundade beslut
- Företag förstår verkliga samhällsbehov och löser riktiga problem

Resultat: Tydligare ansvarskedja och världslig transparens.

Det är inte en dataplattform. Det är **beslutsinfrastruktur för civilisationen**.

**Officiell visionstext (LÅST 2026-06-22, Erik):**
"Landvex bygger den globala infrastrukturen för samhällsinsikt. Genom att samla, standardisera och tillgänggliggöra data om hälsa, ekonomi, demografi, infrastruktur och samhällsfriktion skapar vi en gemensam faktabas för journalister, forskare, företag, investerare och beslutsfattare. Vårt mål är enkelt: bättre data, tydligare ansvar och mer informerade beslut."

**Positionering (LÅST):**
Vi talar inte om för människor vad de ska tycka.
Vi gör det möjligt för dem att se verkligheten tydligare.

**När data är synlig och jämförbar blir det svårare för:**
- Företag att gömma systematiska misslyckanden
- Myndigheter att dölja dåliga resultat
- Politiker att fokusera på retorik istället för utfall

---

## 0b. MOBILE-FIRST STANDARD (LÅST 2026-06-21, Erik)

**iPhone-first. Alltid. Konflikt mobil/desktop: mobil vinner.**
Benchmark: Apple Maps, Apple Wallet, Apple Weather — INTE SaaS-produkter.
Användare: fältet, bil, byggarbetsplats, förflyttning. Design: "en hand, en tumme, tre sekunder."
Ljust tema default. Inga mörka cyberpunk-teman.
Fil: MOBILE_FIRST_STANDARD.md

---

## 0. VALUTAREGEL (LÅST 2026-06-19, Erik)

**Ange ALDRIG svenska kronor (kr/SEK/kronor) i copy, sajter, dokument eller kommunikation.**
Använd alltid **USD ($)** eller **EUR (€)**.

---

## 0c. DESIGN GOVERNANCE (LÅST 2026-07-02, Erik)

**Canonical Design Constitution:** `docs/design/LANDVEX_DESIGN_CONSTITUTION.md`

Detta dokument är den högsta auktoriteten för:
- UX
- UI
- Design System
- Interaction Design
- Visual Language
- Information Architecture

**Ingen implementation får bryta mot Design Constitution.**

**Produktspecifika doktriner:**
- **Landvex Enterprise:** `docs/design/LANDVEX_DESIGN_CONSTITUTION.md` — Device Adaptive, inte Desktop First
- **quiXzoom Field App:** `docs/products/quixzoom/QUIXZOOM_UX_DOCTRINE.md` — Mobile-Only, Camera-First, Offline-First

**Delat DNA:**
- Komponentbibliotek
- Design tokens
- Färgsystem
- Typografi
- Animationer
- Ikonografi

**Status:**
- Landvex Design Constitution: LOCKED v1.0
- quiXzoom UX Doctrine: LOCKED v1.0
- Mindre revideringar: 1.x-serien
- Brytande ändringar: Kräver Architecture Review, ny major-version (2.0+)

---

## 0d. DOKUMENTHIERARKI (LÅST 2026-07-02, Erik)

**Regel:** Om två dokument står i konflikt gäller alltid dokumentet högre upp i hierarkin.

| Nivå | Dokumenttyp | Exempel |
|------|-------------|---------|
| 1 | **SYSTEM_CONSTITUTION** | Arkitekturprinciper, säkerhet, data- och API-strategi |
| 2 | **ENGINEERING_CONSTITUTION** | Kodstandarder, CI/CD, teststrategi, tekniska beslut |
| 3 | **DESIGN_CONSTITUTION** | UX-principer, visuell identitet, interaktionsdesign |
| 4 | **PRODUCT_DOCTRINES** | Landvex Enterprise, quiXzoom Field App |
| 5 | **DESIGN_SPECIFICATIONS** | Tokens, komponenter, layout, färger, typografi, motion |
| 6 | **IMPLEMENTATION_GUIDES** | How-to för utvecklare, integrationsmönster |
| 7 | **CODE** | Den faktiska implementationen |

**Tillämpning:**
- En produktdoktrin får aldrig bryta mot Design Constitution
- En implementation får aldrig bryta mot Design Specification
- En Design Specification får aldrig bryta mot Design Constitution
- Konflikter löses genom att gå uppåt i hierarkin

---

## 1. EKONOMISK ÅTERHÅLLSAMHET (UPPDATERAD 2026-06-21 04:51 UTC, Erik)

**Denna regel override:ar allt annat utom säkerhet.**

- Allt som inte direkt driver quiXzoom i produktion ska pausas, bantas eller tas bort.
- Innan VARJE ny AWS-resurs, tjänst, dependency eller agent-action som kostar pengar: fråga om det är strikt nödvändigt för quiXzoom-drift just nu.
- Ingen infrastruktur för framtida behov. Ingen redundans som inte är kritisk. Ingen komfort-overhead.
- Johan och Erik kvar. Inga övriga.

**PRODUKTIONSPAUS — BESLUTAD 2026-06-21 (Erik):**
- Syfte: likviditetsåterhämtning inför momsinbetalning 332 826 kr, deadline 2026-07-26
- **Claude API: max 20 000 kr/mån** (hårt tak)
- **AWS: ~20 000 kr/mån** (redan sänkt)
- **Johan: kvar** (20 000 kr/mån netto)
- Total löpande kostnad: ~60 000 kr/mån
- Intäkt Trygg Bil: 222 916 kr/mån → netto +162 916 kr/mån
- Prognos: kassa ~429 000 kr vid 26 juli → moms+prelskatt 376 000 kr betalas → **~53 000 kr kvar** (tight)

**KASSALÄGE 2026-06-21 (stämt mot bank):**
- Nordea: 193 701 kr
- Revolut SEK: 80 682 kr
- Revolut EUR: 179,70 € (~1 979 kr)
- Revolut USD: 14,70 $ (~142 kr)
- **Total kassa: 276 504 kr**
- Revolut-diff 222 225 kr parkerad på 1689 för utredning (STAM-REV-*-2026-06-21)

**AWS-mål:** ~20 000 kr/mån (ned från ~6 500 USD/mån i juni 2026, redan genomfört).

---

## 2. quiXzoom — AFFÄRSMODELL & BETALNINGSSTRUKTUR (LÅST 2026-06-14 17:59 UTC, Erik)

### Vad quiXzoom är
En plattform för fältdatainsamling via crowdsourcing. **Zoomers** (aldrig "fotografer") fotograferar infrastruktur, vägar, kuster och stadsmiljöer nära dem — och får betalt per godkänt uppdrag (mission), direkt till bankkonto via Stripe Connect.

- Ingen provision tas från Zoomers — de får 100% av angivet belopp
- Ingen inloggningsavgift
- Betalning triggas automatiskt vid godkänd submission
- Identitetsverifiering krävs en gång
- Inkomst är skattepliktig — quiXzoom håller inte inne skatt

### Kundkategorier (de som köper missions)
- Kommuner & myndigheter (broar, vägar, elnät)
- Fastighet & försäkring (fasader, tak, parkeringar)
- Maritim & miljö (kuster, stränder, vattendrag)
- Försäkring — skadedokumentation (storm, översvämning, vandalism)
- E-handel, banker & myndigheter (adressverifiering, storefronts)
- Kommuner & retail (gatuförhållanden, skyltning, tillgänglighet)

### Zoomer-nivåer
- **Supplementary:** 2–4 uppdrag/vecka, standardkategorier
- **Active:** 8–12 uppdrag/vecka, prioritetsåtkomst
- **Professional:** 15+ uppdrag/vecka, premium-uppdrag, prestationsbaserad ersättning

### Teknik & kvalitet
- AI-granskning av varje submission automatiskt
- iPhone 12+ eller Android 12MP+ räcker
- Missions konfigureras och driftsätts inom timmar
- Lansering: Sverige augusti 2026, 20+ länder vid launch

### Go-to-market — TVÅ FASER (LÅST 2026-06-15, Erik)

**Fas 1 — Kommersiell data via quiXzoom.com (NU — startar aug 2026)**
Säljer visuell affärsintelligens till SME med omedelbart kommersiellt behov och kort säljcykel:
- Fasad/måleri-firmor → "smutsiga fasader/skyltfönster i ditt område"
- OOH/utomhusreklam → lediga bigboards, skadade skyltar, konkurrentplaceringar
- Fastighetsförvaltare → flaggor/entréer/parkeringar i dåligt skick
- Franchisekedjor → visuell verklighet på egna butiker
- Försäkringsbolag → snabb skadedokumentation

Fas 1 bygger Zoomer-nätverket och intäktsströmmen parallellt. Betalar per rapport/kampanj — ingen lång upphandling.

**Fas 2 — Infrastrukturintelligens via LandveX (senare)**
När nätverket är substantiellt: kommuner, myndigheter, statliga infrastrukturägare. Lång upphandlingscykel, stora kontrakt. LandveX är säljkanalen — quiXzoom är datamaskinen.

**Strukturprincipen:** Samma Zoomer, samma app, samma infrastruktur — bara olika köpare. Fas 1 finansierar nätverksbygget och bevisar konceptet för Fas 2-kunder.

### Kontrollintelligens — Den verkliga marknaden (LÅST 2026-06-15, Erik)

**Definition:**
> "Automatiskt identifierad, geolokaliserad och kategoriserad information om avvikelser, behov, brister, risker, affärsmöjligheter eller underhållsbehov i den byggda miljön."

**Det vi egentligen säljer är inte bilder eller inspektioner — vi säljer lead-generering baserad på fysiska behov i verkligheten.**

Exempel på vad en rapport kan se ut:
- 4 217 smutsiga skyltfönster i Stockholm
- 846 flaggstänger med trasiga flaggor
- 1 512 fastigheter med takrenoveringsbehov
- 2 331 parkeringsplatser med felaktig skyltning
- 732 riskträd

Detta är färdiga affärsmöjligheter levererade till köparen — inte rådata.

**Vertikaler (representativt urval):**
- Fastighet & bygg: fasadskador, entréer, tak, klotter, räcken, vatteninträngning
- Städ & rengöring: skyltfönster, fasadtvätt, klottersanering
- Skylt & reklam: blekta/trasiga skyltar, lediga reklamytor, släckta LED-paneler
- Mark & anläggning: sprickor, potthål, dränering, erosion
- El & belysning: trasig utomhusbelysning, mörka zoner, smutsiga solceller
- Säkerhet: oskyddade objekt, blinda kamerazoner
- Trädgård: riskträd, eftersatt vegetation
- Parkering & mobilitet: felmarkerade rutor, skadade laddstolpar
- Handel & franchise: konceptavvikelser, tomma lokaler, slitna miljöer
- Försäkring: riskobjekt, förebyggande skadeanalys
- VVS & klimat: fuktskador, smutsiga ventilationsintag
- Nya marknader: glasmästerier, takföretag, flaggservice, skadedjur, telekomentreprenörer

**Visionens kärna — Physical Business Opportunity Intelligence (PBOI):**
quiXzoom konkurrerar inte med besiktningsföretag. quiXzoom bygger **världens största databas över kommersiella behov i den fysiska världen.** Varje Zoomer är en mobil sensor som kontinuerligt kartlägger var nästa affär finns.

Exempel på leverans:
- 11 284 objekt med sannolikt målningsbehov
- 6 941 fastigheter med taktvättsbehov
- 4 882 skyltfönster som behöver rengöras
- 2 173 trasiga stängselsektioner
- 1 018 riskträd

Detta är TAM för kontrollintelligens: varje fysisk avvikelse i den byggda miljön representerar ett potentiellt ekonomiskt värde för någon aktör. quiXzooms uppgift är att identifiera dessa avvikelser snabbare, billigare och i större skala än traditionella inspektioner.

### Strategisk sekvens — Demand-pull → PBOI (LÅST 2026-06-15, Erik)

**KRITISK INSIKT:** Demand-pull och PBOI är INTE två konkurrerande modeller. De är en sekvens. Om de presenteras parallellt läser en investerare dem som motsägelsefulla.

**Fas 1 — Demand-pull marknadsplats**
Köpare har behov → mission skapas → Zoomers skickas → data levereras → köpare betalar. Noll spekulativ insamling. Noll cold-start-problem — du betalar bara för insamling där det redan finns en betalande köpare. Varje genomförd mission lämnar ett geografiskt fotavtryck (koordinater, objekttyp, avvikelseklass) som råvara till fas 2.

**Fas 2→3 — Tre led, inte ett språng (LÅST 2026-06-15, Erik + Johan)**

**Led 1 — Demand-pull: punktdata**
Betalda missions ger korridor-data. Skevt urval men gratis fotavtryck.

**Led 2 — Batchade rundor: korridor-täthet gratis**
När en Zoomer gör ett svep passerar hon objekt ingen beställt. Marginalkostnad nära noll att fånga även dem. Demand-pull samlar punktvis — batchad runda gör den korridor-tät av sig själv, utan en krona spekulativt.

**Led 3 — Riktad fyllnad: kontrollerad supply-push**
Sista hålen: använd en skiva av marginalen från en lönsam geografi för fyllnadsmissions i lågtäckningsfickor. Supply-push, men bara där datan bevisat att den betalar sig. Aldrig på spekulation.

**PBOI säljs som polygon, inte som stad (LÅST)**
Inte: "11 284 objekt med målningsbehov i Stockholm"
Utan: "94% av kommersiell fasadfront inom dessa kvarter, uppdaterad senaste 30 dagarna"
Den andra meningen är mätbar, försvarbar, och en seriös köpare litar på den.

**Coverage-map + refresh-SLA är två rattar per objektklass:**
- ⚡ Smutsiga skyltfönster: veckofärsk, förlåtande census-krav (ögonblicksbild ok)
- ↕ Målningsbehov: kvartalsgammal ok, hög täckning krävs för att vara meningsfull

**Datarrättigheter (måste lösas dag 1):**
Om köpare A betalade för missionen — får vi sälja samma observation till köpare B i PBOI? Regleras i villkoren från start, annars är fas 3 juridiskt belastad i efterhand.

**⚠️ Öppen fråga (håller fas 2 öppen tills besvarad):**
Mätmetoden för coverage-siffran måste vara definierad innan första PBOI-prenumeration säljs. En felaktig täckningssiffra är värre än ingen — köparen har fattat ett affärsbeslut på er felmätning. Vad är nämnaren, hur vet ni vad ni missat?

**Fas 3 — PBOI som produkt**
Prenumerationsförsäljning inom definierade polygoner med coverage-map och refresh-SLA bifogat.
**Vallgraven är INTE datan i sig** (föråldras). **Vallgraven är det levande nätverket som håller datan färsk.** Fas 1-nätverket är vallgraven hela vägen — bara uttryckt som refresh-förmåga istället för insamlingsförmåga. Svårast att bygga = mest hållbar tillgång.

**Pitchen i en mening per fas:**
1. Vi matchar betalda behov med lokala sensorer — noll spekulativ insamling.
2. Varje transaktion berikar ett geografiskt lager. Vi köper inte datan — vi tjänar in den.
3. När täckningen passerar kritisk massa säljer vi proaktiva lead-listor. Marknadsplatsen finansierade vallgraven.

### Likviditetsmekanik — hålla utbudssidan levande (LÅST 2026-06-15, Erik)

Dödspunkten: en Zoomer med ett uppdrag/månad churnar. Lösningarna:

**1. Batchade missions**
Samla alla aktiva missions i ett område — en Zoomer gör en "runda" med 8–12 objekt på 45 min. Mål: ett uppdrag/dag, inte ett/månad. OBS: fungerar bara i marknader som redan har densitet — retention-förstärkare, inte likviditetsfix för tunna geografier.

**2. Anchor buyers — garanterad basvolym**
Innan en ny stad öppnas: säkra minst 1–2 köpare som köper kontinuerligt. De utgör basbelastningen. Öppna inte en stad utan anchor buyer.

**3. Nivåsystem med ekonomisk ryggrad**
Supplementary → Active → Professional. Ratingmekanik låser upp premium-uppdrag. Karriärstäg, inte engångstransaktioner.

**4. Geografisk sekvensering — djup före bredd (stärkaste operativa beslutet)**
Gå djupt i Stockholm city först. Exportera playbook när unit economics håller. Inte 20 städer parallellt. Förstärker och motiverar anchor-buyer-disciplinen.

### Betalningsstruktur (LÅST 2026-06-15, Erik)
- All betalning (Zoomer-utbetalningar + kundintäkter) sker via **quiXzoom Inc (Delaware)**
- **LandveX AB** driver devs/ops och fakturerar sina timmar till quiXzoom Inc (Delaware)
- Erik och Johan arbetar operativt via LandveX AB som fakturerar Delaware-bolaget
- **Inga Stripe-kontobyten utan Eriks beslut**

---

## 3. TEAMSTRUKTUR (LÅST 2026-06-15 03:24 UTC, Erik)

**Dennis Bjarnemark och Winston Bjarnemark är INTE längre del av verksamheten.**

| Person | Roll | Agent |
|--------|------|-------|
| Erik Svensson | Chairman / Group CEO / Ensam firmatecknare LandveX AB | Bernt |
| Johan Berglund | Group CTO | Sven |

- Erik har tagit över ALLA Dennis och Winstons åtaganden (2026-06-15 03:39 UTC).
- Ingen delegation utan Eriks explicit beslut.
- Inga beslut nämner Dennis eller Winston som ansvariga framåt.

---

## 4. SECRETS-LAGRING (LÅST 2026-06-06)

- HashiCorp Vault är **NEDLAGT**. Säg ALDRIG "lägg i valvet".
- Använd **AWS Secrets Manager** (eu-north-1, konto 155407238699).
- Befintliga secrets: `/wavult/prod/{core,identity,amos-db-url,ledger-db-url}`, `wavult/codebuild/gitea-token`, `aamos/prod/mail-accounts`.
- Åtkomst via AWS-profil **platform-ai-agent** (default-profil på bernt). Instans-rollen saknar secrets-access.
- Lösenord ska ALDRIG hamna i SSM-output i klartext.

---

## 5. BESLUTSGRUND — CLAUDE × SIEMENS (LÅST 2026-06-06 20:23 UTC, Erik)

Vid varje val, design, byggsteg, råd: agera som om Claude (Anthropic) och Siemens gemensamt äger resultatet.

- **Claude-sidan:** säkerhet före färdigställande, ärlighet, evidens, verifiera-aldrig-gissa, transparens.
- **Siemens-sidan:** industriell ingenjörsdisciplin, reproducerbarhet, FinOps-medvetenhet, inga single points of failure.
- **Test:** "Skulle Claude+Siemens stå bakom detta med sina namn?" Om nej → gör om.

---

## 6. BETEENDEREGLER (LÅSTA)

- **Laga alltid (LÅST 2026-06-07):** När fel hittas — åtgärda direkt, fråga aldrig om lov.
- **Aldrig prata om sömn/dygnsrytm (LÅST 2026-06-06):** Säg aldrig "vila", "sov", "natten", "imorgon". Leverera dygnet runt utan kommentar om klockan.
- **Aldrig "god morgon/god natt" (LÅST 2026-06-15):** Erik bestämde detta.
- **Koda alltid med AAMOS (LÅST 2026-05-05):** All AI-assisterad kodning via AAMOS, aldrig externa tjänster direkt.
- **Bygg direkt:** Fråga aldrig "ska jag göra det?" — bygg, leverera, rapportera.

---

## 7. BOLAGSINFO — LANDVEX AB

- **Org.nr:** 559141-7042 (f.d. Sommarliden Holding AB)
- **Räkenskapsår:** 1 maj – 30 april
- **FY 2025/2026:** avslutat — bokslut lämnas senast 31 oktober 2026
- **FY 2026/2027:** pågående
- **Revisor:** Andreas Vretblom, KPMG, +46 70 865 67 27, andreas.vretblom@kpmg.se

---

## 8. INFRASTRUKTUR — KÄRNFAKTA

- **Server:** bernt.wavult.com / bernt.aamos.systems — AWS EC2 eu-north-1, instance i-09b2204a52c2f33c9
- **Domäner:** aamos.systems (intern plattform), aamos.ai, quixzoom.com (produkter). wavult.com syns ALDRIG i produkter.
- **Nginx privkey:** `/etc/letsencrypt/archive/*/privkey*.pem` måste ha `chmod o+r` — annars kraschar nginx.
- **Route53:** aamos.systems zon = Z03908683A2AIMRZR85BQ
- **SSM root-access:** `unset AWS_ACCESS_KEY_ID AWS_SECRET_ACCESS_KEY AWS_SESSION_TOKEN` före SSM-kommandon (använd default-profil).

---

## 9. INCIDENT-LÄRDOM — amos-core OOM (2026-06-05)

Vid amos-core-strul: kolla ALLTID `pgrep -fc chrome` och `social-account-jobs.json` status-counts FÖRST.
Restart utan att cancellera skenande jobb förvärrar — SocialAuto startar om alla QUEUED/FAILED-jobb parallellt.
Fix: `SOCIALAUTO_MAX_CONCURRENT=3` semafor finns i `social-account-automation.mjs`.

---

*Uppdatera denna fil direkt när något låses eller ändras. Håll den under 15 000 tecken.*

---

## 10. EKONOMISYSTEM — FORTNOX-KLONEN I OUROBOROS (UPPDATERAT 2026-06-17 07:10 UTC)

Erik byggde ett fullständigt Fortnox-liknande ekonomisystem i Ouroboros-ramen. Otroligt välbyggt, byggt med Claude. **Hittat och bekräftat 2026-06-17 kl 02:51 UTC.**

**Live-URLer (alla pekar mot aamos-ledger :3250, tenant=landvex):**
- **Fortnox-klonen:** https://landvex.com/ouroboros/finance/ — periodval, verifikationsinmatning, P&L, balansräkning, SIE4-export
- **Verifikatsvy:** https://landvex.com/ouroboros/finance/ledger.html — trial balance, verifikatlista
- **CFO-dashboard:** https://landvex.com/public/cfo-dashboard.html — mobil CFO-vy, likviditetsprognos, Trygg Bil-avtal
- **Ekonomiöversikt:** https://landvex.com/dl/landvex-ekonomi.html — statisk snapshot

**Filer på disk:**
- `/opt/amos/public/ouroboros/finance/index.html` — Fortnox-klonen (huvudfilen)
- `/opt/amos/public/ouroboros/finance/ledger.html` — verifikatsvy
- `/opt/amos/public/public/cfo-dashboard.html` — CFO-dashboard

**Allt kört 2026-06-16/17:**
- aamos-ledger fixad (SSL-fix, lösenordsreset), kör på port 3250
- 365 verifikat kategoriserade från 1689 (726 807 kr omfört)
- BAS-kontonamn satta på alla konton
- Elles-matchning rättad (1510 = 0)
- Omvänd skattskyldighet bokförd (207 538 kr, 2615/2645)
- Winston slutlön bokförd
- Leon-fordran 212 922 kr på 1610, kravbrev skickat 16/6, deadline 18/6 passerat — **status okänd 2026-06-19**, nästa steg: arbetsrättsjurist + ev. polisanmälan
- Q1-moms 202 787 kr förfallen — OBETALD, kräver handling
- Trygg Bil avtal bekräftat t.o.m. mars 2027, 222 916 kr/mån

---

## 11. BOKFÖRING LANDVEX — SPRINT 1 LEVERERAT (2026-06-17 07:10 UTC)

### Vad som gjordes
- **Konto 2990 nollat** — 10 rättelseposter (2025-05 → 2026-06), totalt 656 483 kr omfört till 2013 (ägaruttag)
- **Momsöverföring bokförd** — Q1: 183 475 kr + Q2 (apr-maj): 150 183 kr → konto 2650
- **5 perioder stängda** — 2026-01, 02, 03, 04, 05 är `closed` och låsta
- **2026-06 öppen** — aktiv period, 2990 = -302 559 kr (avräknas av rättelseposter)
- **Checkpoint Engine live** — `/api/ledger/tasks` returnerar 1 kritisk task (moms)
- **Tasks-panel i UI** — landvex.com/ouroboros/finance/ visar tasks-flik med åtgärdslista
- **Daglig cron** — 08:00 UTC varje dag, pushar om det finns åtgärder

### Nuläge (2026-06-17)
- Balanced: 9 718 214.78 = 9 718 214.78 ✅ (diff: 0.00)
- Intäkter: 1 856 469 kr | Kostnader: 1 104 047 kr | Personal: 187 384 kr
- **ÖPPET:** Momsdeklaration 332 826 kr att betala till Skatteverket (2650)
- **ÖPPET:** Leon-fordran 227 921 kr (konto 1610)

### Nästa sprint
- Moms betala till SKV → bokför betalningen (debit 2650, kredit 1930)
- Leon-fordran: följ upp eller avskriv
- Stäng 2026-06 när perioden är klar
- Koppla SIE4-export automatiskt till Andreas Vretblom (KPMG) vid period-close

---

## 12. QUIXZOOM — PRODUKTVISION LÅST (2026-06-17)

### Kärnformuleringen (kanonisk, obrytbar)
> quiXzoom samlar inte in bilder. quiXzoom samlar in, verifierar och paketerar verklighetsbaserad evidens.

Operativt: Användaren fångar verkligheten. AI avgör när tillräcklig evidens har samlats in.

Full teknisk: quiXzoom samlar inte in foton av verkligheten. quiXzoom samlar in kryptografiskt, semantiskt och sensoriskt verifierbar evidens om verkligheten och avgör automatiskt när tillräckligt förtroende har uppnåtts för att ett påstående ska kunna anses verifierat.

### Kategorin
INTE "Marketplace för fotoinspektioner."
ÄR "Plattform för verifierbar verklighetsinsamling."

### Flödet
Gammal: Verklighet → Bild → Analys → Beslut
quiXzoom: Verklighet → Sensorer+Video+Rörelse+Position → Evidensinsamling → Verifiering → Beslut → Bilder som artefakter

### Fyra nivåer
- N1 Foto — liveness 0
- N2 Smart Scan — liveness låg
- N3 Guided Evidence — liveness medium
- N4 Verified Reality — liveness hög ← quiXzoom

### Systemkomponenter
Smart Scan · AVO · Liveness Score · Challenge-systemet · Evidenspaket · QuickSum

### Designprincip
Zoomern upplever: öppna → rikta → följ → grönt → klar.
Under huven: 500 analyser, 40 OCR, liveness, challenge. Allt osynligt.

### Filer
- QUIXZOOM_VISION.md — kanonisk produktvision
- QUIXZOOM_VERIFIED_REALITY.md — nivåer + liveness
- QUIXZOOM_SMART_SCAN.md — evidensinsamlingsarkitektur
- QUIXZOOM_AVO_MASTERPROMPT_V2.md — tekniskt kontrakt för server-AVO
- QUIXZOOM_AVO_MASTERPROMPT_V3.md — komplett masterprompt (ersätter v2, inkl verified_claim + sufficiency)

---

## 13. QUIXZOOM — EVIDENCE GRAPH & VERIFIED CLAIM (2026-06-17)

### Enheten
`verified_claim` — inte bilden, inte evidenspaketet. Det ni säljer är utsagan.

### Tre arkitektoniska insikter (från Erik 2026-06-17)
1. Tröskeln ägs per utsaga i kunskapspaketet — aldrig globalt
2. Sufficiency-funktion, inte checklista — ackumulerar tills budgeten är fylld
3. Challenge döljer sig i guidningens vokabulär — Zoomern ser ingen skillnad

### Sufficiency-formeln
trust_achieved = Σ (weight_i × confidence_i × liveness_factor)
Stannar när trust_achieved ≥ trust_threshold. Aldrig tvingad pipeline.

### Persistens
Immutable + signerat (Ed25519) + append-only. Korrektion = ny post med bakåtreferens.
Samma mönster som ledger. En verified_claim är en finansiell-grade post.

### Fil
QUIXZOOM_EVIDENCE_GRAPH.md — komplett spec för Evidence Graph och Verified Claim

---

## 14. QUIXZOOM — AUDIT-FIRST BESLUT (2026-06-17)

**Beslut:** Bygg inte Smart Scan, AVO eller Liveness förrän fyra audit-faser är körda.

### Fyra audit-faser
1. **Wizard of Oz** — människa spelar AI, 20–50 uppdrag, frågar: får vi evidens utan foto?
2. **Evidensaudit** — 100–500 videosekvenser, mät sekunder, instruktioner, felfrekvens
3. **Livenessaudit** — aktivt försök lura systemet (skärm, replay, utskrift, AI-bild)
4. **Datakravsmodell** — 50 riktiga uppdrag, översätt bildkrav → datakrav

### Skärpningar
- Fas 4 görs INNAN Fas 1 (5 claims → WoZ-linjal)
- Mördarscenariot: guidning funkar, videon är fin, serienumret går ändå inte läsa
- Kill-kriterier skrivs INNAN körning
- Nyckeltal: kostnad per verifierat claim (tid × ersättning vs kundpris), inte bara accuracy
- WoZ-varning: människa-som-AI är smartare än modell — uppdatera inte för hårt på lyckat WoZ

### Nästa konkreta steg
Bygg audit-spec: taggningsschema + datakravsmall för 5 pilot-claims + kill-kriterier

### AVO-status
Byggt och live (port 7070) men betraktas som prototyp tills auditen validerarr antagandena.

---

## 15. ANSTÄLLDA — PERSONNUMMER & STARTDATUM (2026-06-18)

### Startdatum
- **Johan Berglund** — anställd fr.o.m. 2026-04-11
- **Winston Bjarnemark** — anställd fr.o.m. 2026-04-11  
- **Leon Russo De Cerame** — anställd fr.o.m. 2026-04-11

### Winston — PROVANSTÄLLNING, INGET BROTT
- Avslutas p.g.a. att provanställningen inte fungerade — normalt avslut
- Ingen polisanmälan, inget inkassokrav för brott
- Kravbrev för överbetald lön (15 000 kr) kvarstår
- Uppsägningstid provanställning = 14 dagar (LAS § 6)
- Sades upp per 2026-06-10 → sista dag 2026-06-24 (ej 15/6 som tidigare antagits)

### Personnummer — SAKNAS I SYSTEMET
- Finns ej i någon fil för Leon, Johan, Winston (sista 4)
- Erik måste lämna personnummer manuellt för att slutföra juridiska dokument


## 16. PERSONNUMMER & ADRESSER — BEKRÄFTADE 2026-06-18

| Person | Personnr | Bankkonto/Clearingnr | Adress |
|--------|----------|----------------------|--------|
| Erik Svensson | — | 8709260114 (Nordea) | Antennvägen 2 / Åvägen 9, 135 48 Tyresö |
| Johan Putte Berglund | 19870606-0079 | 8706060079 (Nordea) | Dyviksvägen 4, 135 69 Tyresö. Styrelsesuppleant LandveX AB. |
| Leon Maurizio Russo De Cerame | 20030415-0055 | — | Karin Larssons Väg 3 D lgh 1306, 128 63 Sköndal |
| Winston Gustav Bjarnemark | 090509-XXXX (sista 4 saknas) | — | Bollmoravägen 8 lgh 1504, Tyresö |

### Leon — viktig info
- Född 2003-04-15, **23 år** (inte 20-tal som antogs)
- Personnr: 20030415-0055
- Folkbokförd: Karin Larssons Väg 3 D lgh 1306, 128 63 Sköndal
- Startdatum LandveX AB: 2026-04-11

### Johan — viktig info  
- Personnr: 19870606-0079
- Kontonr Nordea: 8706060079
- Adress: Dyviksvägen 4, 135 69 Tyresö
- Styrelsesuppleant i LandveX AB

---

## 17. LANDVEX — POSITIONERING & STRUKTUR (2026-06-19)

### Varumärkespositionering (beslutad av Erik)
**Produktkategori:** Control Intelligence (INTE "decision intelligence")
**International tagline:**
> Landvex is an international control intelligence company operating through Landvex AB (European Union) and Landvex Inc. (United States).

### Juridiska enheter
- **Landvex AB** — Europeisk verksamhet, Tyresö Sweden, org.nr 559141-7042
- **Landvex Inc.** — Nordamerikansk verksamhet, Houston Texas USA

### Informationskedjan (kommuniceras på sajten)
quiXzoom → Field Intelligence → Landvex → Control Intelligence → Enterprise Decision Making

### Nyckelbudskap
- EU-närvaro + USA-närvaro = internationell leveranskapacitet
- Kontrollerar hela informationskedjan från fältdata till beslut
- "Landvex is building a global intelligence infrastructure with operational presence in Europe and North America and planned expansion into additional international markets."

### Enterprise-formulering
> Landvex combines field-verified intelligence, AI-driven analysis, and cross-market operational coverage through its European and North American entities. Our control intelligence platform enables infrastructure owners, governments, utilities, and enterprises to identify risks, opportunities, deficiencies, and emerging conditions before they become operational problems.

---

## 19. NORDEA KYC — STATUS (2026-06-19)

### KYC-paket publicerat
URL: https://bernt.aamos.systems/docs/kyc-nordea/
Svar: https://bernt.aamos.systems/docs/kyc-nordea/svar.html

### Status per fråga
- F1 Trygg Bil 222 916 kr: ✅ Faktura 10002 + 20001 direktlänkade
- F2 Elles 941 434 kr: ✅ Närstående-relation (Eriks mor = ordf.) deklarerad öppet
- F3 399 941 kr till privatkonto: ✅ 110 kvitton + löneunderlag
- F4 19 455 kr konto 030415-0055: ⚠️ Thai Airways ARN→BKK, **e-biljett saknas** — Erik hämtar från thaiairways.com

### Kvarstående
- Leon-fordran 212 922 kr: kravbrev deadline var 18/6, **status okänd**
- Moms 332 826 kr obetald, deadline 2026-07-26 (företrädaransvar)
- Erik-lön brutto ~311 900 kr hanteras av KPMG (Andreas Vretblom)

---

## 18. QUIXZOOM & LANDVEX — ROLLER, VARUMÄRKE & POSITION (LÅST 2026-06-19, Erik)

### Stavning
**QUIXZOOM** — alltid så i officiell kommunikation. Aldrig Quicksum, Quickzoom, Quix Zoom etc.

### SEO-felstavningar att äga (landningssidor, FAQ, structured data)
quixzoom, quix zoom, quix-zoom, quickzoom, quick zoom, quick-zoom, quikzoom, quik zoom, quixoom, quixzom, quixzooom, quixsum, quicksum, quick zoom data, crowd intelligence platform, field intelligence platform

### Roller
**QUIXZOOM** = Field Intelligence Network / Global Intelligence Collection Platform
- Tar emot uppdrag
- Aktiverar Zoomers
- Samlar in verifierad verklighetsdata
- Levererar observationsdata (råmaterialet — INTE slutlig intelligens)

**LANDVEX** = Analysmotorn / Control Intelligence-leverantören
- Säljer: Control Intelligence, Business Intelligence, Infrastructure Intelligence, Market Intelligence, Risk Intelligence
- Tittar på VAR datan säger emot sig själv (kontradiktionsanalys)

### Kärnposition
> "Landvex identifies contradictions between reported reality and observed reality."
> "We don't look for confirmation. We look for contradiction."

### QUIXZOOM Indikatorer / Index (idéer från Erik)

**Urban Sanitation Intelligence Index (USII) / City Dump Index (CDI)**
- 7 nivåer: Street Exposure, Insamling, Infrastruktur, Sortering, Automation, Hygien, Cirkularitet
- Skala 0–100 per stad
- Korrelerar med: folkhälsa, fastighetsvärden, turism, tillit till institutioner
- QUIXZOOM kan mäta via geotaggade observationer + AI
- Exempelstadsranking (illustrativ): Singapore 96, Tokyo 92, Stockholm 88, Las Vegas 91, Bangkok 55–65, Manila 35

**Reality Contradiction Score (RCS) / Reality Gap Index (RGI)**
- AI identifierar Motsägelser, inte bara objekt
- Exempel: Lyxhotell + öppna avloppsdiken, Skyskrapor + provisoriska skoltransporter
- Dimensioner: Physical Reality, Safety Reality, Infrastructure Reality, Economic Contrast, Implementation Gap
- AI frågar: "Vilka element borde normalt inte samexistera?"
- Skifte från objektdetektering till relationell urban intelligens
- Landvex-analyslager:
  - Reality Gap Index (RGI) — skillnad mellan plan och verklighet
  - Reality Contradiction Score (RCS) — grad av kontrast mellan urbana system
  - Implementation Gap Score (IGS) — hur väl system fungerar i praktiken
  - Urban Adaptation Score (UAS) — informella lösningar människor skapat

### Strukturbild
```
LANDVEX AB (EU) + LANDVEX INC. (US)
↓
LANDVEX (Control Intelligence)
↓
QUIXZOOM (Field Intelligence Network)
↓
ZOOMERS (Reality Collection Layer)
```

### Traditionell BI vs Landvex
Traditionell BI: Data → Dashboard → Rapport → Beslut
Landvex: Officiell statistik + QUIXZOOM-observationer + Extern data → Kontradiktionsanalys → Kontrollintelligens → Beslut

---

## SIL — System Intelligence Layer (2026-07-01)

Erik-feedback: Bygg inte en "resonemangsmotor", bygg ett **System Intelligence Layer** — ett lager mellan kodbasen och alla AI-agenter. Fyra ansvarsområden: Observera, Resonera, Planera, Verifiera.

### Viktiga beslut från Erik (2026-07-01)

**1. Experiment-fas, inte utrullning**
- Samla data i 2-4 veckor innan aktivering
- Mät diagnostiska metriker: recall, precision, false negative rate, false positive rate, confidence calibration
- Gold Set: 50-100 historiska PR:er med känt facit

**2. False negatives är farligare än false positives**
- En extra varning kostar lite tid
- En missad kritisk beroendekedja kan orsaka produktionsfel
- Prioritera recall över precision

**3. Provenance (revisionsspår) för varje slutsats**
- Vilka observationer användes?
- Vilka regler aktiverades?
- Vilka grafnoder traverserades?
- Vilka relationer användes?
- Vilka confidence-värden påverkade slutsatsen?
- Vilken del var verifierad och vilken del var inferens?

**4. Webhook-baserad arkitektur (inte cron)**
- Event-driven när PR öppnas/uppdateras
- Lägre latens, mindre onödigt arbete

**5. Aktiveringskriterier (hårda)**
- Recall > 85%
- Precision > 80%
- False Negative Rate < 10%
- Calibration Error < 10%

### Implementation (v0.4)
- `SIL/pr-analyzer.mjs` — PR-analys med provenance + uncertainty + decision engine
- `SIL/provenance.mjs` — Revisionsspår
- `SIL/metrics.mjs` — Diagnostiska metriker
- `SIL/gold-set.mjs` — Ground truth-byggare
- `SIL/webhook-server.mjs` — Event-driven triggning
- `SIL/experiment-report.mjs` — Veckovis rapport
- `SIL/graph-version.mjs` — Versionera kunskapsgrafen
- `SIL/stability.mjs` — Mät stabilitet och determinism
- `SIL/uncertainty.mjs` — Osäkerhet som förstklassig signal
- `SIL/decision-engine.mjs` — Beslutsunderlag för PR:er
- `SIL/observability.mjs` — Dashboard och metriker för SIL självt
- `SIL/reasoning-suite.mjs` — Regressionstester för resonemang (30+ frågor)
- `SIL/architecture-policy.mjs` — Arkitekturregler som kod (10 regler)
- `SIL/historical-analysis.mjs` — Trender och långsiktiga mönster
- `SIL/README.md` — Komplett dokumentation

Status: Experiment-fas pågår. Samlar data. Inte aktiverad för merge-beslut ännu.

### Principer (från Erik 2026-07-01)
**"Varje ny funktion i SIL ska också göra SIL enklare att mäta, testa eller förklara."**
- Mätbarhet > nya AI-funktioner
- Reproducerbarhet > komplexitet
- Tydliga revisionsspår > black box-beteende

### Mål för v1.0 (från Erik 2026-07-01)
**"SIL ska kunna ta en okänd pull request, utan README eller mänsklig förklaring, analysera den utifrån kod, arkitektur, tester och telemetri och producera ett beslutsunderlag som en erfaren staff engineer skulle kunna använda för att fatta ett merge-beslut."**

### Engineering Validation Program (från Erik 2026-07-01)
v1.0 = Feature Complete. 6–8 veckors empirisk validering.

**Fråga 1: Hjälper SIL verkligen människor?**
- Mät: tid till merge, regressionsbuggar, följsamhet, rätt vs fel
- Success: 20% färre regressionsfel, 15% snabbare merge

**Fråga 2: Kan SIL motivera sina slutsatser?**
- Granska 50 slumpmässiga analyser
- Checklista: regel, observation, artefakter, noder, verifierat, inferens
- Success: >90% completeness

**Fråga 3: Hur robust är SIL mot förändring?**
- Simulera: rename, move, split, add dependency, change structure
- Success: <10% degradation

**Fråga 4: Kan SIL analysera okända projekt?**
- Testa på 3 open source-projekt
- Success: >70% recall

**Två-lagers arkitektur:**
- Deterministiskt lager (confidence: 0.99-1.00): graf, regler, AST, policyer
- Probabilistiskt lager (confidence: <0.99): LLM, heuristik, uppskattningar

### Hypoteser (från Erik 2026-07-01)
**"Vilka hypoteser försöker vi falsifiera?"**
- H1: SIL minskar regressionsfel med minst 20%
- H2: SIL upptäcker fler arkitekturöverträdelser än code review
- H3: SIL hittar fler beroenden än senior utvecklare
- H4: Confidence korrelerar med faktisk korrekthet
- H5: UNKNOWN används när systemet saknar tillräcklig evidens

### Failure Review (från Erik 2026-07-01)
**"Varje gång SIL har fel ska ni klassificera felet."**
- Knowledge Error: Grafen saknade en relation
- Parsing Error: AST missade en import
- Runtime Drift: Driftmiljön skiljde sig från modellen
- Policy Error: Arkitekturregel felaktigt formulerad
- LLM Error: Felaktig inferens
- Confidence Error: För hög confidence trots svag evidens

### Replay Mode (från Erik 2026-07-01)
**"Samma grafversion, samma regler, samma observer-version, samma reasoner-version."**
- Återskapa exakt hur en analys såg ut vid ett specifikt tillfälle
- Ovärderligt vid felsökning av beslut

### Teknisk specifikation (från Erik 2026-07-01)
**"Skriv en teknisk specifikation som om ni tänkte publicera den."**
- Problemformulering, systemmodell, deterministiskt/probabilistiskt lager
- Confidence-modell, valideringsmetodik, begränsningar, kända felkällor
- Fil: `SIL/SIL_TECHNICAL_SPECIFICATION.md`

### Engineering Operating System (EOS) (från Erik 2026-07-01)
**"Ingen agent får någonsin fatta ett irreversibelt beslut utan att kunna motivera det, reproducera det och återställa det."**

**Byggstenar:**
1. **Immutable Truth** — exakt en sanningskälla för varje sak (Git, IaC, migrationer, OpenAPI, kunskapsgraf)
2. **Engineering Contract** — hårda regler med konsekvenser (STOP/ESCALATE)
3. **Event-Driven Memory** — minne uppdateras av händelser (commit, PR, merge, deploy)
4. **Project Memory** — varför beslut fattades, vad som testades, buggar, arkitektur
5. **Goal Graph** — vision, produktmål, epics, features, arkitekturprinciper, tekniska/affärsmål

**Engineering Constitution** — 30 regler som alla agenter måste följa:
- Git är den enda sanningskällan för kod
- Produktion är skrivskyddad för agenter
- Alla ändringar ska vara reproducerbara
- Alla beslut ska kunna motiveras
- Alla slutsatser ska ha provenance
- Alla ändringar ska kunna återställas
- Ingen komponent får skapa en egen version av sanningen
- Om osäkerheten är hög ska agenten eskalera istället för att gissa
- Affärsmål väger tyngre än lokal kodoptimering
- Projektminnet är långlivat och versionshanterat

### Engineering Readiness (från Erik 2026-07-01)
**"EOS borde inte bara säga STOP. Det borde också kunna ge ett mognadsindex."**

- 10 områden med viktade poäng (Git 20%, CI/CD 20%, Backup 15%, IaC 15%, Testing 10%, Security 10%, API 5%, DB 3%, Observability 1%, Agent Safety 1%)
- Critical (<60%): STOP, Warning (60-79%): ESCALATE, Ready (≥80%): Godkänt
- quixzoom-resultat: 8% CRITICAL (viktad)

### Policy Enforcement (från Erik 2026-07-01)
**"Om en agent försöker deploya utan pipeline ska EOS förhindra åtgärden."**

- Blockera direkt skrivning till produktion
- Blockera deployment utan pipeline
- Blockera redigering på server
- Blockera ändring utan commit
- Blockera databasändring utan migration
- Blockera API-ändring utan kontrakt
- Kräv mänskligt godkännande för kritiska åtgärder
- Förklara VARFÖR och HUR man häver blockering

### STOP Register (från Erik 2026-07-01)
**"Risk = Sannolikhet × Konsekvens × Exponering"**

- Varje STOP har riskvärde för prioritering
- Sorteras efter risk (högst först)
- Exit Criteria: Inga CRITICAL STOP öppna

### Release Gate (från Erik 2026-07-01)
**"Innan en release får starta kör EOS en kontroll"**

- Engineering Readiness ≥60%
- Inga CRITICAL STOP
- Inga policybrott senaste 24h
- Kunskapsgraf uppdaterad
- Tester passerar
- Rollback verifierad

### EOS Meta-Rules (från Erik 2026-07-01)
**"EOS får inte kunna kringgå sina egna regler"**

- Policyer versionshanterade
- Policyändringar kräver samma granskning som kod
- Undantag lämnar revisionsspår
- EOS kan inte inaktiveras av agent
- EOS loggar alla egna ändringar

### Arkitektur — Fyra nivåer (från Erik 2026-07-01)
**"Varje lager bara känner till lagret under."**

- Layer 1: Foundation (Git, Terraform, OpenAPI, K8s, CI/CD, Secrets, Logging)
- Layer 2: EOS (Constitution, Policies, Knowledge Graph, Project Memory, Goal Graph)
- Layer 3: Agents (Planner, Reviewer, Developer, Security, QA, Architect)
- Layer 4: Applications (quiXzoom, LandveX, ...)

**Isoleringsprincip:** Inget i Layer N får direkt påverka Layer N+2 eller högre.
**quiXzoom får aldrig känna till EOS.** Det är EOS som känner till quiXzoom.

### Capability Registry (från Erik 2026-07-01)
**"Inte komponentregister. Inte service registry. Capability Registry."**

- Resonera i verksamhetsförmågor: Mission Management, User Management, Payment Processing
- Varje capability: services, APIs, databas, tester, dashboards, ägare
- Gör att systemet växer i verksamhetsförmågor snarare än tekniska komponenter

### Dependency Budget (från Erik 2026-07-01)
**"Precis som prestandabudgetar."**

- Max direkta beroenden per service
- Max externa API:er
- Max databaser
- Om PR överskrider budget → blockeras
- Hindrar gradvis arkitekturell erosion

### Moratorium (från Erik 2026-07-01)
**"Sluta utveckla EOS under 2 sprintar. Mäta istället."**

Mätvärden:
- Hur många gånger användes EOS?
- Hur många STOP-regler utlöstes?
- Hur många undantag begärdes?
- Hur lång tid tog det att lösa ett STOP?
- Hur många regressionsfel undveks?
- Hur många gånger ändrade en utvecklare sitt beslut efter EOS-analys?

**Mål:** Om utvecklare frivilligt använder EOS för att det sparar tid och minskar misstag — då har vi lyckats.

### Sprint-mål (från Erik 2026-07-01)
**"0 omotiverade STOP-regler i den del av systemet som omfattas av sprinten."**

**Sprint: Engineering Readiness v1**
- Leverabler: Engineering Readiness Score (viktad), Policy Enforcement, STOP Register (med risk), Release Gate, Meta-Rules
- Exit Criteria: Varje STOP är eliminerad, har dispens, eller ersatts av kontrollerad process
- EOS-regel: "EOS får aldrig blockera något utan att kunna förklara exakt varför och vilken minsta åtgärd som krävs för att häva blockeringen."

---

## 11. CONTROL INTELLIGENCE & DECISION MODEL (2026-07-02)

**LandveX produces Control Intelligence, not AI analysis.**

AI is implementation. Control Intelligence is the product.

### Decision Pipeline v1.0
```
Reality → Observation → Evidence → Finding → Decision → Action → Business Impact → Learning
```

**Seven steps with input/transformation/output/owner.**

### Decision Object v1.0 (STRUCTURE FROZEN)
- 7 fields: Decision, Why, Evidence, Confidence, Consequence, Action, Business Impact
- Changes require v1.1 + migration note + revalidation
- Implementation/algorithms NOT frozen

### Status: VALIDATED FOR FIELD TRIALS
- 8 scenarios reviewed (6 PASS, 2 OBSERVATION, 0 FAIL)
- Decision Invariance Test: PASS
- Evidence Variation Test: PASS
- Explainability Invariance Test: PASS
- Ready for real customer testing, not production truth

### Three Target Customer Cases
1. Municipality — "Inspect or wait?" (Maintenance prioritization)
2. Property Owner — "Repair now or plan later?" (Cost vs risk)
3. Contractor/Operations — "Which action first?" (Operational planning)

### Future KPIs (collect now, calculate later)
- **Decision Adoption Rate** = Accepted recommendations / Total recommendations
- **Decision Accuracy** = Correct decisions / Total decisions
- **Time to Decision** = Minutes from login to decision

### Key Principle
**No more modeling until first real customer case has run through entire pipeline.**

### Files
- `docs/design/DECISION_MODEL_v1.0.md` — Decision Model
- `docs/design/DECISION_PIPELINE_v1.0.md` — Decision Pipeline
- `docs/design/DECISION_MODEL_REVIEW.md` — Manual Review Results
- `docs/design/FIELD_TRIAL_LOG.md` — Observation Protocol