The program you are going to use starts with a map of the fictional Canadian city of Caribou Ford. The map shows shops, houses, green spaces, roads, and parking areas. In real life, all of these can generate waste. A waste manager must be able to forecast how much waste will be generated, of what kinds, and test service responses for collecting and processing it. The map provides a setting for doing so.
Briefly stated, we have models, generators, and scenarios. A generator is a place, such as a shop, that generates waste. A model is a piece of computer program that forecasts how much waste will be generated and what kinds. This will probably depend on internal variables such as a shop's floor area and brand recognition, and also on external variables such as the time of year, weather, and promotional events.
A city is a complex system, and it would be difficult to fit every influence into a single model. So we introduced scenarios. A scenario is like algebra for waste generation: it lets you write formulae that describe a waste history, building them up one piece at a time.
For example, imagine a sports shop called Northern Ice. We could write a simple model that gives it a baseline waste history depending on its floor area and footfall.
But actual waste will also depend, amongst other things, on the season. Around Christmas, we might see furious activity on the 23rd and early 24th, tailing off as shoppers go home; nothing on Christmas Day; sales on Boxing Day; muted turnover during that strange nothing-much period known as Dead Week; and then a return to near-normal activity at the start of January. We say near-normal because many shoppers may find their purses depleted by Christmas.
That being so, we need ways to combine such influences. This is what our scenario notation does.
Look at the map. It contains blue, purple, brown and grey blocks. These represent housing, other buildings, shopping, and parking and delivery areas. Like many Metro maps, this one is topological: it is somewhat stylised to make it easier to read and edit.
On some of the shopping blocks are circles representing shops and cafés. As explained above, we call these generators. There are also a few symbols that we will return to later when looking at how waste is handled.
To pan the map, drag it with the mouse. To zoom in or out, use the mouse wheel.
You can select a block, generator or road by clicking it. More than one item can be selected at the same time. If only one is selected, the panel to the right displays its coordinates, ID, and a few other properties.
You are unlikely to need this information during the walkthrough; it is mainly there to help the developer inspect and edit the map.
Scroll down below the map. Under it is a table with the headings Name, Description, Expression, Range, and Run. Each Expression is a formula defining a scenario. Take a moment to read through the entries in the table.
To run a scenario, press its Evaluate button in the Run column. Several pieces of output will then appear. We deal with these in the next section but one.
The scenarios and models in this demonstrator have been predefined. In a fully developed commercial product, users would need to create and adapt their own, and the system should support that.
But that is some way beyond the MVP. We will need to design a formula language that is easy to type and read, while also allowing the system to check expressions for errors.
The details of that language will depend on the kinds of waste histories, models and combinations that users actually need. Establishing those requirements will therefore need further analysis.
So for the moment, the MVP is restricted to the predefined scenarios in the table and to the models used by those scenarios.
Here is a summary of the main output windows. As already mentioned, Waste-Impact Output shows generated waste day by day, either by waste category or as total weight.
To the right of the plot is a textual representation of the results. It shows the waste categories and quantities for each day. This is mainly intended to help the developer inspect the calculations.
Under the plot is an Explanation Tree. This shows the order in which the system evaluated the scenario expression to obtain its daily values. This is useful for development, but it can also help users check how the result was constructed.
Finally, the Diagnostics window just above the scenario catalogue shows how the model used in the expression arrived at its result. At present, it has room for only one model's worth of explanation, so it under-reports scenarios that combine several models. One task in moving from the MVP to a fuller product will therefore be to find a clear and convenient way to present diagnostics from several models at once.
One principle behind this MVP is that programs should explain their advice. There are way too many programs, ranging from video recommendation systems to hallucinating large language models, that cannot.
As we shall see, the system displays explanations in its output windows. The one that interests us here is Diagnostics, above the scenario catalogue. Exercise it now by pressing the first four Evaluate buttons, looking at Diagnostics, and comparing each batch of output.
You will see that the first three buttons all produce diagnostics that mention "rules" and "firing". Thus, the first model says
Model: shop_baseline
Inputs:
floor_area_m2 = 700
activity_index = 1
Output:
waste_kg_day = 26.19 kg/day
centroid = 26.194977083202925
Rules returned: 9
Rules firing above zero: 1
Active rules:
1. THEN waste_kg_day := waste_26_2 firing strength=1.000
AND membership=1.000
floor_area_m2 value=700 set=medium_floor membership=1.000
activity_index value=1 set=normal_activity membership=1.000
To make sense of this, look at the shop_baseline knowledge base.
The model treats floor area and trading activity as fuzzy quantities. Thus a shop may be more or less small, medium, or large, while its activity may be more or less quiet, normal, or busy. The rules combine these descriptions to predict daily waste. (If you are unfamiliar with fuzzy reasoning, then before going any further, please read About fuzzy logic.)
For Northern Ice, the inputs are a floor area of 700 m² and an activity index of 1. With the original knowledge base, these lie exactly at medium floor area and normal activity. Consequently, one rule fires at full strength, predicting approximately 26.2 kg of waste per day.
But now press Evaluate for fuzzy Variant A. This model interprets the shop in exactly the same way: Northern Ice is still medium-sized and normally active. What has changed is the amount of waste that the rules associate with medium-sized shops. The model has been recalibrated downwards, as it might be after collecting better measurements from real shops.
From a shopkeeper's point of view, Variant A therefore says: "We have not changed our view of how busy your shop is; we have changed our estimate of how much waste a shop like yours normally produces." The knowledge base itself is at shop_baseline Variant A, if you want to see how it works.
Next press Evaluate for fuzzy Variant B. Here the waste quantities attached to the rules have not been recalibrated. Instead, the definition of busy activity has been widened. An activity level that the original model regarded as simply normal can now belong partly to both normal and busy. The Diagnostics window therefore shows more than one rule contributing to the result.
This time, and again from the shopkeeper's point of view, Variant B says: "We have changed how we interpret your level of trading activity. A moderately active day now contains some evidence of being busy, and the waste forecast changes accordingly." Its rules and fuzzy sets can be seen at shop_baseline Variant B .
These two variants illustrate an important distinction. A model can change because experience has led us to alter the quantities predicted by its rules, or because we have changed the fuzzy categories through which we interpret the evidence. In both cases, the Diagnostics window allows the user to see what changed rather than merely being given a different number. Actually changing the rules is made easy with fuzzy logic.
Fuzzy-logic specialists distinguish between fuzzy quantities and crisp quantities. Fuzzy quantities are like "tall" or "busy": ones that can have degrees, and that fuzzy sets were devised to represent. Crisp quantities, on the other hand, have sharp boundaries. "Even" and "odd" are crisp: they are either true or false, with nothing in between.
We wrote one crisp shop model, for comparison with the fuzzy models. This is "Northern Ice normal trading - crisp" in the fourth row. Try pressing its Evaluate button now.
You will see these Diagnostics:
Model: CrispRetailBaseline Implementation: crisp Week-3 shop surface Generator: Northern Ice Sports Inputs: floor_area_m2 = 700 activity_index = 1 Interpolation: floor bracket = [350, 700] fraction=1.000 activity bracket = [0.5, 1] fraction=1.000 corner values = 10, 14, 18, 26.2 kg/day lower-row interpolation = 14.000 kg/day upper-row interpolation = 26.200 kg/day Output: waste_kg_day = 26.2 kg/day
The crisp model is essentially a numerical surface. Floor area runs in one direction and activity level in the other, with estimated daily waste quantities at selected points. For a shop whose inputs fall between these points, the model interpolates between the neighbouring values. A separate composition profile then divides the resulting total among the different waste types.
So the fuzzy and crisp models are alternative ways of answering the same basic question: given what we know about a shop, what would we expect it to generate on an ordinary day? The fuzzy version expresses the model in terms of rules and overlapping categories; the crisp version expresses it as numerical interpolation.
Ordinary trading is only a baseline. Waste can change because something unusual happens. The Gretzky visit model represents a temporary surge associated with a celebrity appearance at Northern Ice. The scenario catalogue adds this extra waste to the ordinary shop baseline for the period of the visit. The model also allows different strengths of event, such as low, medium and high.
The Christmas trading model represents a different kind of temporary influence. Instead of one exceptional event, it uses a calendar of day-by-day trading factors. Waste rises during the pre-Christmas rush, falls to zero when the shop is closed on Christmas Day, rises again for the Boxing Day sales, and then declines during the quieter post-Christmas period. The model calculates the difference from an ordinary day and adds that difference to the baseline.
These examples show why it is useful to keep models separate and combine them in scenarios. We do not need to build a new Northern Ice model for every possible combination of ordinary trading, Christmas and special events. We can combine the models we already have and specify when each applies.
The Twin Fort examples extend the same idea from one shop to a small group of businesses. Normal Twin Fort trading combines the baseline waste of its Sports shop, Food Hall and Café.
The fictional Northern Lights World Comic & Gaming Expo adds a visitor-spillover model, concentrated on the Food Hall and Café. The Midnight Madness Sale instead adds a retail-footfall effect to all three businesses. In the final Twin Fort scenario, the Expo and Midnight Madness overlap, so their effects are combined with the same ordinary baselines.
Again, the important point is composition. We do not need a special "Expo plus Midnight Madness" forecasting model. The scenario expression combines simpler models representing ordinary activity and temporary influences.
Up to this point we have been asking how much waste is generated, what kinds of waste it contains, and how those quantities change through time. But forecasting waste is only half the problem. Somebody then has to store it, move it and arrange for its collection. We therefore turn next from waste generation to service response.
In my introduction, I said that there are a few symbols that we'll see later when looking at how waste is handled. That time has now arrived.
To demonstrate this, please select any of the Northern Ice scenarios. Ignore the ones that follow, for Twin Fort Landing.
As before, then look at the Waste-Impact Output window. Change the view selector from Total Waste to Waste By Type, and inspect both.
Then scroll down, past the Explanation Tree, to Service-response output — Junction Crossing. Ignore the play controls for the moment and look at the film-strip display underneath. Each frame shows the cumulative level of four waste bins, classified by type as shown. Under the bins are their contents, in kg.
You can scroll these horizontally with the scroll bar under the film strip, or move through the strip a frame at a time with the play controls above it.
Now scroll back up the page until you are just under the map. The top-left block in Junction Crossing holds these four bins. A facilities-management operative periodically moves waste from them, compacts it, and has it collected by a contractor for remote processing.
I took this model from a paper on waste management at Bicester Village retail park in Oxfordshire, England. It's simple, but it's logistically plausible, and shows how we can drive waste-handling models with our scenarios.
So we can think about this in two ways. We can develop a scenario, then test waste-handling models to see which best handles the waste it generates. Or we can develop a waste-handling model, then test scenarios against it to see which are best suited to its capabilities.
In practice, we will need to do both. And in both cases, results should be attractively and clearly presented, and downloadable for use by our other analysis programs.