.svg){kind=icon}
Learn
Structured data is information already organized into rows and fields with a defined schema that a machine can read directly, while unstructured data is free text, documents, imagery, audio, and sensor logs that must first be read, extracted, and organized before an AI system can use it.
Last updated: October 18, 2026
Why it matters to your mission. Most of the data a mission runs on is not in a database; it is in reports, cables, scanned documents, imagery, and sensor logs that no model can read as-is. The structured versus unstructured distinction is what separates the small fraction of mission data an AI can consume today from the majority it cannot touch until that data is read and organized first. The outcome is a clear-eyed view of where an AI effort will actually stall, so the work goes into the unstructured content where the hardest questions live instead of the tidy fields that were never the problem.
Structured data is information already organized into rows and fields with a defined schema that a machine can read directly, while unstructured data is free text, documents, imagery, audio, and sensor logs that must first be read, extracted, and organized before an AI system can use it. A third category, semi-structured data, carries some tagging or markup but still needs interpretation. The share that matters for defense is lopsided: the overwhelming majority of mission data is unstructured, and that is the half an AI effort usually underestimates.
The distinction is not academic. It decides where the cost, the time, and the risk of an AI program concentrate. Structured data is close to ready the moment you can connect to it; unstructured data has to be read and interpreted before it means anything to a machine. A program that budgets for the first and ignores the second finds out the hard way that the demo ran on the easy fraction.
This page is the record-level companion to making mission data AI-ready, which covers the full pipeline. Here the focus is narrower and prior: what these two kinds of data are, why unstructured content is the expensive half, and what it takes to make it usable without stripping the provenance a decision depends on.
Key takeaways
Structured data lives in rows and fields with a fixed schema: an order-of-battle table, a personnel roster, a registry of hull numbers, a log of sensor readings with defined columns. A machine can read it the moment it connects, because the meaning is carried by the schema. Query it, join it, feed it to a model; the shape of the data tells the system what each value is.
Unstructured data carries no such schema. A HUMINT report, a diplomatic cable, a scanned PDF, a frame of full-motion video, an intercepted audio clip: the meaning is in the content, not in a column header. Before an AI can use any of it, something has to read it and pull out the entities, relationships, and facts inside, the way an analyst would, only at machine speed. Semi-structured formats like JSON, XML, or an email with headers sit between the two: there is some structure to exploit, but the body still needs interpretation.
The practical consequence is a steep asymmetry in effort. Making structured data usable is mostly normalization and linking: reconciling schemas so the same field means the same thing across systems. Making unstructured data usable adds an entire step before that: reading the content and extracting structure that was never there. That extra step is where most of a defense AI program's time and risk sit, because most mission data is unstructured.
Intelligence and operational data is produced as human communication and sensor output, not as database entries. Analysts write reports in prose. Collection platforms return imagery and signal. Partners send documents. Field units file messages. None of that arrives in fields, because none of it was created to be queried; it was created to be read by a person.
That is why the hard part of fielding AI is rarely the model. Oversight has made the point: the U.S. Government Accountability Office found that having usable data available is a central challenge in developing AI for weapon systems, giving the example that teaching an AI to detect an adversary's submarines first requires gathering many images and labeling them so the system can learn to identify one on its own (GAO, Artificial Intelligence: Status of Developing and Acquiring Capabilities for Weapon Systems, GAO-22-104765, 2022). Those images are unstructured data, and the labeling is the work of making them usable. The model is downstream of a data problem.
The Department of Defense has set the goal at the top. Its data strategy calls for becoming a data-centric organization and names seven goals for data, known as VAULTIS, including that data be understandable, linked, and interoperable (DoD, DoD Data Strategy, 2020). Unstructured content fails those goals by default: it is not understandable to a machine, not linked to anything, and not interoperable across systems until it has been read and structured. Closing that gap is the point of the work.
Structured and unstructured data enter an AI pipeline at different points and demand different handling. That contrast decides where a program spends its effort.
| Dimension | Structured data | Unstructured data |
|---|---|---|
| Form | Rows, fields, defined schema | Free text, documents, imagery, audio, sensor logs |
| Where meaning lives | In the schema (column headers, types) | In the content; must be extracted |
| Readiness out of the box | Largely machine-readable already | Must be read, extracted, and organized first |
| Share of mission data | The minority | The majority |
| First step to use | Normalize and link across systems | Read and extract entities and meaning, then normalize and link |
| How AI relates to it | Consumes it directly | AI both helps prepare it (reading, extraction) and later reasons over it |
| Typical failure mode | Schema mismatch across systems | Never processed at all; sits unread in a repository |
| Provenance risk | Lineage usually travels with the fields | Lineage easily lost when content is extracted and reshaped |
The row that matters most for a mission is the last two. Structured data tends to carry its lineage in its fields; unstructured data loses provenance easily, because extraction pulls facts out of a document and the link back to the source paragraph, with its classification and confidence, is exactly what careless pipelines drop. An extracted fact with no traceable source is fast and indefensible. Keeping that line intact through extraction is the difference between content you can brief and content you merely have.
Preparing unstructured data is a pipeline, not a conversion. In a mission setting the stages are:
The load-bearing stage is reading the content, because that is the step structured data never needs and unstructured data cannot skip. Everything downstream depends on it, and it is also where provenance is most easily lost. A pipeline that extracts facts but severs the line back to the source document has made the data fast and useless for a decision that has to be defended.
These terms travel together in data-readiness discussions and are easy to blur. They name different things. The table separates them so each can be cited on its own.
| Term | What it is | Relationship to structured vs unstructured data |
|---|---|---|
| Semi-structured data | Data with some tagging or markup (JSON, XML, email headers) but no full relational schema | A middle category; part structured enough to parse, part still needing interpretation of the body |
| Data extraction | Pulling entities, relationships, and facts out of unstructured content | The step that turns unstructured data into something an AI can use; unnecessary for already-structured data |
| ETL / ELT | Extract, transform, load pipelines that move and reshape structured data | A mechanism for structured data; necessary but insufficient for unstructured content, which needs reading first |
| AI-ready data | Data made usable by AI and analysts, measured against the DoD's VAULTIS goals | The broader state both structured and unstructured data are prepared toward; see the AI-ready data pillar |
Reading unstructured mission data changes who can use a force's own reporting, which makes ownership a first-order question rather than a procurement footnote. If the only usable, extracted copy of mission content lives in a vendor's proprietary format, the government has made its data usable on terms it does not control. The table contrasts the two models against what a mission needs.
| Consideration | Typical commercial platform | Government-owned reasoning infrastructure |
|---|---|---|
| Unstructured coverage | Often tuned for structured, tabular data | Reads and structures unstructured text, documents, and imagery |
| Control of the processed data | Held in the vendor's proprietary format | Customer keeps the extracted, linked data in open form |
| Relationship to existing systems | Often a migration onto a new platform | Processes data in place; no rip-and-replace |
| Provenance and classification | Varies; often lost in extraction | Preserved through the pipeline |
| Portability of the result | Locked to the vendor's model | Portable; feeds resolution, fusion, and reasoning |
| Governance | The vendor's cadence | The customer governs and maintains the processing |
Government-owned does not mean the government builds everything itself or owns a vendor's underlying intellectual property. It means the processed data, and the logic that extracted and structured it, stay under the customer's control and in a form it can reuse, rather than being usable only inside a proprietary platform. Whether a specific deployment is government-owned (GOTS) or commercial (COTS) depends on the system the customer installs and purchases; when the asset being processed is the force's own reporting and imagery, the government-owned model is the one to evaluate.
The comparison explains why unstructured coverage and ownership matter; the checklist is what to require in an evaluation.
Evaluating a capability? The seven requirements above are the backbone of an unstructured-data evaluation you can score vendors against. Bring them to a scoping call and we will walk each one against your environment: request a technical walkthrough.
Torch.AI builds reasoning infrastructure the customer can own and govern, offered as a government-owned (GOTS) deployment when a mission requires it. It processes data where it lives rather than demanding a migration. The platform ingests and normalizes fragmented, multi-source data, structured records and the unstructured content that defeats traditional pipelines alike, and NEXUS reads that unstructured text and imagery to extract the entities, relationships, and meaning inside it. HALO then links the extracted entities through graph-based fusion so the roster entry and the name buried in a report become one entity an analyst can trust and trace. You can see how this is packaged as a capability on the Torch.AI software page.
Because the content is processed in place and kept in open, owned form rather than a proprietary model, the result stays portable: the same processed data feeds entity resolution, fusion, and GraphRAG instead of being trapped where it was prepared. This is the systems of record versus systems of reason distinction at the center of Torch.AI's approach: reading and structuring unstructured content is the first step of a system of reason that sits on top of the customer's systems of record, leaving the authoritative sources intact.
Torch.AI's approach is built for the conditions this page describes: unstructured, multi-source content; provenance and classification preserved through extraction; structured and unstructured data linked into one picture; and a result the customer owns and can reuse across the mission.
For evaluators scoping a capability, see how Torch.AI reads unstructured mission data and links it with structured records on the software page, or request a technical walkthrough and we will run it against a sample of your own unstructured content, with provenance traced end to end.
Structured data is already organized into rows and fields with a defined schema a machine can read directly; unstructured data is free text, documents, imagery, audio, and sensor logs where the meaning is in the content and must be read and extracted before an AI can use it.
Because intelligence and operational data is produced as human communication and sensor output, reports, cables, imagery, and signal, not as database entries. It was created to be read by a person, which is why reading and structuring it is the main work of a defense AI effort.
AI can consume structured data almost directly after normalization and linking; unstructured data first has to be read so entities and meaning can be extracted, and only then normalized, linked, and reasoned over. AI both helps prepare unstructured data and later reasons over the result.
Connect to the content in place, read it to extract entities and relationships, normalize and link the output with structured records, attach provenance and classification through the pipeline, and maintain it as new content arrives. The reading step is the one structured data never needs and unstructured data cannot skip.
Semi-structured data carries some tagging or markup, such as JSON, XML, or an email with headers, so part of it is parseable, but the body still needs interpretation. It sits between fully structured records and fully unstructured content.
It depends on the deployment. In a government-owned (GOTS) model the extracted, linked data and the logic that processed it stay under the customer's control in open form it can reuse; in a commercial (COTS) model the result can be locked to a vendor's proprietary format. Which applies depends on the system the customer installs and purchases.
Describe the problem.
Define the constraints. We will structure the session.
No demo.
No slide deck.
Real work.
Describe the problem.
Define the constraints. We will structure the session.
No demo.
No slide deck.
Real work.
