Revision 0.19 · 2026-10-16 · Produktspezifikation des Startups · Funktionen, Architektur und Umsetzungskriterien.
Priorität der ersten Phase
Eigene offizielle Inhalte → erlaubte Veröffentlichung → Analyse → gemessene Wirtschaftlichkeit → Erweiterung. Studio und der erforderliche Teil von Social werden gemeinsam auf dem Station-Kern entwickelt. Kundenpiloten, Marketing, CRM, Market und Donations sind keine Voraussetzungen für den Beginn dieses Zyklus.
Die bestehende Integration offizieller Kanäle bleibt Teil des Ausgangsstands. Verbindungsstatus, erteilte Berechtigungen, erlaubte Aktionen und jedes tatsächliche Upload- oder Veröffentlichungsergebnis benötigen getrennte aktuelle Aufzeichnungen. Menschliche Uploads und automatisierte Veröffentlichungen sind unterschiedliche Wege; jeder folgt den für das tatsächliche Konto und die Aktion erteilten Befugnissen.
Die folgenden Zeitfenster sind Planungs- und Prüfziele, keine Zusagen für einen Start oder eine externe Freigabe. Arbeiten an Core/Studio und geschützte Market-/Donations-Testnet-Mechanismen gehören bereits zum Entwicklungsstand; spätere Zeitfenster beschreiben Abnahme oder Erweiterung und behaupten nicht, dass sämtliche frühere Implementierung fehlt. Die tatsächliche Bereitschaft wird für jeden Ablauf gesondert dokumentiert.
| Zeitfenster | Ergebnis | Abnahme und Abhängigkeiten |
|---|---|---|
| Oktober 2026 | Einheitliches Paket auf RU/EN/ES/PT/FR und Ausgangsstand offizieller Kanäle | Nicht belegte Zusagen entfernt; Verbindungsaufzeichnung, Rechte, Berechtigungen, externe ID und Beispielstatus geprüft |
| November 2026 | Wiederholbarer Studio- und YouTube-Zyklus | Vereinbarte Briefings abgeschlossen; Versionen, Qualität, Autorisierung, Veröffentlichungen und Kosten nachvollziehbar |
| Dezember 2026 | Regelmäßige redaktionelle Abläufe | Vereinbarter Kalender umgesetzt; Unterbrechung, Widerruf, ungeklärte Ergebnisse und Vermeidung von Duplikaten geprüft |
| Januar 2027 | Bericht zur Wirtschaftlichkeit offizieller Kanäle | Entstandene Erträge und Auszahlungen getrennt; Abonnements, Generierung, Arbeitszeit und Korrekturen enthalten; keine erfundenen Einnahmen |
| Februar 2027 | Entscheidung über die nächste Plattform und klar begrenzter Adapter | API-Zweck erlaubt; Zugang und Anwendungsfall bestätigt. Ohne Zulassung Medien vorbereiten, ohne automatische Veröffentlichung zu versprechen |
| März 2027 | Analyse unterstützt die redaktionelle Planung | Themen- und Formatänderungen an datierte Kennzahlen mit Quellenbezug gebunden; Qualität wird nicht durch Menge ersetzt |
| April 2027 | Entscheidung über externen Studio-Piloten | Eigener Ablauf stabil; Bedingungen, Rechte, Support und Budget vereinbart. Ohne Teilnehmer kein abgeschlossener Pilot |
| Mai 2027 | Gesonderte Bewertung von Marketing und CRM | Nutzen, Daten, Berechtigungen und Budget definiert; das Datum allein startet keine bezahlten Kampagnen |
| Juni 2027 | Präzisierte Bereitstellungsoptionen | Gemessene Grenzen und Preise; Lizenz, Updates, Support und Abnahme definiert |
| Juli 2027 | Begrenztes Market-Testszenario | Auftrag mit Version, Abnahme und Auslieferung verknüpft; Testumgebung vom kommerziellen Start getrennt |
| August 2027 | Prototyp für Live-Medien und Creator-Unterstützung | Streaming von Base-Zahlungen getrennt; Stopp, Moderation, Zahlungsautorisierung und Buchführung geprüft |
| September 2027 | Skalierungsentscheidung | Qualität, Einnahmen, Kosten und Verpflichtungen verglichen; Ergebnisse und zurückgestellte Aufgaben veröffentlicht |
Eigenständiger Arbeitsbereich Plattformzulassung
Für jeden Connector: Zweck bewerten → Berechtigungen und Konfiguration → begrenzter Test → Nachweise → erforderlichenfalls Zulassungsantrag → Korrekturen → Start innerhalb erteilter Grenzen. Termine externer Freigaben sind keine Lieferergebnisse des Teams.
TikTok Direct Post wird getrennt von der internen Nutzung eigener Medien bewertet. Für eine Prüfung wird kein fiktives öffentliches Produkt geschaffen. Jeder externe Connector benötigt einen echten Nutzerzweck und eine Oberfläche; alternative erlaubte Veröffentlichungswege erfordern eine eigene Bewertung.
Verschiebungen und Änderungskontrolle
Eine Phase ist nur mit Abnahmenachweisen abgeschlossen. Eine Verschiebung dokumentiert ihr ursprüngliches Zeitfenster, den Grund, den überarbeiteten Plan und Auswirkungen auf Abhängigkeiten; ursprüngliche Aufgaben- und Quellidentitäten bleiben als Herkunftsnachweis erhalten. Aktuelle Priorität ist die zuverlässige Produktion offizieller Medien und der erforderliche Veröffentlichungsablauf; externe Piloten und Modulerweiterungen werden als gesonderter Umfang zugelassen.
Zusätzliche Ressourcen können den Zeitplan ändern, ersetzen aber keine Plattformberechtigung, Materialrechte, Ergebnisqualität oder Wiederherstellung. Technische Kriterien · Integrationen.
Eigenständiger Arbeitsbereich: Vantemio Home
Die Home-Ausgabe wird parallel zu Kern und Studio entwickelt: Hardware-/Modell-/Aufgabenmatrix qualifizieren → begrenzter Installationspilot → Lizenzierung und Aktivierung → Updates, Entfernung und Wiederherstellung → Veröffentlichungsentscheidung. Gemessene unterstützte Profile und Grenzen werden nach der Abnahme veröffentlicht. Eine Referenzworkstation ist kein allgemeingültiges Minimum. Home-Bereitstellungsprofil.
Ein qualifizierter Rechner kann die unterstützten Rollen übernehmen, wenn die tatsächlichen Ressourcen ausreichen. Zusätzliche Ausführungsinstanzen werden über dieselben Registrierungs- und Zuweisungsmechanismen des Koordinators angebunden; ihre Zahl ist nicht festgelegt und ein zusätzlicher Laptop ist keine allgemeine Voraussetzung. Die Installation eines Clients oder das Verschieben von Dateien überträgt keine Befugnisse für bestehende Station-Aufträge.
Ein zusätzlicher kompatibler Laptop oder eine Workstation wird empfohlen, um geeignete Aufgaben zu verteilen. Je nach Arbeitslast und Verbindung kann dies Ressourcenkonflikte reduzieren, die Stabilität unter Last verbessern und Produktionszeiten verkürzen. Dies ist eine optionale Verbesserung: Ein qualifizierter Einzelrechner bleibt ein unterstütztes Bereitstellungsprofil.
Cloud-Bereitstellung und Qualifizierung
Die geplante Vantemio Cloud verbindet einen Client mit einem logisch einheitlichen koordinierten Dienst, während die zugelassene Infrastruktur KI und rechenintensive Arbeit ausführt. Home-Workstation-Anforderungen gelten nicht automatisch für den Client. Bereitstellung, Isolation, Wiederherstellung und Lastgrenzen benötigen eine Abnahme für die tatsächliche Konfiguration. Gemeinsames Lernen aus dem Betrieb verbessert Module innerhalb ausdrücklicher Datenberechtigungen; Kundenprojekte, Zugangsdaten und private Materialien bleiben isoliert und werden nicht automatisch für Training verwendet.
Langfristig: ein vollständiger Marktplatz
Vantemio Market auf Boson Protocol ist als eigenständiger Marktplatz mit mehreren Anbietern für digitale Dienstleistungen, herunterladbare Waren und physische Produkte geplant, einschließlich Kleidung und anderer zulässiger Kategorien. Ziel sind ein vollständiger Katalog, Handelsabläufe und Unterstützung für Käufer und Verkäufer.
Phasen: Studio-Dienste und digitale Auslieferung → Konten und Schaufenster externer Verkäufer → Katalog, Suche, Produktvarianten, Bestand und Aufträge → physische Waren, Logistik, Sendungsverfolgung, Rücksendungen und Support. Verkäufer- und Kategorieprüfungen, Angebotsregeln, Bewertungen verifizierter Bestellungen, Käuferschutz und Streitbeilegung gehören zum Plan.
Dienstleistungen benötigen ein vereinbartes Briefing und die Ergebnisabnahme; digitale Waren eine Prüfung von Paketversion, Lizenz, Integrität und Zugriff; physische Waren Verfahren für Spezifikation, Verpackung, Lieferung, Zustand und Rückgabe. Persönliche Adressen und private Nachweise bleiben außerhalb der Blockchain. Jede Produktkategorie benötigt eigene Bedingungen, Integrationen, Ressourcen und Abnahme; der vollständige Marktplatz ist ein gesonderter Entwicklungsumfang.
Gesonderte Produktdokumente: Market-Spezifikation · Market-Agenten und Governance · Technische Donations-Dokumentation · Regeln für Unterstützer und Creators · Donations-Roadmap.
Vantemio entwickelt zwei ergänzende kommerzielle Produkte: einen eigenen Marktplatz und eine wiederverwendbare Handels-Engine mit Agenten für kundeneigene Shops. Das geplante Softwareangebot ermöglicht Kunden, Shops auf Vantemio-Technologie mit eigener Marke, eigenem Katalog, eigenen Richtlinien und Abläufen zu betreiben. Als Erlöswege sind Softwarelizenzen, Bereitstellungs- und Integrationsdienste sowie Support vorgesehen; endgültige Pakete und Preise werden gesondert veröffentlicht. Ein Shop auf dem Vantemio-Marktplatz und eine kundeneigene Installation sind unterschiedliche Bereitstellungsprofile. Siehe Agentenarchitektur und Shop-Engine.
Das Produkt verwendet eine gemeinsame Handels-Engine. Vantemio soll auf dieser Engine einen eigenen separaten Shop betreiben und dieselbe Software anderen Entwicklern für deren Shops bereitstellen. Dies sind Bereitstellungen derselben Engine mit getrennter Shop-Konfiguration, Betreibern und Daten.
Kundenzahlungen für Vantemio-Software und Shop-Engine-Lizenzen, Waren und Dienstleistungen auf dem Marktplatz oder in Shops mit dieser Engine sowie Spenden erfolgen ausschließlich in Kryptowährung. Der Produktumfang enthält weder eine Fiat-Zahlungsabwicklung noch einen eingebauten Dienst zur Umwandlung in oder Auszahlung von Fiat-Währungen. Ein externer Umtausch oder eine Fiat-Auszahlung ist eine eigenständige Handlung des Nutzers außerhalb von Vantemio. Das jeweilige Angebot benennt unterstützte Netzwerke und Tokens, Betrag und Gebühren, Empfänger und Bedingungen der Zahlungsbestätigung.
Umfang der Meilensteine und Abnahmegrenzen
Jeder Meilenstein benennt den tatsächlichen Nutzer oder die ausführende Komponente, erlaubte Eingaben und Aktionen, Ergebnisversion, Qualitätskriterien, Ressourcen, Abhängigkeiten und Abnahmeaufzeichnung. Kundenauslieferung, Plattformzulassung und kommerzielle Bedingungen sind getrennte Entscheidungen. Private Budgets und Beschaffungsvereinbarungen gehören nicht zu dieser öffentlichen Roadmap.
Abgeschlossene, abgelehnte und verschobene Ergebnisse werden dokumentiert, ohne frühere Nachweise zu löschen oder ein Kalenderdatum als Implementierung darzustellen. Projekt- und Abnahmekriterien · Technische Dokumentation.
Lokale KI und Ressourcenlebenszyklus
Die Modellauswahl richtet sich nach registrierten Fähigkeiten, aktueller Bereitschaft, Aufgabeneignung und tatsächlicher Ergebnisqualität. Der erforderliche Lebenszyklus nutzt gemessenen physisch verfügbaren Speicher, bedarfsgesteuertes Laden und die Freigabe oder Wiederherstellung eigener temporärer Ressourcen; feste RAM-Reserven und doppelte Abzüge für bereits verbrauchten Speicher gehören nicht zum Zulassungsmodell. Aktive Arbeit und ungeklärte Ergebnisse werden vor der Wiederherstellung abgeglichen. Abgenommene Sprachausgabe, Transkripte und andere abgeschlossene Ergebnisse werden wiederverwendet, statt sie zur Rekonstruktion eines fehlenden Caches neu zu erzeugen.
Abschließende Phase: ein Loyalitätstoken für das Ökosystem
Wenn die Kernprodukte bereit sind und das Ökosystem zuverlässig arbeitet, kann Vantemio einen eigenen Loyalitätstoken einführen. Mögliche Nutzungen sind Belohnungen, Zugang zu Abonnements und internen Diensten sowie Rabatte auf anwendbare Gebühren. Regeln zu Erwerb, Einlösung, Erstattung und Einschränkungen werden vor dem Start definiert.
Ein Loyalitätstoken ist keine Voraussetzung für die Kernprodukte. Dieses Dokument begründet weder einen Tokenverkauf noch ein Ausgabenetzwerk, Renditen oder automatisch gewährte Rechte. Jede spätere Veröffentlichung benötigt ein eigenes technisches Konzept, eine Sicherheitsprüfung, eine Bewertung des anwendbaren Rechts und veröffentlichte Nutzungs-, Einlösungs- und Einschränkungsregeln. Die Bezeichnung als Loyalitätstoken allein bestimmt keinen rechtlichen Status. Quellen und Implementierungsreferenzen.
Lokale Generierung und private Kundeninstallation
Ein gesonderter Bereitstellungsweg: lokale Modelle auswählen → Rechte und Ressourcen prüfen → Qualität testen → lokale Adapter integrieren → privaten Ablauf und Netzwerkbeschränkungen prüfen → Kundeninstallation abnehmen. Zeitplan und Lieferumfang folgen der Bewertung; externe Generierung ist für dieses Profil nicht verpflichtend.
Lokale Bereitstellungsprofile.
Ein vollständig autonomer KI-Cluster für Unternehmen
Ein Unternehmen oder eine Agentur mit einem leistungsstarken privaten Server oder Cluster kann auch das zentrale leistungsfähige Modell selbst betreiben, das Aufgaben interpretiert, die Produktion plant und Vantemio-Werkzeuge steuert. Unterstützende Modelle, Bild-/Videogeneratoren, Gedächtnis, Schnitt, Audio, Rendering und Qualitätsprüfungen laufen ebenfalls lokal. Dieses Profil benötigt für den Produktionsablauf weder externe Cloud-KI noch einen Cloud-Assistenten oder externe Generierung: Die Kundeninfrastruktur führt den gesamten Prozess aus.
Selbsthosting erfordert leistungsfähige Modelle mit verfügbaren Gewichten oder vertraglichen Rechten für den Betrieb vor Ort. Große GPU-Kapazität allein ermöglicht keine Installation eines geschlossenen Modells, das nur über die Cloud eines anderen Anbieters angeboten wird. Unterstützte Modelle, Adapter, Qualität und Aufgaben werden in der Kompatibilitätsmatrix dokumentiert und bei der Abnahme validiert. Der Kundencluster wird als gesondertes Bereitstellungsprojekt bewertet und gehört nicht zum anfänglichen Budget der eigenen Vantemio-Rechenworker.
Bereitstellungswahl und Produktpriorität
Vantemio entwickelt eine Engine mit lokalen, hybriden, Cloud- und privaten Unternehmensprofilen. Creators und kleine Teams benötigen einen klaren Ablauf und passende Hardware; Agenturen benötigen Kontrolle über Kundendaten, Wiederholbarkeit und Freigaben; Unternehmen benötigen Kontrolle über die eigene Umgebung. Die Auswahl richtet sich nach Qualität, Gesamtkosten, Arbeitslast und Zugriffsregeln, nicht nach einer verpflichtenden Abhängigkeit von einer Cloud oder GPU-Klasse.
Der gemeinsame Produktionsablauf und austauschbare Modelladapter werden zuerst validiert; unterschiedliche Bereitstellungsprofile folgen. Vollständig lokaler Betrieb benötigt keine festgelegte Menge an GPU-Speicher: Die Kapazität hängt von den gewählten Modellen und der Parallelität ab. Ein großer Server ersetzt keine Qualitäts-, Kompatibilitäts- und Lizenzprüfungen. Cloud-Kapazität bleibt für autorisierte Aufgaben verfügbar, niemals als versteckte Abhängigkeit eines privaten Profils.
Cloud-KI und lokale/hybride Ausführung werden parallel entwickelt.
Ein vollständig lokales oder privates Profil wird nur für die tatsächlich qualifizierten Modelle, Aufgaben und Abhängigkeiten abgenommen. Zulässige Datenübertragungen nach außen, Zugangsdaten, Speicher, Updates und Wiederherstellung werden geprüft, einschließlich des Fehlens eines nicht offengelegten Cloud-Rückfalls. Hardwarekapazität oder eine Bereitschaftsmarkierung allein im Quellcode belegen keine Lieferverfügbarkeit. Technische Dokumentation · Quellen.