Pathway - The way to stop the Scope 3 Chaos

I really don’t want this feed to contribute to the sheer amount of AI slop that is being produced. So this is a qualifications section to explain how this was written, firstly these opinions are all mine and not stolen or otherwise lifted from someone else. I have written this article first from years of presentations, making notes with a pen in a journal, then I transcribed it with voice to text, then polished it typing it up, before getting it online.

The graphics, images and webpage itself are built by AI, prompted by me.

I assume, if you’re reading this post, you probably already know the difference between scope 1, 2, and 3 emissions. I won’t go into too much detail, but high level: scope 1 are the emissions we directly emit, scope 2 is the energy emissions from grid electricity, and scope 3 represents the emissions that go into the items you buy or emissions in the items you sell. Scope 3 is the hard bit.

Australia has particularly onerous scope 3 reporting requirements, some of the hardest globally. It’s mandatory for most large companies, both public and private. I would hazard a guess, in my sector of construction anyway, this would have to be some of the most fantastically garbage data ever compiled.

This isn’t because of malfeasance or people purposefully lying or necessarily wanting to hide information about carbon. It’s just, in reality, that we have made the process of tracking and reporting so damn complicated that no amount of resources or training could ever measure scope 3. It’s too complex. Because it’s so complex, we instead spend our time and resource to provide the illusion of carbon measurement, only to secretly know that at the end of a project we have spent a lot of time and money and really not achieved very much.

Hopefully that does not sound too cynical, and by the end of this article you see my point and we can agree that something needs to change, but that change doesn’t need to be extra resources or some new fan-dangled AI tool or software. We already have the information. It’s just about organising the system to collect it.

Immeasurable Complexity

What makes this complex? Well, it might seem silly, but I’m yet to find a construction project that has ever been able to tell me exactly how much ‘stuff’ it bought during its life - that is to say how much concrete, steel, fuel etc. A “small” construction project is $100 million AUD. A big one can be in the tens of billions. There are so many businesses, suppliers and materials being purchased on any one day, that tracking them all would be a mighty effort. At a high level this is outlined in Figure 01.

Beyond the sheer number of ‘things’ we are trying to track, we are also not the only ones who have to track it. Because we get people to buy things on our behalf, we ask our supply chain (subcontractors or suppliers of the project) to track for us and report to us and hope they have the resources to do so.

Supply chain reporting runs into the same wall every time:

• People are not all that interested in carbon reporting, who would be.
• They are often so small that they don’t have to report scope 3 anyway, they don’t really know what it is or why they are doing it.
• They have issues of transparency. They don’t want to expose wastage, margins, or how much they’ve actually spent on the contracts they are given, and why should they if the contract is on lump sum.
• Reporting is so boring, onerous they may need additional resources to do it properly, and that costs money, so it’s easier to report badly rather than accurately.
• Everyone involved, from regulators through to the small supplier, does not have agreed upon boundaries that make it any easier.
• Most of all, there is no real industry accepted system, software or anything to help. I don’t know of two organisations who ask for or store this information in the same way.

Because of these issues, what has ended up happening is a reliance on third parties to try and shine up the junk data. Whether that be an accounting firm charging hundreds of thousands auditing said terrible data, or an on-the-ground sustainability team or consultant that sits in the project and advises and ‘tracks’ throughout its life. As these new requirements expand outwards, more of the industry is going to get sucked into this system, and the issue is only going to grow larger, more entrenched, more complex, and most of all, much more expensive.

Only variety absorbs variety

I like to explain this problem using Ashby’s Law of Requisite Variety. The law states “A control system must have at least as many possible states as the system it is trying to control”. Each variable, material, supplier that comes onto the project is another ball in the air and additional complexity in the system we are trying to control. To control these ‘balls’ of information, we can use one of two methods - guess which one we chose. I’ve tried to show this on Figure 02.

Option 1 represents the system the industry has quietly chosen. Every sustainability professional, consultant, every extra analyst, every subcontractor’s admin, is a person bolted on, as the balls (the data we are tracking) keeps coming in and the count goes up. As we are usually armed with a basic spreadsheet (a low variety system) - we represent this by limiting the amount we can juggle to 4 balls.

Now option 2. Build the system properly (let’s upgrade from the spreadsheet) and one team has the ability to manage many more than 4 balls. This is, I guess, what Pathway is trying to do.

Pathway - a way to juggle more balls

I offer Pathway as an option for any organisation. It’s a way where we can rely less on third parties, less on our supply chain, less on manual reporting, and reduce the overall workload. That means Pathway needs to be as flexible, as complex as the problem we are trying to solve, and it needs to work easily and with as few constraints as possible.

Below is an overview of how it works, and Figure 03 walks the seven steps end to end.

• Take in existing data from as many different sources or systems as currently exist, and try not to ever manually enter anything.
• Be flexible and scalable, the same system should work across multiple jurisdictions, multiple clients, projects, contractors, suppliers, and materials.
• A ‘Material’ is whatever you want it to be: no separate reporting for concrete, fuel, water, equipment hours.
• All deliveries of these ‘Materials’ are put into the same ledger. Let’s call it a Delivery Ledger.
• Fill out this ledger as close to real time as possible. There’s no point finding out that you’ve been pouring the wrong concrete six months after the concrete’s been poured.
• Most of all, be standardised and repeatable.
• system and rules must make sense to the supply chain, as it makes sense to me or to the auditor looking at the books.

Luckily enough, in construction, we already have this system. While we may not be able to tell you exactly how much concrete or steel has entered a project, I can bet that every construction project, every supplier, and every member of the supply chain can tell you exactly how much money they’ve spent. We do that through a very well-understood and very rigorous commercial accounting system.

If I am a supplier and I want to make a claim to a construction company and I want them to pay me, I need to provide an invoice. What’s on that invoice? It typically has:

• what product was bought
• a product number
• how much of it was bought
• the unit it came in
• what date it was delivered
• some physical dockets to provide the evidence for it

When that invoice and that evidence get sent to a construction company, what do they do? They’ll have someone employed already who checks that docket. We have whole teams in construction projects that do with numbers what we need to do with carbon. They forecast upcoming costs, they budget, they do accruals, and they do earned value reporting every month. All of this information goes into a standardised, linked, well-thought-out accounting software, where the data is stored and is auditable. And just as one construction project’s contract costs flow straight up into the end-of-year financial reporting, that is exactly the path the scope three mandatory disclosures are now trying to emulate. There’s a whole ecosystem that already exists that tracks dollars that come through the gate, and therefore, if we think about it, we are already tracking carbon. Remember how I was talking about a Delivery Ledger?

Check it out in Figure 04.

The Ledger is King

Here’s an image of a typical export from a supplier or contractor’s ‘Ledger’. As you can see, we have:

• a vendor
• a date
• a docket number
• a unit of measurement
• a cost code
• material name
• a quantity
• even a cost

And this is our first of two important systems or tables that we need to track. We’ve already got the fields there that tell us what we need to know. Because every business is tracking in some way their sales in this system like this, so long as we can get access to it, we can start running the Pathway tool (or your own similar tool - it’s not too difficult to set up yourself).

Materials table

I can already hear you say “well, Keith, there are literally hundreds of thousands of different products that could ever make it into a construction project accounting system. It’s not that simple.”

To make this system viable we need to be able to store all these various materials as they are written in the accounting system and figure out their carbon. Don’t make changes to the existing data (that’s the evidence). Pathway does this by using a flexible data model to pair all these invoice material names against a set materials (and other things like equipment, energy or fuel) library.

What the supplier actually sends you

Take pipe. One pipe supplier might have over 10,000 products that they sell. Worst of all, a different supplier might have the same products but with a different product name or a different manufacturing process coming in from a different location. The current standard way that we do this is we store our data in endless flat emission factor libraries, that we look up manually every time a new material comes in. Pathway already has all this information, stored relationally.

Here’s the problem in one line. This is a real delivery docket description:

HDPE BLUE BRUTE PE100 PN12.5 DN225 6M STR

That isn’t a material name. It’s a record from an invoice, a product name, jammed into one field by whoever set up the product code twenty years ago. There is no carbon database on earth with an entry called Blue Brute. And the next supplier will send you the same shape/size and material pipe under a different name again. But look at what’s actually sitting in that string. PE100 is the polymer. DN225 is the diameter. PN12.5 is the pressure rating. All three are defined in AS/NZS 4130, and that standard tells you what a metre of that pipe weighs. So the moment we know it’s a DN225 PE100 PN12.5 pipe, we know its mass per metre. Nobody has to tell us and nobody has to type it in.

Pathway holds one table of standard sizes for pipe (and steel beams, mesh, reinforcement, etc). Each of these geometries is shared by its parent material in the system, and each row carries a weight per unit it is measured in. The docket said 24 lengths at 6 m, so that’s 144 metres. The geometry table turns 144 metres into a tonnage automatically. The only emissions factor we ever had to look up is the carbon per tonne of HDPE at that size. One number, not ten thousand. Figure 05 shows the same pipe stored both ways, and what variety reduction is available when you make the data relational.

The system learns the names

This is where we often need to get a human involved. Someone somewhere needs to pair this product name to our database, but this is the only time they have to think about it. Ideally the supplier may have already done it! Somebody looks at HDPE BLUE BRUTE PE100 PN12.5 DN225 6M STR, picks the right material and the right size, and confirms. Pathway stores that decision as an alias: the supplier’s words on one side, our material on the other, along with the conversion from lengths to metres so nobody has to work that out twice either.

Next time that exact string turns up on a docket, it resolves on its own - we hold these matches in a separate table called alias. Aliases are looked up across every project in the system. A mapping somebody made on a sewer replacement in Melbourne two years ago will resolve a delivery on a job that starts tomorrow, as long as it’s the same supplier, product name. The first project with a new supplier is real work. The second one is mostly automatic.

Every docket we read makes the next one cheaper. Every supplier’s product number we learn we’ve learnt for good. That template they export in can be scanned and ingested by the database for every project, organisation and every team. There are hundreds of thousands of products in this industry, and right now every contractor is mapping them separately, from scratch, in their own bespoke way, in their own made-up language, and throwing the work away at the end of the job. Do it once, in one place, so that everyone can use it, and what you end up with is something the industry has never had: a dictionary that says what a supplier’s product code actually means.

What can go askew

Let’s for a minute imagine that one company on a project buys all the materials. The first problem is: how does that information get put into the SAP software? It all comes down, in my experience, to two things:

1. What was written on the invoice
2. How much granularity or effort is the person responsible for typing that information, usually by hand, into the accounting software

Say, for example, we get an invoice with 10 line items of pipe delivered across a month. Depending on the software or the requirements of that business, the administrator is just as likely to just put in the total cost for all 10 pipes as they are to enter every line. At this point, we have completely lost the granularity required to track the different materials, as the activity ledger above might just say Pipes = $10,000. Whether that is the case or not, I can guarantee you that somewhere out there that information exists: listed as line items on the invoice, or more likely in the delivery or accounting/inventory system that supplier used to sell it.

Transducers, the real killer

“Whenever the information carried on a channel capable of carrying further information undergoes transduction, the variety of the transducer must equal the variety of the information which it transduces.”

Stafford Beer, Diagnosing the System for Organisations

So hopefully we agree that the carbon data we need exists somewhere in ours or our suppliers systems, it’s just a matter of getting it. This process of getting and translating it into carbon is a new way we can make work for ourselves and everything breaks down. We are asked by the client or we ask our subbies to take the thousands of deliveries they’ve purchased and translate them into a spreadsheet and report it, outside the invoicing they are already doing, and in a completely novel way.

Think about what we are asking for. Their system already holds every one of those lines. It holds them in a common format. And yet we ask them to translate that into our format (spreadsheet), and then usually a client of ours might ask to translate into theirs (web portal), its translated again to go into home company database or annual report or audit. Between these system as data is passed sits a transducer: a point where the data gets translated. Figure 06 is an attempt to show this concept, flip it over to compare what we currently do to what we should do.

So changing the data from one format to another reduces the data. What is also undersized is the thing doing the translating, usually an admin, engineer with not much time nor desire the training to do it. Depending on the company this admin might do all clients in one hit at the end of the month, or the end of the job, by which point the concrete’s been poured and there’s nothing to be done about it. The number we have pried out of them is hard to check, audit or follow up on.

In Pathway our ledger is their ledger (so there is no translating into new formats)

In Pathway we setup all suppliers for the job to report directly (so there is no middlemen making things up)

It matches the commercial work happening anyway, and our supply chain already can comply. Everyone is always happy to give us this data, because that’s how suppliers get paid, usually sitting in a folder, and they check it to pay their own bills. We’re not asking them to produce anything new or do hours of work. We’re asking for the same evidence they already use to pay their bills.

The purpose of a system is what it does

There is obviously a lot more to it, but I hope that this explanation gets to my key point. The purpose of a system is what it does. What this means, the actual purpose of our current system is designed to be inaccurate, unauditable data, and that sucks in resources and wastes time.

At best its purpose is to ceremonially rubber-stamp fake emissions data; at worst it destroys any goodwill, resource or money that was there to do anything about carbon reduction in the first place. By improving, sharing and working within the same system, we can reduce costs, improve productivity, and get back to focusing on what we really want, which is to have a meaningful impact on climate change, which should have been the purpose all along.

Pathway is not a piece of ‘software’ in the traditional sense - anyone who is interested is welcome to the database for free and to use this idea in your business or organisation. There are enough grifters in this sustainability space and I’m keen not to be another one. If you are interested in using this method for your sustainability reporting - reach out and I am happy to run through it with your project, your team.

Throughout this article I referenced two of my favourite systems thinkers, Patrick Hoverstadt and Stafford Beer, and lots of the words and terminology I used come from the Viable Systems Model. I can’t recommend enough that you take a look at their work, my friend Adam Thompson provides a great introduction to how it works and how we can use it to diagnose what’s going wrong and what we can do about it. Watch Adam’s introduction.