# Vantemio Market: Agenten und Entscheidungsgouvernanz

Revision 2026-10-16 · Öffentliche technische Spezifikation · In Entwicklung

## 1. Zweck und aktueller Status

Dieses Dokument beschreibt die Agentenebene für Vantemio Market auf Boson Protocol. Es ergänzt die [Market-Spezifikation](market.md) und die [Kern- und Studio-Dokumentation](technical.md). Market-Agenten bewerten Nachweise und unterstützen Commerce-Workflows; Station bleibt für die Zulassung von Studio-Produktionsjobs verantwortlich.

| Status | Was diese Revision festlegt |
|---|---|
| In der Quelle beobachtet | Validierung von Moderationseingaben/Empfehlungen, versionierte Richtlinien, Nachweisreferenzen und Hashes, Governance-Aufzeichnungen und ein separater Testnet-Commerce-Autorisierungsschutz. |
| In Entwicklung | Vollständige Integration zwischen Modellausgabe, unabhängig geprüften Nachweisen, Durchsetzung, unabhängiger Überprüfung, Einspruch und Wiederherstellung in tatsächlichen Käufer-/Verkäufer-Workflows. |
| Geplante Abnahme | Ein veröffentlichter, um vertrauliche Angaben bereinigter Release-Datensatz, der diese Workflows und ihre Fehlerfälle demonstriert. |

Quellprüfungen stellen Implementierungsdetails fest; sie stellen keinen öffentlich verfügbaren autonomen Marktplatz, keine Mainnet-Bereitschaft, kein unabhängiges Security-Audit und keine Qualität eines bestimmten Modells fest. Funktionale Rollen unten beschreiben die beabsichtigte Trennung der Zuständigkeiten, nicht die Behauptung, dass für jede Rolle ein separater Produktionsagent deployed ist.

## 2. Rollen und Zuständigkeit

| Rolle | Zuständigkeit | Grenze |
|---|---|---|
| Verkäufer- und Listing-Prüfung | Prüfung von Verkäufernachweisen, Vollständigkeit des Listings, Rechten und Signalen für verbotene Inhalte. | Eine Empfehlung kann keine verifizierte Verkäuferidentität erzeugen oder die vereinbarten Bedingungen eines Angebots ändern. |
| Asset- und Lieferprüfung | Bewertung des exakten Pakets anhand seines Manifests, Formaten, Lizenz und Abnahmekriterien. | Dateiintegrität, erfolgreicher Download und Kundenabnahme sind separate Tatsachen. |
| Transaktionsassistent | Erläuterung von Angebotsbedingungen und Vorbereitung einer Aktion für den autorisierten Akteur. | Eine Modellantwort ist keine Wallet-Signatur oder Ausgabeberechtigung. |
| Richtliniendurchsetzung | Anwendung einer zugelassenen, versionierten Entscheidung auf die zulässige Katalog-/Konto-Operation. | Monetäre Aktionen und Protokollübergänge verwenden ihre eigene Autorisierung und Zustandsprüfungen. |
| Unabhängige Überprüfung und Einsprüche | Erneute Prüfung von Nachweisen, Erkennung von Konflikten und Aufzeichnung einer korrigierten Entscheidung. | Eine Korrektur bewahrt die ursprüngliche Entscheidung und kann die Blockchain-Historie nicht umschreiben. |

Modelle sind hinter der bestehenden Adapter-Grenze austauschbar. Ein Modellname, Confidence-Score oder funktionierender Endpunkt begründet keine Aufgabeneignung. Die Qualifizierung muss die tatsächliche Sprache, Produktkategorie und Entscheidungsaufgabe abdecken.

## 3. Vom Nachweis zur angewandten Entscheidung

Der erforderliche Ablauf ist: Tenant und Subjekt-Revision identifizieren → zulässige Nachweise sammeln → Richtlinien-/Modellversionen aufzeichnen → strukturierte Empfehlung erzeugen → Nachweise und anwendbare Autorität verifizieren → Entscheidung anwenden oder eskalieren → tatsächliches Ergebnis aufzeichnen → Überprüfung ermöglichen, wo anwendbar.

Das aktuelle Empfehlungsschema unterscheidet `approve`, `reject` und `needs_review`. Governance-Aufzeichnungen stellen separat `enforced`, `blocked` oder `escalated` dar. Ein validierter Datensatz ist für sich genommen kein Beweis, dass ein autorisierter Consumer eine Entscheidung angewendet hat. Eine hash-förmige Nachweisreferenz ist kein Beweis, dass die referenzierten Bytes abgerufen oder bewertet wurden.

Ein akzeptabler Entscheidungsdatensatz bindet Subjekt und Tenant, Eingabe- und Nachweis-Hashes, Empfehlung, Richtlinien- und Modellversionen, Entscheidungszeitpunkt, autorisierte Aktion, tatsächliches Ergebnis und jede vorherige Entscheidung im Einspruch. Widersprüchliche oder unvollständige Nachweise erfordern Eskalation statt einer erfundenen Erfolgsmeldung. Die Integration muss tenant-übergreifende, veraltete Subjekt- und inkompatible Richtlinien-Substitutionen ablehnen.

## 4. Smart Contracts und Signierung

KI-Inferenz, privates Material und detaillierte Prüfung bleiben off-chain. Verträge und Protokoll-Events liefern die anwendbaren Transaktionszustände und Commitments. Ein aufgezeichneter Hash demonstriert eine Bindung an Bytes; er begründet kein Eigentum, keine sachliche Richtigkeit und keine künstlerische Qualität.

Bosons Agenten-Dokumentation trennt Transaktionsvorbereitung, Signierung und Broadcast. Vantemio muss die exakte Aktion und Autorität an jeder anwendbaren Grenze verifizieren. [Boson-Signaturmuster](https://www.bosonprotocol.io/docs-app/agents/signing/).

Die geprüfte Vantemio-Testnet-Commerce-Guard prüft Akteur-/Methoden-Berechtigungen, Chain und Ziel, Calldata, Implementierungsbindung, Nonce, Ablauf und unterschiedliche registrierte Unterzeichner; sie prüft die Autorisierung vor dem Broadcast erneut. Diese Prüfungen sind spezifisches Quellverhalten. Mehrere Signaturen beweisen für sich genommen keine unabhängige organisatorische Kontrolle, kein unabhängiges KI-Urteil und keine Berechtigung für eine andere Aktion. Die Produktionsautorisierung bleibt Gegenstand separater Release-Abnahme.

## 5. Moderation, Einsprüche und Kaufstreitigkeiten

Eine Listing-Einschränkung, ein Einspruch gegen eine Moderationsentscheidung und ein Kaufstreit sind unterschiedliche Verfahren. Ein Einspruch muss die Entscheidung, angefochtene Nachweise und die beantragte Korrektur identifizieren. Das erforderliche Ergebnis dokumentiert Gründe, Richtlinienrevision und ob Einschränkungen aufrechterhalten, geändert oder aufgehoben werden; frühere Aufzeichnungen bleiben autorisierten Prüfern zugänglich.

Boson definiert separate Exchange- und Dispute-Zustände. [Exchange-Lifecycle](https://www.bosonprotocol.io/docs-app/concepts/exchange-state-machine/), [Dispute-Lifecycle](https://www.bosonprotocol.io/docs-app/concepts/dispute-state-machine/).

Eine Support-Anfrage oder KI-Prüfung setzt Protokollfristen nicht aus und ersetzt nicht den designierten Teilnehmer/Resolver. Das aktive Angebot und das deployed Protokoll bestimmen verfügbare Rechtsbehelfe. Agenten müssen relevante Fristen und Unsicherheiten sichtbar machen. Einem Kunden darf nicht mitgeteilt werden, dass ein Einspruch die Abwicklung automatisch gestoppt hat. Die vollständige Integration von Einspruch bis Durchsetzung bleibt eine Abnahmevoraussetzung.

## 6. Datenschutz und adversarielle Eingaben

Produktbeschreibungen, hochgeladene Dateien, abgerufene Seiten und Modellausgaben sind nicht vertrauenswürdige Daten. Anweisungen in ihnen dürfen keine Privilegien gewähren, Richtlinien ändern, Signierungen auslösen oder Dateien eines anderen Käufers offenlegen. Marker-Filterung ist eine unterstützende Prüfung, keine vollständige Prompt-Injection-Abwehr.

Die Integration erfordert Tenant- und Auftragszugriffsprüfungen, begrenzten Abruf, zulässige Provider und minimale Offenlegung. Schlüssel, Credentials, rohe Kundendateien und personenbezogene Informationen dürfen nicht in öffentliche Metadaten oder On-Chain-Nachweise gelangen. Hashes sind Integritätsreferenzen, keine Garantie für Anonymität. Private Nachweise müssen nur für ihren autorisierten Zweck und Aufbewahrungszeitraum zugänglich bleiben.

## 7. Fehler, Wiederherstellung und wiederholte Ausführung

Die erforderliche Operationsidentität überlebt Neustarts. Ein Timeout nach dem Dispatch ist ein unbekanntes Ergebnis, bis Belege, Transaktionszustand und Operationsjournal abgeglichen sind. Ein akzeptiertes Ergebnis wiederverwenden statt einen zweiten Kauf, eine Durchsetzungsaktion, Zugangsgewährung oder ein Rendering zu erzeugen. Boson dokumentiert ebenfalls Zustandsabgleich vor dem Wiederholen von Schreibvorgängen. [Idempotenz und Retry](https://www.bosonprotocol.io/docs-app/agents/idempotency/).

Modell-Nichtverfügbarkeit, ungültige strukturierte Ausgabe, widersprüchliche Reviewer und abgelaufene Autorisierung benötigen explizite Ergebnisse. Die Wiederherstellung verwendet die ursprüngliche Subjekt- und Operationsidentität; neue Richtlinie oder Nachweise erzeugen eine aufgezeichnete Revision. Commerce-Zustand, Moderationszustand, Lieferzugang und Studio-Job-Zustand dürfen nicht zu einem einzigen Erfolgsflag zusammengefasst werden.

## 8. Release-Abnahme

Die Abnahme erfordert einen tatsächlichen autorisierten Consumer und einen um vertrauliche Angaben bereinigten Datensatz seines Ergebnisses: gültige und abgelehnte Listings; geänderte Verkäufernachweise; ein modifiziertes Lieferpaket; Fremd-Tenant-Zugriff; adversarielle Anweisungen; nicht unterstützte Richtlinie; Modellfehler; widersprüchlichen Review; abgelaufene Autorisierung; unterbrochenen Dispatch; doppeltes Event; stattgegebenen Einspruch und Aufhebung. Transaktionstests müssen die vorgesehene Testumgebung nutzen und isolierte Verifizierung von operationellen Ergebnissen unterscheiden.

Der Release-Datensatz identifiziert Quell- und Richtlinienrevisionen, deployed Konfiguration, Modell-/Aufgaben-Qualifizierung, beobachtete Ergebnisse und verbleibende Grenzen. Security-Review, Lastkapazität, Mainnet-Deployment und rechtliche Freigabe sind separate Behauptungen, die jeweils eigenen Nachweis erfordern.

## 9. Commerce-Engine für kundeneigene Stores

Vantemio entwickelt seinen eigenen Marktplatz und daneben eine wiederverwendbare Commerce-Engine mit Agenten, die Kunden kaufen oder lizenzieren können, um eigene Stores zu eröffnen und zu betreiben. Der Verkauf von Software für Kunden-Stores ist eine separate Produktrichtung vom Verkauf von Waren und Dienstleistungen über den Vantemio-Marktplatz. Das Ziel ist ein wiederholbares Softwareprodukt mit dokumentierten Schnittstellen, Installation, Konfiguration und Updates.

Das Produkt nutzt eine gemeinsame Commerce-Engine. Vantemio wird seinen eigenen separaten Store auf dieser Engine betreiben und dieselbe Software an andere Entwickler für deren Stores liefern. Dies sind Deployments derselben Engine mit separater Store-Konfiguration, Betreibern und Daten. Geeignete offizielle Boson- und OpenZeppelin-Komponenten können über die bestehenden Schnittstellen wiederverwendet oder angepasst werden, mit Versions-, Lizenz- und Sicherheitsprüfungen. Das Produkt erfordert kein Neuschreiben etablierter Bibliotheken von Grund auf.

Die geplante Struktur umfasst eine gebrandete Storefront; Katalog, Angebote und Inventar; Kunden- und Verkäuferkonten; Aufträge und Lieferung; agentenunterstützte Moderation, Empfehlungen und Einsprüche; Zahlungs- und Protokolladapter; sowie eine Operator-Konsole mit Zugangskontrolle und Operationshistorie. Diese Module beschreiben die Zielproduktzusammensetzung. Die Verfügbarkeit wird für jeden akzeptierten Release festgestellt, nicht aus dieser Liste abgeleitet. Agentenrollen und Zahlungsautorität behalten die oben beschriebenen Grenzen.

Ein kundeneigener Store muss seinen Katalog, Aufträge, Richtlinien, Credentials und private Nachweise von anderen Stores trennen. Gemeinsames Hosting und eine dedizierte Installation erfordern jeweils eigene Isolations- und Recovery-Abnahme. Der Kauf der Engine meldet einen Store nicht im öffentlichen Vantemio-Katalog an, überträgt keinen Kunden-Content auf andere Stores und autorisiert Agenten nicht zum Signieren von Zahlungen. Verbindungen zum öffentlichen Marktplatz werden separat konfiguriert und autorisiert.

Die geplante Monetarisierung umfasst kommerzielle Softwarelizenzen, Deployment und Integration, Updates und Support. Ein gehosteter Service kann nach Abnahme als separates Delivery-Paket angeboten werden. Lizenzumfang, Branding-Rechte, enthaltene Module, Support- und Update-Bedingungen, Hostingkosten sowie etwaige Transaktionsgebühren müssen im jeweiligen Angebot ausgewiesen werden. Kein Lizenzpreis, Abonnementssatz oder Marktplatzgebühr wird durch dieses Dokument fixiert. Eine Lizenz für Vantemio-Software gewährt nicht automatisch Rechte an Modellen, Komponenten oder Inhalten Dritter.

Kundenzahlungen für Vantemio-Software und Store-Engine-Lizenzen, Waren und Dienstleistungen auf seinem Marktplatz oder in Stores, die die Engine nutzen, sowie Spenden erfolgen ausschließlich in Kryptowährung. Der Produktumfang umfasst keine Fiat-Zahlungsabwicklung und keinen eingebauten Fiat-Umtausch- oder Auszahlungsdienst. Ein externer Umtausch oder eine Auszahlung in Fiat ist die eigenständige Handlung des Nutzers außerhalb von Vantemio. Das jeweilige Angebot benennt unterstützte Netzwerke und Token, Betrag und Gebühren, Empfänger und Zahlungsbestätigungsbedingungen.

Vor dem Angebot eines Pakets zum Verkauf muss die Abnahme einen Store von der Installation bis Katalog, zulässiger Bestellung, Lieferung, Agentenentscheidung und Review, Update, Backup und Recovery demonstrieren. Die Release-Dokumentation benennt unterstützte Module, Abhängigkeiten, Datenhandhabung, Kundenverantwortlichkeiten und bekannte Grenzen. Der eigene Marktplatz und die verteilbare Store-Engine bleiben in Entwicklung; diese Richtung kündigt kein verkaufsfertiges Paket und keinen Produktionszahlungszugang an.

## 10. Revisionsnachweise und zugehörige Dokumente

Die am 16. Oktober 2026 geprüfte Implementierungsbasis umfasst Governance-Validierung und die Testnet-Commerce-Guard. Source SHA-256: `ai-governance.mjs` — `8f365f2e69b5905345ba10d20e028402605e1c811ca0998653f2a964a295553b`; `commerce-policy.mjs` — `ca394da54bc9dd2b92a250c23a132a797021d5f0cfb9c03fbb3615333baa1ed5`. Diese identifizieren geprüfte Bytes, nicht ein deployed Release oder ein abgeschlossenes Audit.

[Market](market.md) · [Technische Dokumentation](technical.md) · [Whitepaper](whitepaper.md) · [Roadmap](roadmap.md) · [Datenschutz](privacy.md) · [Bedingungen](terms.md)