Dateien

Eine File in Pipelogic ist Daten, kein Code. Eine Component ist eine typisierte, versionierte, containerisierte Fähigkeit; eine File sind die Modellgewichte, der Datensatz, die Fixture, das Konfigurationsdokument oder das Archiv, das die Component beim Ausführen lädt. Die beiden sind bewusst getrennte Primitive, und der Backend-Graph ist der Ort, an dem sie sich treffen.

Was eine File tatsächlich ist

Eine File ist ein typisiertes, benanntes, adressierbares Objekt im Workspace. Sie wird einmal hochgeladen, einmal gespeichert, nach ihrem eigenen Zeitplan versioniert und per Referenz wiederverwendet, anstatt in ein Component-Image kopiert zu werden. Ein einziges typisiertes File-Konzept deckt ein mehrere Gigabyte großes Modell, einen kleinen Tokenizer, eine CSV-Fixture, ein Triton-Modell-Repository und ein YAML-Konfigurationsdokument ab — es gibt keine getrennte Maschinerie für „Modelldatei" und „Datendatei", nur einen file_type, der angibt, was das Artefakt ist und welche Slots es akzeptieren.

Die entscheidende Eigenschaft ist, dass die File und die Bindung getrennt sind. Das Hochladen eines Modells erzeugt ein Workspace-Artefakt und nichts weiter; das Artefakt läuft erst, nachdem es in einen bestimmten Slot an einem bestimmten Backend-Vertex gebunden und dieses Backend deployt wurde. Dieselbe File kann gleichzeitig in viele Backends und viele Vertices gebunden werden, und sie gegen eine andere auszutauschen ist eine Graph-Mutation — die Bindung neu ausrichten — kein erneutes Bauen einer Component.

Warum Dateien ihr eigenes Primitiv sind

Modelle, Fixtures und Konfigurationen haben Lebenszyklen, die nicht mit Component-Lebenszyklen übereinstimmen. Ein Component-Release ist unveränderlich; ein Modellartefakt wird nach seinem eigenen Zeitplan ausgetauscht; ein Fixture-Satz entwickelt sich unabhängig weiter. Eines davon in die Component zu falten würde das Image aufblähen und für jede Artefaktänderung eine Neuveröffentlichung erzwingen. Die File getrennt zu halten kostet einen zusätzlichen Schritt — hochladen, dann binden, statt das Artefakt im Code mitzuliefern — und im Gegenzug kann dasselbe Modell über Geschwister-Vertices in einem Backend hinweg verglichen werden, dieselbe Fixture über Regressionssuites hinweg wiederverwendet werden und derselbe Tokenizer neben vielen Modellen liegen, nichts davon erfordert ein erneutes Bündeln einer Component.

Die drei Referenzseiten

Alles Weitere über Dateien teilt sich in drei Aspekte auf, jeder mit seiner eigenen Seite:

Wie eine Component eine Datei anfordert. Eine Component deklariert die Slots, die sie benötigt, unter worker.file_schema, und die Dateien, die sie erzeugt, unter worker.generated_file_schema. Dieser Vertrag steht in Dateischema.

Welche Datei in welchem Slot erlaubt ist. Jeder Slot und jeder Upload trägt einen file_type. Die Plattform verweigert eine Bindung, sofern der Typ der hochgeladenen File den Slot nicht erfüllt. Die vollständige Werteliste steht in Dateitypen.

Wie eine Datei hochgeladen und angehängt wird. Das Hochladen registriert das Artefakt und seinen Typ; das Binden hängt es an einen Vertex-Slot an und kann Konfigurationsstandards in den Graphen tragen. Die Mechanik, einschließlich der häufigen Fehler bei Typkonflikten, steht in Dateibindung.

Mentales Modell

workspace files                       backend graph
───────────────                       ─────────────
                                      ┌────────────┐
   detector.onnx ──(add-file)──▶      │  vertex A  │
   (file_id, type=onnx)               │  ┌───────┐ │
                                      │  │ model │◀┼── detector.onnx
   tokenizer.json ──(add-file)──▶     │  └───────┘ │
   (file_id, type=tokenizer)          │  ┌───────┐ │
                                      │  │ tokn  │◀┼── tokenizer.json
                                      │  └───────┘ │
                                      └────────────┘

Die beiden Hälften bleiben unabhängig. Eine hochgeladene File wartet im Workspace, bis etwas sie bindet; die Bindung wird zur Deploy-Zeit wirksam. Deshalb ist ein dateigestütztes Backend reproduzierbar: die Bindung ist ein Eintrag im event-sourced Operations-Log, die File, auf die sie zeigt, ist unveränderlich, und ein erneutes Deployment spielt dieselbe Verdrahtung ab.

Verwandt

• Dateischema — die Slots deklarieren, die eine Component füllt, und die Dateien, die sie erzeugt.
• Dateitypen — der file_type-Katalog, der jede Bindung absichert.
• Dateibindung — Hochladen, Konfiguration anhängen und an einen Vertex binden.
• Datei-Upload und Backend-Bindung — der End-to-End-Durchlauf.
• Modelle — wenn die File ein Modellartefakt ist und der Laufzeitpfad relevant ist.