JDLM and LOGFAS Integration for Coalition Sustainment Planning

Coalition operations live or die on sustainment. A multinational task force can be tactically brilliant and still grind to a halt because fuel did not arrive at the right node, because medical class VIII shifted between two national stockpiles untracked, or because one nation's transport plan assumed a road that another nation's engineers had not yet repaired. The cost of poorly-planned multinational sustainment is measured in combat power lost — not in spreadsheet errors.

NATO's response to this problem is LOGFAS — the Logistics Functional Area Services suite — and a small constellation of supporting tools. The US response, with broader joint and interagency reach, is JDLM. In practice every coalition deployment must integrate both, plus the participating nations' own ERPs. This article is an engineering walkthrough of how that integration actually works, what breaks, and what holds.

The Coalition Sustainment Problem

National armies do not federate by default. Each runs its own ERP — SAP in some, Oracle EBS in others, IFS in a few, bespoke legacy systems in more than admitted. Each has its own materiel catalog, its own NSN-to-local mapping, its own transport schema, its own classification rules. When two nations stand up a combined joint task force, none of this aligns automatically.

The historical workaround was LOGREP — the LOGistics REPort — exchanged as a flat file at planning conferences. LOGREP became the coalition currency: imperfect, lossy, but agreed. A nation's Force List, asset readiness, consumption forecast, and movement plan all collapse into LOGREP entries that other coalition partners can read. Today LOGREP is still the lingua franca, but the exchange has moved from paper and email into LOGFAS and the protocols around it.

The deeper problem is that national ERPs were never built to expose their internals to a coalition. Their data is sensitive, their schemas are commercial-confidential, and their operators are not authorized to publish them. Federation has to be engineered — it does not happen.

LOGFAS Component Tour

LOGFAS is not one application. It is a suite, distributed by the NATO Communications and Information Agency (NCIA), with four components that matter for any integration project.

LOGREP is the data model and the database. It defines the entities — Force Modules, Holdings, Requirements, Stockpiles, Movement Requirements — and the relationships among them. Every other LOGFAS component reads or writes LOGREP. When engineers say "integrate with LOGFAS," they almost always mean "produce or consume LOGREP database content."

ADAMS (Allied Deployment and Movement System) is the planning surface. ADAMS consumes LOGREP, applies a network of routes, modes, and transport assets, and produces movement plans — who moves what, by which mode, to which intermediate node, on which day. ADAMS is where coalition planners spend their hours during the deployment phase.

EVE (Effective Visible Execution) is the execution-monitoring layer. Where ADAMS plans, EVE tracks actuals: where the convoy actually is, whether the aircraft actually departed, whether the stockpile actually arrived. EVE is the closest thing LOGFAS has to a real-time picture, though "real-time" in logistics often means "today's positions reported at 0700."

SDM (System Data Management) is the administrative spine — users, roles, releasability, database synchronization, catalog management. SDM is invisible to planners and central to integrators. Every cross-database synchronization, every catalog harmonization, every releasability rule lives here.

The four interoperate through the shared LOGREP database. A change to a Force Module in one component appears in the others on the next sync. Most integration projects target the LOGREP schema directly, treating ADAMS and EVE as views over a shared substrate.

JDLM (Joint Deployment and Logistics Model)

JDLM is the US Transportation Command (USTRANSCOM) modeling system for joint deployment and sustainment. Where LOGFAS centers on coalition planning, JDLM centers on US joint and interagency moves — and increasingly on the modeling required to evaluate alternative courses of action under constraint.

JDLM consumes a different upstream: TPFDD (Time-Phased Force and Deployment Data) feeds from JOPES and its successor systems, JDLM-native modeling inputs from planners, and intelligence overlays. Its outputs are deployment options scored against time, mode capacity, and risk. The interoperability story with LOGFAS is not symmetry — the two systems do not exchange databases. It is translation. A US plan modeled in JDLM has to be re-expressed as LOGREP-compatible movement and holdings records for coalition partners to ingest.

In practice this means a translation node sits between them — a small service that reads JDLM exports, applies the field mappings, applies the classification rules, and writes the LOGREP-shaped output to a stage that LOGFAS can pull from. Every coalition deployment that includes the US runs some version of this node.

STANAG 2406 Family

The logistics reporting STANAGs sit beneath everything. STANAG 2406 covers logistics reporting in the broad sense, and the related STANAGs in the 2400 series define specific exchange formats — fuel reporting, ammunition reporting, casualty and medical logistics reporting, transport movement reporting.

The MEDLOG extension — medical logistics — is the part teams most often underestimate. Medical class VIII has different shelf-life rules, different temperature constraints, different cross-national releasability profiles, and different reporting cadences from general supply. A LOGFAS integration that handles classes I through V cleanly will still fail audit on class VIII if MEDLOG is not modeled correctly. Plan for it from the first sprint.

The STANAGs define the wire format. Implementers should treat them as the contract: anything the platform produces must round-trip through a STANAG-compliant export and back without loss. This rule alone catches more bugs than any other discipline.

Integration Patterns

Three patterns dominate.

Pull (poll LOGREP). An external system polls a LOGREP replica on a schedule — every fifteen minutes, every hour — diffs against its last snapshot, and acts on changes. Pull is simple, predictable, and easy to operate. It is also lossy: if a record is created and deleted between polls, the puller never sees it. For planning data — which changes on conference cadence, not on the second — pull is correct.

Push (event stream into LOGFAS). Upstream systems emit change events — a stockpile updated, a movement executed — onto a message bus, and a LOGFAS adapter consumes them and writes them into LOGREP. Push is closer to real-time and lossless, but it requires a robust message queue and careful idempotency. For execution data, push is correct.

Staging (translation node with classification gate). The canonical coalition design. National ERPs publish to a national stage. A translation node — owned by the integration team, often air-gapped from the upstream — reads from the stage, applies field mappings, applies releasability rules, and writes to a coalition-side LOGREP. The translation node is the single chokepoint where classification, releasability, and schema all converge. Build it explicitly. Do not let it emerge.

Classification and Releasability

National logistics data is, by default, national. NATO RESTRICTED is the floor most coalition exchanges sit at, but the same record may be releasable to NATO and not to a specific partner nation, or releasable to one mission and not another. Releasability is not classification — it is the orthogonal axis that determines who sees what within a given classification level.

The pattern that works is sanitize-on-egress. Every record carries a releasability vector — a set of nations and missions for which it is approved. The translation node refuses to write any record whose releasability vector does not include the destination. Fields that are nationally sensitive (specific lot numbers, supplier names, end-item serials) are stripped or hashed before the record crosses the gate. Coalition interoperability discipline demands this be enforced in code, not in policy. Policy fails under operational tempo.

The gate also logs. Every record that crosses, every record that is rejected, every field that is sanitized — logged with provenance. Releasability audits will come. Be ready.

Federating National ERPs into LOGFAS

SAP, Oracle EBS, IFS, and Maximo are the four upstream sources we have seen most often. Each maps to LOGREP differently.

SAP MM (Materials Management) carries holdings and consumption with high fidelity but uses national materiel codes — mapping these to NSNs is half the integration work. The mapping is rarely one-to-one; expect a curated cross-walk table maintained by the materiel authority. Defense ERP integration patterns apply directly here.

Oracle EBS Inventory and IFS Supply have similar shapes but different field semantics — "on hand" in one is "available" in another, with reservations and in-transit handled inconsistently. Read the field definitions, not the field names.

Maximo, used heavily for fleet maintenance, contributes readiness data — vehicle status, deferred maintenance, mission-capable rates. Maximo feeds the readiness columns of a LOGREP Force Module record. Mismodel readiness and the coalition plan is built on fiction.

For the pipeline, change-data-capture (CDC) is the right shape. Run CDC against the ERP, materialize a national-side projection, transform to LOGREP shape, gate on releasability, write across. Batch replication breaks on edge cases; CDC's per-record discipline catches them.

Operational Lessons

Steadfast Defender and Trident Juncture exercises both stress-tested coalition logistics end-to-end at scales close to real war. The pattern of failure is consistent.

What breaks first is the catalog. A nation's local catalog drifts from the agreed NSN cross-walk — a new item enters service, the cross-walk update is deferred, and overnight the LOGREP feed produces "unknown materiel" rows that downstream consumers silently drop. Build catalog drift detection into the pipeline. Alert on it the same shift it happens.

What breaks second is time. LOGREP timestamps are reported in local time without zone in older feeds, in UTC in newer ones, and in mission time in some operational contexts. A single integration that conflates these produces movement plans where convoys arrive before they depart. Normalize to UTC at ingest. Never trust a wall-clock timestamp.

What breaks third is releasability. A field that was releasable yesterday becomes nationally sensitive today — a supplier name, a lot number, a route detail. If releasability is hard-coded into the translation rules rather than carried per-record, every change becomes a code release. Make releasability data, not code.

What breaks fourth is the human in the loop. ADAMS planners and EVE operators work shift rotations, and the handover between shifts is where most data-quality regressions enter. A movement is partially updated by the outgoing shift, the incoming shift assumes the record is final, and downstream consumers ingest a half-written plan. The fix is not training. The fix is enforcing record-level atomicity at the LOGREP boundary — partial writes are rejected, full updates succeed. Push the constraint into the schema layer where shift fatigue cannot bypass it.

What survives across exercises is the team that owns the translation node end to end — schema, mapping, releasability, gate, audit log. That ownership cannot be split across nations or contractors without the seams becoming the failure surface. One team, one gate, one accountable owner. Everything else is secondary.

The discipline that survives is data quality. Coalition logistics will not be saved by a smarter optimizer. It will be saved by clean catalogs, honest readiness, faithful timestamps, and translation gates that refuse to lie. Build for that and the rest follows. For the wider operational picture, our defense supply chain software and predictive maintenance articles cover adjacent terrain. For the fusion architecture that consumes logistics signals alongside ISR and operational data, see our defense data fusion guide.