.svg){kind=icon}
Cross-domain data integration is the practice of combining intelligence and mission data that lives in separate, isolated security domains, unclassified or CUI, SECRET, and top secret/SCI, into a coherent picture while enforcing the classification controls and accredited cross-domain solutions that govern what may move between them.
Also called cross-classification data integration or data integration across classification levels.
The tension is built into the problem. The whole point of classified networks is that they are isolated: data at one classification is kept off networks at another, enforced by hardware, policy, and accreditation. But a complete intelligence picture usually needs data from more than one of them. Integrating across domains therefore cannot mean copying everything into one place; it means combining what the rules allow to be combined, moving data between domains only through accredited mechanisms, and keeping classification intact the whole way.
That makes cross-domain integration a classification-governed layer on top of the rest of this hub: you cannot combine across domains data you have not made AI-ready, resolved, and marked for classification. It is also the vertical, by-classification counterpart to the horizontal, by-partner sharing of coalition interoperability.
Key takeaways
Cross-domain integration exists because separation is a feature, not a bug, and yet the mission needs to see across it. Networks are segregated by classification precisely to protect the most sensitive data, and moving information between security domains is governed, not free: Department of Defense policy requires that any transfer between domains go through an accredited cross-domain solution under defined controls (DoD, DoD Instruction 8540.01, Cross Domain (CD) Policy, 2017). Integration across classification levels is not a networking convenience; it is a governed, accredited activity.
The classification tiers map to specific networks, and only some of those tiers correspond to official cloud accreditation levels. The authoritative framework is DISA's Cloud Computing Security Requirements Guide, which defines impact levels IL2, IL4, IL5, and IL6, with IL6 covering classified information up to SECRET (DISA, DoD Cloud Computing Security Requirements Guide, via the DoD Cyber Exchange). Above SECRET, top secret and SCI data lives on the separate JWICS environment; that top-secret tier is not an official cloud impact level, so it should be described as the TS/SCI tier rather than given an impact-level number.
The reason manual approaches fail is that reconciling across these islands by hand is slow and unaccountable. Point-to-point data agreements, manual transfers, and stovepiped holdings at each level leave no common picture and no automated record of what moved where, under what authority. The demand is for integration that is both automated and governed: a shared picture that respects classification at the data level and moves data between domains only through the accredited paths policy requires.
For the mission the payoff is reasoning that spans the classification divide without weakening it: a picture that draws on what each tier is allowed to contribute, assembled at machine speed, with every cross-domain transfer controlled, logged, and defensible.
Bottom line: mission data lives in tiers that map to separate networks, and integrating across them is governed by classification. The official DoD cloud impact levels are IL2, IL4, IL5, and IL6 (up to SECRET); the top-secret tier (JWICS) sits above them and is not an official impact level.
| Tier | Network | Classification | Official cloud impact level |
|---|---|---|---|
| Unclassified / CUI | NIPRNet-tier | Unclassified, including higher-sensitivity CUI | IL4 (CUI), IL5 (higher-sensitivity CUI and national security systems) |
| Secret | SIPRNet | SECRET | IL6 |
| Top secret / SCI | JWICS | TS / SCI | Not an official cloud impact level; the TS/SCI tier |
The takeaway for an evaluator is that the tiers are real networks with real separation, and that precision matters: IL5 and IL6 are official accreditation levels, while the TS/SCI tier is a classification environment, not an impact-level number. A capability that claims an "IL7" accreditation is misusing the terminology, and that is a useful tell.
The pattern that respects both the mission and the controls is to build authoritative knowledge at a lower classification and enrich it as it moves up. The stages are:
The load-bearing idea is build low, enrich up: a shared foundation at a lower classification that each higher tier adds to through accredited transfer, rather than many disconnected pictures or a reckless pooling of everything into one. Done right, the lower tiers are never starved of what they are cleared to see, and the higher tiers are never leaked downward.
These terms cluster around classified data movement and are easy to blur. The table separates them.
| Term | What it is | Relationship to cross-domain data integration |
|---|---|---|
| Cross domain solution (CDS) | An accredited guard that moves data between security domains under controls | The accredited mechanism integration uses to transfer data across classification boundaries |
| Multi-level security (MLS) | A system that handles multiple classifications with built-in separation | A design approach to the same problem; cross-domain integration focuses on combining the data across domains |
| CJADC2 | Integrating data and decisions across warfighting domains and partners | Related but different: see CJADC2. There "domain" means a warfighting domain; here it means a classification domain |
| Classification-aware integration | Handling data with its classification enforced throughout | The property cross-domain integration depends on, applied across tiers |
Cross-domain integration touches the most sensitive data a force holds and the controls that protect it. If the logic that marks classification, drives transfers, and reconciles across tiers lives in a vendor's proprietary environment, the government has put the enforcement of its own classification controls somewhere it cannot fully inspect or accredit. The table contrasts the models against what cross-domain integration requires.
| Consideration | Typical commercial platform | Government-owned reasoning infrastructure |
|---|---|---|
| Control of classification enforcement | Held in the vendor's environment | Customer controls how classification is enforced across tiers |
| Relationship to accredited transfer | Varies | Works with the accredited cross-domain solution, does not bypass it |
| Sensitivity of the data | Most-sensitive holdings externally held | Kept under government control |
| Provenance across boundaries | Often limited | Preserved and logged through every transfer |
| Directional control | Generic | Enriches up without pushing restricted data down |
| Where it can run | Frequently cloud-only | Across CUI, SECRET, and TS/SCI environments |
Government-owned does not mean the government builds everything itself or owns a vendor's underlying intellectual property. It means the classification enforcement, the integration logic, and the transfer log stay under the customer's control and accreditation rather than inside a proprietary model. Whether a specific deployment is government-owned (GOTS) or commercial (COTS) depends on the system the customer installs and purchases; for the integration of a force's own classified data, the government-owned model is the one to evaluate.
Moving data across a classification boundary is an accredited, policy-governed act, so the controls and a human stay in command. The accredited cross-domain solution is the guard that enforces what may transfer; the integration capability works with it, never around it. The machine does the scale: marking classification, reconciling the picture across tiers, and preparing data for accredited transfer, faster than any manual process. But the authority to accredit a transfer path and to approve what moves rests with the security and accreditation authorities, not an automated default, and the system withholds rather than guesses when classification is unclear. This is the same auditable discipline the rest of this hub requires, applied where a wrong transfer is a spillage: the AI integrates and prepares; the accredited guard and the human authority control what crosses.
The sections above explain why classification enforcement and accredited transfer matter; the checklist is what to require in an evaluation.
Evaluating a capability? The seven requirements above are the backbone of a cross-domain data-integration 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, designed to operate across classification tiers. ORCUS ingests and normalizes data with classification preserved at the record level; NEXUS reads unstructured reporting and applies classification and releasability labels at scale; and HALO resolves and fuses the data into a shared picture in which every entity and relationship carries its classification, so the picture can be built at a lower tier and enriched as higher-classification reporting is added. The capability works with the accredited cross-domain solution that governs transfer rather than around it, and every element stays traced to its source and classification through the boundary. You can see how this is packaged as a capability on the Torch.AI software page.
Because classification is enforced at the data level with provenance preserved, the integrated picture is defensible across tiers: a security authority can see why a record carries the classification it does and govern what moves, while the accredited guard enforces the transfer. This is the systems of record versus systems of reason distinction at the center of Torch.AI's approach, carried across the classification divide: the reasoning layer builds the shared picture on top of the authoritative sources at each tier, which stay intact, so a force reasons across classifications without weakening the separation that protects them.
Torch.AI's approach is built for the conditions this page describes: classification enforced at the record level; a shared picture built low and enriched up; accredited cross-domain transfer respected, not bypassed; provenance preserved across boundaries; and government-owned operation across CUI, SECRET, and TS/SCI environments.
For evaluators scoping a capability, see how Torch.AI integrates data across classification tiers while respecting cross-domain controls on the software page, or request a technical walkthrough and we will run it against a representative cross-domain scenario, with provenance traced end to end.
What is cross-domain data integration in simple terms? It is combining mission data that lives on separate, isolated networks at different classifications, unclassified or CUI, SECRET, and top secret/SCI, into one coherent picture, while enforcing the classification controls and accredited cross-domain solutions that govern what may move between them. Here "domain" means a classification domain, not a warfighting domain.
What is a cross domain solution (CDS)? A cross domain solution is an accredited guard that moves data between security domains under defined controls. Cross-domain integration uses an accredited CDS to transfer data across classification boundaries; it never copies data across a boundary without one.
Is there an IL7 classification level? No. The official DoD cloud impact levels are IL2, IL4, IL5, and IL6, with IL6 covering classified data up to SECRET. Top secret and SCI data lives on the JWICS environment, which is the TS/SCI tier, not an official cloud impact level. A capability claiming "IL7 accreditation" is misusing the term.
How do you integrate data across classification levels without a spillage? By enforcing classification at the record level, transferring only through an accredited cross-domain solution, and controlling direction, enriching a lower-tier picture with higher-classification data as it moves up, never pushing restricted data down. Provenance and a transfer log keep every movement accountable.
How is this different from CJADC2? CJADC2 integrates data and decisions across warfighting domains and partners; cross-domain data integration here is about combining data across classification domains (CUI, SECRET, TS/SCI). The word "domain" means different things in the two: warfighting domain versus classification domain.
Why does cross-domain integration need to be government-owned? Because it touches the most sensitive data and the controls that protect it. A government-owned (GOTS) deployment keeps classification enforcement, integration logic, and the transfer log under the customer's control and accreditation. The same capability can also be delivered commercially (COTS); which applies depends on the system the customer installs and purchases.