On Saturday morning, the community garden seemed to be working. On Lucía's phone, a clean line showed that moisture in the tomato bed had fallen through the week and risen again after watering. Someone suggested posting the screenshot online. It was good news for the project: neighbours who had never programmed before had installed sensors, connected a simple board, and produced readable data. But when Marta asked who had decided to water that night, nobody could answer with confidence. The alert had reached two phones; one person was out of town and the other had muted notifications. A third neighbour opened the tap after seeing drooping leaves. That decision, which explained the decisive point in the graph, existed nowhere in the record.
That small absence does not invalidate the experiment. It shows why a citizen laboratory cannot preserve only its final chart. The image summarises a measurement; it does not retain the hypothesis behind putting a sensor in partial shade, the discussion about who could receive alerts, the timetable change that avoided midday watering, or the discovery that a battery expired sooner than advertised. When a prototype ends, learning is not only knowing which value it displayed. It is being able to reconstruct what people observed, which options they considered, which limits they accepted, and what they would care for differently next time.
A sensor does not make a watering decision#
Soil moisture can be measured in different ways and with different degrees of precision. One group may use an inexpensive sensor that detects relative change, another a more stable probe, and both may produce technical-looking curves. Yet neither device nor chart answers a practical question: when should we water, how much, and for whom? The answer depends on root depth, mulch, the weather forecast, water restrictions, and the experience of the people working the garden. It also depends on whether the plot holds tomatoes, herbs, or a learning space where children and older residents should be able to take part without damaging a delicate installation.
Soil moisture can be measured in different ways and with different degrees of precision.
Treating a reading as a decision creates a misleading sense of automation. If a record says 24 per cent but nobody recorded the unit, probe depth, or agreed threshold, the data become difficult to interpret even for the person who gathered them. Worse, they may acquire authority they never had: “the sensor said we had to water.” In fact, someone translated an uncertain reading into an action that uses a shared resource. Naming that translation does not diminish technology. It places accountability where it can be examined.
That is why a laboratory notebook should begin before the board is powered on. It should state a concrete question: “Can we avoid unnecessary watering in this bed during July?” rather than “Can we use sensors?” It should say what the group will observe besides a number: plant condition, hours of shade, leaks, light rain, and obstacles to entering the site. It should also record what it does not claim to prove. A six-week prototype does not show that a system works in every garden or replaces hands-on care. That boundary protects learning from promises the data cannot support.
Preserve changes, not only the version that worked#
Projects are often told backwards. At the end, people choose the placement that worked, clean up the spreadsheet, and present the outcome as though the path had been straight. In Lucía's garden, the first sensor went beside a hose because it had wifi coverage. Two days later, readings rose whenever someone washed tools. The group moved it twenty centimetres, then found that a stone prevented it from reaching the agreed depth, and finally made a small map of the bed. The final curve looked much better. Removing the earlier steps would make a neater story, but it would hide three useful lessons: connectivity is not a sufficient growing criterion, the physical location of a measurement matters, and a seemingly minor choice needs testing in the field.
A useful notebook keeps changes with their date and reason. It need not turn anyone into a full-time secretary. A short session card can record what was expected, what was done, what was observed, what changed, and who will check the effect. A photograph with an arrow, a transcribed voice note, or a sketch may be more valuable than a formal report if it lets someone understand the situation months later. The essential point is that the explanation must not remain locked in one person's memory.
Failed attempts should also be retained without turning them into a list of blame. Perhaps the alarm was set for seven in the morning and nobody could act because the site opened at nine. Perhaps the group measured newly turned soil and compared it with a compacted patch. Perhaps someone found that the app was only in English and stopped taking part in configuration. Each case identifies a design condition: real schedules, legitimate comparisons, linguistic access. If it is simply labelled human error, the next team will repeat the same problem with a different board and a different chart.
Access agreements are part of the outcome#
The question “who can see the data?” often arrives too late. In a small laboratory, sharing an open link can seem harmless; soon there are phone numbers linked to alerts, timetables revealing when a space is empty, or photographs containing children. A moisture sensor may seem unrelated to privacy, but the infrastructure around it can expose people. From the start, a group should decide which data are public, who administers accounts, how access is withdrawn, and how long records are retained.
Agreements include physical access as well. Who has a key to replace a battery? Who may disconnect a device if it becomes intrusive or unsafe? Is there an alternative for someone without a smartphone? In a garden, knowledge should not belong only to the person who knows a password or can navigate an app. A laminated sheet beside the tank, showing the current agreed threshold and a contact person, can be as important an inclusion measure as the electronic board.
Maintenance turns a prototype into care#
Prototypes attract attention on the day they are assembled. Their ordinary life begins when a cable gets wet, a charger fails, or the most enthusiastic participant moves away. If a project keeps only a success graph, the next group inherits an opaque object: it does not know what maintenance cost, which spare parts were used, how often calibration was needed, or whom to ask. Abandonment is then read as lack of civic interest when it is often a lack of practical continuity.
A maintenance record should be deliberately simple: sensor model, installation date, power source, replaced parts, approximate cost, completed checks, and signs of failure. Including human time is equally honest. If checking two beds requires forty minutes a week from an experienced volunteer, that contribution should be visible; not to discourage others, but so a future replication can estimate real resources. The cost of care does not vanish because it is absent from an invoice.
Make a situation replicable, not an object copyable#
When another neighbourhood asks how to repeat the laboratory, sending code and a shopping list is not enough. Its garden may face another direction, have a community with different schedules, limited irrigation water, or no wifi at all. The most honest replication does not promise the same result; it offers conditions and questions for adapting the learning. Where was the sensor placed and why? What manual comparison took place? What decision could the group make for each kind of alert? What happened when nobody was available?
Before closing the project, the group can gather around the final chart and hold a different kind of review. Instead of asking only whether the system saved water, it can ask: what decision did observation help us make? Which decision should we not delegate? What would a new person need to know to care for this in six months? What would we change with a smaller budget? The answers belong beside the chart, not after they have disappeared into conversation.
A citizen laboratory matters because it opens knowledge, not because it displays a flawless curve. In Lucía's garden, the next step was not buying more sensors. It was writing that a neighbour decided to water after seeing the leaves, that the alert failed because the duty agreement was incomplete, and that the sensor served as a clue rather than a judge. That record does not make the project less technological. It makes it more shareable, more open to challenge, and better able to care for both the soil and the people who sustain it.
