Mission AI at the Edge: Equipped, Not Disconnected

Edge AI fails when it assumes a network. That is the through-line of this hour-long FedInsider panel, recorded August 26, 2026, with CW4 Reginald Oliver, Chief Digital Transformation Officer at U.S. Army Capability Program Executive Aviation, and Nick Weir, VP of Mission Engineering at Legion Intelligence. Mark Krzysko of FedInsider moderates. The conversation covers what actually changes once an AI capability reaches the field, drawing on recent Army exercises including Project Convergence Capstone 6 and Scarlet Dragon 26-01, where systems ran on ruggedized edge servers without reachback to enterprise intelligence sources.

The panel treats edge and enterprise as one system with an unreliable link rather than two separate environments. Running a model on a laptop in a tent is the easy half. The harder problem is reconciliation: maintaining a record of the data that arrived, the decisions made, and the repairs completed while a unit was communications dark, then integrating that record back into systems of record once connectivity returns. Both speakers make the same practical point about model size, which is that a small, tightly scoped model with direct access to the right technical manuals outperforms a frontier model that lacks the operational context. The discussion also covers how authorization to operate applies to AI software, including containerized and continuous ATO pathways that shorten the path from development to fielding.

The second half turns to trust and measurement. Token counts and document volume are the wrong metrics; the right ones describe changes to the operating unit's outcomes, such as time to complete a maintenance action or capacity to sustain more aircraft. Surfacing the sources behind a recommendation, so an operator can verify the reasoning rather than accept a black-box answer, is what shortens time to trust. Time to value is measured from the first meaningful outcome, not from installation. Acquisition reform, iterative delivery, small forward deployed engineering teams that hand ownership to the unit, and the cultural side of digital transformation round out the session.

Legion Intelligence builds for the conditions this panel describes. Centurion by Legion Intelligence is a deployable edge system for denied, degraded, intermittent, and limited environments, and The Denied Column examines the architectural case for AI that holds up when reachback does not.

Transcript

The transcript below was produced through Communication Access Realtime Translation (CART) and provided by FedInsider in rough-draft format. It may not be a verbatim record of the proceedings. Names and technical terms may be rendered inaccurately. Where a system or program name was clearly mistranscribed, the correction appears in square brackets alongside the original text. Section headings have been added for navigation and were not part of the original proceedings.

Opening and Introductions

Mark Krzysko: Good afternoon, everyone, very excited, interesting topic today. Getting new capabilities into the field should not take years although we talk about it that way. When mission demands change, organizations need solutions that can be deployed quickly and perform in real operational environments. Even though connectivity is limited.

US military is learning what changes after a capability is fielding from faster mission workflows to more reliable operations, and how those lessons can inform future deployments. The US Army staged Project Converge Capstone VI [Project Convergence Capstone 6] in late July to rigorously experiment with future technologies by significantly expanding the scope, scale and complexity of operations tested in earlier exercises. Join us today as thought leaders from government and industry, sharing their experiences in turning funded requirements into operational capabilities within an existing budget framework then scaling those capabilities across forces. Joining us is CW4 Reginald Oliver, the Chief Digital Transformation Officer, Capability Program Executive Aviation for the US Army. He leads the enterprisewide digital transformation and the application of artificial intelligence to the Army's aviation and sustainment mission.

Reggie has served in aviator and maintenance leadership positions throughout the world, including deployments to Afghanistan, Iraq, Syria, Kuwait and the Arabian Gulf. His work increasingly focuses on bringing AI, data and capabilities into aviation readiness and sustainment. Thank you for your service, Reggie. Also joining us today is Nick Weir, VP of Mission Engineering at Legion Intelligence and leads the Mission engineering team at Legion. And is responsible for all production deployments of Legions products across government classified and unclassified environments. As well as commercial environments and also leads Legions Century and [Centurion] line of deployment products. Nick led the AWS US federal professional services team for computer vision. He also held the data scientist roles at AWS as well as serving on the advisory board for many nonprofit space LLCs.

Where Enterprise Systems Break Down at the Edge

Let's just get right at it. How about that? Let's start with you, chief, you are responsible for digital transformation across the aviation fleet. Most of what you inherited was built as enterprise systems. Where do things break down when enterprise systems is all you have and where should be go with that?

CW4 Reginald Oliver: Yeah, Mark, I appreciate the time and providing a few insights today. On behalf of our program executive, Rodney Davis I want to say hello to everyone in the audience. What is interesting about the question especially from a digital transformation respective is CPE aviation insurance we are aligned with the army digital transformation strategy and the Army unified network plan. We actually find some of the prime opportunities to extend the reach of our enterprise systems and determine what our foundational framework and architecture is for our data and information infrastructure. It is to leverage the power of the enterprise systems that are approved, and make sure we can at least improve the way those enterprise systems can work well with edge technologies.

For example, by us developing hybrid cloud to solutions and edge computer architectures from the folks over at the engineering and architecture assistant capability program executive, CPE aviation's and sure that aviators and our maintainers on the flight line aren't isolated and transforming the enterprise from a static repository into a dynamic reach capability. This empowers local decision-making and so when we execute operations forward and while I speak for CPE Aviation stands as the Army aviation acquisition arm, our job is to modernize, train and equip our fighting force, and sure our leaders and soldiers in the front have everything they need, I think what is important is when we approach it from understanding that sometimes we will have decentralized operations, that those operations with those groups of troopers out there doing the work to fight our nations wards, that they are never disconnected.

Mark Krzysko: You know, it was music to my ears listening to how you aligned to the enterprise of the Army, I feel like I made a contribution when I was an OST.

CW4 Reginald Oliver: Absolutely.

Mark Krzysko: Trying to get out of your old way. Nick, what are your thoughts about that?

Nick Weir: Yeah, everything Chief Oliver mentioned, I certainly agree with and thank you, Chief Oliver for being here and Mark and the FedInsider team for managing the session, I'm excited to share some thoughts. I think a lot of folks present edge and enterprise as two fundamentally different and consistently disconnected operational spaces. And increasingly, thanks to initiatives like what Chief Oliver was describing, that is not the case.

But the technology and the applications that are delivered to the edge environments are still lagging behind the ability to leverage what is available at the enterprise, in some cases, and vice versa in some situations.

So the real opportunity I think is to provide systems, and products, that can work disconnected, or in distributed mesh type configurations like what Chief Oliver described when you are in a decentralized operational paradigm, and the capabilities that are there at the enterprise scale when they do have that connectivity back.

And also have the understanding to be able to reconcile inconsistency between what may have existed as an operational plan before things kicked off and before the unit went comm silent versus when things finally did we connect later. There is a lot of opportunity there in terms of maintaining high op tempo and be able to continue to operate in a disconnected environment where we are just starting to scratch the surface there.

Authorization to Operate for AI Software

Mark Krzysko: Thank you. We had a question from the audience, Reggie, you raised your hand about that, how do you maintain your authority to operate there?

CW4 Reginald Oliver: Yes that's a great question because, that probably leads, that will be a segue to the next question. That we have. The great thing about ATOs authorization to operate, is that it's a fundamental approval through the appropriate communications and channels. To allow a specific type of software, or hardware, to operate on a network. So there are a few ways to attain an ATO, and the reason why they are so important is because there has to be a little bit of vetting. I know there are a lot of vendors, and resources that want to operate artificial intelligence and tools in machine learning, algorithms military networks, but it cannot be the wild West.

I appreciate what headquarters, Department of the Army, DCS G-6, to make sure networks are secure. There's an application process, and I would yield based on which vendor is trying to get an ATO with a specific service, because they are all doing it a little differently.

But the thing about ATO is an approval to operate tools or software on a military network and the reason that is important is there is the standard ATO, or you can also work with specific entities that have attained an ATO through containerized environment, where you can develop, test and produce a specific solution within a sandboxed environment and once again pipelines to production, because it is containerized inside of an ATO environment, you essentially inherit a continuous or CATO, so to faster tracking process because a lot of the development, test and production is on the devsecops side of the house part two tool production, is something that is a little faster than the traditional ATO route.

Granted the traditional ATO route is more arduous but it is certainly something that is quite enduring for the specific platform or application you are looking to try so the continuous ATO, shout out to our colleagues at the artificial intelligence integration Center in Pittsburgh, they have a couple environments, once called Expedition Zero where they've pioneered the way you can develop a containerized application, and then get it through development, test and production, and get it out to the force quickly and inherit a CATO so shout out to all the colleagues over there at The Artificial Intelligence Integration Center.

Operating in Communications Limited Environments

Mark Krzysko: Thank you, Chief. And you even built the segue because the next question gets to that. And it talks about given your experience in deployed maintenance operations, what are the opportunities, challenges, pitfalls, you were just talking about one of them, in a communications limited environment?

CW4 Reginald Oliver: Yeah, especially with communications limited environment it truly is not necessarily a point of failure, some see it as a pitfall but it's one of our primary innovation frontiers. The challenge of local model adaptations is driving us to design truly resilient edge-native AI. So want to tag AI2C, because there's a program called Griffin AI, and with AI2C created this maintenance and predictive analytics tool. It was exposed to the entire force, and it is something you can run locally and continually track your readiness of your fleet, as well as your personnel.

And that's one of those types of tools that program has since been handed over to and managed by Captain Brandon DeArdine but that's an example of how the Army is using its resources like AI2C and the phenomenal personnel, the AI engineers coming out of Carnegie Mellon and they are the ones looking at the innovative solutions at the edge that can be used on the enterprise systems we have, and not necessarily put the tool or the need of information inside of an AI-focused environment, yet an environment that enhances and augments the mission of the soldier. And augments the enterprise systems we have available today, such that there is not only just network resilience but a way for us to track and manage our readiness resilience.

Mark Krzysko: Yeah, I really want to follow up with that because I have always been a mission first person, are your predictive analytics helping you in that mission?

CW4 Reginald Oliver: Absolutely. And you know, what is great about this is the way we are leveraging predictive analytics and predictive maintenance analysis, is so that people in the front, so the fleet managers in the Army and Army aviation, we call them production control officers, or aviation maintenance officers at the battalion level or brigade aviation maintenance officers, and they use these analytical tools at their respective echelons, to show them the information they need to appropriately manage the operations of which they've been charged to manage.

I don't want to see us management by exception, but there is a very high fidelity of what your status of the fleet is at the time. And it enables each of respective echelons I have the right information for the right need to make the right decision, and that is key and what we continue to do in our nations army, and Army aviation, to continually support the efforts to leverage artificial intelligence in machine learning tools, to improve the efficacy of our workflow such that we can maintain our readiness of our fleet. Because we know there may be challenging times whenever we have multiple missions that we've been charged to execute by the commander-in-chief.

But that said using innovation at the speed of and point of need is paramount for our nations forces.

Mark Krzysko: Thank you, Chief, Nick, on your perspective on this limited communication environment?

Nick Weir: Absolutely. There's a lot of challenges in terms of trying to bring the systems that were really built primarily to operate, you know, living in the cloud, living in the big data center, a system that relies exclusively on big frontier models or something like this. And attempting to operationalize that in environments where you just can't trust that you will have connectivity back to those models, or pipes big enough to send the information that you really need.

What we see time and again, and makes perfect sense, given the risk soldiers are putting themselves out in the field, is that if the system does not work in the disconnected environment the way that you would expect it to, it won't get used. And that is appropriate. No one has time to be trying to debug the system or trying to figure out why is this AI tool that is supposed to be making my work faster, more effective or more accurate, not working for me?

So really, what we found is that you need systems that, AI based systems, that are built to be able to operate in those disconnected environments, independently, completely independently.

You cannot rely upon connectivity back to a frontier model that lives in the cloud. There is a lot of challenges that come with that. There's, I think, for the good, there's growing appreciation of the capabilities that some of these really big AI models have. That are available within the cloud. But then there are also the disconnect of, I have my rugged laptop sitting in a tent, and why am I not able to do the exact same thing that the system would do within the cloud?

And that is where we feel that building much more purpose-build capabilities around AI, that similar to what Chief Oliver described around the predictive maintenance use case, enables you to deliver value in a way that you can trust and continue to work in those disconnected environments, to continue to support a mission need.

Defining the Edge and Choosing Hardware

Mark Krzysko: Thanks, Nick, let me stay with you on this because you mentioned this of not even differentiating between enterprise and edge here. But I think sometimes we need to talk about the word edge, it covers laptop, it covers RAG. How do program offices decide what part of this they need? What advice do you have for them?

Nick Weir: That is a good question. It is true, edge can be considered something body wearable or considered a server that can live in a fob or on a carrier something like this. Or anything in between.

And really, the way I believe folks who are thinking about acquiring capabilities in this space should be thinking about it it's a lot less around the device itself and the people that are doing whatever the task is that the AI is enabling you to operate, is this person moving between different aircraft as they are doing maintenance on the flight line? And therefore, they probably need something that can operate without power, that can operate on a laptop or tablet, or something along those lines. And likely, with pretty inconsistent connectivity back to a home base.

Is this something, like what we set up at PCC6, where you are going to have an operational planning element that is going to be operating, yeah, they are in an austere environment, but they are not moving every single moment they are performing the planning, they are setting up and operating out of the same location.

In that case, you don't necessarily need every single piece of your AI technology to live on the laptop, you would be able to have something like the ruggedized edge server we were deployed on during the exercise, to provide more powerful compute and a bit more power to the AI systems that were enabling the operational planning piece.

So really grounded in the way the users operate, is kind of the way that I would encourage folks to think about it, and from there you can get a better understanding of what are the pieces of hardware you can operate with?

Running Fully Disconnected at Scarlet Dragon 26-01

Mark Krzysko: You all are doing a great job setting up my segues because I wanted to go to operating when the network isn't there. And it builds on what you are talking about, Nick, it's Scarlet Dragon 26-01, XVIII Airborne Corps, your system ran fully disconnected on the tactical (indiscernible) what is fully disconnected mean in practice and at what cost?

Nick Weir: Good question. And at that particular exercise we deployed our application on a ruggedized edge server and we were supporting a bunch of intelligence use cases for the unit there.

And what that really meant was, because we did not have connectivity back to a central enterprise intelligence source, or something along those lines, and that was intentional, that was part of the exercise scenario, we needed to do a combination of pre-staging the right data and right intelligence, coming prior to the exercise, to support the operational context.

And then be able to take advantage of that new data that arose within that tactical environment over the course of the exercise.

In terms of cost, that really comes down to the cost of not being able to have that reach back during, from a moment to moment basis. And we will get a little more into what that means. But at a high level, the thing that I see as critical is finding ways to maintain high operational tempo when you don't have that connectivity still.

And then enabling reconciliation back with those supporting elements when connectivity is restored. Because that is the real value prop of having a system that can be connected when, or is connected when it can be and not connected when you have to go comms dark or when you are connectivity is denied, is being able to really maintain seamless operations at whatever is the best of the units ability, given the comms environment it is operating in.

Reconciling Edge Activity Back to Systems of Record

Mark Krzysko: Yeah, I was thinking about that because you find that cop and you go off and go dark and then you have to come back in the connectivity. Things changed, there's a lot of time and distance between those aspects of that. How do you recognize with the enterprise when connectivity comes back?

Nick Weir: I would start but I would love Chief Oliver's perspective also.

I think one thing that we have established within our product for when we are doing this is the ability to maintain the running record of all the new data that is coming in at the edge environments, and something we are actively developing now is the ability to maintain a record of the decisions that have been made, the actions taken, that are going to be relevant to that system of record.

If we are talking about an army vehicle maintenance example, for example, where you have some list of prioritized repairs that might need to be made in a disconnected environment, and when the unit goes comms dark the maintainers are fixing the things and they're not able to go back and update GCSSA [GCSS-Army] and say, all these things have been fixed, and then trickle all that out to the logistics associated with making further maintenance actions in the future. And so being able to maintain individual's ability to operate based on the information they have but then finding ways to ensure that there is seamless integration back with those systems of record, when you do restore connectivity.

But I think Chief Oliver has a lot more experience in this particular spaced on me so I would love his perspective.

CW4 Reginald Oliver: I don't mind interjecting. What's interesting about whatever your comms are disconnected in an operational environment and maintaining the high op tempo, so in the dark both in comms and daylight, you know, you don't have that bidirectional automation cycle you generally expect whenever you have connectivity of our devices. But what a great frontier is and this is where I would yield to our commercial partners and their expertise, is looking towards that edge compute that is on prem of devices. So, small, highly, highly, highly trained and finely tuned for a specific task.

Because there are plenty of times when we have to go to austere environments, for example, we have to be very creative with our limited connectivity on our devices when we have to do some austere environment maintenance on some Apaches in Syria at night with not a lot of connectivity.

So we have to make do with what we had in our enterprise systems. And think about how that connection actually is going to work once we get back to our deeply connected enterprise solution. So to your point, Mark, when the connectivity gets turned back on or when you are there, one of the things to think about is an opportunity for vendor driven solutions is being able to have that highly trained, finely tuned edge compute on prem that can cache all the work being done and also run analytics on the work being done, predicated on what it had prior or what it knew from the network prior to losing connectivity.

So that way once power is restored and that connection is restored, the bidirectional optimization cycle that can continually improve your maintenance and predictive analytics will work well for you and that creates a seamless ingestion of tactical insights that will be required, to make some more of those deeply important decisions for your combat operations, especially when you are operating at the edge or if there is to centralized command and control.

What the Enterprise Needs to See

Mark Krzysko: Yeah, I tend to think, in your past back, it's not only the data in the disconnect but you mentioned the data analytics which is also a product, how do you build them both back you have particular insight at the enterprise, that the enterprise needs to know that they might not see, nor do you want them to do the work because you are closer to the problem.

CW4 Reginald Oliver: Absolutely, based on what needs to be seen, versus what should be seen, are sometimes very different or disparate information. And can be at odds. Because sometimes there are field commanders or higher orders of command that do not want to see, one of my old mentors would say the "itchy detail" they need actionable information from the data, and that's another keyword in my line of work we always save words have meaning, so data is not information but information can be data but true, raw data is something that should be a source no different than if you are going mining for gold, is you know there is a vein in there and the data is there but how do you refine it and distill it into something usable and actionable?

So what is important about what you should see versus should not, or who sees it and at what point they see it, is extremely important. So I would say for the maintenance managers and leaders in the front, so the brigade aviation maintenance officers and Battalion aviation maintenance officers and production control and quality control personnel and maintenance personnel, they are the ones that need the data and itchy details because they are turning the wrenches and torquing the bolts and doing the technical inspections to make sure the aviation assets are safe for us to engage our nation's mission whenever they ask for it at night.

But also I think it is important to have the appropriate tools and the right know-how at the people level, based on what Nick was saying and I agree as part of this, it's not about the technology at all. Some of your most effective edge compute and how you distill that data into actionable information are the people, it is the culture and how they approach the information so they can get it to the right folks but so if you're looking for providing some solutions are helping us approach the opportunities in a different way, that is where we are going, looking at how we can not only use the tools to give their correct information to the right people at the right time but also how we can improve our cultural approach to how we use that information.

From Requirement to Fielded Capability

Mark Krzysko: Chief, I will stick with you because you touched a bit on this but I will be more pointed on this, you sat on both sides of the field problem, flight line waiting on capabilities and now the enterprise office defining it, when a requirement gets translated onto paper what gets lost between those that the operator needs and what eventually shows up? How do you build that bridge?

CW4 Reginald Oliver: Great question. Something that people are traditionally accustomed to is the way we always have done it. Or the way I should say now, used to do it through to the traditional way we generate requirements in order to acquire assets has shifted.

So Secretary Brent Ingram charged all of the respective acquisition leaders and PAEs to focus and drive their organizations to the acquisition transformation strategy. And because of his innovative and forward thinking approach to how we manage acquisitions for the Army, is to ensure that we are using innovation and transformation as a point to assist our requirements generation, as well as understanding the point of need from our soldiers and service people at the front.

So what is great about the acquisition transformation strategy is the traditional pipeline was extremely linear. So you just cannot get from point A to Point B until a lot is done and you can get to B to C, until a lot is done. So traditional people say it is a problem because the acquisitions process takes a long time, well, what is interesting about our acquisition transformation strategy and some of the innovative forward thinking from Secretary Ingram is let's see what we can do simultaneously.

Instead of everything being linear, things can move in parallel and converge at appropriate points. It may look like the branching of a tree but it's ultimately so everyone can be engaged at the same time, to address a point of need from those at the edge, and then it also affords, this is what is cool about this particular transformation, is it allows for lateral communication, as well as vertical communication.

So there is no longer a worry with trying to get through requirements and then nothing happens until the requirements folks drop a document and then you can move forward. You can actually communicate amongst different domains within the acquisition pipeline at the same time, so that way everybody is on the same page and that is something that is very interesting about our transformation strategy, is breaking down the silos in order to ensure that whenever there is a reform of the gets translated to paper, that nothing is lost. Because there's been continual communication across the appropriate domains that directly affect that acquisition process.

Mark Krzysko: I am really glad Secretary Ingram has kept that up, I've worked with him at OSD and you have to look up right and up and down not just in that linear flow, it's good to hear the transformation.

CW4 Reginald Oliver: He is knocking it out of the park and were really excited about his leadership.

Iterative Delivery and Forward Deployed Engineers

Mark Krzysko: He's a great man. Nick, your thoughts?

Nick Weir: Yeah, the side of it that I see a lot, these days as I leave the teams that are delivering this capability at the edge, the way we are transforming how we deliver, particularly in AI but it's true in other products too, is these products in a much more iterative fashion is significant improvement. And it results in a lot better velocity, in terms of our ability to get high quality outcomes into, within customer environments, or with the war fighter or maintainer who is preparing an aircraft.

And what this often looks like is starting with some earlier stage pilot engagements, where with the partnership of those user groups, we are able to quickly, with the forward deployed engineer from my team sitting alongside or standing alongside the maintainer on the flight line, actually see what the task is. And identify areas where the product can help improve the process.

And so, there's obviously all of the acquisition piece to this but also just the piece of how do you actually wrap your head around what the problem is that needs to be solved more effectively? And then deliver against that. And I think a lot of products are still moving in the right direction in the space. We, The forward deployed engineer or the term forward deployed engineer generates very much all love-hate for a lot of folks.

I think the sweet spot is having a product that is intuitive and that is easy to be configured. And then having a very small team of engineers, one or a couple of engineers, from the company you are able to really get the operational units started with the capability. And also train them to further tune the system themselves. I'm not talking about all month long or three month long deep training embedding, I'm talking about eight hours over the course of eight weeks in the system. This enables two, one, not need to keep buying service hours from the vendor or something along those lines but also really enables the war fighter to own the capability that is going to be empowering them and driving the direction they want to go.

Mark Krzysko: I want to follow up with the concept that the Chief was talking about, do you see the collaboration manifesting itself in the field? Not only the engineers, God love them, but anybody from the contracts people to the program people, as a part of being a part of the process?

Nick Weir: Yes, absolutely. I think a lot of the newer contracting methodologies that are starting to get used now, the OTs and things like that that enable much faster activation. And a lot of the great prototyping initiatives being done in parallel to preparing acquisition for the longer stage, the larger stage, larger phase programs is definitely driving much faster procurements of technology in this space.

Measuring Whether Anything Improved

Mark Krzysko: Nick, let me stay with you, how do you measure and how do you know if we've improved anything?

Nick Weir: Yeah, utterly good question. There are a lot of numbers getting thrown around in this area now. How many AI tokens are you using? And people optimizing either up or down against that, depending upon their personal priorities. Or the amount of emails or documents getting written with an AI system or something along those lines, those are all the wrong answers from my perspective.

Really, what one should be looking at is the changes to the outcomes for that specific operating unit. If someone needs to, perform maintenance on an aircraft, just sticking with the maintenance example, and they are able to repair that aircraft in half as much time because they were able to surface the information they needed that much more quickly from manuals, taking advantage of an AI system, then that translates directly into the amount of capacity that you need to maintain, your ability to maintain more vehicles or more aircraft. And everything in that space.

So putting quantitative measures, matters in terms of the outcomes for the unit that matters. And much less around the intermediate products. How many chat messages can you send or something along those lines.

Mark Krzysko: This feeds right into you, Chief, is maintenance getting better? What are the metrics that you are seeing? Maintenance admission, are they really it?

CW4 Reginald Oliver: Yeah, and to Nick's point, the types of metrics you will use or whatever KPIs you're going to use have to be clearly defined and you know what is interesting, some of those KPIs be actually be qualitative and quantitative, so how do you reconcile those?

But for the question, has maintenance gotten better? Well, absolutely. Right? When we say better we say what does better mean? Have we been able to address problems or quickly, based upon the data being ingested? And analyzed? So that way we can take a look at components earlier, in that respect, yes.

Have we been able to have more informed decisions, particularly in a fiscally constrained environment, managing our resources to most effectively manage our fleets to continue to operate at the tempo we've been asked to operate, and execute the missions we been tasked to execute? The answer is, yes also.

AI tools, because while they are pervasive, they are not the end all, be all. What is most interesting about it is the reason we've been able to use the tools effectively in aviation to improve our approach to readiness, is simply because the culture is slowly shifting. People are starting to recognize that, for example, a calculator, it cannot do everything but the things that is made to do it can do pretty well. And we use calculators to do math all the time, to assist us.

And as people are getting more and more training and becoming more and more exposed, and they are becoming more and more comfortable with using these tools, you will start to see the increase in those KPIs in the positive direction, because it is just making the workflow and the efficacy of those workflows faster.

Building Trust in AI Recommendations

Mark Krzysko: Okay. Thank you. I'm going to shift a little bit here because I want to stay with you, Chief, you put your name on the line for an aircraft or maintenance decision, what does it take for a maintainer or pilot to trust your recommendation, your signature, as well as you to put your signature on that?

CW4 Reginald Oliver: Yes I love this question because when it comes to trust it is a two pronged answer.

For someone to be able to trust me or decision I've made when it comes to maintenance or readiness or the safety of an aircraft, it comes down to the most valuable commodity. Time.

Time. It takes time for people to see consistency that the correct decision is being made, and that the type of decision being made is appropriate. That said, I truly believe in that same vein of the most valuable commodity, the way that maintainers and maintenance managers are going to be able to trust AI tools that are assisting them in their work is going to take the exact same thing.

It isn't something that will happen overnight. It is not a magic pill that we can take and wake up and everything is absolutely perfect all the time. That is not the type of universe we live in. And if, I know you know this about maintenance personnel, regardless of the branch, we can be a very, how do I say? critically discerning bunch, I will put it that way. [Laughter]. So if something does not work, we will generally say, I will just do it myself.

But I think once we start to take the time to train and expose our maintenance force to how we can leverage these tools to adequately sustain our workflows and sustain our fleets in a positive way, that is what will be the most effective approach and the only way we can get there is time.

Mark Krzysko: I love that. And I don't think the maintenance group is the only one that is discerning. I mean, once you have to put your name on about anything, you really want to be sure in that regard.

But, Nick, let me turn to because you have a different perspective because the Chief mention time and oftentimes we talk about reducing time. How can you build that trust with the systems? And it is just training and moving that up?

Nick Weir: That is a really good question. I think the time spent getting experience with the system is obviously a huge part of it.

Another thing we consistently see is the context of the recommendation being given by the system. Or the information that the AI system is using to make the decision. If something is magic black box and you put in a question and you get an answer, generally, you will be more skeptical than if you can see, okay, here's all the information that this AI system used to make this decision, and I can go through and verify, yes, that makes sense, that make sense for it oh, wait, that piece doesn't make sense, that should be this other thing. And you are much more effectively able to validate the quality and the decision that is being recommended by that AI system, in the case of recommendations systems.

That's just one example of but overall, something we consistently see as being able to surface that context through citations back to sources, or whatever it might be. This is a key component of shortening that time to trust.

And particularly when your operationalizing something new in a short time window, when we were getting our products up and running for the PCC6 for the operational planning use case, being able to surface the context in terms of what the op boards were that fed into the decision or what the intelligence is that fed into a recommendation, proved to be really huge.

Model Size, Data Quality, and Context

Mark Krzysko: I would like to talk about this because when we talk about AI, it's only as good as the data. And oftentimes, we talk about it and I'd like to hear Nick and then your perspective, Chief, you know, we all search for so much information, so much data. How small can we go and have a data set that is useful in the recommendations? Nick, you first.

Nick Weir: Yeah, so having the right data available to the system is huge. And one thing that we are seeing more and more of as AI models get better and better, is that you can put a lot of time and energy in fine-tuning a model for a specific use case, and there are certainly scenarios where that is critical.

In some other cases, and this is something we at Legion have directly seen, by the time we complete fine tuning against a specific problem set, the next model has come out and it already beats the ability of the past tuned model.

And so what is really critical to making that rapid iteration successful with new models, though, is having the right contextual data and information available to the model. So if you are working on a maintenance use case and you are a maintainer trying to maintain very specialized aircraft, something like an F 35 [F-35] with the thousands and thousands and thousands of pages of maintenance annuals [manuals] associated with that, you don't want an AI system that has been trained on the bulk corpus of all the information in the world and then trying to make maintenance decisions about it. You want that system to have direct access to the manuals to be able to reference the right answers.

And even a system with a very small AI model that can run locally will perform a lot better than a very, very large model that does not understand the context in that setting.

Mark Krzysko: Chief, your thoughts there because it seems to me that requires a bit of training to understand, not only the data, but how models change and the time and distance between models. Because the world is evolving very quickly here. What are your thoughts there?

CW4 Reginald Oliver: Yeah, and, first, I completely agree with everything Dr. Weir is saying I completely agree, if you take these large frontier models, they can do a lot. But when you need something that is hyper focused on very specific, and particularly when it is for critical mission system, you are going to want something that is essentially not a generalist but an expert. So smaller models that are highly trained and finely tuned but can fit that bill, in the same vein, especially with, I will give you a quote from one of my favorite instructors. He's Dr. Reginald Hobbs at the Adelphi Laboratory Center, he always teaches us about AI, think big, start small, and iterate often.

And when we're approaching the types of data we need to be effective in dealing with this, thinking big is properly managing our fleets. Starting small is what it sounds like. Small finely tuned model that can iterate very quickly and the resourcing required to improve that small model over time by its own learning and training in fine-tuning, something we can do often that is reasonable and something that is not very prohibitive.

In doing so, the amount of data we ingest and how we use it, to what Nick brought up. But I would also say the quality of the data is absolutely paramount, especially when you're going to have a highly specific model that is going to be executing computational task for you. And for thinking about artificial intelligence at the tactical edge, well, we're probably going to need something that has on prem compute that is not resource intensive, that's relatively small that can make highly focused calculations quickly, so that way the workflow of the soldier at the edge in a disconnected environment does not feel like they are disconnected because they are being assisted adequately.

And this is where artificial intelligence can support this notion, is we are living right now in an extremely dynamic data centric environment. We've all been charged to use data and approach data as an asset.

So if we do that, we have to think about all the streams of data coming in. And how are we going to refine that data into usable information for us to do this? So, to Nick's point, the data is extremely important and the size of the models will be important, but you do not need a 1 trillion parameter model to get done what you need done on the flight line. But looking at how we approach that and how we can get refine data that is piped in to these smaller models may be the ploy.

Data Governance and Time to Value

Mark Krzysko: I'm going to follow-up the next question. Not all source systems agree which gets to the data governance piece at the edge. How do you manage through that to help the operator get what they need because there may be I, I hate to use the term governance. Because all systems are built on a green field. Nick? Do you want to take some of that?

Nick Weir: Yeah, this is one where they are two different problem sets here intermixed. In one case if you are dealing with a situation where the task you're trying to solve the problem you're solving is inherently one where you're not totally confident Intel use cases are a great example. You want to be exposed to all the potential information that could conflict with one another to make the right decision. There are other cases where this is more of a reconciliation issue. And getting back to the flight line example that we talked about earlier is a good one. Or you may get directives to make repairs coming from a higher order or outside organization that do not understand that you are making a bunch of repairs when you went comms dark and ran out of whatever part it is, so your priorities need to be different.

And that is where you need to have a clear reconciliation process as part of the system. To ensure the edge to enterprise integration we talked about at the beginning of the conversation. But certainly I would love chief Oliver's thoughts as well.

Mark Krzysko: Chief?

CW4 Reginald Oliver: What is interesting about this I truly believe that the way we are leveraging the tools we have and how we are approaching them are absolutely leaps and bounds better I would say and they have been because we're trying to continually innovate. I want to slightly pivot because this addresses one of the audience questions that we got. And there's a couple of them. But in particular I want to talk about this because one of the things were touching upon now with Nick's comments and Mark, your comments is value. And how we look at the tools and technology in terms of value. So I first want to bring up that the time to value is extremely important anytime were looking to adopt any of this technology and looking for a cultural pivot in what we do.

So want to make sure that the time to value we generally see and measure is not just time to when we first adopt technology but the first measurable outcome, and to Nick and Mark, to your points, these mission, these mission measurable outcomes are extremely important to how we do things.

What Has Changed Over the Past Two Years

Mark Krzysko: Something I've always grappled with. Chief, from where you sit. I assume we've gotten better over the past two years. Where do we take credit for what you have done over the past couple of years to get to where we are today?

CW4 Reginald Oliver: I appreciate that question. From an aviation perspective for AI adoption. I can't take too much credit for this, but I certainly want to say that at the time our program executive officer, Brigadier General David Phillips, who has since been promoted onto some other things in DC. But his innovative mindset and desire to make sure ADH and for the Army stays relevant for the army of 2040 and beyond, he's one of the biggest advocates for artificial intelligence and digital transformation as well as our capability program executive. So for both of them I appreciate their support in allowing to be able to look at how we leveraged, both internal and external solutions.

So when you ask have we gotten better, this is a no-brainer. I tell people this. For the digital transformation side people asked what does this mean, what does the digital transformation officer mean. A lot of people think digital transformation must mean technology. It must mean like using the hottest fastest tool. So that is about 10% of the job. Because 90% of the job of digital transformation is about people. Because this is a people business. The Department of War and army and aviation, were in a people business. So at the end of the day, developing the organization mindset? And the approaches to how we use the technology, I'm sure, Nick, you've seen similar things, you have to develop the type of culture that will be inclusive to the technology that you would like to leverage.

Because ultimately, the ultimate thing is that the workforce has the work flow and the tools you use to improve the efficacy of that workflow is what is paramount. So I would double down, both General Phillips and Mr. Davis both have that innovation mindset. And the Army acquisition executive, Honorable Ingram allows us to develop a culture that supports the integration and application of these tools.

Mark Krzysko: Well said.

CW4 Reginald Oliver: I know you guys have a perspective.

Mark Krzysko: Go ahead, Nick.

Nick Weir: I mean, it is a great point. And I think watching the evolution of AI fielding in general has gotten better across so many facets in the last few years, in terms of authorization of the systems, and appreciation of what it means to ATO and an AI product because an AI product is just another piece of software. Right?

And understanding what ATO or authorization controls, AI systems can or cannot touch or impact on what that means from a fielding perspective, this has evolved very very quickly, folks have gotten on board with this very quickly. Really across the department in OAT way that's been really impressive. And has been done, in a safe and secure way while we are still operationalizing AI effectively in a way that does not put people unnecessarily at risk.

The acquisition piece that the Chief talks about in the other side of it is just the technology and its ability to really quickly evolve to support the mission need, I think that is something that has been improving a lot, particularly in the past eight months but really in the past couple of years.

Advice for Acquisition Executives and Commanders

Mark Krzysko: Nick, let me stay with you because we are yes, almost out of time but I want to know what is your one piece of advice for the acquisition executive and one for the operational commander?

Nick Weir: Yeah, I think, so, for the acquisition executive, I think it is to look for solutions from the outcomes perspective and it comes back to outcomes piece. Particularly in the AI space and with any kind of new technology, we saw this with more classical machine learning in the past and computing prior to that. It is easy to gravitate towards: I need the biggest, best computer models, GPUs, or whatever it might be. And that will enable my mission in whatever kind of general way.

And I think really, framing more around the specific mission set or mission problem that you are trying to solve, is something that really enables you to tie the whole thing together.

And for that matter, the commander who is operationalizing the system, building that appreciation for what is, what you really need to do and the different environments and what you need to do at the edge. And starting to think about, what are the human processes that are occurring between the edge any enterprise that we can start leveraging against.

Mark Krzysko: Chief, what do you need from the acquisition executive and what do you need in the operational commander so you can do a better job for both?

CW4 Reginald Oliver: Honestly, I would say this answer is for both. Continue to enable the pathway for innovation and leveraging expertise and continue to trust your people to do the right things at the right time, to successfully support your mission.

Mark Krzysko: That is a great answer. Chief, Doctor, wonderful conversation, you have made my job remarkably easy. It is what it is, but great comments, and I wish you both the best of luck in chasing this through.