Ihr Algorithmus, versioniert - und noch am selben Tag im Produktivbetrieb.
Den Anomaliedetektor schreiben Sie an einem Nachmittag. Ihn auf eine Maschine in einem Werk zu bekommen - Anbindung, Deployment, Update-Weg, die Person, der der Server gehört - kostet die übrigen sechs Monate.
Im Collectu Hub ist Ihr Algorithmus ein Python-Modul. Sie veröffentlichen eine Version; sie erscheint in der Editor-Palette jedes Kontos, das sie ausführen darf - mit dem Parameterformular, das aus Ihrer eigenen Dataclass erzeugt wird.
Nichts davon ist ein Modellierungsproblem.
Das Modell funktioniert auf dem Export. Es auf Live-Daten zu betreiben heißt, dass jemand einen Dienst, einen Scheduler, eine Datenanbindung und einen Ablageort dafür baut.
Der Prototyp ist die Lieferung - und wird nie ein zweites Mal verwendet.
Anderes Historian-System, anderes Protokoll, andere Deployment-Regeln. Der Algorithmus hat zweihundert Zeilen; die Integration darum herum wird jedes Mal neu geschrieben.
Ihre Marge steckt in Klempnerarbeit - und die summiert sich nicht auf.
Wer das Problem hat, sucht eine Lösung, nicht Sie. Einen Vertriebskanal aufzubauen ist ein zweites Geschäft neben dem ersten.
Sie rechnen Tage ab - und Tage skalieren nicht.
Dieselben vier Schritte beim ersten wie beim vierzigsten Modul.
Von der Input-, Prozessor- oder Output-Basisklasse ableiten, eine Configuration-Dataclass deklarieren, start, stop und run implementieren. Für alle drei gibt es eine Vorlage.
Im Browser oder aus Ihrer CI mit einem eingegrenzten Zugriffstoken. Der Hub liest Parameter, Abhängigkeiten, Datenanforderungen und Dokumentation aus dem Code.
Wer sie verwenden darf, zieht sie auf die Arbeitsfläche. Das Formular entsteht aus Ihrer Dataclass - Typen, Standardwerte, Beschreibungen und die Angabe, welche Felder geheim sind.
Erneut veröffentlichen. Konfigurationen, die der neuesten Version folgen, übernehmen sie; Konfigurationen mit fixierter Version bleiben, wo sie sind, bis jemand sie bewegt.
Drei Arten - Input, Prozessor, Output - mit je einer Basisklasse. Alles, was die Plattform wissen muss, steht in der Datei: Parameter mit Typ, Standardwert und Beschreibung, Abhängigkeiten von Drittanbietern sowie die Felder und Tags, die Ihr Code auf einem Datenobjekt erwartet.
Markieren Sie einen Parameter als geheim, gibt der Hub ihn in keiner API-Antwort zurück. Deklarieren Sie eine Abhängigkeit, installiert der Core sie. Schreiben Sie die Dokumentation als Docstring des Moduls, wird sie zur Seite des Moduls.
Es gibt kein Manifest, das mit dem Code synchron gehalten werden müsste - weil der Code das Manifest ist.
Jede Veröffentlichung ist eine Version mit Commit-Nachricht, Autor und Zeitstempel, und jede Version behält ihre eigenen Parameter und ihre eigene Dokumentation.
Eine Konfiguration fixiert entweder eine Version oder folgt der neuesten. Veröffentlichen verändert nie stillschweigend, was auf einer Maschine läuft - und genau diese Eigenschaft bringt einen Betreiber erst dazu, Ihren Code überhaupt auszuführen.
Öffentliche Module können automatisch geprüft werden, und ein Konto kann das verlangen, bevor seine Instanzen sie ausführen dürfen. Dieses Signal bekommen Sie durchs Veröffentlichen geschenkt.
Veröffentlichte Module sind nach Typ, Eigentümer und angebundenem System durchsuchbar, neben den offiziellen, in der Palette jedes Collectu-Nutzers.
Private Module verhalten sich innerhalb eines Kontos oder einer Organisation exakt genauso - so liefert eine Beratung ihre eigene Bibliothek an ihre eigenen Kunden aus.
Für alles, was der Browser tut, gibt es einen Endpunkt: ein Modul veröffentlichen, eine Konfiguration ausrollen, den Zustand einer Instanz lesen, Daten abfragen. Zugriffstokens tragen eigene Rechte zum Anlegen, Bearbeiten und Löschen sowie eine Gültigkeitsdauer.
Damit wird Veröffentlichen zu einem Schritt in Ihrer bestehenden Pipeline - Modul testen, Version veröffentlichen, Release taggen - statt zu einem Handgriff.
Dazu kommt ein Model-Context-Protocol-Server, über den Ihre eigenen Agenten dieselben Ressourcen mit denselben Berechtigungen lesen und ändern können.
Entdecken Sie unsere Anwendungsfälle aus der Praxis.
Lesen Sie den Modulvertrag
Die Basisklassen, die Configuration-Dataclass, das Bereitschafts-Gate und die Datenanforderungen sind dokumentiert - samt lauffähiger Vorlage für jede der drei Modularten.
