When Code Decides Water Rights, Democracy Must Live in the Kernel

This is an opinion column. The scenarios are hypothetical, and the views are the columnist's own.

Imagine a river basin in a dry decade. Dozens of farms, a growing town and a fragile wetland all depend on the same shrinking flow. Imagine, too, that a software system now decides who receives how much water each week, adjusting in real time to sensors, forecasts and contracts. I have no particular system in mind, and I name none. But I think we are heading toward this scenario, and I want to argue for one principle. When autonomous code determines water rights, democratic oversight must be written directly into the kernel.

Why this is different from ordinary software

Most software helps people do things. Allocation software decides who gets a share of something they cannot live without. That makes it closer to a law than to an app. A rule that says a field receives less water in a drought is a decision about livelihood, food and fairness, even if it is expressed as a line of code.

Traditional law has long had ways of handling such decisions: hearings, written reasons, appeals, and the possibility that a court will say the rule was unfair. Code can bypass all of these without malice, simply by being fast, opaque and automatic.

What oversight in the kernel would mean

By kernel I mean the core logic, not some add-on that lives outside it. A system that is truly accountable would, in my view, include at least the following.

• Readable rules. The allocation logic should be published in a form that ordinary people and independent experts can inspect.
• Reasons for every decision. Each allocation should produce a plain-language explanation that a farmer or a resident can read.
• A path to appeal. A person who believes the system erred should have a clear route to a human reviewer with the power to change the outcome.
• Human override. In an emergency, accountable officials must be able to pause or adjust the system, with the override itself logged.
• Public audit. Independent reviewers should be able to test the system against past data and report their findings.

The objection from efficiency

A fair question is whether all this slows things down. Perhaps it does. But speed was never the only value in a water system. A slightly slower decision that people understand and accept may serve the basin better than a fast one that breeds suspicion and litigation.

There is also an argument from trust. Water arrangements work when people believe the sharing is fair. A system that cannot explain itself invites the assumption that it favors someone, and once that assumption sets in, cooperation can unravel.

What I am not arguing

I am not arguing against automation. Well-designed systems may allocate more fairly than tired committees, and sensors can spot leaks that humans miss. Nor am I claiming that any existing system is flawed; my scenarios are thought experiments. And I do not pretend that a list of features guarantees justice. Communities will disagree about what fairness means, and software can encode only the answer we choose.

One practical suggestion follows. Before any allocation system goes live, I would want a public rehearsal: run the proposed rules against historical conditions, publish the results and invite objections from the people who would be affected. If the rules produce outcomes that seem unjust when replayed on the past, better to learn that on paper than in a dry summer. Rehearsal is cheap, and legitimacy is not.

The takeaway

We tend to regard code as a tool and law as a constraint on tools. In resource allocation, the two merge. So the democratic questions, who decides, who can see, who can object, must be settled at the design stage rather than patched in after the first crisis. When autonomous code determines water rights, democratic oversight must be written directly into the kernel. If we get that right, automation can serve a community. If we get it wrong, we will have handed a public trust to a machine with no one to answer to.