Boston Aerospace AI - Predict with precision. Explain with clarity.

Boston Aerospace AI v1.0.0 – Official Launch
I'm a self-taught 19-year-old developer from Chimoio, Mozambique, and I built Boston Aerospace AI entirely on my own. This is its first stable release: an OpenAI-powered intelligence layer for aerospace predictive maintenance.

The Origin Story
I didn't come into this from inside the aerospace industry — I came into it from the opposite direction. My first "lab" was a dumping site behind repair workshops in Chimoio. My first sensor was salvaged from a broken DVD drive. I taught myself machine learning through PDFs downloaded whenever I had internet access, coding in Termux between power outages.
The idea behind Boston Aerospace AI came from a simple observation: predictive models can tell you a component's Remaining Useful Life with real accuracy, but they can't tell you why it's degrading or what to investigate next. SHAP helps — but raw feature-importance numbers still aren't an answer an engineer can act on.
So I set out to build a system that doesn't replace predictive models, but wraps them in something that can actually explain and investigate.

The Problem We're Solving
Black-Box Predictions — ML models output RUL estimates and anomaly scores, but not the "why."
Information Silos — sensor data, technical manuals, and external research live in disconnected places.
Time Pressure — in aerospace, every hour spent manually investigating an alert is an hour not spent preventing failure.

How Boston Aerospace AI Addresses This
Foundation: Trusted ML Models
The core is a 6-model ML ensemble (XGBoost, LightGBM, CatBoost, Random Forest, GBR, Extra Trees) trained on NASA's CMAPSS turbofan dataset to estimate Remaining Useful Life.
Transparency: SHAP Explainability
Every prediction comes with SHAP analysis showing exactly which sensor signals drove it.
Intelligence: OpenAI Orchestrator
This is the new piece in v1.0.0. The orchestrator takes the ML prediction and SHAP explanation and enriches them with:
Internal technical documentation (manuals, service bulletins) — when available.
External web research — when the question needs it (the model decides per-query, not on every message).
It synthesizes all of this into a structured answer to three questions: What is happening? Why is it happening? What should I investigate?

Source-Aware Analysis
Every part of the answer is tagged by origin — 🟢 ML Prediction, 🟡 SHAP Explanation, 🔵 Internal Document, 🔴 External Research — computed by the system itself, not self-reported by the model, so the attribution is reliable.

From Prototype to Platform
Phase 1 — Local prototype. I originally built the assistant on Ollama, running fully offline/locally — important given inconsistent connectivity where I live.
Phase 2 — OpenAI integration (this release). I rebuilt the orchestration layer on OpenAI's Responses API with native web search and structured output, which meaningfully expanded reasoning depth and made source-aware synthesis possible. The Ollama/local path stays in the codebase as a future option for operators who need fully offline, air-gapped deployments.

Important Disclaimer
Boston Aerospace AI is a research and decision-support prototype. It is not certified for autonomous maintenance decisions and must never replace qualified aerospace engineers, approved maintenance procedures, or regulatory requirements (FAA, EASA, etc.). It's a collaborative assistant that helps engineers investigate faster — the final decision always rests with a human engineer.

Technical Architecture
Código
📊 What's New in v1.0.0
✅ OpenAI-powered AI Orchestrator with native Web Search
✅ Predictive Remaining Useful Life (RUL) estimation
✅ SHAP-based explainability
✅ Optional internal technical-document analysis (RAG)
✅ Structured, source-attributed responses
✅ Computer vision modules (crack detection, thermal analysis, vibration anomaly)
✅ Automated PDF maintenance reports

We Need Your Feedback
This is a solo, self-funded project, still early. If you try it, break it, or have ideas for what would make it genuinely useful to real maintenance teams, I want to hear it — that feedback is how this gets better.

What's Next
Validation with real (non-synthetic) operational data
Integration with additional data sources (fleet history, weather, supply chain)
Custom fine-tuning for specific engine types
Working toward compliance/certification readiness
Built alone, from Mozambique, with more curiosity than resources. Thanks for checking it out. 🛩️