Data Ops is the neglected middle child of AI Industry
Everyone wants to show you the app. A chat window with flashy UI design, a clever agent, a demo that answers (some) questions about a company’s documents in four seconds. Nobody wants to show you what sits underneath it. Cloud companies provide you the solution to a quick setup of the most fundamental layer which is your infrastructure.
Thus, the Neglected Middle Child is the Data. Messy, inconsistent, scattered across systems that were never meant to talk to each other. In my experience, this is the part of the AI world that gets the least attention and decides the most outcomes.
I want to lay out a problem statement we are working in CD Foundation Data Ops initiative. It comes from a conversation I had this week with senior members at CDF, and from the reason I brought my PhD at the Universidad de Granada and the INTELLIWIND EU project around this topic in the first place (see veritas-aidb).
The flashy layer and the hard layer
The visible half of modern AI is a third-party LLM behind an API. These are general models. They know a little about everything and nothing about your plant, your contracts, your sensors, or the way your organisation names its assets. It may not even know your internal discussion, jargons, concepts, check lists, SOPs etc. The hard portion of this is data. Most of the data we have out there is unstructured. One system stores a turbine as WTG_07, another as Turbine 7, a maintenance PDF calls it “unit seven”, and a spreadsheet kept by a technician calls it nothing at all. A human reads these four references and knows they are one machine. A pipeline has to be told. The industry has tried to solve this with code which does help to a limit. Even so, a lot of plumbing remains around it. Sorry, I mean Engineering and it needs to be treated with the respect the word carries.
Why not just ask the LLM
The obvious shortcut is to hand the raw mess to a large model and ask it to tidy up. I think this is the wrong tool for the job, for two reasons.
The first is hallucination. Huang et al. 2024 [4] survey the problem at length and give it a formal taxonomy: models produce fluent content that is unfaithful to the source or to the facts. In a chat about holiday plans that is an annoyance. In a pipeline that decides which sensor reading belongs to which asset, it is a silent corruption of the record, and silent corruption is the worst kind.
The second is custody. Most hosted LLM providers retain prompts for some period. Industrial data, financial data, and anything under a confidentiality clause then travels the open internet to sit on someone else’s servers. My view is simple: we do not want our data on other people’s servers if we can avoid it.
I am doing my best here not to dive too deep just on this section but there are a lot more problems we have here other than non deterministic nature of LLMs and ownership problem. For now let us keep it to that.
Local models answer the custody problem. They raise a new question, which is whether a small local model is good enough.
The underdog gets a harness
For a while, small language models were the underdog. Smaller, cheaper, weaker on open-ended reasoning.
Then agent harnesses arrived. By harness I mean the scaffolding around the model: tools it can call, scripts that do the deterministic work, validation of every output, retries, a narrow task description. My own observation is that this scaffolding lifted small-model performance considerably, because the model no longer has to do everything. It has to do one thing, inside a fence.
NVIDIA’s research group makes a related argument. Belcak et al. 2025 [1] observe that agentic systems often involve language models performing “a small number of specialized tasks repetitively and with little variation,” and conclude that small models are powerful enough, better suited, and more economical for many of those tasks. To be precise, the paper does not credit harnesses specifically; that connection is mine. What it does give us is an authoritative case that the repetitive middle of an agent workflow does not need a frontier model.
Data operations are exactly that kind of work. Most steps are repetitive and well specified. Parse this file, map this column, normalise this unit, flag this outlier. Coded scripts handle the bulk of it, with a language model in the loop for the pieces that need judgment, such as interpreting an ambiguous label, and a routing layer deciding which step goes where. The principle is the same one I apply to software generally: keep the model for the slice that truly needs meaning.
A model that only decides
Some steps need a decision or a route, not a paragraph. Is this record a sensor fault or a maintenance note? Which database should it go to? Which ontology class does this label map to? An LLM can answer those, but it answers in prose, and then code has to parse the prose.
This is where Jev comes in. TypeSafe AI, whose co-founder and CEO is Diogo Almeida, released Jev in early access in September 2026. They call it a System One model, built “to make fast, structured decisions that software can use directly” (Almeida, typesafe.ai, 2026 [10]). You give it a state, as text or JSON, plus typed questions about that state. It returns a choice, a score or a probability, each with a confidence value, and your code branches on it (TypeSafe documentation, 2026 [11]). It cannot write prose or code, and that is the point.
For data ops this fits the router’s job well. A typed answer with a confidence can be tested, logged and audited. A paragraph cannot.
Precisely speaking, the speed and cost claims are the company’s own. TypeSafe reports end-to-end responses of 70 to 500 milliseconds and efficiency gains of two orders of magnitude over frontier LLMs on this kind of task [10]. Their own write-up concedes that the workflow evaluations were built by their team and scored against reference answers averaged from other LLMs. I treat the numbers as promising and unproven until someone independent tests them, calibration included.
So the stack I have in mind has three layers. Scripts for the deterministic work. A small model for the language work. A decision model for the routing. Each does the one job it is good at.
Structuring the data to giving it meaning
Bringing structure to unstructured data is half the job. A table with clean columns is still just a table. It does not know that a gearbox is part of a turbine, that a turbine sits in a wind farm, or that a vibration alarm on the first implies a maintenance question about the second.
That knowledge is meaning, and the machinery for it is old and well understood: ontologies and knowledge graphs. An ontology declares the kinds of things in a domain and how they relate. A knowledge graph holds the actual instances, connected according to that ontology.
Think of it as the difference between a pile of dockyard manifests and a chart of the harbour. Same information, but only one of them lets you plan a movement.
Once your data lives in different databases (relational, time-series, document, graph), the graph becomes the layer that ties them together. You get one query surface, SPARQL or Cypher, rather than five query languages and a spreadsheet of tribal knowledge.
Now I think more on this, we can say “One Language to Query them All”. You use natural language which is then converted to SPARQL/Cypher query and the rest works automatically there on.
The graph makes the model honest
Now put a language model on top of that graph.
Pan et al. 2024 [8] describe why the pairing works: LLMs are black boxes that often fall short at capturing and accessing factual knowledge, while knowledge graphs hold facts in structured form and can supply the model with external knowledge that aids inference and interpretability. The two have complementary weaknesses.
The practical effect is that when the model talks, it talks with more meaning behind the words. It can retrieve from the graph rather than guess. Better still, it can link its answer back to the source node, and from there to the document or sensor stream the fact came from. An answer with a traceable origin is a different kind of object from an answer that merely sounds right.
Graph-based retrieval is an active research area. Edge et al. 2024 [3] report that an LLM-derived entity graph, with pregenerated community summaries, gave substantially better comprehensiveness and diversity than a naive vector baseline on corpus-wide questions, although plain vector retrieval stayed more direct on narrow ones. I take two things from that. Graphs help when the question spans the whole corpus, and no single technique wins everywhere, which is why I keep the architecture polyglot.
What humans already do
If you think deeper into this from a psychological aspect, People do data operations in their heads every day. We read. We notice that two names refer to one thing. We connect a number in a report to a decision made last quarter. Those connections live in a person’s memory, and when the person leaves, they leave with them. You dont have the whole book in mind but you take out certain key words and definitions and you are able to connect them with one another.
Get Sage Khan’s stories in your inbox
Join Medium for free to get updates from this writer.
On the computer side of things, the same connections can be OWL and TTL files linked to a knowledge graph. The mental model becomes a written, versioned, inspectable artefact that a team can review, argue with, and improve. In that sense, an ontology is institutional memory with a diff. The whole pile of documents are not to be stored and queried from then. You query the key concepts and if you want to go deep, then you can go deeper to the source materials.
This is also the thinking behind VERITAS, the open-source tool I am building to automate industrial data pipelines from data to knowledge and meaning (Khan, github.com/veritas-aidb [5]). The public repositories currently cover the architecture specifications, a wind-energy domain ontology, and database adapters.
The Basic Definition?
Here is the part I care about most, and the reason this is a problem statement and not a product pitch.
People say DevOps, DevSecOps, LLMOps, AIOps and a dozen other “Ops” terms as though each one had a settled meaning. Platform engineering has quietly taken a lot of what people used to call DevOps. I mean, these days you just pick a term and add Ops to it, you are perceived as the ultimate thought leader. I think then we will have Semantic Ops, Ontology Ops, Knowledge Graph Ops, Cabling Ops, Typing Ops and God knows what other kind of Ops to everything. I come from a Naval Background from Ops Branch and my fellow Seafarers will agree that Operations branch is considered as the King of all branches because the Chief of Naval Staff is from Ops branch. You don’t throw away the term “Operations” just like that.
Meanwhile DataOps, the oldest of the data-flavoured terms, has no formal definition that everyone accepts. Liebmann is generally credited with the first use of the term, in a June 2014 post on the IBM Big Data & Analytics Hub [6]. Palmer is credited with popularising it in a May 2015 post titled “From DevOps to DataOps” [7]. The 2017 DataOps Manifesto from DataKitchen set out five values and 18 principles and gathered more than 30,000 signatures [2]. Gartner placed DataOps on its Hype Cycle for Data Management in September 2018, which a SAS conference paper records alongside the observation that adoption of the term accelerated afterwards [9]. Even so, those same accounts describe a term with a contested origin and no shared standard. Ten-plus years in, then, we have a manifesto, a hype-cycle entry and a vendor ecosystem, but we do not have a formalised definition that a university can put in a syllabus or a regulator can put in a clause. My submission of the DataOps Landscape coming very soon on the CD Foundation repo and eventually the website but there is more that needs to be done. The formalization of Data Ops needs to be the starting point.
At CD Foundation, this is how I see the work being done.
- The panel of CDF talk through topics and problems in bi-weekly meetings. Those meetings can be linked to a note-taking tool such as Read AI, so that what was said, by whom, when and where is on record and that should be kept properly.
- Those notes are mined for problem areas.
- We discuss solutions to each problem area.
- We write blogs on the discussion, the problem area and solutions.
- Once narrative has formed through enough discussion and blogs, we write white papers and academic papers, for example a unified DataOps framework.
- Where possible, we build open-source tooling around the solution of the problem or set of problems.
- With enough blogs, tools and papers behind us, we go for a book. This book can be source of syllabus building for Corporate training, University Courses and Certifications.
Each stage feeds the next, and each leaves a public trail that others can check. I like that discipline. It is close to how a working group in a military turns an after-action review into doctrine.
The Trident nature of the Approach
A term only becomes real when different people adopt it for different reasons. We have to go three-pronged.
The general audience, which includes business people, learns that something called DataOps exists and that organisations need people to build and maintain it. That creates demand.
The technical audience reads papers and technical reports. Existing tech teams need to learn DataOps as a new skill, in the same way operations teams once had to learn infrastructure as code.
The academic audience reads research papers and books. Academia produces the next line of professionals, so the term has to reach the classroom. Our papers and books then become the basis for certification development around it.
Skip any one of the three and the term stalls. Business without academia gives you a buzzword. Academia without business gives you a syllabus with no jobs attached.
Henceforth…
Everyone is racing to put a model in front of the customer. The teams that will still be standing when the novelty fades are the ones that did the unglamorous work underneath: structure first, meaning second, a model on top that can show its sources. Marcus Aurelius wrote that what stands in the way becomes the way. For AI, the data is what stands in the way. Hence the work of this initiative, which begins with giving that work a name people can agree on.
A definition does not guarantee adoption. Several well-written manifestos exist and the term is still used loosely. On the other hand, the small-model claim has limits. Belcak et al. [1] frame their position as a value statement and invite critique, and tasks needing broad open-ended reasoning may still call for a larger model, local or otherwise. A heterogeneous system, with different models for different steps, looks like the realistic answer. An ontology is only as good as the people who curate it. A badly modelled graph gives the language model confident, traceable, wrong context. Traceability helps you find the error; it does not prevent it. Finally, I am a PhD researcher and founder inside this initiative, not a neutral observer. Weigh my enthusiasm accordingly.
If you work in data, in academia, or in a business that is about to discover it needs this capability, I would like to hear how you define DataOps. The best definition will probably come from several of us arguing about it in public.
References
- Belcak, P., Heinrich, G., Diao, S., Fu, Y., Dong, X., Muralidharan, S., Lin, Y.C., Molchanov, P., 2 June 2025, “Small Language Models are the Future of Agentic AI,” arXiv:2506.02153, https://arxiv.org/abs/2506.02153. Accessed 22 October 2026.
- DataKitchen, 2017, “The DataOps Manifesto,” https://datakitchen.io/manifestos/. Accessed 22 October 2026.
- Edge, D., Trinh, H., Cheng, N., Bradley, J., Chao, A., Mody, A., Truitt, S., Larson, J., 24 April 2024 (revised 19 February 2025), “From Local to Global: A Graph RAG Approach to Query-Focused Summarization,” arXiv:2404.16130, https://arxiv.org/abs/2404.16130. Accessed 22 October 2026.
- Huang, L. et al., 2024, “A Survey on Hallucination in Large Language Models: Principles, Taxonomy, Challenges, and Open Questions,” ACM Transactions on Information Systems, https://doi.org/10.1145/3703155. Accessed 22 October 2026.
- Khan, D.S., “Veritas AI DB,” GitHub, https://github.com/veritas-aidb. Accessed 22 October 2026.
- Liebmann, L., 19 June 2014, “3 reasons why DataOps is essential for big data success,” IBM Big Data & Analytics Hub (publication date as recorded in “DataOps,” Wikipedia, https://en.wikipedia.org/wiki/DataOps). Accessed 22 October 2026.
- Palmer, A., 7 May 2015, “From DevOps to DataOps,” Tamr (publication date as recorded in “DataOps,” Wikipedia, https://en.wikipedia.org/wiki/DataOps). Accessed 22 October 2026.
- Pan, S., Luo, L., Wang, Y., Chen, C., Wang, J., Wu, X., 2024, “Unifying Large Language Models and Knowledge Graphs: A Roadmap,” IEEE Transactions on Knowledge and Data Engineering, 36(7), 3580–3599, https://arxiv.org/abs/2306.08302. Accessed 22 October 2026.
- SAS Institute, 2020, conference paper 4649–2020, SAS Global Forum proceedings, https://support.sas.com/resources/papers/proceedings20/4649-2020.pdf. Accessed 22 October 2026.
- Almeida, D., 2026, “Introducing System One Models & Jev,” TypeSafe AI Blog, https://typesafe.ai/blog/introducing-system-one-models-and-jev. Accessed 22 October 2026.
- TypeSafe AI, 2026, “Introduction,” TypeSafe documentation, https://docs.typesafe.ai/introduction. Accessed 22 October 2026.
Dan “Sage” Khan is an AI and Cybersecurity (CyS) Engineer and a Marie Skłodowska-Curie PhD Scholar at the Universidad de Granada, working on the IntelliWind EU project. He served in the navy for thirteen years, in the cyber and maritime domain, and is a Project Lead for the DataOps Landscape Initiative at the Continuous Delivery Foundation. LinkedIn | GitHub
