 Gomar, before you begin, let me just provide a brief overview and introduction. So Gomar, Vance Rien's background, is he's the enterprise data architect at Shell. And in his role, he supports the contracting and procurement, as well as the safety environment and carbon management functions, and is accountable for providing a consistent and complete data design across the relevant IT application portfolios. Gomar is also going to be covering in his presentation today all about the data platform, the alignment with external development, the data platform developments as they currently are at this time. He'll be reviewing the GHG scopes, one, two, and three, support, and how do we maintain the flexibility, our plans for the next months, nine months, and also just some of the current data definitions and, again, some of the developments. So Gomar, I'm going to turn it over to you. Thank you, Heidi. You're welcome. All right, let me see if I can move to the next slide. All right, so quick overview of what I wanted to cover, building on the story that Sammy already explained a bit. So I'm going to do a bit of a deep dive in the various types of greenhouse gas scopes, as these are known as. On top of that, I'll start with an overview of how a flexible data design in this space can help us supporting multiple industries, as well as link to the various reporting frameworks, some of which have been mentioned before. And without going into too much of the technical details, I do want to highlight a bit of how the platform works, how it's being developed. And what our plans for the future are, at least in the coming nine months. So what is the goal of a data model in general? Let's provide structural thoughts initially. And those structure thoughts can then be put into, typically, into systems to organize data. So in the domain of OFP, we basically want to do exactly that. As being said, there's a whole load of different standards and reporting frameworks out there. Some of them are more or less detailed. There was quite some variety in that. And these standards also exist as standards that are covering an industry or are, in certain cases, specific to a country that sets or region, jurisdiction, that set regulations around what greenhouse gas emission figures need to be reported, how you should be reporting that. But what these standards typically don't do is they prescribe exactly how that data needs to be formatted, the data that you require to do calculations about them. So there's detailed guidance around what you should do. There's also procedures to describe how you should do it, although there is some level of optionality in there and flexibility that gives organizations the option to, for example, do calculations in different ways, depending on the available data that they have. And what we want to do with OpenFoodPrint is build on that and provide that next level of detail, basically, the structure to organize these reporting frameworks such that you can use them to facilitate data entry, processing, and exchange. So by doing that, we can get also to a, I would say, higher level of confidence about certain figures. Typically, figures about companies who are going to, companies' own operations are relatively well-known. But of course, whenever you're looking at the whole value chain of the lifecycle or product, there, of course, are many unknowns for the individual players in that value chain, because there's quite a few handoffs as products are being bought and sold. Last goal of the data model, of course, is to make sure that all of that data that we want to store and on the platform is accessible through standard what's called APIs, application programming interfaces, which allow various types of software or application services to communicate with the platform. So first, a quick overview about emission scopes that we want to cover in open footprint. People familiar with this area might recognize the picture. It's from the Greenhouse gas protocol. And this picture nicely summarizes how we determine three types of scope for emissions. In the middle, you see what's called scope one. And scope one is basically all the emissions associated with the operations of a company that does reporting. So that could be running a factory. It could be moving materials or people around with vehicles with aircraft. So it basically gives an overview of what your own operations basically produce in terms of greenhouse gases. And the greenhouse gases themselves are highlighted at the top. Sometimes one or a few more are included, but these are the six main greenhouse gases. And of course, the most well-known is CO2. All the other greenhouse gases can be translated into CO2 equivalents to highlight their impact on our environment. As you also can see at the bottom before and after the reporting company, you see upstream and downstream activities being highlighted. So those are the activities that as a company that does reporting about their greenhouse gases, you typically don't have full visibility. And this is where we want to create a contribution by making sure that it becomes more easy over time to make sure that also these what's called scope three emissions can be made visible. So as I said, scope one is your own operations. Scope two, which you see linked to it, also typically has impact on your own operations. But scope two is basically isolated in a way because it covers all of the energy that you as a company consume for executing your operations. So that's typically the electricity that you buy can be from a grid provider or potentially if it's applicable any steam or heating or cooling that you get from another provider as well but which you use in your own operations. So those are the scope one and two emissions, which we are covering in our first minimum viable product of the reference implementation of open footprint. So we want to capture those first. But then building on top, going back to the scope three emissions, we want to improve the visibility on the other emissions. So on what's highlighted as upstream activities, those can be, for example, your employees travelling to work. That's something that produces emissions as such. It's considered also as an emission that in the end attributes back to the products or services that you as a company sell. The same applies to any items, goods or services that you buy from other companies. If you of course use the menu operations to produce something new. These products also contribute to the overall footprint of the products that you sell as a company. Likewise, on the downstream activities, you see a similar list. But then this focuses more on what happens after you have produced a product or service. So it can be the processing of the goods and services that you sell. It can also be the use of those. In case of a raw material that's being sold. Of course, the impact of processing that raw material into an end product. That's also something that over the whole lifecycle of the product of course has impact on the total number of emissions. So with that, this is the overview. In the end, we want to make that big distinction between first, what do you have visibility on as a company that does reporting, which is typically your scope and scope one and scope two, and potentially to some extent also your scope three emissions, which are called upstream. So what do I take as an input? But with the platform, we then want to further extend this view against the whole value chain, which we are aiming to do with the Business Council for Sustainable Development to make sure that we can exchange product emissions along that supply chain. So how does this data design look like in a nutshell when we consider the picture that we just saw? So at the top, top left, you'll see an overview. So off what's very much trimmed down version of a data model. That's all of this, which you see on the left and on the right hand side, you see some example, dummy content that links back to the objects that are highlighted on the left. So I'll go through this structure to explain a bit how we organize data that's related to emissions. So looking at various standards that are out there, thinking of the greenhouse gas protocol or the ISO standards in this space, first thing you typically do as a company, if you want to have visibility on your emissions, is to set what's called boundaries. And what boundaries basically describe in this context is really saying what is actually considered my operation and what's someone else's operation. Thinking of the picture we just saw of the greenhouse gas protocol and the scope one, it's important to distinguish what our operations that you as a company are operating and which are operations from someone else. Both in the end are relevant, but in terms of how you get to the data and prevent any double counting, both need to be clearly identified to make the split what's in and out of scope of your calculations and allocations or emissions. So what you see in the picture in the left, you'll see two organizational structures. And with the dashed lines you see a split being made. So in this picture you'll see that there is one suborganization which is actually not part of the other organizations on the left is taken into a scope. These things can happen because what you typically do is you look at an organization, how it's broken down into subsidiaries or business units and you say all of these business units, their operations we consider all in scope. But it might be if you have for example a big financial stake in a company but you're not doing the actual operations, you still might want to include it in your operations or in your operations figures if you have the information for it. Vice versa is also possible. You expect the other company to provide the exact details around emissions related with their operations and you just as a consuming company then need to disclose a percentage of that figure to your own operations because you have a financial stake in that company. So the first step is setting those boundaries and the boundaries are typically started like I said on the level of organizations. But the breakdown into the next level is basically the business activities that you execute as an organization. And these can be very high level activities like this is my commercial branch as a company and this is my production branch. But you can break these down into very detailed level of activities and these lowest level activities are sometimes also called greenhouse gas sources and sinks. So those are the activities that produce or take greenhouse gases out of the air where of course producing them is much more common. Such a low level activity can be something like what you see over here. You have an activity of transporting. Subactivity is road transport and that would in terms of classification if you have road transport. Biggest source of emissions is the combustion of fuel. That's typically categorized as something called mobile combustion. So your lowest level activity would be then basically saying driving a car or driving a truck. In the example here on the right. Now what you can do for these activities in order to get figures for those basically get information about how you calculate those you link them to your company assets to the facilities that are executing or involved in executing those activities. So in this example, I have listed here an activity of transport which breaks down into road transport potentially air or sea transport as well. You and the facilities in this picture would be your trucks. Other activity could be cooling your buildings and what you would do over there. You don't have a direct facility involved in that. Maybe you want to say I have my air conditioning system that you kind of link. But if you say, well, we just paid the electricity bill and we don't distinguish between our air conditioning and our heating system, it might say, well, we just link to the activity we link the consumption. And that's what you see over here. What's called activity parameters. Those are all the measures or metrics that you want to capture about the activities that you're executing in order to calculate emissions. And again, an example is given on the right. So in this example, we are staying with the example of trucks moving goods, for example. There would be three parameters, activity parameters that are being highlighted over here. So the first one is fuel consumption. So for a truck, you want to know how much fuel is consumed. You typically break that down by the periods over which this is done. You look at what is the carbon intensity of the fuel. Very, very much. Of course, nowadays, if you have an electricity, an electric vehicle, the carbon intensity of the fuel might be zero unless you say, well, actually the electricity is produced by burning coal, then the electricity doesn't have a carbon intensity of zero, but a higher one. So this carbon intensity, in this case of fuel consumption, is another parameter associated with your activity, but this is typically a static one. So you have a default figure, for example, for gasoline or for diesel that's being used, and that allows you to do calculations. Then another related figure which is often useful to do a calculation is the actual distance that you have covered with your truck. So those are your activity parameters. And of course, I'm simplifying the world here in realistic cases when you're monitoring a plant. The calculations would be much more complicated and you would stack much more of them. But the principle states the same. You calculate or, first, you list down what are the parameters that describe the operations of my facilities, which ones I use for executing certain activities. And then you're combining these into calculations and for a lot of standard activity, standard processes, there's a given formula that you need to execute and what formula you need to execute, as well as maybe the static data, like the factors that you use, like carbon intensity, these might be dictated by the reporting framework that you use or that you have to use. So that might be something that's different in one country as opposed to another, because local regulations might say, well, you need to use this carbon intensity figure. So you combine your activity parameters into formulas, basically into calculation methods, which then can be used to collect emissions at the lowest level. So I have two simple examples. One which allows you to do a calculation on the carbon emissions. Just make sure that you multiply your carbon intensity, which are fuel consumption, which gives the actual emissions of your activity, of truck driving. What's typically important as well next to the absolute emissions that are being recorded is, of course, to record the carbon intensity as it's sometimes called. So how many tons of CO2 do you produce per distance in this case? But it might also be per product that you sell as a company. So that highlights how efficient are you as a company in producing something? So in this case, you need slightly different figures, or you need actually the travel distance in addition to your carbon intensity and your fuel consumption. So you get a figure by combining the travel distance in this mixture. So again, this is just two very simple examples of doing a calculation, but it summarizes the way that we bring these things together. Now, the last step that you typically have to do as a company is combine these figures that you have of your operations into greenhouse gas statements. So these hold the actual quantities of produced emissions. As well as maybe the intensity of your operations, the carbon intensity of your operations into statements. Typically done for the specific breakdown of your organization into business units, maybe into the activities, high-level activities that these business units are executed, and then filtered by a period. So that way, in a nutshell, you have summarized how you can get to your emissions. Of course, there are very many nuances around this. So for example, just highlighting one. If you don't have the direct figures, for example, around your fuel consumption, in this case around truck driving, what you can do as an approximation is saying, well, for my whole fleet, I paid X amount for an amount of diesel or gasoline or something like that. And on the basis of what I've paid, so basically on my invoices, my fuel invoices, I'll do a calculation of the emissions of my trucks. And you might even have to, if you don't have a clear figure about the details of the fleet, so maybe you use partly third-party vehicles and you don't know whether it's a diesel truck or an electric truck or a combination. In that case, you have to, of course, assume a different carbon intensity of the figure. All of those things would need to be fit into your calculation. So you can say, well, the quality of my data order, but uncertainty about my data is bigger because it don't have the direct figures, for example. That's all things that we want to embed into our data design, so into our model that describe the calculation. So not just the raw numbers, but also these kind of figures and potentially you want to refer back to the standard that you used, that, for example, dictates what figure for carbon intensity do you use. And if you need to provide evidence to an auditor about what were your truck emissions as a company, you want to be able to be articulate which carbon intensity fixture did you pick and why did you pick that. So that might be metadata that you want to tag to the actual calculation that you've executed. So with this in mind, the platform is set up using a few principles that facilitate the whole process of having transparency on what's basically stored in the platform and how it's used. So the key principles are about preserving raw data in combination with all data are immutable. So what do these things mean? It means that all data that you take into the platform is persisted and cannot be changed after it's been ingested. That doesn't mean that you can't do updates to data. That's very well possible. But every mutation to data is stored as a new version if you can, for lack of a better word, new version of the same data set. That way we can facilitate full transparency about what happens to the data as it's been processed. Associated with that, we want to make sure that data ingestion efforts are minimized. That means that data is loaded onto the platform as fast as possible and processing is done afterwards. Processing could mean tagging with the right information about who can edit it, where does it need to be stored, when was it modified, etc. So the benefits of doing that and the last principle I forget is to bundle data that's related to each other in what's called work products. So we bundle related sets of data together. So think of the organizational boundaries with the activities that the company executes by these are bundled into a work product. And that's used. Those work products are used to provide small package of information that can easily be consumed by a user or by an application service that's steered by a user. So the key benefits of those principles is to make sure that emissions, but also the factors and all the import models that we used to calculate emissions or to store emissions can be audited in a transparent way. Immutable data along with the right metadata tagging makes it possible to easily search through all of the data that we have from the platform. So it's organized in a way that you can easily find back data that you persisted before. And of course the last one which is very important especially if you exchange information between organizations about scope 3 mainly, that we do that in standard formats. So it's easily understood which facilitates automation and therefore minimize the cost of doing and doing so. So I eluded already to the implication of this. So in case of a change to a data object a new version is created tagging, processing done after loading of data and the last that I didn't highlight too much so far is that the idea of the data platform of OFP is that multiple applications or software service can interact with the same data set. This is different from what you sometimes see with applications or services today is that because this is a single platform the idea is that applications that interact with it don't need to exchange data directly with each other is they both communicate with the same data on the platform. They both have a connection to the platform which makes sure that you can execute basically something like a workflow on top. So you have one application for example for setting up your organizational boundaries if you want to and maybe the next step of defining the actual calculations for calculating emissions might be done by someone else by a different application service but it's done on the same data set. So there is with the central platform you prevent direct connections direct connections between applications are not strictly needed because both applications if they can communicate with the interaction service of the platform they communicate with exactly the same data set and only modifications done are stored and again as new record in the platform. So how do we want to make this flexible the main point here to make things flexible on the platform is to make use of what's sometimes called a data-driven design and the idea behind that is what you see in the in the table over here is to have a template which defines in this case default inputs and outputs for for calculated emissions and the way that's done is in the example I filtered by an industry sector the activity as well as the emission source and the idea is that all of our I would say reference data is organized in such a way that in case you get for example a new requirement from a reporting framework or maybe from an industry specific framework you can bring that into the system with actually without changing its structure. So as you can see we simplified we want to put things into a table it's not really in reality in the platform it's not really a table but a data object but it highlights in this case and I'll go through the example on the left it highlights to which industry sector is in this case this is about calculation to which industry sector is this calculation applicable you can make a selection there maybe multiple combinations are valid you'll highlight for which scope the emission calculation is you connect it to the activity for which it applies and then following categorization that's typically used by the greenhouse gas protocol as well by ISO standards you have a categorization that tells a bit more detail around what kind of emission is this that way you can collect all the associated calculations in this case and the same might work for all the associated input parameters because they are collected over here as well that you require for executing a certain activity depending on the industry or the domain in which you're operating as a company so sticking with the example here at the top you see four again simplified view of the world for calculating scope emissions if you're talking about the road transport which categorize as mobile combustion if you talk about the fuel burnt two input parameters are required you need to have an emission factor per mass or volume of fuel and you need to have that volume of fuel that you combust calculation in this case is aggregate all the volumes of fuel consumption that you have multiplied by the emission factor that gives you your emission for scope one mobile combustion for road transport in this case I refer to a standard for factors this is one of the international energy agency that provides emission factors for fuel combustion and again multiple standards or multiple reference databases provide these figures and those figures can vary so important again to include the standard that you use for your calculation in the actual audit trail that you do for executing your calculations next example this is about upstream scope pre emission so basically this is this is about purchase goods so in this case if for your activity of packaging your goods you buy cardboard or paper to do the packaging so you're buying a material and that material the amount of cardboard has of course an intrinsic CO2 emission value associated with that so you have to take that into account so as part of your packaging operations if you're a logistics company you consume basically carton and paper so also for that activity you need to tag CO2 emissions to that packaging not just by doing the activity itself if it's done by hand by people the packaging there's no emissions from your operations from doing it but of course the carton or paper that you used does have these emissions so and there again there's a standard that holds these factors to give guidance about which figure or which factor you should use for doing the calculation the last three lines are about in this case an example of the cement industry there's a a dedicated standard or the cement sustainability initiative that provides guidance around doing calculations for the cement industry and I just picked up three examples for scope 1 and 2 scope 2 is as I mentioned at the start of the session about purchased energy in this case purchased electricity so what you need to know is your power consumption and the power consumption emission factor in a case where you just take energy off the grid you can use grid factors which are refreshed yearly from the International Energy Agency that tell you how much which percentage of the energy in this green so basically how much carbon is associated with producing electricity of course this figure changes if you have as a cement company you might have for example your own power plants as well or in an advanced case you might have solar panels of course your power consumption first needs to be adjusted for that so that you only talk about the power consumption of the electricity grid so that they do that calculation which would be a separate entry again in this very same table then there are two detailed activities being highlighted the calciumation of clinker which is typical activity in cement production as per the cement sustainability initiative to tell you what do you need to know about the amount of clinker that's produced and from that you're going to get the fraction of calcium oxide in there because by heating the clinker CO2 is emitted so from your operations first you need to know how much calcium oxide is actually in the clinkers and then next step actually two calculations required to get to your emissions first get that number and from that number you get the translation factor again this is given by in this case the industry specific standard that tell you what figure do you need to multiply with in order to get from your amount of calcium oxide to the number of CO2 molecules that are being produced which tell you what your emission is so this is just one example that covers the definitions of calculations this holds for all of the data design that we try to do as much as possible basically abstract away from the actual content and load the actual content in this case definitions of calculations as values into our data design such that the model is fully flexible and can be adapted maybe for specific calculations for a company but also to various improvements or changes that are made to industry specific or country specific regulations so how does this look like in the platform summarizing we start off with certain inputs so I talked about your organizational boundaries your activity data your measurements factors static data which you either get from external standards or if you have an advanced laboratory you may have tests about the products that you consume as well so you might know far better that the fuel you're burning is maybe less carbon intensive so all of these data you combine basically you combine you feed into the platform and in combination of course with the reporting framework that tells you how to combine these figures you store that on the platform and that can be done by any application so also parts of these figures might come from one application and others might come from a second application but the principle always is the same as I mentioned the idea is that any application communicates with the same platform such that you prevent direct connectivity that's required between all kind of applications which could create a whole load of interfaces so the idea is with the platform you have the ability by using standard structuring of information any application feed data into the storage it's processed over there and recorded and it's made available through a search engine such that you can find content back in an easy manner now then your outputs could be carbon intensity figures there could be statements and reports that you want to disclose at an organizational level of course there can also be statements for an individual product thinking of this whole operations you might say well we're not going to do our calculations for my total amount of emissions but given by the X number of products I'm producing I'm going to make a breakdown of the emissions produced and split them towards the different products that I'm producing and of course if you have one step you're covering one step in a value chain you want to exchange at least these product level emissions or service level emissions between organizations so this is an optional step if your counterparty organization also uses open footprint they basically would have the same methods of storing the information so again this principle could also work with third party applications of course only if as a company you want to do that you can of course restrict data access completely so there's no default option that the whole world can look at your data but it's a possibility so how does this look like in the picture of the what's called an architecture picture an IT architecture picture you saw a very small example of this already in Sami's presentation this picture covers in a nutshell what the platform is about so the platform covers the blue parts and the main area that I've talked about so far is this blue box the beta platform an ingestant framework so the data design the simplified data design that I talked about just before is sitting in this area so this is here where we set the standards for storing data and processing data and all of that communication to that data is handled through what's called APIs these application programming interfaces these facilitate the exchange of information from and to the platform now in our case of the reference implementation the colors are a bit off here now what's in gray basically is basically not part of the platform that could be any application that sits on top but what we have with the reference implementation and Surab will probably tell more about that what you see in green is we have with the reference implementation of open footprint we have a default user interface basically so screens on your computer that you can use to interact with the platform itself so you can create alternatives for that you can also say well I have my own application which communicate with the platform but at least there is this default front end that communicates with the platform and also part of the platform will be at least the default calculation engine which allows you to do emission calculations yourself again these can be done using using the template inputs that I just shared before which highlights which calculations you can do and then in your organization setup you can then define the applicable ones and link them to your actual data so how do deployments of the platform look like so just to stress once more the idea is not to have a single platform for everyone in the world the idea of open footprint platform is that every organization every company can have multiple deployments on their own one or more deployments so if you're a small company you might only want to have one if you're a big company you might have multiple deployments but these deployments are organization by default so just to stress that there's no one big platform that everyone connects to everyone can have their own setup of the platform and setup the integrations with their own existing software might be there that might be your ERP in which you have maybe sales figures or production figures about the materials and services that you buy and sell it might be operational data if you have plans it might be third party data around your travel but that would be all within a single company and these deployments can be deployed on your own physical hardware if you want to buy a server and they can be deployed on on cloud infrastructure and as was mentioned at the start for example AWS and IBM and Microsoft and others can have their own implementation of the platform so as a company you could say well we have a implementation and we want to deploy it on our own cloud infrastructure so you can also scale up and down as you want to so between different deployments within a company you can replicate metadata such that the same configuration applies to multiple deployments while users can be across the world and communicate with each instance individually and then what's optional it's possible if you want to thinking about scope three emissions if you want to know how many or what emissions are associated with the services that we buy from another company that might be something that you agree with that other company we want to exchange information about that in that sense you can connect to open footprint deployments across companies to each other as well by exchanging that information so quick overview of the roadmap and plans for the next months of course our first priority is to you will see a demo in the coming days of that is to have our reference implementation launched like I said that covers not only the platform itself a full setup of the platform but also a user frontend so screens that allow you to interact with the data platform directly and we and we allow you to enter emission data and take out emission data plus related data so the things like carbon intensity or input figures can be stored already on to the platform and then building on that we want to extend that with calculation support for scope one two and three emissions so initially we have already have an overview of some industry specific attributes as we call them industry specific requirements so to say like I showed in the picture for cement there are some specific requirements what do you need to disclose for an activity how do you do those calculations we want to embed some of those already in the first release and that's something that we want to extend over the coming period with under other industry sectors to make the platform even more widely useful of course as an individual organization you can also define your own calculations and entries but these inclusion of these sector support templates make the whole process a little bit easier first we also we have a basic reporting capability and data entry capability on top and on top of that we work over the next months to basically like I said extend with for other industries but also start working in a bit more detail around making sure that accounting rules can be embedded and that the auditing and logging which is embedded into the platform can be organized in such a way that you can actually hand that over to auditors in cases in case you want to have your emission figures audited in such a way that it's workable for them and we work with other standard organizations to develop integration with the data platform and we want to facilitate the process of reporting input data so on the requirement side the input for doing calculations we want to make sure that you can do checks already upfront before you do your calculations so for example on quality of the data that you get into your platform as a starting point and then longer term we want to consider the inclusion of non-GAG materials because the principle of calculating the footprint of a product does not only cover of course greenhouse gases if you think of environmental impact or impact might be important to disclose as well but the same principles can be followed for that so we want to have that into the platform as well we want to be able to facilitate external disclosure of information maybe to regulators for example in standard formats which can be done on top of of course the data that already sits in the platform then and we want to facilitate the exchange of scope 3 or partial scope 3 product footprint calculations across a supply chain of organizations that connect to each other related to that there might be there might be requirements also for more complex allocations of scope 3 emissions again in the story before I talked about you might not always have primary data so data that you have from your own operations and so you have to fall back to what's sometimes called secondary data so data from standard database that tell these are the default emission factors of product X and so on these are the rules you have to follow in order to calculate emissions if you don't have measurements or direct data about that again that's something that we want to build up as we as we scale out our solution and bring in new features so with that I want to hand over back to Heidi thank you Gomar that was terrific an outstanding job so thank you thank you again we have quite a few questions so Sammy or Johann did you want to share or read some of the questions for Gomar or yourself they would have been answered at the same time okay wonderful I think there are a couple sorry Johann I think there are a couple that Gomar would be good to get your feedback on as well I see this one from Tupolt I apologize if I butchered the names but there's a question around you know the need for a universal template and catalog vocabulary to organize the data sets and harmonize the methods before we facilitate the input how much work needs to be sort of done ahead of time to kind of get everything ready to put it into everything we just talked about it's nice to have it up front but I think it's also important to keep in mind that a lot of companies already have calculations defined for their emissions the I think the real value of that of bringing or doing that ahead of time is that you simplify especially for calculating scope 3 emissions simplify the life of everyone but like I said the templated structure is extendable so that way it's possible to do this after the fact of course with which if you for example change your calculation then of course will impact the actual numbers that you can out as well but it's not a direct requirement it's a nice to have maybe a bit more than nice to have but it's not really required the more we have the better but of course it's workable without any other questions I think there's one other one around from Sonya here around the specifically asks is a relevant where the users are located to choose where the infrastructure is deployed you know considering issues around latency and you know users being in different locations what's the viewpoint around that that's not important because the protocols we are using are not latency sensitive so you could have your open footprint implementation in one country it could have users in the US sites around the world even because your applications will be browser based and your data lonely is also not data sensitive so I don't see that as a real problem for the implementation Excellent I think there was one go ahead Johan please one other one maybe maybe you see the same one there was a question about is there a marine version available yeah go for it okay yes we have and we're going to hear about later today from Gravinda I think it's late today we are looking at various industries and looking at what do we need to add to the scope one scope two definitions to support an industry and marine I think is the one of them we've done and you hear about late today but the principle the way we support industries is making sure looking at those industries what are the important fields we need to add to scope one scope two and make sure it's part of template you just heard about from Gormaar we can support these industries as well we make sure that for certain industries certain fields are being asked for anything to add to that No that's right and maybe one thing I made the example of the of course the calculations for industry specific we're also looking into making I would say different templates for industry so thinking of marine in the case of marine you need to at least for bigger ships you need to register for example the identification code of the ship I don't recall the exact name of the field but that kind of information we put in a separate template basically for example to label your assets in this case ships it's not just restricted to calculation inputs and outputs that those industry specific data okay Sammy do you want to answer the last question is there a carbon footprint for the reference architecture I'm going to say yes because I think there's a carbon footprint for everything there's actually a number of articles around the carbon footprint of artificial intelligence that I've seen but I think I would say yes have we quantified it is probably a better question the answer but I think it's a good worthy test data exercise for us so thank you yeah I think this was the last question Heidi okay very good well everyone thank you we have a 15 minute break and so we will be reconvening again at 845 central daylight time and that will be 45 central European time and just as a reminder please enter your questions in the Q&A we do see some of them have been added to the chat so we'll try to address those as well but just continue with us and we'll be back in 15 minutes