Why 99.5% Accuracy Isn't Good Enough (And What to Do About It)

Every executive in manufacturing has heard the pitch by now: AI changes everything, and you need to get on board or get left behind. What the pitch skips is that knowing AI exists and actually extracting value from it are completely different problems.

Over the past two years we've been embedded with a specialized aerospace manufacturer, working through this transition firsthand, and the gap we keep seeing is implementation. Organizations get stuck because there's a huge disconnect between what the models can do and what anyone in the building knows how to do with them.

The stakes are what make this hard. A tool that's right most of the time looks incredible in a demo, but in production manufacturing even a 0.5% error rate can be catastrophic, whoever or whatever made the error. You can't risk your delivery reputation on the assumption that edge cases won't hit you.

So most organizations freeze. They know they should be doing something with AI and they're afraid of falling behind, but nobody has shown them a path from "everyone has ChatGPT" to "AI is materially improving our operations." We've walked this path enough times now to have a framework, and it's simpler than you'd think.

Stage one: give everyone access

If your people don't have access to a capable AI model, start here. Not next quarter, this week.

This doesn't require enterprise infrastructure or a multi-year rollout. It means making sure every person in your organization, from the estimating desk to the purchasing desk, can ask a model questions the same way they'd ask a colleague. Do it responsibly, with SSO and retention policies in place and real controls on what data gets shared, but don't let compliance paralysis stop you from taking the step. The same way everyone in your organization has an email address, everyone should have access to a model. You'll see immediate lift in everyday drafting and research work, and that lift is real. It's also just the entry point.

Stage two: teach the model your business

Most organizations either commit at this stage or stall here for good.

You've given people access, but the model knows nothing about your operation. It doesn't know what a work order means in your ERP, or that in your system an RFQ becomes a quote, becomes an order, becomes a work order that rolls up into multiple purchase orders. It can't reference your specs, your part numbers, your supplier lead times, or your change order history. Stopping at Stage One is asking an employee to contribute without giving them access to company systems.

Stage Two is exposing your data so the model can actually function as a member of your team. That means structured integration, connecting the model to your sources of truth rather than dumping everything in and hoping for the best. Think of it like onboarding a new hire. You explain what matters: "This is how we track programs. These are the objects that run our world. Here's where to find the current revision. Here's who owns what." The model needs the same context. Without it, you're just using ChatGPT with better branding. With it, you have an assistant that understands your business and can help with your actual processes.

Stage three: build tools

This is where the value shows up, and it's where xSkel lives.

Once your data is exposed, you start noticing the grunt work, the repetitive and error-prone tasks that eat hours and create risk:

• Comparing purchase order revisions to catch every change
• Extracting bills of materials from engineering drawings
• Tracking long-lead components across multiple programs
• Validating contract language differences between versions

Most organizations assume the answer is "get the AI to do it." It's not, and the reason has nothing to do with how capable the models are. This work sits on your critical path, and anything on the critical path has to be verifiable: you need to know where an answer came from, and you need a record showing the check happened. A bare model response gives you neither, no matter which model produced it. The answer is building software tools, augmented by AI, that run these processes with the verification built in and a human making the calls.

What changed recently is the economics. Five years ago, building custom software for a small piece of your workflow made no sense: you'd need a development team and ongoing maintenance, all for a single process improvement, and the enterprise vendors weren't interested in contracts under seven figures. You'd end up adapting your workflow to their platform rather than the other way around. Today a competent developer can prototype a functioning tool for a fairly complex workflow in about a week. That tool can use AI for the parts that need contextual reading and judgment, and plain deterministic software wherever the result has to be reproducible and auditable.

Our design partner, a specialized aerospace manufacturer building complex assemblies, was already operating at 99.5% accuracy, an excellent track record built on skilled people and rigorous processes. But in aerospace, the remaining 0.5% is where programs die. A component with a 19-52 week lead time that doesn't get ordered on schedule is a six-month program slip waiting to happen. And the cruel thing about rare, catastrophic failures is that manual review can't catch them consistently. They slip through precisely because they're edge cases; they don't happen often enough for anyone to stay vigilant.

So we helped them implement one simple, consistent process: every morning, automatically check every active work order and ask "Is this part on time?" We integrated their full ERP and built a tool that runs the check across all programs and alerts project managers before an issue becomes a problem.

Why does this need AI at all? Traditional ERP alerts work when you can define exact rules, something like "flag any PO where lead time exceeds X days." Real manufacturing edge cases don't fit neat rule definitions. You need a system that can read across a work order, understand which components are long-lead based on supplier history and current availability, compare that against the program timeline, and flag the intersection of factors that creates risk rather than any single threshold breach. That kind of contextual cross-referencing is where AI earns its place. The human still owns the decision; the tool makes "should we be worried about this part?" an answerable question across the whole book of work, every morning, and turns "someone should probably check this" into "this gets checked, without fail."

That's Stage Three: using AI to make custom automation economically viable for a mid-sized manufacturer, building the supports that catch edge cases before they cascade.

Stage four: rethink what's possible

The first three stages mostly automate work you already do. Stage Four is first-principles thinking: redesigning workflows around what's actually possible now, instead of paving the existing paths.

With the first three stages in place, you can start asking different questions. What handoffs could you eliminate entirely? What quality checks could move to the beginning of a process instead of the end? My guess is this is where the durable advantage gets built, because the gap between what the models can support and what organizations have actually explored is wide, and it's widest right here. But this stage needs the discipline of the first three underneath it. Redesigning a workflow around a check nobody can verify is how you get burned.

Where xSkel fits

We're an exoskeleton company. We come in and learn your highest-risk failure modes, then build the small, focused tools that stop costly mistakes from propagating through your operation.

We do it this way because we've watched manufacturers attempt the transition without a partner who understands both the technology and the operational reality. The common version is getting stuck at Stage One, where everyone has ChatGPT and nothing changes. The other version is skipping ahead, building tools without the data groundwork, and getting burned by outputs nobody can verify.

We work with whichever foundation models and infrastructure fit your security requirements, whether that's on-premises, private cloud, or API-based. The specific technology matters less than the integration, connecting to your actual systems of record and building tools that operate reliably within your constraints, which is why we're model-agnostic: the bottleneck is the implementation. The tools we build do the first pass on critical work, enforce the checks humans can't sustain manually, cite their sources, and flag for human review when they're uncertain. We deploy inside your network to meet your security requirements, and we train your people in their actual workflows so the tools get used.

The gap between knowing AI exists and extracting value from it isn't closing on its own, but the path is clearer than it looks: access, then data, then tools, then redesign.