# Alami Vision — Produkt- & Tech-Roadmap > **Stand: 2026-07-03.** Antwort auf die Handoffs `AILLMHANDOFF.md` (Mobile-Agent) > und `TRASH_INTELLIGENCE.md` (Admin-Dashboard-Agent). Dieses Repo ist das > **Standalone-Projekt "Alami Vision"**: die visuelle KI der Alami-Plattform. > Die App konsumiert nur die API — Modell, Training und Daten-Flywheel leben hier. --- ## 1. Wo wir stehen (ehrliche Bestandsaufnahme) **Was existiert und funktioniert:** - **Serving:** FastAPI + ONNX Runtime, YOLOv8-seg (TACO-trainiert, 7 Material- klassen), Temperature-Calibration, Docker-fähig, deployed als Hugging Face Space (`nangiale-alami-trash-ai-api.hf.space`). Live im Economy-Gate der App. - **Trainings-Pipeline (Colab/Scripts):** `prepare_taco` → `train_yolov8_seg` → `calibrate_temp` → `evaluate` → `export_onnx` → Bundle. Dazu `ingest_feedback.py` (Feedback → YOLO-Dataset) und `active_sampler.py` (Active Learning) — das Flywheel-Gerüst ist schon da. - **Modellstand (v20251018-220439):** mAP50 0.42, Makro-Accuracy 0.81. `organic` und `ewaste` haben **F1 = 0.0** (keine Trainingsdaten). Auf strukturlosen Bildern neigt das Modell zu False Positives (im Test: 86 % Konfidenz "paper" auf einer grauen Fläche) — relevant, weil False Positives TC auszahlen. **Was auf diesem Branch gefixt wurde:** | Problem | Auswirkung | Fix | |---|---|---| | `requirements.txt` mit unaufgelöstem Merge-Konflikt | Jeder Docker-Build schlug fehl | aufgelöst | | `names.json` fehlte im Repo (von `.gitignore` verschluckt) | Server startete aus frischem Clone **gar nicht** | byte-identisch restauriert (SHA-256 == Original-Checksum), Fallback auf `model_card.json` eingebaut | | Bounding-Box-Rückprojektion wurde berechnet und dann verworfen | Alle Boxen in 640er-Raum statt Originalbild — Overlays/Flächen falsch | behoben + Regressionstest | | `verify=False` bei Bild-Fetch | TLS-Verifikation global aus | Default an, Opt-out nur per Env | | Debug-Endpoints öffentlich | Angriffs-/SSRF-Fläche in Prod | nur noch bei `ALAMI_DEBUG=1` | | Kein Auth | Jeder kann Feedback einschleusen (Trainings-Poisoning) und Compute stehlen | optionaler API-Key (`ALAMI_API_KEYS`) | | `raw_label` fehlte im Response | Mobile-Contract (`api/alamiAi.ts`) erwartet es | additiv ergänzt | **Neu auf diesem Branch:** `/v1/analyze` + `/v1/analyze/upload` (Standalone-API- Fläche mit Materialsummary, Stückzahl, Gewichtsschätzung v0), erweitertes `/feedback` (objektgenaue Korrekturen, `source`), Testsuite (13 Tests, inkl. End-to-End auf dem echten ONNX). --- ## 2. Produktvision: von der Müll-KI zur visuellen KI **Alami Vision** ist ein eigenständiges Produkt mit einer API: ``` ┌─────────────────────────────┐ Alami Mobile ──────► │ Alami Vision API │ ◄────── externe Kunden (validate + RLHF) │ /predict /v1/analyze /feedback │ (Städte, NGOs, └──────────────┬──────────────┘ Entsorger, Marken) │ Daten-Flywheel ▼ Fotos + User-Korrekturen (Typ, Stück, kg/Liter, Geo, Zeit) │ ingest_feedback → active_sampler → retrain → deploy ``` Die `domain`-Dimension der v1-API ist der Expansionspfad: heute `trash`, morgen weitere visuelle Domänen (Sperrmüll/Recyclinghof-Klassifikation, Container-Füllstand, illegale Deponien aus Drohnen-/Satellitenbildern, generische Objekterkennung mit Gewichtsschätzung). Clients integrieren einmal und bekommen neue Fähigkeiten als neuen `domain`-Wert — keine Migration. **Der eigentliche Asset ist nicht das Modell, sondern das Flywheel:** Millionen gelabelte, geo-getaggte, deduplizierte (pHash + SHA-256), fraud-geprüfte Müllfotos mit menschlich bestätigten Typ- **und Gewichts**-Angaben. Diesen Datensatz hat sonst niemand — genau deshalb zahlt die App 1 TC pro Solo-Foto: das Foto *ist* das Produkt. --- ## 3. Phasen ### Phase 1 — Fundament härten (dieser Branch) ✅ Bugfixes, Auth, v1-API, Tests, Doku. Deploybar auf den HF Space, 100 % rückwärtskompatibel zum Mobile-Client. ### Phase 2 — Modellqualität (nächste 4–8 Wochen) 1. **False-Positive-Rate senken** — sie kostet direkt Geld (FP ⇒ unverdiente TC) und Review-Last (Trust-Score). Hebel: Hintergrund-Negativbeispiele ins Training, Kalibrierung nachziehen, ggf. `conf_thr` je Klasse. 2. **`organic`/`ewaste` trainierbar machen** (Daten via `augment_external_datasets.py`, sonst Klassen vorerst aus `names.json` nehmen statt tote Klassen auszuliefern). 3. **Feedback-Flywheel** ✅ — code-seitig geschlossen (siehe `docs/FLYWHEEL.md`): `run_flywheel.py` orchestriert sync → ingest → report (wöchentliche GitHub Action) und train → calibrate → evaluate → export → **quality gate** → promote (GPU-Box/Colab). Regression ⇒ kein Deploy; jede Modellversion traceable über Registry + `model_version` auf jeder Zeile. Scharfschalten braucht nur noch die Checkliste in FLYWHEEL.md §5. ### Phase 3 — Gewicht lernen (das Alleinstellungsmerkmal) - Heute: `material_prior_v0` (ehrlich getaggte Heuristik, s. `docs/api.md`). - Die App liefert bereits `corrected_weight_kg` über `/feedback` und Events liefern kg/Liter-Angaben ⇒ es entsteht ein **(Bild, Boxen, Gewicht)**-Korpus. - Ab ~50k gewichts-gelabelten Fotos: Regressions-Head aufs Backbone (Gewicht pro Objekt + Unsicherheit). `weight_source` wechselt von `material_prior_v0` auf die Modellversion — Clients merken den Umstieg am Feld. - **Ökonomie-Umstellung Solo → kg-basiert** ist danach möglich, bleibt aber laut Hard Contract eine **Founder-Entscheidung** (Server-RPC, nicht KI-seitig). ### Phase 4 — Brand Intelligence (Geld-Phase, braucht dein Sign-off) Deckungsgleich mit `TRASH_INTELLIGENCE.md`: Vision-LLM extrahiert Marke/ Hersteller pro sichtbarem Logo, asynchron über den Foto-Backlog (nie im Submit-Pfad), Ergebnisse in `trash_brand_detections` (Schema-Vorschlag liegt vor, **kein Schema-Change ohne dein Go**), Human-Review-Queue im Admin-Dashboard, jährlicher **Alami Trash Transparency Report**. - Technisch hier im Repo: Batch-Worker, der `/v1/analyze`-Detections mit einem Vision-LLM-Call (Logo/Brand) anreichert; Join über `trash_photo_signatures`. - Privacy wie im Proposal: PII-Blur vor Inferenz/Training, nie Reporter- Identität in Aggregaten, Cascade-Delete. ### Phase 5 — Skalierung als Plattform - **Serving:** stateless API hinter Load Balancer; HF Space ⇒ Container auf eigener Infra (Cloud Run/Fly/K8s) mit Autoscaling; GPU-Batch-Worker für Backlog-Jobs; Warteschlange (z. B. Supabase Queue/Redis) für async Analysen. - **Uptime ist Auszahlungs-kritisch** (`unavailable` ⇒ 0 TC): Health-Alerts, zweite Region/Replica, Canary-Deploys neuer Bundles (Registry existiert). - **Multi-Tenant:** API-Keys je Kunde (heute simple Env-Liste, später Tabelle mit Rate-Limits/Quotas + Usage-Metering pro Key = Abrechnungsgrundlage). --- ## 4. Monetarisierung 1. **Vision-API als Produkt** (`/v1/analyze`): Abrechnung pro Bild, Staffelpreise. Zielkunden: Kommunen/Städte (Littering-Monitoring), Entsorger (Sortier- Vorprüfung), NGOs, andere Cleanup-Apps. Multipart-Upload existiert schon — Kunden brauchen keine Bild-URLs. 2. **Brand Transparency Report** (Phase 4): jährlicher Report "welche Marken liegen in der Landschaft" — relevant für **EPR-Compliance** (Extended Producer Responsibility, EU-Verpackungsrecht), ESG-Reporting der Hersteller und Presse. Verkauf als Report + Daten-Abo pro Marke/Region. 3. **Datensatz-Lizenzierung:** der deduplizierte, gelabelte, geo-gestempelte Litter-Korpus (nur mit PII-Blur + Privacy-Regeln aus dem Proposal) für Forschung/Industrie. 4. **White-Label-Dashboards** für Städte (Karten, Trends, Materialmix) auf Basis der Aggregate aus dem Admin-Dashboard-Projekt. Reihenfolge bewusst: erst Modellqualität (2), dann Gewicht (3) — beides macht die API verkaufbar —, dann Brand (4) als margenstärkstes Produkt. --- ## 5. Hard Contracts (gelten unverändert, aus `AILLMHANDOFF.md` §5) 1. KI setzt **niemals** TC-Beträge — nur Signale (`ai_detected`, `ai_status`). 2. Der Submit-Pfad der App darf nie an der KI scheitern (`verifyPhotosWithAI` bleibt non-throwing; API-Fehler ⇒ `unavailable` + `needs_review`). 3. `ai_status`-Vokabular fix: `verified | no_detection | unavailable`. 4. Ökonomie-Zahlen leben in `tc_config`, nicht im KI-Code. 5. Fraud-Signale (`trash_photo_signatures`, pHash, `needs_review`) nicht schwächen. 6. **API-Keys erst erzwingen, wenn die Mobile-App den Header sendet** — sonst `unavailable` für alle ⇒ ehrliche Nutzer bekommen 0 TC. --- ## 7. Strategische Erweiterung — von der Müll-KI zur räumlichen Vision-KI > Founder-Vision (2026-07-15): Alami Vision soll mehr können als Müll erkennen. > Es soll **Szenen verstehen** — „das ist eine Pflanze, kein Müll", „das ist ein > Stuhl", „ich sehe 3 Plastikflaschen und eine Katze" — und diese räumliche > Objekt-Intelligenz später als **API an Industrien** verkaufen (Drohnen- > Luftbild-Erkennung illegaler Deponien im Wald, Entsorger, Kommunen, …). > Ziel: das führende Vision-KI-Modell für die physische/ökologische Welt. ### 7.1 Warum das kein Umweg ist, sondern unser aktuelles Problem löst Der teuerste Fehler des heutigen Modells ist der **False Positive**: Es „sieht" Müll auf leerem Boden (86 % „paper" auf grauer Fläche im Test) und würde dafür TC auszahlen. Ursache: Das Modell hat nie gelernt, wie **Nicht-Müll** aussieht. „Erkenne die Pflanze / den Stuhl / die Katze" ist damit **exakt die Medizin gegen unser Nr.-1-Problem** — nicht ein Nebenprojekt. Wer weiß, was eine Pflanze ist, zahlt sie nicht als Müll aus. Die Auto-Negatives (Runde 3) sind die primitive Vorstufe; echte Objekt-/Szenenerkennung ist die ausgereifte. **Synergie, kein Ablenkungsmanöver.** ### 7.2 Die zentrale Architektur-Entscheidung (hier verdienen wir Geld oder verbrennen es) Es gibt zwei Wege, „Katze/Stuhl/Haus erkennen" zu bauen — und nur einer ist für ein Startup richtig: | | ❌ Weg A: Generalisten selbst trainieren | ✅ Weg B: Spezialist auf Fundament | |---|---|---| | Was | Von Null ein Modell bauen, das die ganze Welt kennt | Ein **Open-Vocabulary-Backbone** (YOLO-World, Grounding-DINO, OWLv2, SAM) nutzen, das „Katze/Stuhl/Baum/Gebäude" schon kann, + **unseren Fach-Kopf** obendrauf | | Kosten | Millionen, Jahre, Google/Meta-Liga | Wir integrieren das Fundament, trainieren nur unsere Schicht | | Ergebnis | Schlechter als das, was es gratis gibt | Etwas, das **niemand sonst hat** | **Weg B ist die Strategie.** Zwei Schichten: - **Fundament (die Augen):** ein offenes Objekt-/Szenenmodell, das benennt, was im Bild ist — Katze, Stuhl, Baum, Auto, Flasche. Von der Stange, austauschbar. - **Alami-Fach-Kopf (das Gehirn):** was davon ist Müll, welches **Material**, welche **Entsorgung**, welches **Gewicht**, welche **Marke**, recyclebar? Diese Domänen-Intelligenz hat **nur** Alami — sie kommt aus dem Flywheel (echte Feld- fotos + menschliche Korrekturen + kg/Material/Disposal-Wissen). Ergebnis-Beispiel: *„Ich sehe 3 Plastikflaschen (Gelbe Tonne, ~60 g), 1 Pflanze (kein Müll), 1 Katze (kein Müll)."* — Fundament sagt WAS, unsere Schicht sagt was es FÜR DIE UMWELT bedeutet. Das ist der verkaufbare Unterschied. ### 7.3 Ehrliche Trennung von zwei Ambitionen Damit die Vision nicht am Kapital scheitert, zwei Dinge sauber trennen: - **Ambition A — erreichbar & riesig:** *DER* Domänen-Experte für die physische Welt aus Umwelt-/Kreislaufwirtschafts-Sicht — Müll, Material, Entsorgung, illegale Deponien, Container-Füllstand, EPR-Compliance. Hier schlägt uns unser **Datengraben** jeden Generalisten. Verkaufbar an Entsorger, Kommunen, Versicherer, Drohnen-Survey-Firmen, ESG-Abteilungen. - **Ambition B — Moonshot, andere Kapital-Liga:** ein allgemeines Vision- Fundamentmodell wie GPT-4V/Gemini. Das baut man als Startup **nicht** von Null. Aber: Wir **reiten** diese Modelle (als Backbone) und legen unsere Schicht drauf — so bekommen wir die räumliche Fähigkeit, ohne die Fundament-Kosten. Positionierung: *„Wir schlagen das Generalmodell nicht — wir sind der Spezialist, der es für Müll/Umwelt nützlich macht, mit Daten, die niemand sonst hat."* ### 7.4 Neue Produktlinie: „Alami Aerial" (Drohnen-/Luftbild — naheliegend) Die Drohnen-Idee ist **nicht** ferne Zukunft — die Daten liegen schon lizenzgeprüft im Katalog: **DroneWaste** (4.993 Luftbilder, CC BY 4.0), **UAVVaste** (Apache-2.0), **pLitterStreet** (13k Straßenszenen aus Fahrzeugperspektive, CC BY 4.0). Die `domain`-Dimension der v1-API kann `aerial-litter` als neuen Wert aufnehmen — **ohne Migration für bestehende Clients**. Zielkunden: Forstämter, Umweltbehörden, Kommunen (illegale Deponien im Wald/an Feldwegen), Drohnen-Dienstleister. Mögliche eigenständige, früher als Brand-Intelligence startende Umsatzlinie. (Gefahrgut-Hinweis „nicht anfassen, Behörde informieren" aus dem DroneWaste-Paper passt hier dazu — siehe Backlog.) ### 7.4b Dritte Domäne: „Alami Marine" (Unterwasser/Meer — Founder-Vision 2026-07-15) Damit ist Alami Vision **dreidimensional**: **Land** (Boden/Produkt) + **Luft** (Drohne) + **Wasser** (Unterwasser-Drohnen/ROV/AUV, schwimmender Meeresmüll). Das macht uns zur kompletten Umwelt-Litter-Plattform — jede Domäne ist ein neuer `domain`-Wert (`underwater-litter` / `marine-debris`), kein Client-Bruch. **Datenlage (bekannt, Lizenz-Verifikation ausstehend):** - **TrashCan 1.0** und **Trash-ICRA19** (Uni Minnesota, Hong/Fulton/Sattar) — ROV-Unterwasser-Müll, Instanz-Segmentierung/BBox. Standen bisher als „academic use"; **die genaue DRUM-Lizenz muss geprüft werden** (könnte CC BY/ CC0 sein — dann kommerziell nutzbar). Top-Priorität der Meeres-Recherche. - Weitere Kandidaten für den Sweep: **FathomNet** (MBARI, Tiefsee-Bilder mit Concept-Labels inkl. Debris), **JAMSTEC J-EDI Deep-sea Debris DB**, **MARIDA/MADOS** (Satelliten-Meeresplastik), schwimmender Fluss-/Hafenmüll. **Machbarkeit — ehrlich:** Unterwasser ist bildtechnisch *härter* (Blaugrün- Stich, Trübung, Rückstreuung, wenig Licht, Bewuchs, Größenambiguität). Die Zwei-Schichten-Strategie trägt trotzdem: offenes Backbone als Augen + unser Fach-Kopf, **fein-getunt auf Unterwasser-Daten** (Farbkorrektur à la Sea-thru als Vorverarbeitung). Kunden: Marine-Survey-Firmen, Häfen, Ocean-Cleanup-NGOs, Aquakultur, Forschungsschiffe. **Marktgröße kleiner & spezialisierter als Land/ Luft, Datenknappheit größer** ⇒ Einordnung: **nach Aerial**, nicht davor — strategisch top, aber der Reihe nach. > Ein eigener lizenzgeprüfter Meeres-Datensatz-Sweep (6 Finder + adversariale > Verifikation + Machbarkeit) ist vorbereitet und wird gefahren, sobald die > Umgebung stabil ist; Ergebnis kommt hier in §7.4b + TRAINING_DATA.md. ### 7.5 Sequenz (ohne die aktuelle Dynamik zu bremsen) 1. **Jetzt:** Basis-Detektor fertig trainieren (Kaggle-Lauf läuft), organic/ ewaste aus F1=0 holen, False Positives über Negatives dämpfen. 2. **Als Nächstes — „ist das überhaupt Müll?"-Gate:** Open-Vocabulary-Backbone als neue Fähigkeit (`domain=scene`) andocken → Objekt-Inventar + Nicht-Müll- Erkennung. Halbiert False Positives und liefert das „3 Flaschen + 1 Katze". 3. **Parallel/danach:** `Alami Aerial` (Daten da) → dann `Alami Marine` (Unterwasser, §7.4b — nach Aerial), Gewichts-Kopf (Daten wachsen), Brand (geparkt). 4. **Plattform:** Multi-Tenant-API mit Usage-Metering pro Key (Roadmap §Phase 5) = Abrechnungsgrundlage für den Verkauf an Industrien. Das Reproduzierbarkeits-Manifest (`dataset_manifest.py`) ist dafür Voraussetzung — Industriekunden/Investoren auditieren, worauf trainiert wurde. **Roter Faden:** Jede neue Domäne (Boden, Produkt-Scan, Luftbild, Szene) füttert **dasselbe Flywheel**. Der Datengraben wächst mit jeder Domäne — das ist der Grund, warum ein Spezialist mit eigenem Datenmotor einen Generalisten in dieser Nische dauerhaft schlägt. --- ## 6. Offene Fragen an dich / den Mobile-Agenten 1. **HF-Space-Code vs. Repo:** Der Space lief bisher mit einem Bundle, das dieses Repo nicht vollständig enthielt. Nach Merge dieses Branches sollte der Space aus dem Repo deployt werden (Single Source of Truth). Wer deployt den Space — CI hier, oder manuell? 2. **Brand-Pipeline Sign-off** (Phase 4): Schema `trash_brand_detections` wie im Proposal? Welcher Vision-LLM-Anbieter, welches Budget pro Bild? 3. **Mobile:** Wann kann der App-Client den `x-api-key`-Header mitschicken (kleines Change in `api/alamiAi.ts`), damit wir Auth scharf schalten können? 4. **Supabase-Logging:** `SUPABASE_URL`/`SERVICE_ROLE_KEY` am Space setzen, damit Predictions zentral in `trash_predictions` landen (heute nur JSONL im ephemeren Space-Storage — bei Restart weg)?