Below I go into why that happens, and what architecture can do about it.
The data is there
I was braced for emptiness: small country, modest budgets. It went the other way.
CENTA holds a digital soil map, soil analysis and agrochemical recommendations. SIAM, the MAG app, carries agroclimatic alerts, prices, an exporters directory and a register of producers and buyers, letting them trade without intermediaries. MAG itself has moved its procedures into a Ventanilla Única running around the clock, and maintains RUPA, a single register of agrifood producers: you sign up with an ID document and get a digital card for access to state programmes.
On top of that sits an external layer: satellites, climate, drones, Sentinel-2, vegetation indices, moisture, meteorological data. All of it available, none of it pulled into a single experience for the state.
Each of these systems does its own job. The question isn't about them but about what sits between them. A single producer register is already being built, and that's exactly the step to start from. But a register on its own doesn't bring soil, climate, market and application into one line, and there's no visible place in the public descriptions where the data turns into a concrete action.
Collected for the report, not for the action
What follows is an assumption, though a fairly safe one, because this is how almost any public sector is built.
A report travels upwards: to the ministry, to the donor, into the annual statistics. The decision is taken somewhere else and at a different pace: by the producer on his plot, by an agency on its own patch. Data gathered for the first breaks down on the second.
It arrives aggregated more coarsely than the person acting needs. It arrives later than the decision was worth making. And often it has no particular addressee: the indicator is there, while the person who does something with it doesn't appear anywhere in the description of the system.
What's worth understanding before the architecture
Before choosing an architecture, let alone a technology, there are a few things worth establishing about every indicator:
Who stands behind this data: who collects it, who maintains it, who answers for its quality.
How it works today: where the number comes from and what happens to it next.
How fast it appears: hours, days, a season.
What people do when the number doesn't match what was expected.
The last one matters most. With no answer to it, the indicator exists for reporting, and a decision system can't stand on it.
What I built
So the observations are kept by one agency, for its own report, while the decisions are taken by other people, at a different pace and on different ground. Between them sits a gap, and Chivo Agro is built to close it: the scattered sources come together into one ecosystem where data reaches an action.
That produced three interfaces: an app for the producer, a national dashboard for the state, and a public portal.
The first two are separate not by audience but by the speed of the decision. The producer decides within days: irrigate, treat, sell. The state decides across a season and across a year: where to direct support, what to buy, what counts as a budget priority. One shared dashboard for both doesn't work, because a number that helps in the field in the morning is just noise to the ministry, and the other way round. The third interface isn't about decisions at all; it's about transparency.
But interfaces are only the top of it. Underneath, the principle is a loop.
The producer opens the app for the day's work: how the plot is doing, what the weather will be, where there's disease risk, which tasks are urgent. They mark what they've done, send up the drone, ask the assistant a question and get an answer drawn from their own plot's data, with its crop, its soil and its history. And every one of those actions becomes data in its own right: it joins the state sources and the satellites, and what rises to the top is a picture by territory, by crop, by programme.
So the person in the field is not only a recipient but a source. While the data travels one way the loop stays open and the system remains a display case. Once it closes, every number at the top has an origin at the bottom, and every action at the bottom has a meaning at the top.
Who answers for what sits between the systems
Connecting the sources, building on the single producer register, laying it out across the interfaces. That's understandable work, and you can cost it in months and people.
The harder part is elsewhere. A common line of authority does exist: MAG sits above CENTA and SIAM. But answering for an agency and answering for a result that only appears where several systems meet are two different jobs. Whether the second one has an owner isn't visible from outside.
Which is why the question of who will act on this data and what they are answerable for belongs at the very start, before any architecture. If there's no answer, what the project needs isn't an architect yet, but a decision about who owns it.
What it adds up to
The technology for this kind of connectedness has existed for years and gets cheaper annually, and the gap between measurement and action holds anyway. So it isn't a technical gap.
The job is still to connect: to pull the sources into one working system where data reaches an action and the load is shared between the people who maintain it. But a connection doesn't hold by itself; something has to hold it. Either an owner of the result, or rules binding on everyone involved — those can be written into a protocol, though the decision to act on the data still sits with a person. With neither in place, the links get made once, during the project, and drift apart afterwards.
One more thing this work made visible. The smaller the country, the shorter the distance between agencies and the cheaper it is to close the loop. El Salvador has an easier job of it than Brazil or India.
