Operational Cookbooks from Tribal Knowledge

Client Profile: Major aerospace propulsion OEM (anonymized)

Engagement Length: Ongoing Program

Key Results

• 82% cookbook resolution rate in matched cookbook scenarios
• 3.5 hours of manual record digging reduced to under 6 minutes
• ~340,000 records spanning 28 years normalized into a single queryable schema
• 71% of incoming cases matched to an existing cookbook with high confidence

Executive Summary

A leading aerospace propulsion OEM held decades of operational knowledge across maintenance logs, inspection reports, sensor histories, and experienced technicians. The value was real, but trapped.

The same failure was often described in different ways across records, and hard-won fixes stayed in individual memory instead of becoming repeatable process.

The breakthrough was to use AI for organization first: structure messy history, convert it into operating cookbooks, and feed each new repair back into the same format so the playbook improves over time.

The result is a living system rather than a static knowledge base. A recommendation arrives with the historical evidence behind it, and every outcome makes the next recommendation a little sharper.

The breakthrough was to use AI for organization first: structure the history, convert it into cookbooks, and feed every repair back in so the playbook compounds.

Where Things Stood

Knowledge was spread across 11 distinct record types: maintenance logs, operator notes, inspection findings, sensor streams, repair histories, shift handoffs, failure investigations, photo archives, engineering change orders, supplier deviation reports, and quality escapes. Some of it was 28 years old, written in shorthand by people who had long since retired. The company had a deep reservoir of wisdom, but inconsistency in language and format made it nearly impossible to search, compare, or operationalize. Across the archive, roughly 1,900 distinct terminology variants described the same underlying set of conditions, the same component named differently across sites, shifts, and decades.

The most experienced technicians could connect those dots from memory. But that expertise was a single point of failure: when a veteran retired, a portion of the fleet knowledge retired with them, and there was no system that captured what they knew in a form anyone else could use.

There was also no feedback loop. A clever fix applied on one engine rarely made it back into anything reusable. The next technician facing the same symptom started from scratch, often re-deriving a solution that already existed somewhere in the archive.

The opportunity was twofold: give the history a shared structure so it could be compared; build a loop so that solving a problem once made it easier to solve forever after.

The most experienced technicians could connect those dots from memory. That expertise was a single point of failure.

1) Structuring the Historical Data

The first AI use case was conversion, not prediction. Unstructured records were normalized into reusable operational fields: a shared schema that every record type could be mapped into regardless of how it was originally written.

This was deliberately unglamorous work, and it was the foundation for everything else. By the time the normalization was complete, roughly 340,000 maintenance and inspection records spanning 28 years had been reconciled into a single queryable structure, and approximately 1,900 distinct terminology variants had been collapsed into a controlled vocabulary of about 210 canonical terms. That consistency is what made every subsequent use case possible.

• Roughly 340,000 records normalized across 28 years of fleet history
• 11 distinct record types mapped to a single shared schema
• Maintenance text categorized by engine type, part number, failure mode, condition, action, and outcome
• Sensor data aligned to operating conditions, temperature ranges, vibration patterns, and flight hours
• Photos mapped to visual defects, wear levels, crack patterns, and inspection findings
• Operator notes translated into standardized fields for searchability and comparison
• Roughly 1,900 inconsistent terminology variants collapsed to about 210 canonical terms

2) From Structured Data to Cookbooks

Structured history was translated into 124 operating cookbooks, each capturing a recurring failure mode and the response that history showed worked best for it. Together they cover the top recurring conditions across the fleet.

Instead of asking "Has anyone seen this before?", operators follow data-backed guidance showing what usually works for that pattern. The cookbook does not replace technician judgment; it gives that judgment a running start grounded in everything the fleet has already learned.

• Condition: Engine temperature trending above normal after defined cycles
• Historical pattern: 47 prior cases matched at program start, trending toward 300+ for mature failure modes
• Recommended checks: Target components, sensor history, maintenance interval verification
• Recommended action: Execute historically successful intervention sequence
• Expected outcome: Temperature normalization or escalation to deeper inspection

3) Capturing New Data in the Same Format

Every new inspection, repair, operator note, and outcome is captured in the same structured format as the historical baseline: 100% of completed repairs enter the schema without a separate documentation step. The work and the record are the same act.

Of incoming cases, 9% are flagged as novel and escalated rather than matched to an existing cookbook. That number matters as much as the 91%: it means the system is not silently forcing unfamiliar problems into familiar boxes. The compounding loop only improves guidance for what the system knows; the escalation flag keeps humans in front of what it does not.

4) Comparing New Cases Against the Baseline

As new events arrive, AI checks whether the situation matches known patterns and recommends the right cookbook or flags novel behavior. Of all incoming cases, 71% match an existing cookbook with high confidence; 9% are escalated as genuinely novel. The remainder are partial matches where the technician reviews the closest precedents and makes the call.

That 9% is as important as the 71%. Flagging the unfamiliar is how the system avoids quietly forcing a new problem into an old box, and it directs expert attention to exactly the events that deserve it.

• 71% of incoming cases matched to an existing cookbook with high confidence
• 9% of cases flagged as novel and escalated for expert review rather than forced into an existing cookbook
• Vibration signatures matched to prior known issues
• Visual findings compared with previously documented defect classes
• Maintenance outcomes checked against expected post-fix trajectories
• Sensor drift flagged outside lifecycle-appropriate ranges

5) Continuous Improvement

Each cookbook run captures whether the recommendation worked, whether extra steps were needed, and whether the issue recurred. Those three questions, asked every time, are what keep the guidance honest. The aggregate resolution rate has been improving approximately 3 to 5 percentage points per quarter as outcomes compound into the baseline.

That feedback continuously updates the cookbook into a living operational system. A recipe that starts to underperform gets revised; a workaround that consistently succeeds gets promoted into the standard recommendation. The playbook is never finished; it tracks the fleet as the fleet actually behaves.

• Outcome of each cookbook run captured: resolved, escalated, or recurred
• Underperforming recipes flagged for revision based on outcome rate
• Consistently successful workarounds promoted to standard recommendation
• Revision history tracked so changes are auditable, not silent
• Resolution rate and escalation rate visible per cookbook

Keeping Humans in Charge

The system was built to assist decisions, not to make them. Every recommendation arrives with its supporting evidence (the prior cases, their outcomes, and the confidence behind the match), so the technician is reviewing a reasoned suggestion rather than obeying a black box.

That transparency matters most in aerospace, where accountability is not optional, and the cookbook system was designed around that principle from the start.

It also changes how expertise spreads. A less experienced technician working with the cookbooks effectively has the fleet veterans looking over their shoulder, and the veterans codify their judgment into something that outlives any single career instead of leaving with them.

A recommendation that cannot show its work is a recommendation no one should act on.

Practical Impact

Before the system, surfacing a relevant historical precedent required manually searching across disconnected records: roughly 3.5 hours per investigation on average. With the cookbook system, the same lookup takes under 6 minutes, a reduction of about 92%. The answer arrives with the evidence attached, not as a guess but as a ranked set of prior cases with their outcomes.

A typical recommendation reads: "This issue looks similar to 47 prior cases. In 82% of those cases, this inspection sequence resolved the issue. Capture your outcome to improve the cookbook."

The time savings compound differently for newer technicians. Failure modes that previously took months to build intuition for are now covered by cookbooks: a new technician has the fleet veterans' accumulated judgment from the first day on covered cases, and ramp time on those failure modes has shortened from months to weeks.

Historical data becomes the cookbook. Structured new data improves the cookbook.

What It Unlocks Next

The value of the cookbook system compounds as the schema fills in. Each repair cycle adds more resolved cases to the baseline, which raises match rates and sharpens recommendations. A program that starts with 47 prior-case matches for a given failure mode is already trending toward 300 or more for mature failure modes, and the larger match pool produces a materially more confident recommendation.

The same pattern extends naturally to other record types. Sensor anomalies, quality escapes, supplier deviations, and engineering change orders are all candidates for the same treatment: normalize them into the shared schema, surface the historical pattern when something similar arrives, capture the outcome, and let the guidance improve. The schema becomes connective tissue across a record system that was previously a collection of silos.

The longer-term prize is institutional. A propulsion fleet where the knowledge lives in a system rather than in a handful of experts is less vulnerable to attrition, faster to onboard new technicians, and better positioned to transfer hard-won lessons across facilities. A veteran's judgment does not retire when the veteran does; it compounds into every cookbook that benefited from their experience.

Our Approach

Infineray structured historical maintenance data, converted recurring patterns into practical operating cookbooks, and captured every new event in the same schema so the playbook compounds over time.