 Good afternoon or good morning, depending where you're dialing in from my name is Brendan O'Donnell. I'm a contractor supporting PO aviation and the vice chair of the business working group. And I'll be. Leading the discussion here today for the, for the business overview portion of the face to face meeting. It's great to see so many folks and particularly that I don't recognize. So, so welcome. If this is your 1st face business overview session, and for those that are coming back, it's always good to kind of refresh the, the, the, the, the, why behind why we're doing this or taking this face approach. So agenda for today, you'll hear from 3 speakers. I'll get, I'll give the executive overview and talk to the conformance program and processes in the, in the face library. Jason York from PO aviation will talk about the contract guide and the business guide and then chip down from RTI. We'll talk about some of the initiatives. So, well, you know, as a very high level, what is, what is face? What is face? It's an open, it's an open standard collaboratively developed under the auspices of the open group. And with participants from government industry and academia, it seeks to define a new, both technical and business approaches to developing and procuring avionics software and everything that all of the sort of finished products that the consortium produces are publicly available. And we use the, the internal processes for developing consensus from the open group, but the overall goal of face and the face approach is to get the best avionics software to the warfighter faster. And we'll talk a little more depth kind of what this means here, but but that's, that's a very high level overview of, of, of why face. Well, a little more details of why or what the current landscape looks like that has driven us to the face approach. Historically, DOD, airborne systems have been developed by a single vendor and they've been developed to a unique set of requirements. Those are platform unique designs that in the past have not enabled reuse of software across programs. There's high barriers to entry or high barriers to competition within and across platforms. So it's very difficult to get new technologies sometimes onto existing platforms. And it drives, you know, particularly from the government perspective, the need to bundle software and prevent us from getting the latest most current software on platforms because we have to kind of integrate them all together in a way that makes financial sense before we're able to put those the latest and greatest software on our platforms. The chart down there on the lower right hand side talks to the increasing complexity of software over time and throughout different platforms, both in the DOD space and in commercial aviation. And as you can see, you know, a generation or two ago, a lot of the capability in a aviation platform was, was in the hardware and the systems on the aircraft and over time, that capability really now resides in the increased capability resides in the software. And commercial aviation was on it a path of exponential growth from a software complexity and cost standpoint. They, they put in some processes to drive down or break that curve in order to flatten it out and reduce the cost and time required to integrate software. And, you know, a lot of the the impetus for face came from some of those efforts to bring that to the DOD platforms. So currently, or historically, we haven't been able to reuse software across platforms. There's no set of open standards in that. And for those that did exist, it was, it was very difficult to enforce conformance to those standards. As importantly, the, the acquiring aircraft organizations within DOD weren't funded or incentivized to look across the enterprise and support reuse of software. And so the face, the organizations that started face realized that perhaps a government industry collaborative open standard may address some of those issues and face was born. So, let me tell you kind of from a very practical perspective, what's this what this means to the the warfighter who's flying a DOD aircraft, and I'll use myself as an example. I'm a former Marine Corps attack helicopter pilot in 2005, I was a young captain in the fleet, flying fleet aircraft, with no appreciation for any sort of acquisitions or systems development. I was the squadron safety officer, which, which each squadron has a school trained safety officer who's responsible for the safety program within the organization, and additionally is responsible for conducting a mishap investigations. While the ploy overseas to Iraq, we were conducting a mishap investigation that was related to some causal factors having to do with the way that the transponder was installed in the H1 aircraft. In that aircraft, the transponder was installed in the front seats, so two pilots, only the front seat pilot could change the transponder. And that transponder had mechanical dials, kind of plunger buttons that needed to get pushed. That often got stuck, lots of sand got in there. And so at one point, this, this mishap occurred because the pilots lost situational awareness due to the fact that they had to pass the controls to the pilot in the front seat in order to make a transponder change. Within the course of doing that investigation, we developed something called a hazard report, which gets promulgated out to the aviation community. And some folks came forward with a potential solution that would replace that mechanical box, move it to the tail boom of the aircraft, and put the ability to change transponder codes within our CDN use or a comm nav system. That would enable pilots in either seat to change those codes and then eliminate the problems that we had with the mechanical plungers. And so we ran that up the process. Again, as a young captain in the fleet, did everything that we needed to do, and the response that we got back was no, we're not going to do that. We're not going to make that investment. And when we pushed a little more, we said, this is, this is crazy. The cost to do this is not that much per aircraft from what we had discovered. However, the, what we didn't realize is that this happened, the hardware costs, but really was the integration intuitively of that new software that we're prohibitive. Additionally, we had an upgraded aircraft that was coming out that would address this issue. But the type model series that we flew flew for another about 10 years with this same problem that never got fixed. From a fleet aviaries perspective, something like FACE, had we had that in place, may have reduced those software integration costs and been able to provide the latest technology out to the fighter. So just a quick case study of at a very practical level for what we think FACE can improve and over the current way we field technology. So looking at FACE and this diagram here asks the question about what is competitive about all these devices and we're re-in the room together. I'd wait for an answer, but it's pretty obvious here that what's competitive about these devices is the application design. So a light bulb can provide light in many different ways. It provides different wavelengths. It provides, has different characteristics for the amount of heat it gives off, et cetera, et cetera, et cetera, energy efficiency and all of those are competitive features of the light bulb. However, it would make no sense if every time you were, you know, wouldn't be efficient if every time you wanted to change the type of light bulb that you were using in your house, you had to go completely replace all of the light bulb receptacles. So the interface to the modern light bulb has been standardized and there's an ANSI standard there that describes the interface that those light bulbs need to use in order to be, in order to be attractive to the marketplace. And this at a very basic level is what we're trying to accomplish with this. So on the left side you see how we've traditionally developed new technologies and fielded them into DOD aircraft, very low level integration. Each, on the left side, each of those technologies really has a one-off or a one-X integration cost and effort for each of the platforms on the left-hand side. With the, you know, all of the requirements that the war fighters have, we just have too few dollars to supply all of those technology needs and we wind up making trades over, you know, what technologies we're going to prioritize. On the right-hand side, with the face approach and looking at the face sort of technical architecture there that the TWG overview will go into much more detail, the desire is to be able to develop those technologies and use them across multiple platforms. And so if we do invest in a new software provided capability that we can not only use that as we would on the on the left-hand side for a single platform, but that same software can be used across the fleet. The bottom line is to be able to provide more capabilities to the war fighters for the for the dollars that we're investing. And so that drives kind of four characteristics of face, affordability, drive down costs for both industry and government, speed, enable fielding of technology at a more rapid rate, something that's been proven in the commercial aerospace world. Agility, using common architecture and common data models and data platforms, increasing interoperability across domain systems and capabilities. And then finally, excellence driving, the face does not make claims about the technical performance as we'll see here in a minute about about a face conformance software. We do believe that the face approach will support the excellence in the development of aviation software. So the two major stakeholders that that you know form the members of the consortium and really are the beneficiaries of the face approach on the one hand is the government. We've talked a bit about there, but the face approach helps government PMs. It helps government technologists address policy mandates. So, you know, there were some recent guidance released in the form of the tri-services memo. Each of the services have been promulgating updated policy mandates regarding modular open systems architecture approaches. And so face helps government systems engineers and PMs address some of those policy mandates. In addition, we believe the face approach will enable the government to spend their investment dollars in a much more efficient way. So reducing lifecycle costs, reducing obsolescence issues, enabling the government to spend their dollars on fielding technologies to the warfighter. We believe face will allow us to do that at a faster pace. So, you know, the example I showed before from my experience, you know, perhaps had the face ecosystem existed then, there would have been a faster path to be to enable the increased capability that would have made sense from a 10-year horizon when it didn't make sense because we had a replacement type model series coming. At the end of the day, we want to support reuse in order to be able to drive increased capabilities to the warfighter. Just as important, and I think something that the face approach has done very well is in the development of the technical standard and these business approaches have been very conscious of industry's role in developing software and their need to make a profit. And so what are some of those benefits to the industry stakeholders within face? Obviously, the customer has those policies and mandates we talked about earlier about open systems architectures and face helps industry support the customer requirements. Face for industry can increase competitive opportunities. So, in the legacy way of providing capabilities to the warfighter, many of those platforms, the, you know, competition was effectively locked out because a vendor didn't win a spot on the latest and greatest platform that was selected. Those vendors had high barriers to entry and because those were closed platforms. With the face approach, even if a particular vendor is not successful in getting in, let's just say on an initial acquisition of a platform, because that platform has open architectures designed in, they can remain competitive over the lifecycle of the platform. So things that were previously closed to them under the face approach are not. And then, you know, face is just a good way to do business as far as being able to reuse software across product lines, drive down industries time to develop new software and pursue product line approaches that have a real return on investment. So for a long time in this brief, we talked about face as something that was coming. Face that was from a business perspective that was very future looking and had all of these great promises. But face is up, it's running. Version three dot one of the standard is out. Industry is using software product lines with face requirements across multiple primes and suppliers and seeing a return on those investments. There's a ton of technical business expertise available. If you look at some of the face outreach events, the efforts with Balsa to get a hello world type face application out there, all of the technical interchange meetings and the integration events that have been supported have demonstrated that from a technical perspective, folks can build software to face. And folks are interested in building software to face. On the other side, government has come out with several RFIs, RFPs, programs of record that have face requirements. If you go to the face registry, which we'll talk about in a little bit, there's currently 22 units of conformance that have completed the complete process from 13 software suppliers. And every indication we have is that there is a lot more on the way. So the bottom line is that face is not something that's coming in the future. It's here today. It's ready to use and it's ready for folks to develop to. Here are some consortium members. I won't spend a lot of time here, but you can see just from the organization of consortium, they're sponsor level members, principal level members, and then associate members. It's the face is broken up into the business working group, technical working group. And then there's the enterprise architecture standing committee and the domain interoperability working group are sort of the main or the organizational structure of the consortium. A few common misconceptions, just as before we get started in talking about some of the details on conformance and the face library that that will address, particularly, we found this is helpful for folks who are participating for the first time, is that all face platform software must be face, all platform software must be face conformant. That is a misconception. What those pieces of software that are or are not face conformant on a particular platform or program, that's a business case that the individual PM will need to work through, but there's nothing inherent about face that requires everything on a platform to be face conformant. Lots of folks have concerns around data rights and how face impacts industries ability to maintain their IP. There's nothing inherent about face that makes any claim on software intellectual property or data rights. All of those things just like in any other program will require clear contractual language to spell out what the government or assistance integrator is going to acquire and those that they're not. Face as you'll see here in a bit has provided a good deal of guidance to help both software developers and program managers or integrators think through those issues. Face only applies to future systems, not true. There's lots of efforts going on right now to apply face to the current fleet. Another misconception is that face somehow guarantees or prevents airworthiness qualification. Again, nothing about face and we'll talk to you in a bit. Face really is talking about software interfaces and there's nothing about face that either guarantees that you'll be airworthy if you develop somebody in the face standard or prevents it. That being said, there's lots of work going on to assist software developers and integrators and program managers to be able to reuse artifacts that were generated for face conformance for other qualification processes including airworthiness. Misconception about faces that it either ensures or inhibits performance. Talk about this more, but face does not test your unit of conformance for function and you only test for whether it aligns or meets the requirements of the face technical standard. Then it's cost and schedule prohibitive. Again, nothing about face and we believe this has been demonstrated is particularly costly or time consuming from a software development perspective. There's lots of, and we'll talk about where you can find these, but there's lots of work that's been done in the consortium over the past several years to support development of the standard and to support folks being able to develop and acquire software that's been developed to the face standard. Here's just a sample of some of those products that are available to you. If you're interested in developing to the standard, we'll talk about where you can find some of this information. Again, as we said before, all of the work products, once they get through the internal approval processes for face are publicly available and anybody in the world can develop face units of conformance. Just real quick for those that are interested in participating this week in the business working group, we kind of have two focuses that we've taken. One is kind of a strategic longer-term focus, led up by James Doty, who's the PWG chair and chip downing, who's the chair of the outreach committee, looking forward and looking at things that are coming down to Python where we want to be next year or five years down the road. The other side of the work with the business working group is ensuring the processes that we've got today, conformance, some of our library tools, problem reporting and change request processes, are working and those current trains are being run on time. For this week, we've got two sessions. There's one tomorrow afternoon and then one Wednesday afternoon. The first session will be focused on outreach, upcoming events and some of the near-term focus work. And then the second session will be more general all hands and we'll talk about some of the some items related to face road map. So how are we looking forward and where do we, Joe talked a little this morning about evolution of the face technical standard, but where do we see that from a timeline and then what are all the events to the left of, let's just say the next either minor or major version of the face technical standard that need to happen to support that. We'll also talk about some of the website updates and some other things during that second session tomorrow. So if you have an interest in some of the face business processes, please join us for those two sessions this week. So I'll stop here and pause. If there's anybody got any quick questions on the overview, we can try to address them. Next, we'll talk a little bit about some of the more specific products and processes, the contract guide, business guide and then some outreach items. And like I said before, I am trying to keep us right about two and a half hours so folks can make the CWG at 315 Eastern. All right, thank you for your attention. And like I said, if you do have questions, go ahead and just submit them in the chat box and we will try to address them. We'll also try to make some time at the end for just any general questions. But next up will be Jason York to talk about contract guide and the business guide. Thank you, Brandon. So I want to talk to you just briefly about the face contract guide and the face business guide. But before I do that, I kind of want to set the stage, give you a bit of background while we think these are important and then discuss the aspects of each. Next slide, please. Brandon, can you advance? Sorry about that. Hey, no problem. Thank you. So over the last 20 months, we've seen a significant amount of modular open system approach guidance come out. Back in January of 19, there was a cross-services memo. We were very excited about that because it's simply called out face as an open standard. We got a couple of quotes from that memo. And shortly after that, the secretary of the Navy issued an instruction that was already in the works. But that kind of expanded upon that and emphasized the importance of MOSA for the Navy. The Army acquisition executive back earlier this year put out a policy for MOSA that was specifically derived from the tri-services memo. And most recently, the secretary of the Air Force issued an instruction back towards the end of June. So I just wanted to make sure that you're aware of all the MOSA guidance that we've received over a very short period of time. And there are, you know, follow-on more detailed, you know, guidance coming out. This isn't something for a specific service. This is really DOD-wide. And if you're interested in more details on this, we actually have it in the Face Business Guide 3.0 that will be published soon. So hopefully by the end of this week or maybe next week. But it's definitely in the pipeline and should come out so you can read more about this. So why is this important? Next slide, please. So MOSA and the face approach. And to understand MOSA, there are really five principles that it's broken down to. I've got them listed here. And the face approach actually addresses each one of those principles. So why is the face approach important? Because if you follow the face approach, now granted, it's restricted to the software domain. That's what we are as a component level standard for software. But if you follow the face approach, you address all five of the MOSA principles. Or at least it greatly helps you address all five of the MOSA principles. So that's why it's really important. Next slide. So the face contract guide 3.0. This was recently published in June, right before the virtual 10-year anniversary meeting. So the intent of the contract guide is to help with the finding requirements, help recreation of solicitation with face requirements. It actually provides sample language that acquiring PM can go in and read tailor for their facilities. And it's broken down, the original version, version 1.0, we focused on request for proposals. So that's broken down in the specific things that you typically see. Statement of work, section L, section M, section H, and deliverables. So in the deliverables coverage of the contract guide, there's a table. And it goes through the standard software deliverables and any specific tailoring that you would need for face. And one thing that's really telling is faced up and require additional software deliverables. They're seed drills. We start talking about additional seed drills. PMs start bringing time and money. Well, we fit context of deliverables that's already currently out there and common in acquiring software. So for version 2 of the contract guide, we expanded it. We were seeing a lot of request for information coming out. So for version 2, we added request for information. Section E gave some example topics that covered a few different things including data architecture, data modeling. And then the most recent version, we expanded that into broad agency announcements and other transaction authority topics because we were seeing a good bit of that coming out. Just for, this may be old hat to most people, but the broad agency announcement, it does follow the FAR 30-016. And you can use that for acquisition of basic and applied research, but it can't be specifically related to a specific system or a hardware procurement. Now, the OTA is not governed by FAR, but it gives the government the authority to carry out certain prototype projects. So it really helps streamline and what we're seeing here is acquisition of innovative research and prototype from industry and academia. So I'm sure that most of your seeing things come out, opportunities come out in DAAs or OTAs, so we decided to expand the contract guide to cover those. And I want to say, there's many different ways for the acquiring people. We didn't want to be cookie cutter, so we took a standard approach, but we also provided a commentary box which shows other ways to ask for certain things. Maybe you don't want to have a separate risk management plan, and if Paulie should explain that you're pretty small, but you want to roll that into a software development plan, we get commentary in there to give you some options. We couldn't enumerate all the potential cases that are acquiring PMs on my encounter, but we tried to cover most that feels pretty common. And the contract guide, the focus is, like I said, acquiring PMs and their staff to actually, where the rubber meets the road to go out and make procurement with products that satisfy face requirements to acquire that software. Next slide. Now the business guide version 3.0, like I mentioned, it is going to be published. It's in the final stages of publication, so you should wrap up and get that out published and make it publicly available. It is more of an outreach document, and it goes over the value and benefit of the government and industry and how they are addressed. And what you will see in that is a lot of this makes about it, how the face approach is satisfying the most about it, and it is the reason why you should follow the face approach. So those are the two assets that I wanted to cover with you today. Next slide. Quick summary, comparing the face contract guide, the business guide, who is our intimate audience and what is the purpose. If you have any questions about this, we have contact information for James, Brendan and myself. We are happy to engage with you and provide you with anything you need on either of those. Okay, Jason, thank you. And Mr. Matthew Drew, I see your question there. That's a great question. I promise you we will come back and we will address that. I would like to keep moving here and give Chip enough time at the end, and then we will come back and definitely talk to that. So next topic is to talk about face conformance and that process, and perhaps we will address some of your questions here, kind of the why, what, who, and how related to the face program. And so what is face conformance? It is an assessment of a software item or domain specific data model known as a unit of conformance to the applicable conformance requirements in the technical standard. So the, that which gets certified is known as a unit of conformance. And it gets certified against the face technical standard. So I've briefly discussed a bit earlier. It is not a measure of any of the functionality or performance of the software that's to be being developed. Only alignment to the face technical standard primarily how those interfaces align to the technical standard. Some verification evidence is done by inspection, but there's no functional testing as part of the face performance process. So if your, you know, your algorithm adds two plus two, face will not be checking to make sure the answer is four. And if it's five, it won't, it can still be face conformance. And it's also not a guarantee of a plug-and-play solution. So face does not eliminate the need for systems engineering, but it likely reduces the level of the engineering requirements in order to reuse that software. And so when we talk about face, and if you've been around the open group for any number of times, certain folks will beat you up about being very precise in some of the language. But there is no compliance to the conformance standard. There's no alignment to the face standard. It's either certified conformant or it is not. And what that means is it's completed all the steps in the face conformance process. Systems don't get necessarily a face certification. Only those units of conformance are what gets certified. And a system or a subsystem can be made of both face-certified UOCs or software components that don't align to the face standard. And there's currently no face certification for things like independent libraries, runtimes, or frameworks. So why do the face conformance process, why do face conformance in this Jason highlighted earlier, one of the most tenants was having certification. And so face provides a level of confidence that the unit of conformance does comply to the technical standard. So we'll talk a little bit here about some of the roles in the face conformance process. And as you read some of the documents that Jason described earlier, you can get more details about each of these. But we talk about the software supplier. And let me just say, often companies can fill, well, a few different roles, but the software supplier generally is that entity that's developing software to the standard. So that could be an integrator or the original developer or anybody else that wants to get a get some software certified. Face verification authorities have been approved by the face steering committee. And there are several of them. I believe right now there are four face VA's. Some of them are government organizations. Some of them are commercial entities. But those are the those are within face that is who conducts that for the record tests that tests your software against the face technical standard. And then once that's complete, they provide the verification evidence for the face certification authority. So there is a single face certification authority. Currently it is the open group. And that's the organization that's required or that's responsible for ensuring that all of the paperwork from the VA has been complete. All of the data about a face UOC has been provided. And then at the end of the day, they're the ones to provide that face conformance certificate. In addition to that, there's also some benefit that they provide from a trademark and maintaining the brand of the face perspective. And then additionally, there's the face library administrator. So that's the entity also being performed by the open group currently that is responsible for managing the listing of the face of the face certified units of conformance that are published publicly available in the face registry. So just a very high level diagram of the process that the face conformance program lays out. Before a software supplier gets started, there's some work to be done to the left of the process, which is preparation. So that's understanding what's involved in developing the software, doing your homework and then building your software. When a software supplier is ready, they can initiate verification of that software that's been developed. And to do that, they will coordinate with one of those face verification authorities. That is a contractual relationship between that software supplier and that face verification authority. There's a cost associated with getting that unit of that software verified. That cost will vary and it's a market set price. So depending on how complicated your software is, the cost may be relatively low or high. Once that process is complete, then the software supplier can initiate certification of that unit that software. They'll provide some paperwork. They'll provide, you know, they'll acknowledge the terms and conditions of using the face brand, the face logo, all those things. And then there's also a fee that I believe is about $980 right now to get that unit of that software fully certified. Then when the software supplier wants to, they can register that software in the face registry. So they can make that face certified unit of conformance publicly available for folks to discover. So whether you're a systems integrator or a government program person, there's one place to go to discover face software. So a few takeaways. In face, the software is either fully, has completed the face conformance process or it's not. So there's no such thing as being almost face or aligned to the face standard or compliant with the technical regulations of the face standard. It's either been through the process or it's not. If you want to learn more about conformance, if you go to opengrip.org slash face, there's a conformance tab. And then for everything we've over the last couple of years, one of the keys to success to navigating through this process is getting with your verification authority early. They are the technical experts on doing face conformance certification. And those folks can help you navigate through the most difficult part of the process, which is getting the technical certification. So that's a bit about face conformance and the process. And I'll talk next about the face library. So I'll go through these relatively quickly, but face has provided infrastructure to discover units of conformance that have completed the process. In addition, there's a few web tools, the web page, and a couple other tools that support communicating information about face and also some of the certification processes that we'll talk about here in a second. So we have this something called the face registry. It's at facesoftware.org slash registry. And as we discussed before, only software that has completed the entire face conformance process is listed in the registry. So once it's complete, then at the software suppliers initiation, they can publish that into the registry and the world can discover their face unit of conformance. The registry is kind of set up like an Amazon. You can filter for different characteristics. You can search the registry and the purpose there is to promote discovery of face applications. When we get to how you're going to actually acquire or get that face unit of conformance, that then moves into kind of a one-on-one contractual interaction between a software supplier and the acquiring party. We have something called the face landing page, which a lot of you I'm sure I have seen, but it's at opengroup.org slash face. And here's where you can find lots of information on generally about the consortium, when the next meetings are. And then this is really the gateway to all of that publicly available face information, the documents and things that we talked about a few slides earlier. To support gathering the metadata that eventually will populate in the face registry, the government members of the consortium have developed and provided to the open group a workflow tool. So users can log in. You can provide metadata about your unit of conformance. And then there are steps in the process to get that metadata published into the registry. And as you can see at the top, that workflow in the workflow tool maps to the high-level diagram we talked about earlier. And then the face registry, as I mentioned, is where users can go and view those units of conformance that have completed the process and that are available to be acquired. I mentioned earlier that all of those face documents, once they're complete, the internal open group review process are publicly available. So anybody in the world can get them and develop face conformance software for those users that don't have access to something like the face-to-face meetings, or for anybody that has a problem developing using those published documents and tools. We also have a problem reporting and change request web tool. So any user can come here, can log in. Their information is anonymized when it gets submitted, but they can either provide recommendations for improving an existing face document or tool, or if there are a problem developing to the standard, they can communicate that. When things come into the tool, they get adjudicated, they get sent to the right folks within the consortium to address them. If their routine matters, they get put on a certain track to get addressed, if it's something that's preventing a user from developing to the standards, say one of our tools is not working as advertised or there's a problem that the consortium wasn't aware of, that gets on an accelerated timeline to be addressed. And so the face library, as I said, everything contains a few tools, the website, the problem reporting change request process and the registry primarily, and it's really about supporting the infrastructure for developing and discovering those face users. Okay, still haven't forgotten about the questions in the chat. We'll chip you're up and I'll click through your slides and then we'll come back and address those questions and then anything else and then that way folks who need to move on to the TWG will not hold. Thanks, Brendan. Can everybody hear me okay? Yep, got you on the clear chip. Perfect, next slide please. I am Chip Downing. I am the Senior Market Development Director at Real-Time Innovations. I also am the face BWG Outreach Chair. We have a committee that's formed to promote face globally. Here's our charter right here about promoting the adoption and support of the face technical standard and business approach. These efforts include developing, coordinating, messaging, education, events, outreach efforts, whatever it takes for supporting a global aerospace defense audience. Next slide please. So today's, or I think it's, yeah, I think it's today's outreach agenda during the BWG meeting. We typically go through new announcements and updates and there's typically always something that changes almost every meeting. We'll talk about the different government speaking opportunities. We look at our five-year strategy. We have Army, Navy and Air Force update the team on their commitments. Also take a look at some activities, events that are coming up here in the near future. Next slide please. Things change. Certainly COVID has made a lot of things change. We're going to have a face technical interchange meeting and that's an event sponsored by the face consortium and its members where we meet at a facility and demonstrate our face conformant and or face aligned products together. It was supposed to be in the Holiday Inn in Solomon's in a couple weeks. It's not going to happen now. It's now going to have been pushed off to March 23, 2020 at the same location. This is an event that's open to everybody. It's free. There's no cost to attend. There may be a slight cost to exhibit but in most cases it's free as anybody can come in including folks from outside the United States. It's not an ITAR or any type of U.S. only type of event. It is open to everyone. It's a good venue to see all the different partner integration stacks, to see the different players organized together and just network with everybody on the team. Next slide please. This is James. Just to clarify, the date is 2021 for the next time, not 2020. I think I've been correctly marked on that chart. You're right. Absolutely. Okay. Just making sure. The date's changed so much. I know I've got something wrong here. So on this slide I was smart. I did not put a year in but the same thing happened with the aerospace tech week. It was supposed to happen in March. Then it was supposed to happen next March 2021 and just this week it was announced that they've now pushed that out to June 9th and 10th and to lose France. And if you've ever been to France in the summer times to lose a great place to go, especially the first week of June, couple weeks of June. So I hope everybody can go there. This is not a face consortium sponsored event. This is sponsored by Aerospace Tech Week. There is exhibition space available for face members and other companies that are exhibiting face conformant and or face aligned products. But there's a few spots left and I think with this date extension we'll probably do a sellout at this event. So keep this in mind as you go forward, put this into your travel plans, your business networking plans. If you are trying to sell your face conformer products over in Europe, this is a great place to try to do that. If you like being a face ambassador to European nations, this is also a great place to do that. Next slide please. Any questions? So next slide. There's some contact information here. One more. There you go. So the presenters are James Stote, Brendan O'Donnell, Chip Downey, Jason York. Feel free to contact us if you have any questions whatsoever. Back to you Brendan. Okay, James. Thanks, Chip. And I just wanted to emphasize more and send out earlier, I believe last Friday, with the registration that for the September 21st, Tim, the event itself was to get canceled and the in-person portion of that is getting moved to live next March. But there is an event on the 21st, so from today, next Monday, where the papers are going to be presented. Sally or Alicia, if there's anything I missed there was unclear about, please let me know. Yeah, no, actually Brendan, this is Sally. Thank you for reiterating that. Lauren did send out a reminder to ask folks to register for the Tim next Monday. We're looking forward to a great event. It's actually got several papers from FACE being presented and there's two tracks. So that's open. And then yes, indeed, we are looking forward to the expo live and in person on March 23rd and having a lot of the exhibitors and all of the new products and achievements to be showcased. So thank you for pointing that out. I appreciate it. Alicia, anything to please ma'am? I would just say that there are non-FACE topic related papers and I think there's an additional five or so SOSA papers and even some of the SOSA papers show the interaction relationship between FACE and SOSA technical standards working together. So we're very, very excited about this. This is a situation where if it hadn't been virtual, all the authors would not be able to present. And so we are very, very excited that the authors of all nine papers are able to present at the team. So thank you. And in one additional comment, I apologize, Brendan, for Shanghai and the meeting real quick on the Tim next week. Once we are with our sponsor, Adakor, who's kicking it off and then Captain Wilson, who will be giving opening remarks, that's when we will shift off to two tracks. I wanted to share the news that the start of track two is actually Chris Crook, who will be doing a FACE introduction and then he will share the microphone with Patrick Collier, who's going to do a SOSA one. But that's right off the bat after the opening remarks happen at the Tim next Monday. Thank you. And that's open to... To the public. It's free to attend. Yep. So thank you for those updates. Okay. So we have about 17 minutes until the TWG brief starts. We'll shift. So number one, thank you for your time and attention. I want to try to keep us on schedule. And so we'll go to the question, Matthew, that you had and for folks who might not be able to see the chat. And the question is, can you explain a bit about the emphasis on low cost? Is my understanding that gaining conformance can be expensive and time consuming process? How do you market this to new UOC developers slash companies interested in throwing in? How can you market this to new companies interested in throwing in their hat to the FACE development community? So I will say just... And I want to make sure we were precise about this earlier in the brief. When we talk about, and I think particularly from the government perspective, reducing costs. What we're really talking about is reducing integration costs and enabling DOD to spend its investment dollars on capabilities that are going to go to the war fighter and not spending those resources on kind of deadweight integration costs. And so there's definitely other folks on this call who can talk more about the... From a technical perspective, the time and the costs for developing a FACE UOC. But I think as Chris alluded to in his comment in the chat, generally not more expensive. But a lot of that's going to be a function of the complexity of the unit of conformance that you're trying to get certified. And so I think you have to look at it as compared to what and the question is does developing a piece of software to the FACE standard add appreciably more time and effort or cost than if you were developing that software to another standard perhaps? Chris, if you're on the line, is there anything else you'd like to talk to there? Okay, great. Let's see. I hope that answered your question, Matthew. And if there's other questions, I'm happy to stay on the line for a while, but I did want to allow our folks to get a quick break before they have to be back for the TWG overview. Are there any other FACE business overview related questions? Just one last comment, friend, and sorry, Sally again. I'm also excited to announce that Jill Carter is giving the closing remarks at the TIM next Monday. So, Joe, forgive me for not mentioning that up front. We're thrilled to have you do so. Thanks. And so for folks who are new to FACE, please, you know, you saw a couple names on there. My name, Brendan O'Donnell, Jason York, Chip Downing, James Doty, who's the Chair of the BWG. There's anything in particular that you want a deeper dive on or get a demonstration of, or have specific questions from a business perspective, particularly if you're looking to advocate for FACE in your organization, and you need materials to help describe why the FACE approach and some of the benefits there. Please don't hesitate to reach out to any of us. If we, you know, if we can't do it this week because of the FACE meeting, we're happy to do it kind of a one-on-one session with anybody, you know, over the next couple of weeks to get you the information. And with that, I don't see any other questions. I'll give about five more seconds. And if anybody wants to post one, great. And if not, then appreciate your waste time. And we will talk to you later this week. And please join us for the Business Working Group sessions tomorrow and Wednesday.