CTDE - Khan BMS Battlefield Management System
A short, opinionated brief on CTDE — Centralized Training, Decentralized Execution — and the role it plays inside a Khan BMS formation under contested conditions.
For the record: CTDE stands for Centralized Training, Decentralized Execution. Training pattern where agents learn with shared global information but deploy using local observations. Centralized Training, Decentralized Execution is training pattern where agents learn with shared global information but deploy using local observations. In defense applications, it produces policies that coordinate well during training yet survive disconnected field execution. The hard part is training-deployment mismatch and hidden dependence on unavailable global state, especially when systems are deployed across contested links, coalition boundaries, and mixed human-machine teams. KhanBMS treats it as a fit for KhanBMS formations that rehearse as a Tumen but fight as local Arbans, tying the concept back to modular command, edge execution, and auditable authority.
Khan BMS's design choice on CTDE is unfashionable but defensible: keep authority bounded, keep schemas small, keep the ai & multi-agent surface area legible to a human Khan. Cleverness at the edge is a liability when the link is contested.
The Zuun (one hundred nodes) is the natural composition point for CTDE. Ten Arbans aggregate their CTDE state into one Zuun-level picture; one Zuun commander supervises ten subordinates, never a hundred individual feeds. The cognitive-load math is the entire point.
A jammed forward node, a half-readable track, a window measured in seconds — that is where CTDE earns its keep. Centralized Training, Decentralized Execution is not a slide-deck capability; it is the seam where doctrine meets a contested radio.
CTDE is one of perhaps a dozen primitives that decide whether a modern force can fight through denial. Khan BMS is built on the premise that all of them deserve the same treatment.