Aoi Minamoto: From Industrial AI to Longitudinal Intelligence

It started with technology in general, and with seeing firsthand what it can do for people. I was born with a significant visual impairment in my left eye. My vision in that eye is about 0.04, or roughly 20/500. When I was a student at Indiana University, the Student Center gave me access to assistive technology that could read my textbooks aloud. I was no longer limited by how much text I could comfortably read. I could listen, learn, and study on my own.

That shaped how I think about technology. For me, the point of AI isn't just to make machines more intelligent. It's to expand what people can understand, create, and accomplish. That idea has stayed with me from my academic work through industrial AI and, now, KinaBot.

My path into AI wasn't a straight line. As an undergraduate, I studied Japanese language education and did my teaching practicum as a high school Japanese teacher. To help pay for school, I also worked as a medical interpreter, which showed me how directly language decides whether people can access and understand critical information.

After finishing a master's in economics at Keio University in 2009, I worked in marketing in Tokyo and became more and more interested in data analysis. I started analyzing consumer purchasing data: finding behavioral patterns, segmenting customers, and working out why different groups behaved differently. That was a turning point. I realized computation could surface patterns in human behavior that you'd never see by looking at people one at a time.

That curiosity pulled me deeper into data science and eventually to the United States, where I earned a second master's, in data science, at Indiana University. That's where the threads came together. My background in language, human behavior, economics, and accessibility started to connect with machine learning, human-computer interaction, and AI.

That history shapes both what I build and the limits I put on it. I don't see AI as a replacement for human judgment. I see computation as a way to extend what people can do: to reveal patterns, lower barriers, and give people information they couldn't easily get on their own. The person should still be the one who understands the context and makes the call.

Start from the frontline, not from the model. My time as a manufacturing engineer convinced me that's one of the most effective ways to build AI that holds up in the real world. I watch how engineers actually work, figure out where they lose time or information, and find a real unmet need. Then I build an MVP quickly, put it into the actual working environment, let engineers use it, listen to their feedback, and fix things right away.

That's how I built the Manufacturing AI Platform at Toyota Battery Manufacturing North Carolina. I didn't join in an AI role; I was hired as a controls engineer. Working directly with production engineers and manufacturing systems, I kept running into the same information barriers between Japanese technical knowledge and the U.S. engineering teams. So instead of starting with an AI solution and looking for somewhere to use it, I started with that problem and built tools around what engineers actually needed.

The production floor became part of the development process. The platform went through more than 500 rounds of testing and iteration on real engineering scenarios and user feedback. I'd build, test, watch how engineers used it, find where it failed or slowed them down, improve it, and test again. That loop taught me far more than evaluating a model in isolation ever could.

The platform has now been used more than 1,500 times. In its first three months, it generated nearly $1 million in quantifiable economic value, based on our internal estimates. That figure doesn't yet include engineering hours saved, information-related defects avoided, faster access to technical knowledge, or smoother workflows. As adoption grows and the system improves, I expect that value to keep rising.

The experience sharpened how I define a good AI system: it's the one that solves a real problem for the people who use it. The process is simple. Observe the frontline, build fast, test in reality, listen to users, measure the outcome, and iterate. Technology becomes valuable when it works inside real human work, not just in a lab.

In a genuinely new environment, there may be nothing to build from: no mature dataset, no terminology base, no historical solution.

Toyota has many plants across North America, but the North Carolina battery plant was a new manufacturing environment, built around batteries for electrified vehicles. We couldn't simply inherit decades of accumulated North American terminology and operational knowledge for every new process. I realized early that if an AI system was going to support frontline engineers, the quality of its knowledge foundation would matter as much as the model.

That's why I put so much weight on building and validating a manufacturing glossary. Terms had to be collected from different shops and real engineering materials, then reviewed and confirmed by engineers who actually understood the processes. I led the glossary's design and collection and initiated the design of the verification process. A technically sophisticated model is useless if it misunderstands the language of the factory.

At the same time, we couldn't wait for every term, workflow, and design decision to be perfect before testing. I experimented quickly with how the glossary should interact with the AI system, tested outputs against real manufacturing information, identified which steps improved information quality the most, and then scaled up terminology collection, validation, and user testing in parallel.

Adoption was just as hard. New technology needs its first real users. I deliberately sought out engineers who needed the tool right away, were willing to try it, and could give meaningful feedback based on real technical documents and workflows. Their use became part of development: build, test, observe, listen, improve, test again.

During the most intense stretch, in May and June, I was often working more than 12 hours a day, because development, terminology validation, frontline testing, and improvements were all happening at once. But experimentation in manufacturing needs boundaries. I had to show clearly where the AI made a significant difference, while making sure it didn't introduce unacceptable risk into production work. Management support came much more easily once the system showed concrete improvement at a critical information step: better access to technical knowledge, real time savings, and measurable economic value.

It changed how I see the role of an AI engineer. I think AI engineers increasingly need some of the instincts of entrepreneurs. AI is moving so fast that many organizations are running into problems for the first time, with no playbook and sometimes no dataset or standard to follow. In those situations, you have to be willing to experiment responsibly, find the highest-value problem quickly, build something useful, test it with the people who need it most, and learn fast enough to know what to do next.

So moving AI into production isn't just a model-deployment problem. You're building knowledge, trust, standards, users, and technology all at once.

In manufacturing, language isn't just a communication tool. It's part of the engineering infrastructure.

High-quality manufacturing depends on precision, and standardized production depends on standardized ways of describing engineering knowledge. Engineers need a shared technical language to train people, explain operations, understand how equipment behaves, troubleshoot machines, interpret alarms and PLC logic, and discuss problems consistently. Without it, even excellent technology gets bogged down in repeated explanations, ambiguity, misunderstanding, and rework. Eventually, the language gap becomes a productivity problem, and even a safety problem.

I saw this clearly in Japanese–English manufacturing environments. In Japan, decades of manufacturing experience are embedded not only in equipment and processes but in the language used to describe them. Vendor documentation, operating instructions, engineering standards, process explanations, and millions of lines of PLC logic and comments have all developed within a mature Japanese technical vocabulary. That language itself carries accumulated engineering knowledge. When that knowledge moves into a newer, English-speaking production environment, an equally mature English vocabulary may not exist yet. That's a deeper problem than translation. Sometimes the English terms exist, but teams use them inconsistently. Sometimes a Japanese abbreviation or concept carries engineering context that disappears in a direct translation. And sometimes there's simply no established local term that carries the same technical meaning.

If you translate the words without transferring the engineering meaning behind them, you haven't really transferred the knowledge. That realization changed how I designed manufacturing AI. I started treating terminology standardization as part of the AI architecture itself. The goal wasn't just Japanese-to-English translation. We had to collect terminology from different shops, understand how engineers and machine vendors actually used it, validate key terms with domain experts, and gradually build an English technical vocabulary that reflected the same engineering reality.

AI only becomes powerful in manufacturing when it's built on accurate, standardized information. Before you ask AI to help engineers, you have to define the language of the production system: what each process means, how common production standards are described, and how terms are used consistently across more than 700 machines and many engineering contexts.

Once that foundation exists, AI can begin to understand how different parts of production relate to one another and carry technical meaning accurately across languages and document types. An engineer might run into the same underlying concept in a PLC comment, a machine manual, an operating instruction, a troubleshooting document, or training material, each expressing it differently. AI can help them recognize that it's the same idea and get to the right information faster.

That's the real value of multilingual manufacturing AI. It helps engineers learn and train, understand equipment, repair machines, troubleshoot production stoppages, and find the technical knowledge they need to work more productively. But AI can't create engineering excellence out of inaccurate or poorly defined information. The foundation comes first: accurate terminology, shared definitions, and standardized engineering knowledge. Then AI can amplify it.

I think AI can make technical knowledge dramatically more usable, but there's an important limit: AI shouldn't be allowed to define engineering truth on its own. Humans have to stay in the loop, especially when knowledge is being standardized.

That view took shape through my manufacturing work and through my role as an invited speaker and panelist at NIST's Artificial Intelligence for Manufacturing Workshop, where I took part in discussions on human-AI teaming. In an industrial setting, AI can retrieve, translate, organize, compare, and explain information at a scale people could never manage by hand. But before AI can amplify that knowledge, people have to establish, and control, the critical definitions the system depends on.

Take terminology. When we standardize manufacturing terms, I believe the important ones should ultimately be reviewed and validated by engineers with domain expertise. Once a term has been validated and accepted as part of the plant's information standard, AI can build on that trusted foundation: interpreting different documents, translating technical information, explaining PLC comments, connecting related concepts, and opening up engineering knowledge to many more people. That human validation is what gives the system credibility. If AI generates its own definitions and those start circulating as organizational standards without expert review, the quality of the knowledge becomes hard to control. In manufacturing, that's not just an accuracy problem. Bad information can spread through training, troubleshooting, maintenance, and production decisions, with downstream effects that may be difficult even to measure.

So I see human-AI teaming as a division of responsibility. Humans define, validate, and govern critical knowledge. AI helps organize, translate, retrieve, explain, and scale it. The goal isn't to take people out of the knowledge loop. It's to use AI to multiply the value of knowledge people have established and trust.

It starts with a simple idea: before we ask AI to predict something about us, computation should help us observe ourselves.

We speak every day, but most of the information in our speech disappears the moment a conversation ends. KinaBot uses computation to measure explainable speech and language features, such as pace, pauses, vocabulary, and linguistic complexity, and lets users record those feature scores over time.

There are established clinical methods for evaluating cognitive decline. But there's a gap before clinical evaluation. How does an ordinary person, or a family member, know when a change in everyday life is worth paying attention to or raising with a professional? Natural speech contains many measurable features, but the human brain isn't built to continuously calculate multiple NLP features and compare them across months or years of conversation. Computation can fill that observational gap.

The next piece is the personal baseline, which comes straight out of my human-centered design philosophy. Speech and language patterns related to cognition are highly individual. The data becomes more useful when it shows people how their current patterns compare with their own history.

That's what longitudinal intelligence means to me. Instead of producing one score or making a prediction from a single moment, the system helps the user see a trajectory. What's my normal range? Is something changing? In which direction? For how long? Are several features changing together?

KinaBot starts with observation, not diagnosis. I want it to give people something they didn't have before: a computational mirror that makes their own language patterns, and how those patterns shift, visible over time.

My boundary is clear. AI can observe, compute, remember, and make change visible. Humans interpret what that means and decide what to do. That's the value of longitudinal intelligence: using computation to help people see changes they couldn't easily measure themselves, while keeping them in charge.

A single measurement tells you where you are at one moment. Repeated measurements can tell you whether you're actually changing.

That distinction is central to how I designed KinaBot. Speech varies naturally from day to day. Someone might speak more slowly because they're tired, pause more because they're distracted, or use simpler language because of the topic. One unusual measurement on its own may mean very little. I don't want KinaBot turning normal human variation into an alarm.

What matters is the trajectory. Once we've established a personal baseline and keep collecting observations, we can ask different questions. Is a feature moving consistently in one direction? How long has that lasted? Are several independent features, like speaking rate, pauses, vocabulary, or linguistic complexity, shifting together? And eventually, has the person settled into a new baseline?

Time changes what computation can tell us. Instead of asking, "Is this score abnormal today?" we can ask, "Is something about me changing, and is that change sustained?"

That's especially important for everyday cognitive awareness. People and their families experience life continuously, but human memory is bad at quantitatively comparing subtle language patterns across hundreds of conversations over months or years. Computation can preserve those observations and make the trajectory visible.

I think of it almost as a personal time series of language. KinaBot doesn't need to label one temporary deviation as a problem. It can first watch whether the pattern returns to baseline, keeps moving, shows up across several features, or gradually becomes a new baseline. That's what time makes possible: telling a moment apart from a pattern.

To me, that's far more human-centered than making a strong prediction from one short sample. The point isn't to tell someone what will happen to them. It's to give them a clearer view of how they're changing, so they can decide what that information means for their own life.

A personal baseline is fundamentally a human-centered design choice. Cognitive and language patterns are highly individual, shaped by education, language, culture, age, and a lifetime of experience. So I'm interested not only in where someone stands relative to a population, but in how they change relative to their own history.

Longitudinal research gives a strong reason to look at change this way. One study followed cognitively normal older adults for an average of 7.5 years and later examined Alzheimer's pathology at autopsy. Cross-sectional cognitive scores didn't clearly separate the groups, but their rates of cognitive decline over time did.¹ To me, that illustrates something important: sometimes the trajectory holds information a snapshot doesn't.

Conventional repeated testing has another problem: practice effects. When people take the same or similar tests again and again, they get better at the test itself, which can mask real underlying change. Research has shown that accounting for practice effects can change how cognitive decline is detected and classified.² That's one reason I'm interested in a different measurement space: everyday natural speech. We produce language constantly. My research question is whether we can identify explainable speech and language features that are meaningfully related to cognitive function, and use computational methods to quantify and visualize those features for the individual.

So KinaBot follows a simple principle: compare you with you. Rather than repeatedly asking someone to perform the same cognitive task, I want to explore whether naturally produced speech can provide a complementary longitudinal record. Each observation adds to a personal history, so users can see how their individual feature scores move over time.

I'm careful about the boundary here. KinaBot does not claim that a change in a language feature indicates Alzheimer's disease or any other medical condition. The question comes earlier: can computation make meaningful patterns in everyday language visible, so people can notice changes that would otherwise be hard to quantify?

Often the hardest question isn't where to find a good doctor. It's when to seek a professional evaluation at all. Changes in longitudinal feature scores can give people one more signal to inform that decision. If I saw several of my grandmother's language features show a sustained decline of around 20% from her personal baseline, for example, I would take that seriously and consider talking to a neurologist. The system wouldn't make that decision for me. It would make the change visible so I could make a better-informed decision myself.

This connects to how I see the future of personalized AI. As computational models become more accessible, I think individuals may increasingly have personal models that learn from their own history. Instead of requiring everyone to fit a generic reference, the technology can learn what's typical for that person and make deviations and trajectories visible.

The opportunity is to use computational science to turn natural language, something we already produce every day, into an explainable longitudinal record of ourselves. AI doesn't decide what a change means. It gives us the ability to see it.

I don't really see it as a move from industrial AI to healthcare. Looking back, it's one continuous idea: AI doesn't need to create a new reality. Its value can come from helping people understand information and patterns that already exist but are hard for humans to process at scale.

Manufacturing taught me that. At Toyota, the engineering knowledge already exists in production processes, technical documents, PLC logic, machine instructions, and engineers' experience. My AI system doesn't define that knowledge. We first establish trusted information, especially manufacturing terminology and glossary definitions validated by engineers. On top of that human-defined foundation, I use AI translation, prompting, and language processing to make technical documents more accurate, flexible, and accessible in both Japanese and English.

In other words, human-validated knowledge is the source of truth. AI helps us use it more effectively. KinaBot applies the same philosophy to the individual. The source of truth isn't something AI generates. It's the person's own natural speech. People can talk freely about their daily lives, as often as they like. Computation extracts measurable features from those conversations and gradually establishes that person's baseline. As observations accumulate, AI can become sensitive to changes in the trajectory and visualize them for the user. It doesn't invent the change, and it doesn't decide what the change means. The data comes from the person. Computation measures it. AI helps detect and present the pattern. The human interprets it and decides what to do.

That's the bridge between my manufacturing work and KinaBot. In manufacturing, I start with engineering knowledge that people define and validate, then use AI to make it easier to access and apply. With KinaBot, I start with natural human behavior and use computation to make personal patterns and long-term change easier to see.

The common principle is that AI shouldn't replace human reality with an artificial one. That's what I mean by human-centered applied AI.

The point of tracking speech over time isn't simply to collect more data. It's to help people see when a meaningful change may be starting. One of the hard problems with cognitive decline is that it can begin gradually, long before it's obvious enough for a person or their family to know that a professional evaluation might be appropriate. Longitudinal research has found that cognitive trajectories can show identifiable turning points before a clinical diagnosis, and large cohort studies have observed accelerated cognitive decline years before dementia is diagnosed.

That matters more now because some newer Alzheimer's treatments are meant for earlier stages of the disease. Donanemab, for example, is FDA-approved for people with mild cognitive impairment or mild dementia due to Alzheimer's, the population in which it was studied. So early awareness has growing practical importance, even though observation on its own is not diagnosis.

That's where I see the opportunity for KinaBot. People already produce enormous amounts of natural speech in everyday life. Instead of asking them to take a diagnostic test, I'm exploring whether computational methods can extract explainable features from that speech, establish a personal baseline, and show how those features change over time.

The goal is to make the turning point visible. If someone's features fluctuate and then return to their normal range, that may just be everyday variation. But if several features start drifting away from the baseline and stay there, the trajectory becomes something the user can see and think about.

KinaBot doesn't determine that a turning point means Alzheimer's or any other medical condition. That requires proper clinical evaluation. Its role comes earlier: using computation to help people notice changes in their own everyday speech that memory alone could never quantify over months or years.

That's the value of longitudinal intelligence. It's not about predicting a disease from one moment. It's about helping people see when their own trajectory starts to change.

• Clinical medicine: determines what the change means.
• KinaBot: helps make the change visible earlier.

Multilingual measurement matters to me because language shouldn't determine who gets represented in health data.

We already know clinical research doesn't represent every population equally. The FDA has acknowledged that people from underserved communities remain underrepresented in clinical trials, and researchers have identified barriers that include healthcare access, insurance status, transportation, geography, language, health literacy, trust, and even how participants are recruited. In Alzheimer's research specifically, ethnically and racially diverse populations remain underrepresented, and researchers have pointed to language, literacy, education, and the design of assessment tools as key issues.

If certain populations contribute less data to research, the knowledge and technology built on that data may serve them less well, too. Technology should help close that gap, not reproduce it.

That principle shapes how I design KinaBot. If computational methods can handle multiple languages, longitudinal measurement shouldn't belong only to people who speak one dominant language. Someone speaking Japanese, Chinese, English, or another language should have the same chance to turn their own speech into measurable features and see how those features change over time.

So my long-term goal isn't to build one English cognitive model and translate the interface into other languages. It's to explore whether we can develop a common measurement framework that respects linguistic differences while giving people comparable access to longitudinal self-observation.

Accessibility has an economic side, too. In the United States, many people face barriers to regular healthcare. KinaBot is currently free for individual users, and I want the core technology to stay broadly accessible. You shouldn't need to be wealthy, live near a major medical center, belong to a particular racial group, or speak a particular language just to start observing your own patterns.

The input is something almost everyone already produces: speech. If you can speak, you should be able to build your own longitudinal record, establish a personal baseline, and see how your language features change.

This doesn't replace doctors, clinical assessment, or medical research. It adds an earlier, more accessible layer of observation. And if people choose to contribute their data to research in the future, with proper consent and privacy protections, I see a path toward more linguistically and culturally representative datasets. That's the kind of equality I want technology to expand.

For me, human-centered AI means technology should expand human agency, not shrink it. That's personal. As I mentioned, I was born with a significant visual impairment, and assistive technology later removed barriers to reading and learning on my own. It taught me something I've carried through my whole career: technology doesn't have to take control away from people to be transformative. It can expand what we're able to perceive, understand, and accomplish.

I apply that directly to the systems I build. In manufacturing, AI doesn't define engineering truth. Engineers establish and validate the terminology, standards, and technical knowledge that production depends on. AI then helps translate, organize, retrieve, and apply that trusted information at a scale people couldn't manage by hand. The human-defined knowledge stays the foundation.

KinaBot works the same way. The person's natural speech is the source data. Computation extracts explainable speech and language features and builds a personal longitudinal record. AI can help detect and visualize changes in that trajectory, but it shouldn't decide what those changes mean medically or make important decisions on the user's behalf.

For systems that support people over long periods, I think transparency, accessibility, human validation, and human decision-making are essential. People should be able to understand what information the system is using, what it's measuring, where the uncertainty lies, and what it can't conclude.

Personalization also shouldn't mean giving AI more and more authority over a person as it learns about them. I see it almost the other way around: the more a system learns about someone, the more useful it should become to that person, while preserving their ability to understand, choose, and decide.

Accessibility is part of the same philosophy. Human-centered AI can't work only for people who speak a dominant language, can afford expensive services, or happen to resemble the population a model was built on. Technology should adapt to human diversity, not force people to adapt to it.

So my boundary is clear. Humans provide the reality, values, and meaning. Computation measures and structures information. AI helps us see patterns at a scale we can't easily process ourselves. And humans keep the authority to interpret and act.

My story: technology expanded my own capability. Toyota: humans define trusted knowledge; AI amplifies it. KinaBot: humans generate the data; computation reveals the patterns; humans decide.

It depends largely on the cost of being wrong.

That question became especially important to me through manufacturing and through the NIST workshop, where I took part in the discussions on human-AI teaming. In real industrial environments, the question isn't just what AI can do, but what it should do on its own and where human authority has to remain.

I'm comfortable letting AI automate tasks when the information is reliable, the task is well defined, the result can be verified, and mistakes can be undone. But the more safety-critical, personal, uncertain, or irreversible a decision becomes, the more human judgment should matter, not less.

In manufacturing, AI can translate, retrieve, organize, and explain technical information, but engineers should define and validate critical standards and make the safety-critical calls. With KinaBot, computation can measure speech features, compare them with a personal baseline, and surface sustained changes. It shouldn't decide that someone has a disease or needs treatment.

AI should widen the information available to us and make us better at deciding. It shouldn't quietly shift the right to decide from people to machines.

• University of Glasgow research - tests new measurement questions and explores how KinaBot can support academic research.
• Purdue University milestone project - gives students a real startup platform for hands-on learning and experimentation.
• NIST collaboration papers - turn practical experience into broader frameworks, standards, and directions for AI in manufacturing.
• Toyota Battery Manufacturing North Carolina (TBMNC) - proves technology in real production, with measurable operational and economic impact.
• ACM/IEEE peer review - keeps me close to emerging research and the questions researchers are actively trying to answer.

I'm fortunate that my work lets me see AI from several very different vantage points at once. What I've learned is that no single community has the whole answer. Each one sees something the others miss.

With researchers at the University of Glasgow, KinaBot has been used to generate speech and language measurements for research on people communicating with social robots. In that setting, KinaBot works almost like a language-measurement mirror: the interaction produces natural speech, and computation makes the features of that speech measurable for research. Working with researchers surfaces questions that might never come up in product development alone.

At Purdue University, KinaBot was selected as a student capstone project. Students in the online data science master's program work with an existing startup product rather than a simulated classroom problem. I want them to be able to explore the platform, experiment, test ideas, and work through milestones on personal baselines, longitudinal measurement, and cross-language evaluation. They bring new technical perspectives to KinaBot, and KinaBot gives them experience with a real product where the answers aren't already known.

NIST gives me another perspective. I currently have two papers in progress on human-AI teaming and sensemaking in manufacturing. That work asks a broader question: how do lessons from individual deployments become frameworks, standards, and directions that manufacturers of different sizes can use? I think of it as drawing a map that connects what we learn in individual factories to principles that can support manufacturing more broadly, in the U.S. and internationally.

At Toyota Battery Manufacturing North Carolina, the feedback loop is completely different and extremely practical. Engineers use the technology in real production work, and the results show up in engineering time, productivity, quality, and ultimately economic value. Then the system can be improved again the next day. It's a constant reminder that an elegant technical idea is worth little if it doesn't solve a real problem for the people doing the work.

I also learn from the other side of academic research. Reviewing more than 100 papers for ACM and IEEE venues, including SIGCHI and other HCI communities, shows me what researchers, particularly emerging ones, are trying to solve, which technologies are gaining importance, and which questions remain open. Reviewing other people's work has changed how I evaluate my own.

Together, these form a cycle rather than separate activities. Research helps me ask better questions. Industry tests whether an idea actually works. Standards work asks whether the lesson can scale. Students bring new ways of thinking. And peer review keeps me connected to where the research community is heading. That's why interdisciplinary collaboration is essential to how I work. Real-world AI isn't only a computer science problem. It involves people, language, engineering, organizations, standards, economics, accessibility, and, increasingly, questions of human agency.

My role is often to connect those perspectives: take an insight from one environment, test it in another, and turn what we learn into something that creates value beyond where it started.

I think one of the most important shifts in AI over the next five to ten years will be from general intelligence toward personalized, contextual intelligence.

Large language models have shown that AI can learn from an enormous amount of human knowledge. The question that interests me next is what happens when computational intelligence starts to understand the specific person or environment it's supporting. Not just what's happening today, but its patterns, baseline, history, and how it changes over time.

At the individual level, I think each person may eventually have a personal computational model that learns from their own longitudinal history. Instead of a generic system that treats everyone the same, personal AI could understand what's typical for you and help you recognize meaningful changes in your own life.

I see the same future in manufacturing. Every factory has its own production lines, equipment, terminology, operating cycles, engineering knowledge, and history. A truly useful manufacturing AI should understand that specific factory rather than apply a generic model to it. Over time, it could learn the plant's normal production patterns, preserve validated engineering knowledge, recognize deviations, and help engineers understand and improve the system continuously.

That's the common thread between KinaBot and my manufacturing work: AI becomes more valuable when it understands the longitudinal context of whatever it supports. For a person, that means personal patterns and change. For a factory, it means production patterns, engineering knowledge, and operational change. This direction is personal for me, too. Technology helped me get past barriers, starting with my eyesight, that could otherwise have limited how I learn and work. That's the future I most want to build: AI that helps people and organizations overcome physical, linguistic, cognitive, and informational limits so they can reach more of their potential.

The most valuable destination for AI isn't replacing human capability. It's expanding it, and making intelligence more relevant to the specific person, place, and context it's built to serve.