Trust Center
Diese Seite trennt Produktstand, technische Evidence, synthetische Showcases und offene Grenzen. Sie ist kein Zertifikat. Öffentliche Beispiele verwenden nur erfundene Unternehmen mit .example Domains. Reale Betreiberwerte aus Search Console, Bing oder Analytics sind kein Marketingbeleg und erscheinen hier nicht.
Ein Installer Test belegt Installation. Ein HTTP 200 belegt Erreichbarkeit. externalWrites 0 belegt, dass der Testlauf kein externes System verändert hat. Keiner dieser Befunde beweist Rankings, Zitate, Leads, Zeitgewinn oder Umsatz.
Gebaut bedeutet, dass Code vorhanden ist. Geprüft bedeutet, dass ein benannter Test mit reproduzierbarem Ergebnis lief. Beobachtet bedeutet, dass eine Messung in einem passenden Zeitraum vorliegt. Offen bedeutet, dass die Aussage noch nicht getragen wird. Das Proof Ledger nutzt diese Trennung.
Velunor Bikes unter velunor-bikes.example, Qevora Systems unter qevora-systems.example und Studio Talvori unter studio-talvori.example sind erfundene Unternehmen. Namen, Domains, Ziele, KPIs, Freigaben und Ergebniswerte dienen nur der Produktdarstellung. Sie sind keine Kundenreferenzen.
Der erste implementierte Addon Umfang wird mit Founding Partnern geprüft. Ein final signiertes öffentliches Releaseartefakt, Self Service Checkout und allgemeiner Lizenzverkauf existieren noch nicht.
OpenClaw und Hermes nutzen in Direct begrenzte Werkzeuge für lesende Arbeit und lokale Entwürfe. Direct ist keine Prozessisolation und nicht für beliebige fremde Eingaben gedacht.
OpenClaw Secure ergänzt Docker Schutz, ist aber noch nicht untrusted oder Production ready. Hermes Secure ist nicht verfügbar und stoppt vor jeder Änderung. Eine allgemeine Secure Zusage für beide Runtimes wäre falsch.
Dreizehn lokale Tests prüfen Sequenzlücken, Rücksprünge, Forks, falsche Schlüssel, manipulierte Ledger, gelöschte Tails, konkurrierende Writer, unklare Persistenz und denselben Betriebssystemaccount. Der letzte Fall wird bewusst nicht als unabhängig akzeptiert. Die dedizierte Reviewer-Bereitstellung betreibt den Witness unter einer zweiten Identität; dieser Beleg ist auf den Reviewer-Host begrenzt.
Automatisierte Lifecycle Tests laufen in isolierten Windows Testverzeichnissen. Eine frische Kundenmaschine und ein aus dem aktuellen Quellstand gebautes, signiertes Paket wurden damit nicht geprüft. Der reale Release Lebenszyklus ist für Windows, macOS und Linux noch offen.
Die fünf Dienste laufen als getrennte Prozesse, im Standardaufbau aber unter demselben Benutzerkonto. Das ersetzt keine Kernel Grenze. Für produktive Isolation sind getrennte Konten, Container oder eine gleichwertige Plattformgrenze nötig.
Workspace, Ziele, Evidence, Actions, Freigaben, Receipts und Audit liegen in der lokalen Produktdatenbank. Website und Bing nutzen getrennte Quellenpfade. Google-Tokens bleiben serverseitig im Managed Connector und erreichen nie Browser, Local Agent, OpenClaw, Hermes oder ein Modell. Die öffentliche Website lädt Analytics erst nach Einwilligung. Formulardaten werden nicht an Analytics übertragen.
Der SHA256 Wert eines ZIP Archivs prüft dessen Bytes. Er beweist nicht, wer es veröffentlicht hat. Für die Herausgeberidentität muss der vollständige Public SPKI SHA256 Fingerprint über einen unabhängigen Kanal bezogen und mit dem Signaturschlüssel verglichen werden. Er darf nicht aus demselben ZIP oder seinen Sidecars übernommen werden. Ein endgültiger Fingerprint erscheint hier erst nach eindeutiger Prüfung der finalen Release Sidecars.
Ein offener Meldeweg ist wichtiger als ein erfundenes Gütesiegel. Hinweise gehen an francesco@scilipoti.de. Ein formales Bug Bounty Programm, garantierte Reaktionszeiten und externe Zertifizierungen bestehen derzeit nicht.
Dazu gehören vollständige Workload Isolation, ein final signiertes Kundenartefakt, Google Review und die allgemeine Kundenfreigabe sowie echte Kundenläufe auf Windows, macOS und Linux. Der getrennte Witness-Beleg der dedizierten Prüfumgebung gilt nur für den Reviewer-Host. Allgemeine CMS-, Bing- und andere Writes brauchen weiterhin einen eigenen Connectorvertrag. Die aktuellen 11 von 11 Quellbelege schließen keine dieser Grenzen automatisch.
Sicherer Abruf
Diese Dateien sind Prüfwerkzeuge und noch kein freigegebenes Kundenpaket. Der öffentliche Release Pointer ist nicht veröffentlicht. Nach seiner Veröffentlichung prüft der Acquisition Bootstrap zuerst dessen Signatur und danach das unveränderliche Release Set mit allen sieben Zielsystemen und 56 Dateibindungen. Erst daraus wählt er die acht Dateien für das aktuelle System. Der separat bezogene Verifier, die Trust Pins und der öffentliche Release Schlüssel bleiben eigene Vertrauensanker. Er startet MarketingOS nicht. Vergleiche die Prüfsummen dieser Dateien zuerst über einen unabhängigen Kanal.
Weiterlesen
Die Sicherheitsseite erklärt Direct Profile, Secure Profile und die Grenzen der Host Runtime ohne Abkürzungen.