Eine Pflanzendatenbank, ein Sprachmodell und zwei Wege dazwischen

Die Entscheidung – und warum sie anders ausfällt als geplant

Die Make-Datei ist keine Automation, sondern eine geladene Vorlage. Das ist nachprüfbar und keine Einschätzung: Die Systemnachricht an das Sprachmodell hat kein content, das Notion-Modul zum Zurückschreiben hat kein einziges Feldmapping, und Auslöser- und Zieldatenbank tragen zwei verschiedene Kennungen, von denen keine zur Pflanzendatenbank gehört. Der Dateiname ist der unveränderte Name der Make-Vorlage.

Die Zapier-Strecke trägt Spuren von Arbeit. Acht Schritte, davon ein selbst geschriebener JavaScript-Schritt, ein Filter, ein Formatter und eine Schleife über Einzelwerte. Nichts davon ist Bestandteil einer Vorlage, und der Stand v5 sagt, dass fünf Fassungen nötig waren.

Für die Portfolio-Darstellung wird deshalb die Zapier-Strecke geführt. Der Grund ist nicht, dass sie besser liefe – das ist nicht belegt –, sondern dass sie überhaupt gebaut wurde. Die ursprüngliche Frage „welche der beiden war die finale Variante" beantwortet sich damit von selbst: Zur Wahl standen nie zwei Strecken.

Was der Vergleich nicht leistet

Ein Vergleich zweier Artefakte ist kein Vergleich zweier Läufe. Ich kann nicht sagen, wie die Strecken mit einer unvollständigen Eingabe umgehen, was bei einer unbekannten Pflanze passiert oder wie viele Aufgaben ein Durchlauf verbraucht. Ein Test dazu bräuchte die Zugänge zu beiden Konten und zur Datenbank – und Zugangsdaten gehören nicht in dieses Projekt. Solange dieser Test nicht stattgefunden hat, steht hier nicht getestet und nicht „funktioniert".

1. Derselbe Wert steht zweimal in der Auswahlliste

Das Feld Winterhärte (Freiland) führt -15 °C und –15 °C als zwei Optionen. Der Unterschied ist ein Zeichen: einmal der Bindestrich U+002D, einmal der Gedankenstrich U+2013. Küstenmammutbaum und Kartoffel-Rose tragen die eine Variante, Lavendel und Salbei die andere.

Das ist der teuerste Fehler von den dreien, weil er unsichtbar ist: Ein Filter auf „−15 °C" findet die Hälfte der passenden Pflanzen und meldet dabei keinen Fehler. Diese Prüfung ist automatisierbar und läuft im Prüfskript mit – sie vergleicht nur Zeichen und beurteilt keine Bedeutung.

2. Ein Vokabular vermischt drei Fragen

Das Feld Frucht kennt die Werte keine, Zapfen, essbar, Weiß und unbdeutend. Darin stecken drei verschiedene Fragen – gibt es eine Frucht, was für eine ist es, kann man sie essen – und dazu eine Farbe. Wonach hier gefiltert werden soll, ist damit nicht beantwortbar. unbdeutend ist außerdem ein Tippfehler, und weil er in der Auswahlliste selbst steht, wiederholt er sich in jedem Datensatz, der ihn verwendet.

3. Zwei Felder wurden nie gefüllt

Wachstumstyp und Transporttyp sind in keinem der neun Datensätze belegt. Ein Feld, das nie gefüllt wird, ist entweder überflüssig oder es fehlt der Schritt, der es füllt – beides sollte man wissen, bevor die Sammlung wächst.

• Kein Testlauf. Keine der beiden Strecken wurde für diesen Beleg ausgeführt. Es gibt keine Laufhistorie, keine Fehlerfälle aus dem Betrieb und keine Angabe zum Verbrauch. Wo im Vergleich „nicht belegbar" steht, heißt das nicht „funktioniert vermutlich".
• Keine Berufserfahrung mit Automationswerkzeugen. Make, Zapier und Notion sind hier privat und für eigene Zwecke eingesetzt. Es gibt keine berufliche Station, in der ich damit gearbeitet habe.
• Neun Datensätze sind kein Datenbestand. Das Datenmodell ist für mehr gebaut, gefüllt ist es kaum. Was hier gezeigt wird, ist die Struktur und ihre Prüfung, nicht eine gepflegte Pflanzendatenbank.
• Keine fachliche Prüfung der Inhalte. Ob Rosa rugosa tatsächlich bis −15 °C freilandhart ist, sagt dieser Beleg nicht. Er sagt, dass diese Angabe im Datensatz steht, dass sie auf einen Wikipedia-Artikel verweist und dass kein Feld dokumentiert, ob jemand sie nachgeprüft hat.
• Keine Zugangsdaten, keine Schlüssel. Weder in dieser Seite noch im Projektordner. Die Blueprint-Datei wurde ausgewertet, aber nicht veröffentlicht – sie enthält Verweise auf Verbindungen und Datenbank-Kennungen.