Suppose you manage the waste from a shopping area. A sports shop has an ordinary trading day, then Christmas makes it busier, then a special event brings in an extra crowd. The question is not merely, "How much waste does the shop produce?" It is also, "What happens when several such influences occur together, and what does the collection system have to do about them?" Green Village was built to explore questions of that kind.
The basic building block is a waste generator: a shop, public-realm area, or other place which produces waste. Each generator has facts which a model can use. Northern Ice, our fictional Canadian sports shop, for example, has a floor area, a level of activity, and a characteristic mixture of cardboard, paper, plastics, residual waste, food, drinks-related waste and damaged goods. A model turns such facts into an estimate of how much waste the generator produces and what that waste consists of.
The models need not all work in the same way. One may use a conventional numerical calculation, another a fuzzy expert system, and another simple arithmetic. Green Village deliberately allows this. The important thing is what the model means in the waste manager's world, not whether every model uses the same internal technique.
A single day's estimate is not enough, because waste management happens through time. Green Village therefore works with waste histories: dated sequences of waste arisings. An ordinary baseline can be repeated over a month; a Christmas effect can apply for a limited period; a celebrity visit can rise to a peak on one day and then fall away again.
Once we had several such effects, we needed a simple way to say how they fit
together. That led to a small scenario algebra. Operations such as
Repeat, Anchor, During and
Add let us say, in effect, "repeat the ordinary model",
"put this event here", "apply this effect during these dates", and
"combine these influences".
A complicated scenario can therefore be assembled from small understandable models instead of being hard-wired as one large special case. For example, ordinary Northern Ice trading can continue throughout a month while a Gretzky visit adds a short-lived spike on top of it. The baseline has not disappeared merely because something interesting is happening.
Evaluation then produces two things at once: the numerical result and an explanation of how it was obtained. Individual models can show their own diagnostics, while a larger explanation tree shows how the component models and algebraic operations combine.
Finally, for Northern Ice, the resulting waste history is passed into a separate service-response model. Waste goes into local containers, Facilities Management may move it to a service yard, and the yard may in turn require a contractor collection. So we get a second history: not merely what waste was generated, but what happened because of it.
I have tried to make the system understandable by showing the same situation in several different ways. None is intended to replace the others. The pictures give an immediate impression; the figures let somebody inspect the detail; and the explanations show why the system reached the result it did.
The fictional city of Caribou Ford provides the setting. Its map is schematic rather than geographical. Shops and other waste generators appear in places, districts give them context, and selected service infrastructure shows where waste goes afterwards. The map is therefore not just decoration: it gives the models somewhere concrete to act.
The scenario catalogue shows the situations which can be evaluated. The algebraic expression is left visible rather than hidden behind a button, because it is useful to see the structure of a scenario. A client can see that ordinary trading, Christmas trading and a special event are separate effects which have been combined, rather than being handed an unexplained number.
The waste-impact display then shows the resulting history. A graph gives the overall shape — perhaps a quiet baseline followed by a sharp event spike — while another view can separate the result into individual waste streams. The textual output beside it gives the dated figures.
This distinction matters. Thirty kilograms of cardboard is a rather different operational problem from thirty kilograms of food or residual waste. A total is useful for seeing the broad shape of a situation; the individual streams are needed when we start asking what the waste service must actually do with it.
There are two further explanatory views. The Diagnostics panel shows how an individual model obtained its answer: fuzzy-rule firing strengths, interpolation details, event factors, or whatever is appropriate to that particular model.
The Explanation tree answers a different question. It shows how the separate models and algebraic operations were combined to produce the complete result. In other words, diagnostics explain a model; the tree explains the scenario.
For Northern Ice, the service-response display takes the story one stage further. The live map shows the current state of bins, Facilities Management, the yard and contractor movements. Beneath it, a horizontally scrollable storyboard shows the same history day by day, rather like a strip of little operational scenes. Quiet days look quiet; intervention days stand out.
The exact numerical history remains underneath, so the visual account can always be checked against the figures. This is intentional. An inspector may first notice a coloured bin or a lorry moving across the map, but if they ask "Why did that happen?" or "How much was moved?", the answer is still there.
The result is deliberately redundant in a useful way. The map answers where?; the plots and storyboard answer when?; the figures answer how much?; and the diagnostics and explanation tree answer why?. Different people can enter the system through whichever of those questions is most natural to them.
The project began with a simpler idea: attach understandable waste models to places in a city and show what they predict. That remains the foundation. But as soon as we tried to describe situations which looked more like real life, individual models were no longer enough.
A shop does not stop its ordinary business merely because Christmas arrives. A promotional event does not replace the baseline; it adds another influence. Two temporary events may overlap. The same model may also need to be reused in several different scenarios.
Without some means of composition, the software would quickly become a collection of one-off cases: one model for ordinary trading, another for ordinary-trading-plus-Christmas, another for Christmas-plus-Gretzky, and so on. The algebra was introduced to avoid that. We model the pieces once, then say how they are combined.
This also explains why Green Village does not insist that every model be
fuzzy. Fuzzy logic is useful when the knowledge itself is naturally vague
— when, for example, there is no sensible knife-edge between a
medium
and a large
shop, or between normal
and
busy
activity.
But some effects are better represented by ordinary arithmetic, and others by conventional numerical surfaces. A useful system should be able to combine them without caring how each one was implemented. If a better model becomes available later, we should be able to replace the old one without having to rewrite every scenario which uses it.
Explainability became more important for the same reason. Once several models are combined, a final number on its own says too little. A client or inspector should be able to ask what assumptions were used, which model contributed what, and how the pieces were put together.
That is why model diagnostics and the explanation tree are separate features. One explains the workings of a model; the other explains the structure of the complete calculation. The intention is that the system should not become more opaque merely because it becomes more capable.
The service-response model was introduced because generation is only half the waste-management problem. If a model predicts an extra 40 kg of waste, a manager will reasonably ask: which container receives it, how full does that container become, does Facilities Management need to act, what reaches the yard, and when does a contractor need to collect it?
Passing the waste history into a service model connects prediction to operational consequence. It turns "we expect more waste" into something more useful: "this is what the extra waste is likely to make the collection system do".
The richer graphics were added for a practical reason too. An inspector or prospective client may have only a short time to understand the demonstrator. The map, coloured bins, plots and storyboard make the behaviour visible quickly. But the numbers and explanations remain underneath, because a convincing demonstrator should survive a second look.
The present figures are illustrative rather than calibrated forecasts. That is an important limitation, not something to hide. Northern Ice and Caribou Ford are fictional, and some capacities, thresholds and event effects are assumptions chosen to make the behaviour easy to examine.
The point of the MVP is to demonstrate the architecture: models can be attached to places, combined into scenarios, evaluated through time, explained, visualised and passed into an operational service model. Real measurements, operator records and client-specific rules can later replace the illustrative ones without throwing that structure away.
So Green Village is more than a waste calculator. It is a small environment for building complicated situations out of understandable pieces, watching their consequences unfold through time, and keeping the reasoning visible while this happens. That is the part intended to scale.