Handing Over a Digital Shadow

DAVID SEWELL: Hi. Welcome to this session called Handing Over A Digital Shadow. So, right out of the block, what on Earth is a digital shadow, I hear you ask? I first came across this term when reading an article by Dr. Melanie Robinson from the BIM Academy.

In this article, she explained the industry referenced digital twin to describe so many different things. But in her view-- and I'll paraphrase here-- digital twins start to introduce the user to applications such as simulation, prediction, and even control, meaning it can become an active agent in the owner's decision making process.

So as an example of that, machine learning algorithms, they can analyze data from sensors on a building and diagnose problems quickly and efficiently. These problems can then be rectified by autonomous robots performing repetitive tasks accurately and precisely at any time at all without causing disruption to the building occupants.

And really, that's probably something that owners and much of industry, including technology, don't quite yet have the capability to achieve. So, while we're not here to argue what does and what doesn't qualify as a digital twin, what we do know is that producing good quality information during project delivery is paramount if we intend to use it in operation.

So whether that be to have a searchable, accurate, and valid O&M information, or to predict the building behavior in the future, we still need that quality information. So ensuring the project information or static data is a solid quality means that it can be seen as the foundation, or indeed, the digital shadow to future possibilities of digital twin. So that's our class today.

And a quick intro to myself. So I'm Dave Sewell. I work at Perkins Will in London. And the bullet points in the slide there explain a little bit about me. But essentially, I'm part of a global digital practice team and we specialize in using technology and digital tools to provide efficiency, richer content, and develop new capabilities that hopefully advance our projects.

Now I've been interested in this topic we're going to talk about today-- we're calling it data life cycle-- since around about 2015, when I happened to meet Lester, while working on a data center project. And with that, I'll pass over to Lester.

LESTER MORGAN: Thanks, Dave. Yes, I'm Lester Morgan. I'm a director of a company called Edocuments. And we've been involved in providing handover information mainly for construction clients in stages 5 and 6, which is construction handover. And we've been developing a database platform for, I guess, 15, 20 years now, to actually keep the data as rich as possible, structured as possible, to enable us to provide many different handover outputs for our clients.

One of our continual, I guess, things we've been trying to do is to make sure that anything we do, whether it's new technology that comes out, we're always trying to integrate it and make sure we can future proof our customers. Thank you.

DAVID SEWELL: Thanks, Lester.

LESTER MORGAN: So, I'm going to talk a bit about the data types. And some of the data that we collect is structured in this way, or unstructured. Structured data generally refers to any data that resides in a field within things like databases and spreadsheets. So Excel is an example of that.

We have lots of unstructured data currently being used by the construction industry, which are really very simplistic textual files, and typically, which contain most of the information in various types of formats and types of information that is just located in unstructured files as such.

We then move on to now semi-structured data, which is really information that is partly structured. A good example of this, HTML web pages. We were able to put some tags against things like headings, and paragraphs, and links, and be reused or imported. And then we also have metadata, which is really data about data. And it provides some supplementary information to files, which is things like who uploaded it, the reference, and the date.

And also, just to note that a Revit model contains partly structured data and semi-structured data. So it falls into two categories. But most of the industry at design and construction stage deal with all these types of data. But what we really need is to make sure that any form of data is well structured and provides a good foundation.

So, connecting this structured data. So once we have this structured data, we're trying to create what's known as a common data model. And while its primary applications are recognized, the full scope of its potential remains largely unused. And what I mean by this is that we hand over information in export formats, generally. But obviously, a lot of this is available in a structured format, which gives you far more opportunity to learn and to find out how usefully this can be used not just in current applications, but also future applications.

Some of the benefits are quite self-evident. But a few examples include it's very efficient and quick, in the sense that structured data can be processed and you can query it fast. And a good example of that is Google, and the way that Google has structured their data.

Accuracy and reliability is improved and it reduces the chances of errors. So when we're passing this data into other platforms and also consuming to other platforms, we can make sure that we're using information that is virtually error free. Can provide lots of analysis and insights so we can make informed decisions based on clear insights that we get from our data.

And one of the big issues, certainly in the UK, is to make sure it complies with regulations such as the fire regulations, where we're being expected now to make sure that we can produce a golden thread of information so we can tell you who actually input the data, who checked it, who validate it, and what systems it's passed between.

And finally, a thing that I think every company wants, is to make sure we're cost effective and we're efficient in what we do. We can save time on cleansing data and preparing it. And also, this translates into saving on resources in terms of using the data, putting in the data once, and using it many times.

And as we move forward into the world of AI, we can also use it for things like automation and machine learning, which we can use large amounts of data and analyze it. Finally, data storage and management. We can store in a very systematic manner. And one of the certain future requirements for our customer is to be able to reuse and update rather than create information from new.

DAVID SEWELL: OK. So there's a different data type. So that's how we tend to use it to go forward. But with that in mind, today, we want to explain how we are working to deliver connected information via a centralized platform in an open, flexible, structured, and reusable format.

So forcing data into complicated authoring tools can be a waste of time. Our aim is to get the right people to deliver the information in the format that they are most proficient and accustomed to. Just trying to get delivery teams working to an agreed standard is quite a challenge. So we've tried to offer a solution that we hope simplifies the information delivery from project inception to completion, and even beyond that.

So just before we get going, just to start off, when we think of terms like BIM, we instantly think of the geometric model, clash avoidance, and object classification. Now of course, this is the important part, but it's only one part. Ensuring that we manage all of the relevant information in a structured way is paramount.

So, poor information management can be a factor of projects running over budget or getting delayed, as they produce massive amounts of data from many sources in all sorts of format. And this is all shared in many different ways.

So, to mitigate this, we work to provide a common thread of design and construction information, aiming to show who input data when, what decisions were made, and what time during the project delivery process did this all happen. We then ensure that we have a data framework associated to the relevant building elements.

And then, as we move forward, we then use tools to ensure that these data fields are complete before exporting into common formats for use and operation. And our process, it's aligned with ISO9650, which is an international standard, aiming to provide the right information to the right person, at the right time, to make the right decision. But we can also align with any project-wide standard, or indeed, layer in any specific client requests.

So essentially, a single way of managing a digital flow of information working through design construction to enable delivery of handover information in a common format for use in other business platforms and applications. So going back to what Lester was saying right at the start, that's what we're aiming to do.

So, how do we go about this? I think initially, we need to focus on building a data structure right at the start of project outset. So our aim approach is to understand the what, the who, the how, the where, the when right at the start. So what do you want from your handover data?

What formats do you need? How are we going to share this information? Where do you want it? And who's going to essentially go and check and make sure it's OK? So this is what we talk about right at the start.

This next slide, it skips right to the end of the process. And it gives an example of what we provide at handover information. So this is the headquarters. It's in operation. It's in use now of a well-known streaming platform, media streaming platform. And you're not looking at a Revit model here. You're looking at a view of a database, OK?

So it looks like a model. It's got models linked to it, but this is just a database view. Like BIM 360 and Forge, you can zoom in and zoom out. You can cut, you can slice, you can dice, and you can walk around it. You can also turn off the different models that make up this federated model. And we're going to go down and pick an element, i.e. a door.

We pick that door and you can see these extended properties pop up. And now we're looking at a form view of the database. And now we're going to pop in and we're going to look at the validation view of the database. So here, you can see lots and lots of data have been input here, but very many different people. So designers, constructors, and you can see that there's green and red boxes. Green means it's been completed and checked, red means there might be a duplication or error, so the validation area.

Not only that, we can also link in other information. So again, we've chosen that door from the model. We're now looking at the O&M manual for that door. Yeah, so again, linking information. So essentially, we're talking about fully connected geometry and data, like your one stop shop of structured project information.

Again, this is set up during design, populated during design, and then layered upon during the construction. This is a continuous flow of information. This is the beauty of it. And as the previous slide demonstrated, the data is now connected. So we're then able to deliver consistent information from that single database.

Handover information is exported in standard formats, so there's no collation. There's no physical delivery. There's no data mismatch between the outputs or PDFs. So really, this means that contractors don't necessarily need to deliver record documentation as we know it. We just need them to add information into that database and then we can do that export. So there's no COBie. There's no asset registers. There's no maintenance schedule, PPM, or CAFM exports. Whatever's required for this particular project, this can be done as part of an export from this database consistently using standard forms.

And I guess this really is the message, OK? So we're able to deliver structured static data that can be used as the foundation for other things, whether that be for smart integration or providing the data for digital twin. Or indeed, we provide a digital shadow to a future digital twin.

So this is all great. It looked great, didn't it? How do we go about this? What do we do? It does all sound great, but it isn't automatic. It doesn't just happen. So to deliver a digital shadow, we really need to make sure that all five of these steps are addressed. I'm going to go from left to right here.

So we look at steps 1 and 2. Really, we're talking about the client requirements. And often, these are not clear at tender stage, or often, sometimes, when we're actually starting the projects as well. And they're not very clear. And if they have been defined, it's often they've been defined using templated BIM language, unfilled and uncomplete documents, and they're not really focused on what the user really wants, the user outcomes.

So the problem with that is that when we then move to steps 3 and 4, designers or constructors. These are supply chain. These are cost focused, OK? They want to deliver the minimum. Because of that lack of clarity and because of that, it's very difficult to provide a competitive tender. You're going up against other constructors, other constructors. We want to win the project, OK? So you know what you're being asked to deliver, so you've got to put in a reasonable bid. So that's another issue.

And then we get to the next step, step number 5, what's received at the end. Now this often isn't consistent for quality. As I've said before, the information is delivered from many sources in a variety of outputs rather than what we were showing you earlier, rather than that single source or this database.

So often, unfortunately, the reality doesn't match the expectation. And clients are left underwhelmed at handover or are kind of questioning, what was it they spent all this money, and time, and effort on? And I'll give you a very quick example of this. In the early days, I attended a project meeting of about 25 people, designers, design teams, clients, project managers, cost guys, and then these two BIM consultant guys were there. They were the guys leading the BIM process.

But they started talking in this BIM acronym, and you can see people getting lost. Nobody understood what was going on and nobody really sort of called it out. An awful lot of time was wasted and we ended up delivering something that ultimately wasn't needed. So it's really, really critical that when we talk about this stuff, we need to ask simple questions and get the entire team engaged. Let everybody understand what they're doing and hopefully, we can deliver something that's of use. I'm

Now going to hand over to Lester and he's going to talk about exactly how to do that using the information management project role.

LESTER MORGAN: Thank you. So, obviously, a very, very key function, a very important role of the information manager. And during the project delivery stage, it's really important that somebody taking on this role understands the importance of these five steps.

So, once rules are established, it's making sure they're adhered to. The diagram here is basically showing us that we start off with creating the digital requirements. And this is creating the database so that we've got the right inputs, the right rule sets, and the right outputs as well.

Step 2 and 3 is taking that and transmitting that to the teams to make sure that they understand their responsibility, who needs to do what, and when. Step 4 is then checking, and validating, and making sure that if information is required at the different stages, that the information is there and available. Not only available in terms of as pure data is data drops, but also making sure there's certain output formats.

If a client wants early stage information at stage 3, stage 4, to enable to use for other purposes, we need to understand that and make sure that that part of the information is validated that happens. And again, as I mentioned before, fire safety requirements are becoming an early stage deliverable.

So we try and do this to make sure that the input is continual and gets ramped up as we go through construction. And finally is the goal of connected data, which you mentioned earlier. What we're trying to do is make sure that that single source is available, validated, and ready to be connected. And in this graphic, we're showing it connected to the model there.

So the other important aspect of information manager role is that an outside party from outside the contract is validating this information that has been input by the design and construction teams. OK, so we go to the first part of this, where we're understanding and interpreting the outcome of what is required versus what is being actually asked for.

So instead of giving very complex spreadsheets for the different client team to fill in, the better thing to do is to ask plain language questions or have conversations which will, from that, elicit the LOIs you need. The requirements that we can input for the customer saves them a lot of time because we want to make sure that they're not overwhelmed by the requests. Some of these spreadsheets run to 300 to 400 rows of information required. And not only that, each row may have 10 to 30 to 40 different data points required.

So, very simple plain language questions we would ask was, if we were asked to deliver models in a Revit format, we would simply ask, do you have staff who are trained and are able to use these models once they're handed over? If, for instance, a finance department needs information, do we need information so that they can depreciate the assets over a certain value? Again, that will give us a number of data points which we can cover by just the simple answer of yes or no.

What systems or plans need to be managed by the FM team? Will they have any external FM providers? Knowing this, we can then set the rules for how the security is handled, how we structure and enable access to that data. Are there any uptime targets to be met? Critical environments like data centers, hospitals, there's certain areas that have backup systems. And again, we need to know the level of expectation of what information they need.

So asking and answering a few questions on critical items, we can actually pre-select what's needed for that. And finally, the operating and maintenance manuals. Everyone's used to the usual PDF type single output and view. We're able, by structuring the data, to be able to provide this information by system, by zone, by department, by discipline.

Examples of this are hospitals where they sublet some of their laboratory areas and operating theaters to third parties. They may need access just by a zone or department, and we're able to do that. So really, the takeaway from this is to derive the data requirements from the plain language conversations rather than giving your customers complex spreadsheets.

Now, once we get into manage the process, we understand that we have to adopt a flexible but structured approach so the supply chain can easily provide the information at the relevant stage. And when I talk supply chain, I also mean designers, not just the constructors and suppliers.

To do that, we give them very simple forms to fill in, so that all the heavy lifting is done in the background by the database. The sharing of the information is kept very relevant. So if you are the user who just needs to input the two or three fields, that's all you'll see. You don't need to see the 30, 40, 50 fields. And we provide you these reporting tools so that when you've completed the items you need to, you can see that you've done the bit that you need to.

The challenges we face are really split into three main headings. And this is the challenges for the different information providers and reviewers, how information is categorized. Designers and operators generally tend to look at system categorized by their element, or the system, or the asset product code. Whereas constructors who are delivering to program are looking at work packages, phases, locations.

So just to explain that a bit more, single work package may contain many systems. So if you look at something like a groundwork, a contractor, or a package, it may have underground drainage. It may have road surfaces. It may have aggregates. And all these things have to be properly categorized and not just put together as one single output delivery.

And a phase delivery will normally include many, many different systems in partial format. And again, we have to be careful of repetition and duplication. Second part we move from categorization is how it's created and collated. A single system may have 8 to 10 different designers, manufacturers, installers, commissioning engineers all inputting data to make that one complete system.

And within each organization, they may be two or three different people putting in that information, from engineers to modelers. So we may need to make sure that all of them have sufficient time to pull all this information together to present it. Each of these companies also will have their own internal processes and procedures. And this will include how this data is formatted and shared, so we need to be aware of that.

And finally, point 3, how information is delivered. Each company will have their own environments, their own servers, their own email. We're also, then, during the project, asking them to put that into a CD, and also using software programs such as Revit.

So again, when you multiply all these different categories and the amount of people involved within it, it becomes a complex process. But making sure we use simple interfaces and simple workflows in a central point makes it much easier to be flexible and not try and enforce a one-size-fits-all solution.

The quality, trying to improve the quality to make sure that we don't have repeated delays in getting information reporting it. Because of these complex data supply chain, this often results in delays to timescales. So when we have delays to timescale, quality is often skipped or compressed. And not enough time is given to this.

By using this structured database approach with rules built in, we can see that information can be checked as its input, as I mentioned earlier. And when we use tools or features, such as prebuilt lookup tables, dropdown lists, we ensure that the information comes from a known source. And if a single item needs updating, then we can update it in one place and it goes across the application globally.

And an example of this is if you have a locations table and you build a location table lookup, everyone's using the same dropdown in the search tables, meaning that there's very little chance of you getting the spellings wrong or the room references wrong.

Finally, reports on all this can be generated instantly because data is being updated instantly. And the inbuilt validation will reduce the whole error checking cycle.

Finally, when we get to the delivery and we want to hand this over to the operator, we've got all the information in a single source. And we can now pivot it and connect it to other databases if we want. Because we've got this structure of assets, and elements, and systems, and spaces and rooms, that means we are very flexible in the ability to give these different outputs.

And again, these are all on demand so you don't even have to wait. When the data is in at any point, you can download and use it. And it can also be linked to models. And linking to models doesn't mean if the model is available now. Even if the model won't be available until a future date, you can still connect it into this database.

So, in summary, we want to ensure customers meet their statutory requirements. Change is inherent and we build this in. We don't expect our customers to know everything or try and predict what they'll need in the future. But what we can do is make sure that the foundations are there to make sure that we can deliver a comprehensive handover solution.

DAVID SEWELL: Lester, thanks. That's great detailed processes, and a solid understanding as well. So, we talked about this before, so making geometry data light enables designers and modelers to minimize both data input and that internal validation we were just talking about.

But this was the dream, wasn't it? It was the Revit BIM dream, the designers all working in authoring tools, embedding the data into geometric elements from design, to construction, to operation. So there's a lot of love going on there. Designers loving Revit, Revit loving designers.

Now, while most of the experts in the room here probably have no issue with this at all, often-- if I'm being honest-- our designers struggle, as does industry, given the quality of the majority of design and construction models that we receive and have to look at. Models usually look great when visualized. But ask a non-Revit expert to fill in standard parameters or define calculated values, and they start to glaze over, right? It's just not pretty.

So we tend to then mean that we need Revit modelers to assist. So we get rid of designers. We need people with Revit degrees because they're the ones that can fill this in accurately. But the problem with that is that we end up with this data mismatch, right?

So we end up with a little bit of fudging, a little bit of Revit here, a little bit of Excel here, just as an example. Our designers, their output, the thing they're comfortable with. They've always had their finishing schedule. That's what they want to use. That's how they're going to deliver.

So, to get it into a single source or attach it to 3D geometry, we have to pass that information to our modelers, our expert modelers. And they'll then fill those parameters in or create those complex parameters that allow this all to happen.

Now, the problem with this is that there's a risk of error, obviously. There's obviously duplication of data as well. And don't forget, there's the added time. No one's got any time anymore. So we've never got time. So this is a continuous problem. We need designers that are expert in Revit, or we need to move this data around and create these duplications.

But what if we had this easy button? A button that pushed and pulled data between sources? And this is without complex mapping and without running really complex scripts and that kind of thing, there's a nice easy button that went to and fro. So what we can do, what if we had a universal identifier? And this universal identifier is present in each data format. We use it to connect the data types. So you've got your schedules, your designers, and you've got your modelers and your geometry. And we've got this common identifier that's present in both. I'll just show you an example of this.

So here's a data light model with the universal parameters highlighted. So you can see there, we've got a door selected. We go into the type properties and we go into the properties. And you can see there's a UNI_ type mark and a UNI_ mark. Now there's obviously loads of other data in here, loads of other parameters that have been filled in. But they might not match the actual door schedule, for instance.

So yeah, this is what we're going to focus on, keeping the models very, very data like. And here's the data heavy schedule, OK? So again, lots and lots of information in this. And again, imagine having to fill this in Revit. Think of all the parameters you have to create, and the calculated values, et cetera, et cetera.

Now I know there's going to be a link between the two anyway. But there's always extra fields in here that we need, that's sort of not linked to geometry. But we also include here, the three parameters on the right hand side in blue, if you like. So we're back to our UNI type mark, our UNI mark, and we've also got a UNI type description there, a sort of plain language called door. And then that door will then be fed back into a PR or an SS code that satisfies a UNI class specification system. So yeah, so that's how we're trying to get around this, having the same universal identifiers in each data format.

Now I'm going to now pass back to Lester, who's going to give you a little demo of the platform in action.

LESTER MORGAN: OK. So I'm going to show you a few screenshots and then we'll launch into three videos. In this graphic here, this is a view of our data platform. And what we're showing here is that data has been imported from a model using a connector. And also, it's been imported from an Excel spreadsheet. So those are our two data sources. And in this example, it's the door schedule.

And as you can see here in the highlighted areas of your screen, you've got where the data is from, the schedule or the model, and you can see that we've got a match there on the UNI marks in the Revit identity, which means that we now know that the schedule and the model match, which means that if we need to connect the data, we can do that. And we've got some other examples there at the bottom of exactly the same.

You'll see items in green and red, which is really just showing you where there's other validation rules that haven't been met or still have to be checked, so that we can confirm that this is correct. But everything in green now is available to be used. On the next slide, here's an example of something that we've found in a model, but it's not actually in the schedule. So this is now highlighting to us that there is a potential issue where either something's been not input into one of the data sources, or maybe something's been deleted or added without one data input party not talking to the other.

Also, on the top left, I just want to highlight in there that there's also other tabs in this interface where there's more and more information that may be required. But that could be from different parties. So when you go into the data, the fields you need to fill in are for you to fill in. But there's other information that may be from other areas and other parties, things like the spares information and health and safety, which is a bit more construction focused rather than the design focus that we're showing here.

So this is a video of actually the ACC Construction Cloud, where we're going to look at an architect's model. So we navigate into the documents model. And then we're looking here at the PWA architecture models for a particular floor. And we're going to navigate to a model.

And we're going to find that door in there and we're going to look at the properties here. So the properties displayed here are simply all the properties that are part of that object. They could have been input. They could have been imported, but this has been done typically by the modeler. And we're looking for this particular field called UNI_Mark.

So we're looking to match and connect to this data. That's our identifier. And just down here are more and more properties that, if we wanted, we could get. But we're just looking at a very limited set at this moment in time.

We then go into our platform. We search for the project. And this is where we're looking to set the mapping configurations. So, from all the fields in the object, we just want a few specific fields which are things like the mark, the description, the classification, and the floor.

And as it goes through and shows you how this is all picked, you can also put further logic in there. So if you wanted just to put doors for a certain floor or an area, you can actually add further filtering in to make it really specific. So, as we're going through, we are just setting up all those different parameters. We're also picking what coding classification system, which is Uniclass at this point. And then we're also looking at the floor spaces and looking at what we actually want, whether it's the floor name or the description.

And once we save that, then that link has been set. We then look at whether all this information is being joined. So we just go into the database, check that these are the synchronized models with the Autodesk Construction Cloud. And what we're doing here is making sure that we've got the right path for where the ACC files are located. And we're going to set the synchronization and also the metadata that is included within those models. And we can set those options.

One important part in here now is to pick the relevant model and to use the tools to actually set the data extraction, to pull it from the model into the database. So once it's done in the background, the information now is synchronized and imported, and we go and look at this particular door set system.

So in here, you'll see a simple form where it shows you some data. And you can now go in and view and edit it, as you saw in some of the previous screenshots. So you can see here, for instance, there's data missing for the items in red, but there is data that's been collected. These are examples in the schedules. And now I can basically filter and search for the exact door name that I actually want.

So, in here, I'm filtering to the particular door. And you can see, it's got that information. And as you scroll to the right, you'll be able to see more and more information fields that are required. And again, these may be a manual input, or it may be an imported input from another source like an Excel spreadsheet.

OK, next. OK, in this schedule, we've looked at in the previous video how we automate the import, in this particular example, we're showing how we can import from an Excel spreadsheet. We can either import it using the tools in the left hand menu, or in this example, we're just going to show you a simple cut and paste exercise.

So you can go into your spreadsheet, cut and paste the information in, and it will pre-populate with certain fields that may already be existing. If, for instance, in this example, you have manufacturers already in the database, you can simply start searching their name and it will pick from a preformatted list, again, saving time and increasing accuracy. And if this data gets updated, if you have the automation in there, the next time the model, et cetera, is updated, it will update the data in your database.

And finally, the manual data entry. This is quite important during the construction phase because things change. And there might be small additions, minor changes, more doors added, some doors removed, some door types changed. And it's quite quick and easy just to go into here and actually just change that data you need to, rather than redoing all the schedules or redoing the models.

Now another feature in here is that you can basically use these as placeholders for data. So if the model isn't ready yet with that information but you know extra doors are being added, you can put these placeholders into this database. And in future, the modelers can come and simply take the ID from here, the unique ID, and put it into the mark field. And the data will connect at the next synchronization.

DAVID SEWELL: OK. Lester, thank you. Thanks for demo. Hope that made some sense, hope that was useful. So finally, we're just going to close out in a couple of slides here, perhaps just some of the challenges that we're facing. I think we might have covered a couple of them, but while we think that model geometry is generally good, model data fields are generally incorrect or incomplete. And they often contradict other schedules and specifications.

Same with standard O&M and spec sheets, or building regs information. It's often delivered by data inputters rather than qualified subject matters, which means that there's more QA/QC that's required. But often, it's overlooked and information is issued unchecked.

Now operational staff, I think we mentioned this already. You can see the crazy graphic. They suffer from handover information overload. Multiple contradictory sources in dumb formats and data mismatches between formats as well. So data mismatches between models, certificates, drawings, all the stuff we've been chatting around.

Now, much of these problems, though, what's the reason for this? Why are they overlooked? But we think it's because task teams-- sorry, teams are tasked with checking items linked to digital workflows that can't physically be seen or are not understood. So one project we know of, it's in occupation. It's been in use for nine months already. The supply chain still haven't delivered accurate information as defined in the requirements nine months in, right?

And I think that's a problem, right? Because those delivering digital information, they need to be accountable if they fail to do so. And the information managers, these guys are tasked with making sure everything's OK. They're monitoring. They really need the authority to challenge those that don't deliver.

So you think about it, right? You buy a piece of furniture. Suddenly, it's got a leg missing. First thing you do, you see it, you send it back, right? But when we have missing digital information, it often gets overlooked because nobody can see it. And again, nobody quite understands at the moment.

So, this is why the emerging standards like the ISO that we're talking about, they identify responsibility for checkers and approval not just at the end, but by the teams delivering. These standards are very, very welcome. What we need to do is get these workflows to be more widely understood and more widely adopted.

Just to close off then, so our experience, we've been talking about some of this. These are some of our completed and ongoing projects that are adopting this way of information delivery. I think the buzzword at the moment is day-to-day, to day, to day, that's all you hear. It's becoming more of a requirement as clients begin to understand that if they do want to look at overlaying and reviewing, and collecting data types in the future, then laying this foundation really, really early as part of the static data delivery process is kind of critical.

So with that, I'd like to say thank you very much for listening. And yeah, thanks very much.