Orange Beach, Alabama

My wife found a dead mouse behind the door. It looked like it’d moved into a sneaker in which it spent its final breath.

Then it was thrown in the container, the sneaker repurposed as a home now finally repurposed as a casket.

Meanwhile, I was outside in the blazing sun, carpeting slowly. Sweating thirstily.

There’s now blue tarp hanging on the facades, because of renovations, so therefore I get the sense that I’m in a simulation, and there’s nothing out there.

But I know that’s not true, because the mouse is buried in a sneaker in a container outside

And out there, I feel and see the sun.

Field Notes is a working surface — immediate and off‑the‑cuff.

I’m keeping this space public because part of the friction of writing today comes from the platforms themselves: the heaviness of editors, the awkwardness of publishing flows, the sense that everything must be polished before it can be seen. Field Notes is the opposite of that. These are chat‑notes, quick thoughts, early attempts at saying something the best way I can in the moment.

Now that Marshall Review has been elevated to short but polished think‑pieces, this space becomes the practice room — the place where ideas land first, before they harden into essays or reviews.

Field Notes is a working surface — immediate and off‑the‑cuff.

I’m keeping this space public because part of the friction of writing today comes from the platforms themselves: the heaviness of editors, the awkwardness of publishing flows, the sense that everything must be polished before it can be seen. Field Notes is the opposite of that. These are chat‑notes, quick thoughts, early attempts at saying something the best way I can in the moment.

Now that Marshall Review has been elevated to short but polished think‑pieces, this space becomes the practice room — the place where ideas land first, before they harden into essays or reviews.

Marshall Review has moved to review.marshall.ie.

I originally set it up on a .re domain as a way to test the platform and to write in an unedited, off‑the‑cuff mode. Like many writers, I’ve felt the friction of the tools available to us – the heaviness of some platforms, the awkwardness of others, and the constant negotiation between writing and the systems that are supposed to support it.

This move from .re to .ie reflects a simple shift: Marshall Review becomes an edited, intentional space, while the unedited commentary continues elsewhere.

I’m keeping the lighter, provisional writing – the “Field Notes”, the quick observations, the unpolished commentary – at notes.marshall.re, where it belongs. That space remains informal and exploratory.

“Marshall Review” stays focused, edited, and deliberate. It now joins its sister columns at Marshall – Marshall On Policy (policy.marshall.ie on Substack) and Essays (essays.marshall.ie on self‑hosted WordPress), where some content is also being redirected. “Field Notes” remains here on Write.as at notes.marshall.re — loose, reflective, and off the cuff.

Dat komt dus van denken.

in het schaduw kabinet van de linkerkant der onderbuik gevoelens kon de rechter zijde niet gedijen op een dag kwam het tot een uit handen lopende confrontatie tussen beide partijen de een zei dat de gewenste interventie niet afdoende was gefundeerd, volgens de ander had deze ingreep zin om een deal over deze kwestie te forceren hakten ze vervolgens eeuwenlang om de beurt op elkaar in terwijl ze eertijds hadden toegezegd elkander geen wilde noch geknipte haar te krenken En dat kindjes komt dus van denken dus pas maar goed op met dat onbetrouwbare frommeltje in je kop

hij was tot de conclusie gekomen dat om deel te zijn van deze gemeenschap zinvol was om vaak naar 'de stam' kroeg te gaan sloeg daarom nooit een sociaal werk weekend over en liet zelden het gebrandmerkte sociale glijmiddel staan dankzij zijn alcoholische vrijgevigheid en innemendheid ontving hij snel de vaste beloning van kroeg en de gemeenschap uitvergrote vriendschap massa, altijd minstens een gelijke om hem heen die mee ging op stap wat eens begon met eenvoudige push berichten werd na een paar jaar een serie katers iedere keer kwam hij zwalkend thuis, meestal drie maal hoger niveau dan tooegestaan peiltje theewater en iedere keer na zo'n diepte investering verloor hij meer en meer de grip op de realiteit en zijn integriteit, arbeid en al heel vlot ook zijn gezondheid na een paar jaar leverde zijn lever geen prestaties meer ging zelfs niet meer stand by staan het gif van buiten ingenomen werd het ook van binnen en toen hield het setje op met dingen sturen net voordat het hart was opgehouden met slaan dit allemaal alleen maar om te bewijzen dat hij alcohol bestendig was en zich nooit naar zijn mallemoer zou drinken En dat kindjes komt dus van denken dus pas maar goed op met dat onbetrouwbare frommeltje in je kop

hij ging altijd losjes om met alles wat hij iedere dag moest transporteren of het nou ging om 200 kilo gouden ringen, 300 kilo rubberen horloge bandjes of 250 plastic drijfveren Ze zeiden wel dat hij voorzichtig moest zijn maar daar had hij maling aan hij ging met alles er in en op en aan op volle toeren van baan, naar afrit, naar andere baan soms was het wat lastig om in een rechte lijn te gaan naar zijn beoogde doel maar onderweg naar de bestemming redde hij het elke keer op zijn richtingsgevoel toch op die dag in november in de hoge bergen op weg naar de plek voor zijn zware last was de hoge grond daar onder zijn voertuig allesbehalve vast hij stuurde naar links, hij ging naar rechts, hij trok nogmaals aan het stuur maar het had niet het beoogde effect en met een doodsmak kwam hij tientallen meters lager aan de flank van de meedogenloze berg terecht en hij ontdekt net voor zijn laatste snik dat als je de hele lading niet door een expert laat vastklenken het voertuigje veel te wild over met name hoge ijle veel wind vangende banen gaat zwenken En dat kindjes komt dus van niet genoeg denken dus pas maar goed op met dat onbetrouwbare frommeltje in je kop

(dit was de laatste van vandaag hoor, het is wel genoeg geweest, ga nu maar naar bed, al dat wakkere gedoe, ik heb er zo geen zin meer in)

The short version

PlantLab can now analyze more than one plant in a single uploaded photo. Instead of forcing the whole image into one diagnosis, the API slices separable plants into their own canopy boxes, runs the diagnosis cascade per plant, and returns a results[] array with one entry per plant.

This is a breaking API change. The response schema is now 3.0.0. Fields like is_healthy, growth_stage, conditions, pests, and reliability_score moved out of the top level and into results[]. Image-level fields such as is_cannabis and cannabis_confidence stay top-level.

If your code already treats a diagnosis as “the answer for this plant,” the migration is simple: iterate results[]. Single-plant photos still return exactly one result.

---

Why this had to change

Most plant diagnosis tools assume one photo equals one plant.

That is convenient for an API contract. It is not how people take grow-room photos.

Growers send canopy shots. They send side-by-side plants from the same tray. They send one wide image because it is faster than taking six separate photos. Sometimes one plant is healthy and the plant beside it is showing early deficiency. Sometimes the left side of a tent is getting different airflow or light intensity than the right side.

The old PlantLab response could only represent one diagnosis. If the image contained three plants, the model still had to answer as if it were looking at one object. That creates two bad outcomes.

First, the answer can become a blend. A healthy plant and a deficient plant in the same frame can collapse into a single diagnosis that is not quite true for either plant.

Second, the UI has no place to show location. Even when the model found the right problem, it could not say “this plant, in this part of the image.” For automation and history, that is a real limitation. A diagnosis without a region is hard to compare over time.

The fix was not another confidence field. It was a different shape of response.

---

What changes for growers

When the photo contains one plant, the experience should feel the same. PlantLab returns one diagnosis, with a full-image bounding box:

"results": [
  {
    "bbox": { "x0": 0, "y0": 0, "x1": 1, "y1": 1, "normalized": true },
    "is_healthy": false,
    "growth_stage": "flowering",
    "conditions": [
      { "class_id": "magnesium_deficiency", "confidence": 0.85 }
    ],
    "reliability_score": 0.87
  }
]

When the photo contains multiple separable plants, PlantLab returns multiple entries. Each entry has its own normalized bounding box and its own diagnosis fields:

{
  "schema_version": "3.0.0",
  "success": true,
  "is_cannabis": true,
  "cannabis_confidence": 0.99,
  "results": [
    {
      "bbox": { "x0": 0.06, "y0": 0.12, "x1": 0.45, "y1": 0.92, "normalized": true },
      "is_healthy": true,
      "health_confidence": 0.91,
      "growth_stage": "vegetative"
    },
    {
      "bbox": { "x0": 0.52, "y0": 0.10, "x1": 0.93, "y1": 0.95, "normalized": true },
      "is_healthy": false,
      "health_confidence": 0.88,
      "growth_stage": "vegetative",
      "conditions": [
        { "class_id": "nitrogen_deficiency", "confidence": 0.80 }
      ],
      "reliability_score": 0.83
    }
  ]
}

The boxes are normalized x0, y0, x1, y1 coordinates in the original image. They are designed for overlays, history views, and automation clients that need to keep a result tied to the plant it came from.

The original uploaded image stays the canonical image. PlantLab does not store a separate cropped image for each plant as the primary record. The boxes are metadata attached to the original frame.

---

Why the response is an array, not plant_1, plant_2, plant_3

Arrays are boring. That is why they are the right answer.

A grow tent can have one plant today and four plants next week. A user can upload a single close-up, then a wide tray shot, then a photo where the plants overlap too much to split safely. The API should not need new field names for each case.

With results[], the contract is stable:

• len(results) == 1: use it like the old response.
• len(results) > 1: show a plant selector or iterate through every result.
• Each result carries its own bbox.

This also makes the API easier for automation systems. If you are feeding PlantLab into Home Assistant, Node-RED, a dashboard, or a cultivation controller, each plant result is a normal object. You can pick the first plant for backward-compatible behavior, show a plant count, or build a UI that lets the user choose which plant they care about.

The PlantLab Home Assistant integration has already been updated for this shape. Version 0.7.0 reads schema 3.0.0, keeps the existing sensors pointed at the primary plant (results[0]), and adds sensor.plantlab_plant_count so automations can tell when the last frame held more than one plant.

---

What changed for API consumers

Before schema 3.0.0, diagnosis fields were top-level:

{
  "schema_version": "2.1.0",
  "success": true,
  "is_cannabis": true,
  "cannabis_confidence": 0.99,
  "is_healthy": false,
  "growth_stage": "flowering",
  "conditions": [
    { "class_id": "magnesium_deficiency", "confidence": 0.85 }
  ],
  "reliability_score": 0.91
}

In schema 3.0.0, those diagnosis fields live inside results[]:

{
  "schema_version": "3.0.0",
  "success": true,
  "is_cannabis": true,
  "cannabis_confidence": 0.99,
  "results": [
    {
      "bbox": { "x0": 0, "y0": 0, "x1": 1, "y1": 1, "normalized": true },
      "is_healthy": false,
      "growth_stage": "flowering",
      "conditions": [
        { "class_id": "magnesium_deficiency", "confidence": 0.85 }
      ],
      "reliability_score": 0.91
    }
  ]
}

Migration pattern:

const primaryPlant = response.results?.[0]

if (primaryPlant?.is_healthy === false) {
  for (const condition of primaryPlant.conditions ?? []) {
    console.log(condition.class_id, condition.confidence)
  }
}

If your integration displays only one diagnosis, start with results[0]. That gives you a safe primary-plant path while you add richer multi-plant UI later.

If your integration can display multiple plants, iterate the array and draw each bbox over the original image.

If you use the official Home Assistant integration, update to v0.7.0. It is rollout-friendly: the updated integration understands the new results[] response, but it also falls back to the old flat fields when talking to a pre-3.0.0 API. That means you can update Home Assistant before the API flips without breaking existing sensors. Older integration versions should be upgraded before you depend on schema 3.0.0.

---

Why I made it breaking

I considered keeping the old top-level fields for one release and adding results[] beside them. That sounds friendlier until the two disagree.

Imagine an image with two plants:

• Plant A is healthy.
• Plant B has a deficiency.

What should the old top-level is_healthy say? If it says false, the healthy plant is wrong. If it says true, the deficient plant is wrong. If it tries to summarize the whole image, it stops being the same field that integrators already rely on.

Keeping both contracts would make the API easier to call and harder to trust. I would rather force one clear migration than leave stale fields around for months.

So the schema version bumped to 3.0.0. Consumers must read results[].

---

What PlantLab does when the image is messy

Multi-plant analysis is only useful when the plants can be separated cleanly enough to diagnose.

Dense canopy shots are hard. Touching plants, heavy overlap, blur, and poor lighting can make a crop ambiguous. Splitting too aggressively is worse than under-splitting, because an over-split can create contradictory diagnoses from pieces of the same plant.

PlantLab uses a conservative policy:

• If the image looks like one plant, return one result.
• If the plants are separable, return one result per plant.
• If the scene is too dense or ambiguous, prefer one safer result over several questionable crops.
• Cap the number of plant crops so latency stays bounded.

That last part matters. A multi-plant image now runs a lightweight slicing step, then the diagnosis cascade per plant. We also removed a wasted whole-image cascade for multi-plant paths, so a three-plant image runs the plant diagnosis work three times, not four.

The point is not to pretend every canopy photo is solvable. The point is to make the output honest about the structure of the image.

---

What this unlocks

For growers, this makes wide shots more useful. You can upload a photo of a tray and see which plant the diagnosis belongs to.

For paid history, bounding boxes make comparison over time more meaningful. A diagnosis can be stored with the region it came from instead of being attached only to the original image.

For automation, the response is finally shaped like the thing it describes. A controller can loop over plants, display per-plant state, or decide to alert only when any plant crosses a threshold.

For training, this closes a long-standing mismatch. A whole-frame label is often too crude for a multi-plant image. Per-plant boxes let the system learn from the plant region without pretending the entire image has one uniform condition.

This is the main reason I was willing to break the schema. The old response was simpler, but it encoded the wrong assumption.

---

Migration checklist

If you maintain a PlantLab client, check these paths:

• Replace reads of top-level is_healthy, health_confidence, growth_stage, conditions, pests, mulders_hypotheses, reasoning fields, and reliability_score with reads from results[].
• Keep reading top-level is_cannabis and cannabis_confidence.
• Treat results[0] as the primary plant if you need backward-compatible behavior.
• Use len(results) as the plant count.
• Draw result.bbox over the original uploaded image if your UI supports overlays.
• Treat {x0:0, y0:0, x1:1, y1:1} as the whole-image fallback box.
• If you use Home Assistant, update plantlab-ai/home-assistant-plantlab to v0.7.0. Existing diagnosis sensors continue to show the primary plant, and the new sensor.plantlab_plant_count exposes len(results).

The full OpenAPI schema is available in the PlantLab docs at plantlab.ai/docs.

---

PlantLab is free to try at plantlab.ai. Three diagnoses a day, structured JSON responses, and API docs built for automation clients.

---

FAQ

Does every upload now return multiple plants?

No. Single-plant images return one result. Ambiguous dense canopy images may also return one result if splitting would be unsafe.

Did the old fields disappear?

Yes. Per-plant diagnosis fields moved into results[] in schema 3.0.0. Top-level is_cannabis and cannabis_confidence remain image-level fields.

How do I get the plant count?

Use response.results.length.

Are the bounding boxes pixel coordinates?

No. They are normalized coordinates from 0 to 1, relative to the original image. Multiply by image width and height when drawing overlays.

What should older clients do?

Read results[0] first. That restores the old “one diagnosis” behavior while keeping your code compatible with multi-plant uploads.

Is the Home Assistant integration ready?

Yes. The official Home Assistant integration is updated in v0.7.0. It reads schema 3.0.0, surfaces the primary plant through the existing sensors, adds sensor.plantlab_plant_count, and still tolerates pre-3.0.0 flat API responses during rollout.

Anfang der zweiten Woche: 22. Juni

Es ist schon irgendwie witzig – anscheinend können wir einfach nicht ganz problemlos in einem Hotel wohnen. Irgendwelche Missverständnisse oder Schwierigkeiten müssen uns wohl immer begleiten. Dieses Mal sind wir mit der Organisation überhaupt nicht einverstanden. Gut, vielleicht habe ich auch einfach etwas auf Deutsch falsch verstanden. Das passiert mir noch. Trotzdem kommt es mir langsam so vor, als wären wir auf dieser Reise irgendwie verflucht. Gott sei Dank geht es diesmal nicht um einen kaputten Aufzug! So weit ist es immerhin noch nicht gekommen.

Diesmal geht es um die Zimmerreinigung. Als wir eingecheckt haben, wurden wir gefragt, wie oft unser Zimmer gereinigt werden sollte. Wir antworteten: „Alle drei Tage reicht völlig aus, aber die Bettwäsche kann einmal pro Woche gewechselt werden.“

Eigentlich leben wir hier inzwischen etwas anders als normale Hotelgäste. Wir machen uns Kaffee, essen einfache Sachen wie Sandwiches oder Snackplatten und haben keine Mikrowelle. Deshalb kaufen wir meistens Lebensmittel, die auch kalt gut schmecken. Diese Woche wird es außerdem besonders heiß, sodass man ohnehin nicht viel essen möchte.

Natürlich füttern wir auch unsere Hunde und haben selbst regelmäßig etwas zu essen. Deshalb fällt regelmäßig Müll an. Heute sollte unser Zimmer gereinigt werden – das ist jedoch nicht passiert. Also fragte ich an der Rezeption, was wir mit unserem Müll machen sollten.

Dort erklärte man uns, dass wir einen Tag vorher Bescheid geben müssten. Aber warum wurden wir dann überhaupt gefragt, wie oft wir unser Zimmer reinigen lassen möchten? Das müssen wir wohl noch herausfinden. Heute habe ich jedenfalls gesagt, dass wir den Müll entsorgen lassen möchten. Das eigentliche Problem war, dass wir in der Umgebung keine normalen Müllcontainer gesehen haben. An der Rezeption sagte man uns jedoch, dass wir uns darum keine Sorgen machen müssten. Danach fragte ich mich natürlich, ob wir für diesen Service vielleicht zusätzlich bezahlen müssen. Wie ihr seht, gibt es hier noch einige offene Fragen. Deshalb würde es mich inzwischen gar nicht mehr überraschen, wenn uns das Leben hier noch irgendeine zusätzliche Rechnung präsentieren würde.

Bei der Arbeit mache ich langsam Fortschritte. Gemeinsam mit Kai bereite ich gerade eine Reportage über unseren Theaterbesuch vor. Das Material ist nicht ganz einfach, und ich spreche dort noch ziemlich unsicher Deutsch. Deshalb ist es gar nicht so leicht, daraus etwas wirklich Sinnvolles zu machen. Aber gemeinsam finden wir bestimmt eine gute Lösung.

Imke hat am Wochenende leider ihr Handy verloren. Deshalb sind wir heute ohne sie im Büro. Ich schreibe mein Feedback zur Tastführung, schneide unsere Aufnahmen und sammle weitere Informationen für die Website. Irgendwie macht mich die Atmosphäre in unserem Büro sehr produktiv, obwohl mein Arbeitstempo noch nicht so schnell ist, wie ich es mir wünschen würde. Meine täglichen Sprachübungen bestehen momentan aus meinem Tagebuch und Duolingo. Aber das ist eigentlich noch zu wenig.

Übrigens gibt es noch eine sehr wichtige Nachricht! Dieser McDonald's, den ich so gelobt habe, hat mich nun schon zum zweiten Mal enttäuscht! Schon wieder habe ich ein völlig geschmackloses vegetarisches Sandwich gekauft. Wie konnte das nur passieren? Früher dachte ich immer, wenn ich einmal in Berlin leben würde, wäre das bestimmt mein Lieblingsrestaurant!

Ich gebe McDonald's jetzt noch genau eine letzte Chance, bevor ich endgültig aufgebe. Sowohl der McVeg als auch die andere vegetarische Variante waren trocken, fast ohne Käse und mit viel zu wenig Gemüse. Ich erinnere mich noch an einen unglaublich leckeren Beyond-Meat-Burger. Vielleicht gibt es den inzwischen gar nicht mehr?

I’m making some final changes, a read through, and then export them in EPUB and PDF. Also have to create a product page for it on Gumroad. Once I publish it I will celebrate. I can’t believe I accomplished so much in so little time.

Again, thanks for all your support!

#writing #draft #editing #novelette #shortstory #update