What Is the Traffic Coordination System for Space (TraCSS)?

The Crowded Sky: Why the World Needs Space Traffic Control

For the first six decades of the space age, the region of orbit above Earth was a vast, open frontier, a near-infinite void managed primarily by a handful of government actors. Today, that frontier is gone. The orbits around our planet, particularly the highly desirable region known as Low Earth Orbit (LEO), are now a congested, contested, and complex operational domain. This zone, stretching from roughly 160 to 2,000 kilometers in altitude, is the “shipping lane” of the modern global economy. It’s where satellites provide the internet, observe our climate, manage global logistics, and support national security.

This new reality is driven by a revolution in commercial space activity. The cost of launch has plummeted, and the size of satellites has shrunk, paving the way for the deployment of “mega-constellations.” These are vast, interconnected networks of thousands, or even tens of thousands, of small satellites working in unison. While these constellations are poised to connect the entire globe to high-speed internet and provide unprecedented Earth-observation capabilities, they have introduced a challenge of staggering proportions: space traffic.

Today, there are more than 10,000 operational satellites in orbit. This number is projected to increase by two- to six-fold by the end of this decade alone, with some estimates suggesting a future population of over one hundred thousand active satellites. This explosive growth in “active” traffic is happening in an environment already dangerously polluted by decades of “inactive” traffic – orbital debris, also known as space junk.

The result is a domain where the risk of collision is no longer a remote, theoretical possibility. It is a daily, operational reality. In a typical 72-hour period, automated tracking systems may register between 120,000 and 150,000 “conjunctions,” or instances of two space objects passing uncomfortably close to one another. SpaceX, the operator of the world’s largest satellite constellation, Starlink, has had to perform tens of thousands of collision avoidance maneuvers to protect its assets.

This is an ad-hoc, unsustainable, and dangerous way to manage a multi-trillion-dollar economy. The historic method of space traffic management – a passive catalog of known objects maintained by the U.S. military – was not designed for this high-density, high-velocity, commercial-led era. A single catastrophic collision could create a shotgun blast of new debris, setting off a chain reaction that could render entire orbital highways unusable for generations.

The world doesn’t just need a better catalog of space objects. It needs a system of coordination. It needs a “digital lighthouse” for space – an active, civil-led service that can ingest data from all sources, predict near-misses with high fidelity, and, most importantly, serve as a neutral, trusted clearinghouse where all operators can coordinate their movements for the safety of all.

This is the mission of the Traffic Coordination System for Space, or TraCSS. It is the United States government’s answer to the problem of a crowded sky, representing a fundamental shift in policy and technology designed to protect the future of the space economy.

A Brief History of Orbital Debris

The orbital debris problem began the moment the space age did. On October 4, 1957, the Soviet Union launched Sputnik 1. While the satellite itself re-entered the atmosphere months later, the massive upper stage of the R-7 rocket that carried it to orbit remained, becoming one of the first large pieces of space junk. Every launch since has left something behind.

“Orbital debris” or “space junk” is a catch-all term for any human-made object in orbit that no longer serves a useful function. This includes defunct satellites that have run out of fuel or failed, spent rocket upper stages that delivered their payloads and are now tumbling uncontrollably, “shedding” from rocket and satellite operations (like lens caps, insulation, or flecks of paint), and the countless tiny fragments from past breakups.

These objects are a unique and persistent environmental hazard. In the vacuum of space, at altitudes above 600 kilometers where atmospheric drag is negligible, a piece of debris can remain in orbit for decades, centuries, or even millennia. The problem isn’t just the objects themselves; it’s their speed. In LEO, objects travel at more than 17,500 miles per hour (over 7 kilometers per second). At that velocity, a collision with an object the size of a marble carries the kinetic energy of a bowling ball dropped from a skyscraper. A fleck of paint can pit a space shuttle window. An object the size of a softball can completely obliterate a multi-million-dollar satellite.

For decades, the primary source of new debris wasn’t collisions. It was explosions. The space environment is, in effect, a minefield of “ticking time bombs.” Many older satellites and rocket bodies were not “passivated” at the end of their missions. This means they were left in orbit with residual fuel in their tanks or high-pressure batteries. Over time, as these derelict objects are exposed to the extreme temperature cycles of space, these components can degrade and spontaneously explode.

These explosions are the single largest contributor to the current debris problem. A single rocket body explosion can create hundreds or thousands of new fragments, each becoming a new, independent projectile threatening active satellites. Despite international guidelines recommending that all new spacecraft be passivated at the end of their lives, the number of these explosive breakup events has not declined. This is because of the vast inventory of “legacy” objects launched in the 1970s, 80s, and 90s that are still waiting to break apart.

This creates a “pre-loaded” environment of risk. The problem is actively getting worse on its own, even before we account for the new traffic.

Cleaning up this mess is not a simple solution. The technology for “active debris removal” (ADR) is in its infancy; it’s extraordinarily complex, expensive, and unproven at scale. Furthermore, most of these legacy objects were not designed to be captured, grabbed, or de-orbited. The persistence of existing debris, and the constant creation of new debris from explosions, means that cleanup is not a viable, near-term strategy. The global space community has been forced to pivot from remediation (cleanup) to mitigation (avoidance). If the environment can’t be cleaned, the only remaining option is to navigate it more carefully.

The 2009 Collision: A Warning Shot in Orbit

For 52 years, the space community operated with the statistical comfort that while a collision was possible, the sheer volume of space made it improbable. That comfort was shattered at 16:56 UTC on February 10, 2009.

At an altitude of 789 kilometers over the Taymyr Peninsula in Siberia, two massive satellites slammed into each other at a combined velocity of 11.7 kilometers per second – over 26,000 miles per hour. It was the first-ever hypervelocity collision between two intact satellites.

The two objects were a perfect, and tragic, representation of the orbital debris problem. The first satellite was Iridium 33, an active, 560-kilogram commercial communications satellite. It was part of the original Iridium constellation, a vital piece of global infrastructure. The second was Kosmos 2251, a defunct, 950-kilogram Russian military communications satellite. Launched in 1993, it had been non-operational for over a decade, left to tumble uncontrollably through one of the most crowded orbital corridors.

It was a case of an active, valuable asset being destroyed by an unmanaged, derelict piece of legacy junk.

The impact was catastrophic. Both satellites were instantly destroyed. The collision was not a “fender bender”; it was an explosive vaporization and fragmentation event. The U.S. Space Surveillance Network, the global system of military radars and telescopes that tracks space objects, was overwhelmed. In the immediate aftermath, it cataloged over 1,400 new, large, trackable pieces of debris (larger than 10 cm). The true number, including fragments too small to track but still large enough to be lethal to other satellites, is estimated to be in the hundreds of thousands.

This single event was like a “shotgun blast” that “significantly increased” the amount of debris in an already-congested region. The fragments didn’t just stay at 789 km. The force of the hypervelocity impact threw debris into a wide range of new orbits, polluting adjacent “orbital highways” and creating new, long-term threats to countless other satellites. Some of the larger pieces from this one collision are projected to remain in orbit for more than a century. Years later, the International Space Station, has had to perform avoidance maneuvers to dodge debris fragments from the Iridium-Kosmos event.

But the most chilling part of the 2009 collision was not the event itself. It was the failure of prediction.

This was not an “unknown” event. Both satellites were being tracked. In the days leading up to the conjunction, existing tracking systems run by the U.S. military had analyzed the pass. Their models predicted the two satellites would miss each other by a “safe” distance of 584 meters.

The collision happened inside the margin of error.

This was the moment the space community realized its tools were inadequate. The problem was not a lack of tracking but a lack of data fidelity and risk assessment. The “covariance” – the bubble of uncertainty around a tracked object – was so large that 584 meters was considered a “miss,” when in reality, it was a direct hit. No one truly knew, with actionable certainty, “how close is too close.”

The 2009 collision was a warning shot. It proved that simply cataloging objects was not enough. It exposed the economic and operational vulnerability of the entire space industry to a problem it had long ignored. It was the “origin story” for the modern economic and operational necessity of a far more sophisticated system – a system that could not only track, but predict, warn, and coordinate with high precision.

The LEO Revolution: Mega-Constellations Change Everything

If the 2009 collision was a warning shot, the LEO revolution of the 2020s is an exponential escalation of the threat. The problem of orbital congestion is no longer defined by a sparse population of large, defunct satellites. It is now defined by a dense, rapidly growing swarm of new, active commercial ones.

The “LEO Revolution” is shorthand for the industrialization of space, driven by private companies building “mega-constellations.” These are not single, school-bus-sized satellites, but “webs of networked satellites” numbering in the thousands.

Companies like SpaceX (with its Starlink constellation), Eutelsat OneWeb, and Amazon (with its upcoming Project Kuiper) are the most prominent players. They are joined by dozens of other private companies and state-backed enterprises, most notably China’s planned Guowang (“National Network”) and Qianfan constellations. These systems are designed to provide global, low-latency broadband, remote sensing, and other telecommunication services.

To achieve this, they must operate in Low Earth Orbit. Their sheer numbers are fundamentally rewriting the orbital equation.

In 2018, there were approximately 2,000 active satellites in LEO. By 2022, that number had surged to over 5,000. As of late 2025, with SpaceX launching rockets almost weekly, the number of operational satellites in orbit has surpassed 10,000. This is just the beginning. The trend suggests a future population of well over one hundred thousand satellites within the decade.

This creates a “high-density ‘space grid'” that is tightly wrapping the Earth in multiple layers, particularly at altitudes between 400 and 1,000 kilometers. The environment has fundamentally shifted from a “sparse highway,” where collisions are rare, to a “crowded urban intersection,” where conjunctions (near-misses) are constant.

The operational data confirms this new reality. The number of conjunction events tracked by NASA has seen a staggering 250% increase in just three years, from the end of 2020 to the end of 2023. As mentioned, a single commercial tracking firm now logs 120,000 to 150,000 potential conjunctions in a 72-hour period.

This isn’t just a statistical problem; it’s a massive operational and economic burden. The “canary in the coal mine” is Starlink. As the operator of the largest fleet, SpaceX is on the front lines of this problem. The company has had to perform approximately 50,000 collision avoidance maneuvers for its constellation.

Each maneuver is a costly and risky event. It consumes precious onboard fuel, which directly shortens the satellite’s operational lifespan and its revenue-generating capability. It requires a 24/7 team of highly skilled operators to analyze the risk and execute the maneuver. And it can cause a temporary disruption in service as the satellite moves out of its planned “slot.”

This creates a powerful economic incentive to solve the problem. But the new bottleneck is not a lack of data; it’s a lack of coordination.

The single biggest problem in space traffic management today is the lack of “operator intent.” A satellite’s ephemeris – its precise positional data and, most importantly, its planned maneuvers – is the most accurate information that exists for that object. But in a competitive commercial environment, this information is proprietary and guarded. Today, only 3-4% of global satellite operators openly share their ephemerides with the industry.

This leads to a “fog of war” in orbit. The central tracking systems are, in effect, guessing. They might see two satellites on a collision course, but they don’t know that one of them is already planning a maneuver to change its orbit. This results in thousands of “false positive” alerts, which in turn leads to “warning fatigue.” If operators are constantly dodging “ghosts,” they may become desensitized to a real threat.

The mega-constellation era has made it clear that the problem can no longer be solved by a single entity’s radar. It can only be solved by a trusted, central, civil-led clearinghouse where commercial competitors and international partners feel safe sharing their operational data.

The Kessler Syndrome: A Cascade of Catastrophe

The 2009 collision was a single event. The mega-constellation boom is a chronic condition. The “Kessler Syndrome” is the theoretical “worst-case scenario” that these trends are leading toward – a cascading catastrophe that could end the space age.

The scenario was proposed in 1978 by NASA scientist Donald J. Kessler. He observed that once the density of objects in a particular orbit reaches a “critical mass,” a self-perpetuating chain reaction will begin.

The mechanism is simple and terrifying. A collision – like Iridium-Kosmos – generates a field of new debris. This new debris dramatically increases the probability of more collisions. Each of those subsequent collisions then generates more debris, which in turn causes more collisions. This is a “cascading chain reaction” that, once started, grows exponentially.

The 2009 collision was, in effect, a micro-Kessler event. It created thousands of new projectiles that increased the collision risk for everything else in that orbit. The theory posits that once the rate of new debris creation from collisions exceeds the rate at which debris is naturally removed by atmospheric drag, the cascade becomes self-sustaining and irreversible.

In this nightmare scenario, the debris field would grow until LEO is reduced to a “junk yard” of small, lethal fragments. This would “render certain orbital regions unusable” for decades or centuries. It could “extinguish any safe orbits,” making new launches impossible and threatening all existing space infrastructure. It could, in a very real sense, trap humanity on Earth, unable to access the orbital domain upon which its modern economy depends.

For decades, the Kessler Syndrome was a distant, science-fiction threat. It is not anymore.

Some experts now state that it is “a question of when, not if” this process begins. The non-linear nature of collision frequency means that as we add more and more satellites, we are getting closer to that “critical mass” tipping point. Some models suggest that even if all space activity stopped today – no new launches, 100% sustainable practices – the existing mass of legacy objects in orbit (especially the unpassivated rocket bodies) is already sufficient to eventually start the cascade.

This reframes the entire purpose of space traffic management. A system like TraCSS is not just an “air traffic control” system to prevent “fender benders.” It is an orbital environmental protection system. Its mission is not just to save individual, high-value satellites. Its mission is to prevent the first major cascade. It is to ensure the “long-term viability” and “space sustainability” of the orbital domain itself.

The combination of legacy debris, exploding rocket bodies, the 2009 failure of prediction, and the new density of mega-constellations created a perfect storm. It was clear to policymakers that the old way of doing business was broken. A new, more sophisticated, and fundamentally different approach was a strategic necessity.

The Mandate for Change: A New National Space Policy

The growing crisis in orbit demanded a top-down, national-level response. The ad-hoc system of the 20th century was clearly insufficient for the 21st. The United States government, as the traditional de facto provider of space safety data to the world, recognized the need for a fundamental shift in policy. This realization was formalized in a foundational document that serves as the “birth certificate” for TraCSS, redefining how America, and by extension the world, would manage space traffic.

Space Policy Directive-3: A Civil Solution for a Crowded Domain

On June 18, 2018, the White House issued Space Policy Directive-3 (SPD-3), titled the “National Space Traffic Management Policy.” This directive was a landmark document. It wasn’t an incremental update; it was a conceptual revolution. It officially acknowledged that the orbital environment was a complex domain on par with the air and sea, and that space traffic management (STM) was a national priority.

The “key element” of SPD-3, and its most impactful instruction, was the mandate to shift responsibility for civil and commercial space safety. For decades, the U.S. Department of Defense (DoD) had been responsible for maintaining the public catalog of space objects and providing collision warnings to all operators, domestic and foreign.

SPD-3 explicitly directed that this responsibility be transferred to a civil agency.

The directive was precise. It stated that “a civil agency should… be responsible for the publicly releasable portion of the DoD catalog and for administering an open architecture data repository.” It then explicitly identified that “the Department of Commerce should be that civil agency.”

SPD-3 went on to lay out the functional requirements for this new civil system. It was not just to be a passive, static database. The directive called for a modern system with:

• An Open Architecture: A flexible “open architecture data repository” that could ingest data from diverse sources, including the DoD, commercial companies, international partners, and satellite operators themselves.
• Standardized Formats: The use of “standardized formats” to ensure data from all these different sources could be easily combined and understood.
• Active, Actionable Services: A shift from a passive catalog to an active service. The system was to provide “actionable and timely conjunction assessments” and use “automated processes for collision avoidance.”
• Data Protection: Measures to “safeguard proprietary or sensitive data,” a key requirement to build trust with commercial operators.
• A Public Good: And, in a statement of economic policy, SPD-3 directed that the Department of Commerce provide these “space traffic safety data and services” to all operators “free of direct user fees.”

In effect, SPD-3 redefined basic space safety. It was no longer a military-provided by-product. It was now an active, civil-led public service – a foundational piece of infrastructure provided by the government to enable and protect the growing commercial space economy. TraCSS is the system being built to execute this mandate.

From Warfighters to Weather Forecasters: Why the Department of Commerce?

The decision to move this critical responsibility from the Department of Defense to the Department of Commerce was a deliberate, strategic, and logical choice driven by two primary factors.

First, the Department of Defense’s core mission is national security. Its space-tracking capabilities, run by the U.S. Space Force and U.S. Space Command, are designed to detect and defend against threats. Their mission is “space domain awareness” (SDA) and “space warfighting.” As the LEO environment became exponentially more crowded with commercial traffic, the public safety mission of providing collision warnings became a significant “burden” and a distraction from this core military function.

Every sensor and every analyst dedicated to warning a commercial satellite about a piece of old debris was one not focused on monitoring a potential adversary’s activities. As General Stephen Whiting of U.S. Space Command later stated, migrating the civil mission to TraCSS allows the military to “focus on… military space operations.” The DoD was, and remains, a very willing partner in this transition.

Second, if the DoD was the wrong agency for the job, the Department of Commerce was uniquely right. The mission was specifically given to the National Oceanic and Atmospheric Administration (NOAA), a bureau within Commerce.

Why NOAA? Because NOAA has “decades of experience fielding operational, public safety systems that issue hazard alerts to protect lives and property.”

The analogy is powerful and direct. For decades, NOAA has run the National Weather Service. It ingests massive, complex datasets from ground sensors, ocean buoys, weather balloons, and its own fleet of satellites. It fuses this data in supercomputers and runs complex predictive models. And it issues 24/7/365, time-sensitive, high-stakes “hazard alerts” – tornado warnings, hurricane tracks, flash flood warnings – that the public and the economy rely on.

This is the exact same operational model required for space traffic. The new mission simply swaps the data: instead of ingesting weather data to predict storms, the agency will ingest orbital data to predict collisions. NOAA is one of the few government agencies with the cultural and technical DNA to run a 24/7, data-driven, public-safety “hazard alert” system.

This move was more than a bureaucratic shuffle. It was a strategic uncoupling of public safety from national security. A military’s primary mission demands secrecy. A public safety mission demands openness and transparency. This conflict of interest was a major barrier to international cooperation.

International operators and commercial competitors were, and are, deeply hesitant to share their sensitive, proprietary maneuver plans with a foreign military. This “distrust” created a “strategic dilemma” that poisoned diplomacy and prevented the very data sharing needed to solve the traffic problem.

By moving the mission to a transparent, civilian, science-based agency like NOAA, the U.S. government defined space safety as a global, civil, environmental problem – like weather – that can be collaborated on openly, separate from military competition. This uncoupling was the political prerequisite that makes a system like TraCSS possible, as it’s the only way to build the trust needed to get international operators and commercial competitors to share their most valuable data.

The Role of NOAA and the Office of Space Commerce

Within NOAA, the “principal unit” tasked with executing this historic mandate is the Office of Space Commerce (OSC). This small, specialized office sits at the precise intersection of government policy and the new space economy.

The OSC has a clear, dual-pronged mission. First, its overarching goal is to “foster the conditions for the economic growth and technological advancement” of the U.S. commercial space industry. Second, it is the office charged with the practical, hands-on development and operation of TraCSS to “provide basic space situational awareness (SSA) data and services” to the world.

Housing TraCSS within the Office of Space Commerce is, in itself, a powerful declaration of policy. The mission wasn’t given to the Federal Aviation Administration (FAA), which is primarily a domestic regulator. It wasn’t given to NASA, which is a science and exploration agency. It was given to the agency whose entire purpose is to promote economic growth.

This means the U.S. government views basic space safety not as a scientific curiosity or a regulatory burden, but as pro-growth economic infrastructure.

By providing this data for free, as mandated by SPD-3, the OSC is providing the foundational “public utility” for the 21st century. It is the digital equivalent of the U.S. government building the interstate highway system, which enabled the trucking industry, or providing the GPS signal for free, which unlocked a multi-trillion-dollar economy of logistics, location-based services, and precision agriculture.

The OSC’s job, through TraCSS, is to make the “shipping lanes” of Low Earth Orbit safe, predictable, and efficient, thereby “fostering… economic growth” by creating a stable operating environment for the entire global commercial space economy.

Inside TraCSS: The Architecture of a Digital Lighthouse

TraCSS is not a single piece of software or a new radar. It is a modern, cloud-based data platform – a “system of systems” that brings together data and capabilities from a wide range of sources. The best way to understand its architecture is as a “digital lighthouse.” It doesn’t “steer the ships”; it ingests data from all around, processes it to identify dangers, and then broadcasts high-fidelity warnings to all operators, allowing them to navigate safely.

This architecture is built on three main components, each named with a fittingly expansive, horizon-themed-acronym: OASIS, SKYLINE, and HORIZON.

A Modern, Cloud-Based Foundation

Before examining the components, it’s important to understand the philosophy of the system’s design. TraCSS is not a typical, 1990s-era “big government” IT program. It’s a “modern, cloud-based IT system” built from the ground up on a “modular… architecture.”

This is its single greatest technical advantage. The system runs on commercial cloud infrastructure – specifically, Amazon Web Services (AWS). It is being built by a commercial system integrator, Parsons Corporation, using an “Agile software development program.”

This “Agile” approach means the system is not being built in one go, with a 10-year development plan. Instead, it is being developed through “iterative upgrades.” This allows the OSC to field a “minimum viable product,” get it into the hands of real users, and then “field successive upgrades” to add new capabilities based on real-world feedback. This “crawl, walk, run” method is faster, more flexible, and more responsive to the rapidly changing needs of the space industry.

The “modular” design is equally important. It means the system is built like a set of “Lego bricks” with well-defined interfaces. This “fosters a competitive environment” by allowing “third-party capabilities” and “commercial space services” to be “plugged in” or “replaced” as technology improves.

This is a revolutionary departure from a traditional, monolithic government system. It’s the difference between a 1980s mainframe, where all the code is 20 years old and impossible to update, and a modern smartphone. TraCSS is being built as the “smartphone” (the platform), and its architecture allows it to run an “app store” (which is SKYLINE) of the best, most innovative tools the commercial market can produce. This design ensures the system can evolve and scale to meet the challenges of the future.

OASIS: The Data Lake

TraCSS-OASIS is the foundation of the entire system. It is the “data repository,” or “data lake.” Its sole function is to “ingest, archive, process, and disseminate” all the raw data needed for space situational awareness.

This is the “data fusion” hub. OASIS is being designed to “blend” data from all available sources to create a single, unified picture of the space environment that is more accurate and comprehensive than any of its individual inputs.

The four primary data streams flowing into OASIS are:

1. Department of Defense (DoD) Data: The “bedrock” of the system. This is the high-accuracy data from the DoD’s global “Space Surveillance Network” of powerful, military-grade radars and telescopes. This data serves as the foundational catalog.
2. Commercial SSA Data: The “augmenting” data. The OSC is actively purchasing data from a new generation of commercial space surveillance companies that operate their own private networks of radars and optical telescopes. This data adds resilience and, in some cases, higher-fidelity or more rapidly updated tracking.
3. Operator Ephemerides: The “intent” data. This is the most valuable input. OASIS ingests positional data and, most importantly, planned maneuver data directly from satellite operators (like SpaceX, Iridium, and Amazon). This is the only way the system can know an operator’s intent, which is the key to eliminating false-positive alerts.
4. International Partner Data: The “global” data. OASIS is designed to ingest data from allied international “hubs,” such as the European Union’s EUSST system, creating a global, cooperative picture.

A key technical detail illustrates the power of this model. TraCSS relies on the DoD’s raw catalog data (its sensor readings), but it does not use the DoD’s collision warnings (its CDMs). This is intentional. TraCSS generates its own CDMs.

It ingests the “raw” DoD data, “blends” it in OASIS with the highly accurate commercial data and the operator “intent” data, and then runs its own superior analysis (in SKYLINE) to produce a better, more reliable warning. The “data fusion” in OASIS is the secret sauce that enables a more accurate, timely, and actionable service than the legacy DoD system could ever provide.

SKYLINE: The Application Engine

If OASIS is the “data lake,” TraCSS-SKYLINE is the “application engine” that runs on top of that data. It’s the “brain” of the operation.

SKYLINE is the “application hosting service” or “SSA application layer.” This is where the actual “mission services” and “software applications” live. These applications, which can be developed by the government or (more often) procured from “third-party” commercial vendors, are the tools that do the work.

They reach into the OASIS data lake, pull the fused data, and perform the calculations. The most important “app” in SKYLINE is the Conjunction Assessment (CA) engine. This is the software that screens the entire catalog of objects, identifies potential “close approaches,” and calculates the probability of collision.

When the CA engine finds a high-risk event, it automatically generates the “Conjunction Data Message” (CDM) and sends it to the operator.

The brilliance of the SKYLINE architecture is its modularity. The OSC is not trying to invent the world’s best collision-avoidance algorithm from scratch. Instead, SKYLINE is an “app store” for space safety. This modular, “plug-and-play” architecture allows the OSC to host a competitive environment of applications.

As the commercial SSA industry develops new, faster, or more accurate algorithms, the OSC can test them and “plug” the “best-of-breed” solution into SKYLINE. This ensures TraCSS can always be “state of the art” and “continuously improve” by integrating the best innovation the private sector has to offer, all without having to rebuild the entire system.

HORIZON: The Research and Development Sandbox

The final component, TraCSS-HORIZON, is the system’s “development and experimentation testbed,” or “sandbox.” It is a “modeling, simulation, & research environment” that is deliberately separated from the live, operational OASIS and SKYLINE components.

Any 24/7 public-safety system has a core problem: innovation is dangerous. You can’t just “try new code” on a system responsible for the safety of billions of dollars in assets. A single bug could be catastrophic. This is why legacy government systems are often so slow to update.

HORIZON is the elegant, architectural solution to this problem. It is a “test track” where the OSC can safely test, validate, and develop new capabilities before they are “graduated” to the operational system.

This is where the “Crawl, Walk, Run” philosophy is put into practice. The OSC uses HORIZON to run its “pathfinder studies.” For example, if the OSC wants to test data from five different commercial SSA companies, it can run a “bake-off” in HORIZON. It can feed all five data streams into the sandbox, compare them against the “gold standard” DoD data, and use independent quality-monitoring tools to “assess the accuracy, consistency, and quality” of each one.

After months of testing, the OSC can prove which commercial data streams are reliable enough for operational use. Only then are they “plugged in” to the live OASIS data lake.

This testbed is a joint effort. The Office of Space Commerce is “partnering with NASA on the R&D component.” NASA, with its deep scientific expertise, manages a partition of HORIZON dedicated to “advancing the state of the art in SSA” and fostering innovation from the academic community. This provides a direct pipeline for cutting-edge science, not just commercial products, to be vetted and integrated into TraCSS.

HORIZON is the “engine” of TraCSS’s evolution. It allows the system to innovate rapidly while never risking the safety of the live, operational mission.

From Policy to Practice: Building and Deploying TraCSS

Translating the ambitious policy of SPD-3 and the sophisticated architecture of OASIS, SKYLINE, and HORIZON into a functioning, operational system is a massive undertaking. The Office of Space Commerce has adopted a methodical, phased, and transparent “Crawl, Walk, Run” approach. This strategy is designed to manage the immense risk of the transition, build trust with users, and incrementally add capabilities as they are proven, all while ensuring there is no “gap” in space safety services.

The Phased Rollout: A ‘Crawl, Walk, Run’ Approach

The core challenge of the TraCSS program is replacing a system that, while imperfect, is the global standard. The entire world’s satellite operators are accustomed to receiving data from the DoD’s Space-Track.org. OSC can’t simply “flip a switch” and turn off the old system. A “gap in service” is not an option when a collision could occur at any moment.

For this reason, TraCSS is being deployed in a “phased… development approach” designed to “minimize disruption” and ensure a “smooth offloading” of responsibility from the DoD. This is an “Agile” software program, where the system is fielded in a series of iterative “Program Increments” (PIs).

The “Crawl” phase was the launch of a “minimum viable product” (MVP). This initial version was given to a small, select “beta group” of expert users. The OSC is now in the “Walk” phase, where it is gathering real-world feedback from these users and “fielding successive upgrades” to fix bugs, add new capabilities, and improve performance. The final “Run” phase will be the full production release, when the system is declared fully operational and all civil and commercial users are migrated to the new platform.

This deliberate, parallel approach is a critical risk-management strategy. For much of the transition, operators are receiving safety data from both the old DoD system and the new TraCSS system. This “dual-track” operation allows OSC to validate TraCSS’s performance against the existing “gold standard.” It also allows operators to “get comfortable” with the new system’s data and interface, building the user-trust that is essential for its success.

Phase 1: The On-Orbit Conjunction Mission

Phase 1 of the TraCSS program is the “Crawl” and “Walk” portion. It is focused entirely on the single most urgent mission: providing “on-orbit basic SSA/STC data and safety services” – in other words, preventing collisions for satellites that are already in space.

The “Phase 1.0” rollout, the system’s “go-live” moment, was achieved on schedule on September 30, 2024. This was a major milestone, marking the first time the Department of Commerce officially delivered space traffic safety services.

This initial capability was rolled out to a “beta group” of nine major satellite operators, including legacy giants like Intelsat, Iridium, and Telesat, as well as new “mega-constellation” operators like Eutelsat OneWeb and Planet Labs. This beta group has since expanded to include the two largest LEO players: SpaceX (Starlink) and Amazon (Project Kuiper).

As of late 2025, this beta program, while still in its “walk” phase, is already providing spaceflight safety screening services for operators who manage over 8,000 spacecraft. This single group represents nearly 80% of all active space objects worldwide.

The “Program Increments” of Phase 1 show a clear, logical progression of capability:

• PI 1.0 (September 2024): This was the “crawl” step. TraCSS officially began ingesting the DoD catalog and generating its own collision alerts (CDMs). To ensure a smooth transition, these initial alerts were delivered to the beta users through the old Space-Track.org website they were already familiar with.
• PI 1.1 (December 2024): The system was moved from its development environment to its final “production” cloud infrastructure, run by system integrator Parsons.
• PI 1.2 (May 2025): This was a major “walk” upgrade and a significant advancement for space safety. This release introduced two new capabilities:
  1. On-Demand Screening: For the first time, an operator (like SpaceX) could electronically submit its planned maneuver (its ephemeris) to TraCSS. The system could then screen this new trajectory against the entire space catalog and return a “safety check” in “two to five minutes.” This is a revolutionary improvement from the hours it historically took to get a new analysis from the DoD.
  2. Bulk Submissions: This new capability allowed “large constellation” operators to submit thousands of ephemerides at once, a feature essential for managing fleets like Starlink.
• PI 1.3 & 1.4 (Late 2025): These increments are focused on rolling out the final “presentation layer” – the new TraCSS.gov website – and onboarding all remaining pilot users in preparation for the “run” phase.

The “run” phase – the full, public Production Release of TraCSS Phase 1 – is scheduled for January 2026. At this point, the system will be declared fully operational, and the OSC will begin the process of migrating all civil and commercial users from the legacy Space-Track.org to the new, modern TraCSS.gov platform.

The main product that TraCSS generates and delivers is the “Conjunction Data Message,” or CDM. This is the “workhorse” of the entire system.

A CDM is a “standardized notification” or “alert” that describes a “potential close approach” between two space objects. It is a highly structured data file, not a simple email. It is designed to be read by computers and to provide a satellite operator with all the precise, actionable information they need to make a “maneuver or don’t maneuver” decision.

A single CDM answers the critical questions:

• Who: It identifies the two objects at risk (e.g., “your satellite” and “defunct rocket body X”).
• When: It provides the exact “Time of Closest Approach” (TCA).
• How Close: It details the predicted miss distance (e.g., 200 meters) and, just as importantly, the uncertainty in that prediction.
• What’s the Risk: It provides a calculated “Probability of Collision” (Pc).

This standardization is perhaps the most important, and most overlooked, aspect of the system. The OSC is not inventing this format. It is building its CDM product on “common, internationally recognized standards,” specifically those developed by the Consultative Committee for Space Data Systems (CCSDS).

The CDM is the lingua franca of global space safety. By adopting the CCSDS standard, the OSC is ensuring that a CDM generated by TraCSS in the United States “speaks the same language” as a CDM generated by the European Union’s EUSST system. This removes all ambiguity in a high-stakes situation. When two different operators are analyzing a risk, they are looking at the same data in the same format.

This “plumbing” of international coordination is essential. It’s what allows different regional “hubs” to exchange data seamlessly and ensures that an operator (like Intelsat, which is part of the beta for both systems) doesn’t get conflicting or confusing information.

Future Phases: Launch Safety and Re-entry

The “Crawl, Walk, Run” plan does not stop at Phase 1. The OSC’s vision for TraCSS is to manage the entire lifecycle of a space object, from “cradle to grave.” Once the “run” phase of the on-orbit mission is stable, the program is planned to expand to two new, essential services.

Phase 2: Launch Collision Avoidance (COLA)

This phase is planned to focus on “launch collision avoidance services,” or COLA. This service will screen a rocket’s planned trajectory before and during its launch. It will analyze the rocket’s path as it ascends through the crowded LEO environment to ensure it doesn’t fly through a debris field or come dangerously close to an active satellite. This provides a “safe launch window” for operators. The OSC is already doing early-stage work on this capability, running a “Commercial COLA Gap Pathfinder” to study the problem and signing a research agreement with SpaceX to develop advanced screening techniques.

Phase 3: Re-entry Assessment

This phase will focus on “reentry assessment and management.” This involves the other end of a satellite’s life. The service will track large, non-maneuverable objects (like old rocket bodies or dead satellites) as their orbits naturally decay. It will use the OASIS data to provide more accurate predictions of when and where these large objects might re-enter the Earth’s atmosphere, providing more timely and reliable warnings for public safety.

This three-phase plan shows a holistic, long-term vision. Phase 1 solves the most urgent problem (on-orbit collisions). But a truly comprehensive space traffic system must also manage the “on-ramps” (launch, Phase 2) and the “off-ramps” (re-entry, Phase 3). This lifecycle approach is what separates a simple “conjunction alert service” from a true, sustainable “Traffic Coordination System for Space.”

A Public-Private Ecosystem

The most innovative feature of TraCSS is not its technology; it’s its business model. TraCSS is not a traditional, “big government” program where the government builds, owns, and operates everything. Instead, it is a hybrid, public-private ecosystem.

The Office of Space Commerce is positioning itself as a platform integrator. It is building the core, government-run “operating system” (the TraCSS platform) and then integrating a complex web of stakeholders. This model leverages the strengths of each player: the “gold standard” data and stability of the government, the speed and innovation of the commercial sector, and the real-world operational knowledge of the satellite operators themselves.

This ecosystem is defined by three key partnerships.

The DoD: An Enduring Partner, Not Just a Predecessor

The Department of Defense is not “handing over” the mission and walking away. It is “working side-by-side” with the Department of Commerce to “ensure the seamless transfer.” The DoD’s role is simply shifting from being the public-facing service provider to being the foundational partner and a key customer of the new system.

First, the DoD remains the most important data provider. The DoD’s “worldwide space surveillance network” is a collection of powerful, high-accuracy sensors that is unmatched in the world. This data forms the “bedrock” of the TraCSS-OASIS data lake. It is the high-fidelity “ground truth” that all other data sources are measured against. An automated data pipeline has been established to get this “High Accuracy Catalog” from the DoD to TraCSS in near-real-time.

Second, in what has been described as “not a one-way street,” the DoD “is going to be a TraCSS user” itself. This creates a brilliant, symbiotic data loop that benefits both parties.

The logic is as follows: A commercial operator, like SpaceX, has sensitive, proprietary “ephemeris” data (its planned maneuvers). It is unwilling to provide this “intent” data directly to the DoD, a military organization. However, it is willing to provide it to TraCSS, a civil agency, in order to receive its safety services.

TraCSS, as the civil integrator, “ingests” this rich feed of commercial operator data. The DoD, as a “user” of TraCSS, now gets rule-based access to this unified data feed.

This is a “win-win-win.”

1. The operator (SpaceX) wins because it gets faster, more accurate “on-demand screening” (from PI 1.2) that reduces its false-positive alerts.
2. The civil system (TraCSS) wins because it gets the “operator intent” data it needs to create a high-fidelity traffic picture for all users.
3. The military (DoD) wins because it gains unprecedented visibility into commercial operator plans – data it could never get on its own. This makes the DoD’s own job of “space domain awareness” much easier, as it no longer has to “re-discover” a commercial satellite that has maneuvered. It allows the Space Force to focus its powerful sensors on actual national security threats (the “unknowns”) instead of wasting time trying to find “known” commercial assets.

The Commercial Data Providers

A core objective of SPD-3 and the OSC is to “encourage US Commercial SSA leadership” and “rely on commercial SSA providers to the greatest extent possible.” TraCSS is being deliberately designed with “on-ramps for commercial data, services, software, and innovation.”

The OSC is acting as a “smart buyer” and “integrator,” not a builder. It is using the “pathfinder” projects run in the HORIZON “sandbox” to test and “bake-off” commercial capabilities before they are integrated into the live system.

This “Consolidated Pathfinder” has resulted in contracts with a diverse set of companies, each specializing in a different part of the problem. This creates a resilient, multi-vendor marketplace.

• Commercial Data Collection: The OSC has purchased data from LeoLabs, which operates a global network of advanced radars to track objects in LEO, and Slingshot Aerospace, which operates a global network of optical telescopes. This “dissimilar sensor” approach (radar + optical) provides a more robust and complete tracking picture than either could alone.
• Commercial Data Fusion: The OSC has also contracted with COMSPOC (a division of Analytical Graphics, Inc.) for its “enterprise catalog maintenance” services. This is a commercial algorithm that can take in data from multiple sources (like DoD, LeoLabs, and Slingshot) and “fuse” it into a single, high-quality catalog of objects and their orbits.
• Independent Quality Control: In its savviest move, the OSC also hired two other companies, Kayhan Space and SpaceNav, to act as independent evaluators. Their one and only job is to “assess the accuracy, consistency, and quality” of the data products being delivered by LeoLabs, Slingshot, and COMSPOC. To ensure their independence, these “quality monitoring” companies are disqualified from competing for the “data provider” contracts.

This public-private model is the blueprint for TraCSS’s future. The “official” TraCSS catalog will be a hybrid product, where the “gold standard” government (DoD) data is “blended” with multiple, validated commercial data streams to create a “single source of truth” that is more resilient, more accurate, and more rapidly refreshed than any single system could be on its own.

The Satellite Operators: From Data Takers to Active Participants

The final, and most important, piece of the ecosystem is the end-user: the “civil and private space operators.” The TraCSS beta program already includes virtually every major name in the industry: Iridium, Eutelsat OneWeb, SpaceX, Maxar, Planet, Intelsat, Telesat, and Amazon Kuiper. This group alone accounts for nearly 80% of all active satellites.

Under the old DoD model, operators were passive recipients of data. They waited for Space-Track.org to send them a warning. The TraCSS model, as envisioned in SPD-3, requires them to be active participants.

The “new deal” is simple: to get the best service from TraCSS, operators must provide their own “owner-operator ephemerides” (their location and maneuver plans) to TraCSS.

This creates a powerful “virtuous cycle” of data sharing – a “Waze-for-Space” model that benefits everyone. This model, which was impossible under the “distrusted” military system, is the key to solving the space traffic problem:

• Step 1: SpaceX wants to move a Starlink satellite. It submits its planned maneuver data to TraCSS’s “on-demand screening” service.
• Step 2: TraCSS ingests this “intent” data into OASIS. Within minutes, its SKYLINE “app” screens the new path against the entire fused catalog (DoD data + commercial data + other operators’ data).
• Step 3 (The Operator’s Benefit): SpaceX gets a high-confidence “all clear” or “potential conflict” alert before it even makes the burn. This also stops TraCSS from sending SpaceX “false positive” alerts based on its old, pre-maneuver path.
• Step 4 (The Ecosystem’s Benefit): Now that TraCSS knows SpaceX’s plan, it also stops sending false alerts to other operators (like OneWeb or Amazon) who might have been on a (now non-existent) collision course with SpaceX’s old path.

By sharing their data, each individual operator makes the entire system more accurate. A more accurate system gives them fewer false positives and more reliable, actionable alerts. This “crowdsourcing” of a high-fidelity picture of LEO, facilitated by a trusted civil integrator, is the core brilliance of the TraCSS public-private model.

Politics, Funding, and the Fight for Space Safety

The development of TraCSS has not been a simple, linear story of technical progress. As a high-profile government program that sits at the junction of national security, public safety, and a multi-billion-dollar commercial industry, its path has been fraught with political, ideological, and financial challenges.

Just as the system was proving its technical viability, it was very nearly terminated by a political battle over its fundamental purpose: is space safety a “public good” provided by the government, or a “private service” to be purchased on the open market?

A System on the Brink: The FY2026 Budget Controversy

After years of slow progress due to congressional skepticism and funding delays (the OSC didn’t receive its first dedicated, significant appropriation for TraCSS until Fiscal Year 2023), the program hit its stride. It was fully funded in FY24 and FY25, allowing it to hire the system integrator (Parsons), build the cloud platform (on AWS), and successfully launch the Phase 1.0 beta service on schedule in September 2024.

The system was working. The “crawl” phase was a success, and the “walk” phase (PI 1.2) had just delivered a major new capability (“on-demand screening”) to operators representing 80% of all active satellites.

Then, in a stunning “about-face” from the very administration that created TraCSS via SPD-3, the White House’s FY2026 budget proposal called to “terminate” the program.

The budget proposed “zeroing out” TraCSS funding, slashing the entire Office of Space Commerce budget from approximately $65 million in FY25 to a skeleton-crew level of just $10 million in FY26.

The administration’s stated rationale was that the private sector had “demonstrated it can provide” these services. The argument was that the goals of SPD-3 had been met because a commercial SSA market now existed. Ironically, the administration was using the success of TraCSS’s own “Consolidated Pathfinder” projects – which had successfully vetted commercial data providers like LeoLabs and Slingshot – as the justification to cancel the government integrator that was coordinating them.

This budget crisis was not a debate over $60 million. It was a fundamental, philosophical war over the very definition of space safety. The administration’s proposal endorsed a “purely private” model, where collision avoidance would be a fragmented “pay-for-service” market. This would be, as some critics noted, like having “no FAA,” where “every airline tracks only its own planes” and collision alerts are a patchwork of competing, for-profit vendors.

A United Front: Industry and Congress Push Back

The backlash to the proposed cut was immediate, “wide,” and – most importantly – unified. The very public-private ecosystem that TraCSS had spent years building rallied to save it.

The Department of Defense: The military, the very organization TraCSS was designed to “relieve,” was one of the first to oppose the cut. A U.S. Space Operations Command (SpOC) spokesman publicly stated that they “continue to advocate” for the SPD-3 model. The DoD’s logic was clear: if TraCSS is canceled, the “mission will fall back to the Space Force.” This would pull their resources and personnel away from their core national security mission, re-burdening them with a civil safety job they had just successfully “offloaded.”

The Commercial Industry: The administration argued the “private sector” was ready, but the private sector itself disagreed. A broad coalition of “seven aerospace industry associations,” representing over 450 companies (including the Satellite Industry Association), wrote to Congress, “urging” them to fund TraCSS. Their argument was that a “private-only” model is chaos. They need a single, trusted, “inherently governmental” partner to act as the neutral integrator, to fuse all data streams, to be the “single source of truth,” and to be the official U.S. government entity that coordinates with international bodies.

Congress: Appropriators on Capitol Hill, hearing this unified message from both the DoD and the commercial industry, “rejected” the administration’s proposal. The Senate Appropriations Committee, in its report, “directly disagreed” with the White House’s rationale. It stated in no uncertain terms that SSA and STM are “inherently governmental” functions.

The result was a powerful reversal. Congress restored the program’s funding. The Senate bill proposed $60 million for OSC to “continue expanding the operational capabilities of TraCSS,” while the House proposed $50 million.

This political “near-death experience” was the single greatest validation of the TraCSS public-private model. The administration argued that the “private” half of the ecosystem made the “public” half obsolete. But the private sector itself argued that they were not mutually exclusive. They were partners in a symbiotic ecosystem, and that the private sector’s success was dependent on a stable, competent government integrator.

The Challenge of International Trust

Beyond the technical and financial hurdles, the greatest long-term challenge is one of trust. Space is global. A U.S.-only traffic system is, at best, a partial solution. But for a global system to work, all operators – commercial and sovereign, from Europe, Japan, India, and elsewhere – must be willing to share their most sensitive operational data.

For decades, this was a non-starter. The only high-fidelity data source was the U.S. military.

This “poisons diplomacy.” A European satellite operator (like Eutelsat OneWeb) or a sovereign agency (like the Indian Space Research Organisation) is understandably “unwilling” to “trust the military of a foreign government.” They are not going to send their proprietary, high-value satellite maneuver plans to the Pentagon, where they fear it could be used for military intelligence or surveillance.

This “distrust” creates a “strategic dilemma” that has been the single biggest barrier to a truly safe, coordinated space environment.

This is precisely the problem that the civilian nature of TraCSS is designed to solve.

The move to the Department of Commerce and NOAA was a powerful diplomatic signal. A civil, science-based agency like NOAA – which already has decades-long, trusted data-sharing relationships with every weather service in the world – is a far more neutral and acceptable partner. International operators are much more willing to share their “ephemerides” with the “U.S. weather service” than with the “U.S. Space Force.”

The civilian, transparent, and open-data nature of TraCSS is its most powerful diplomatic tool. It is the key to unlocking the critical international and commercial data that the DoD could never get. It solves the data-sharing “prisoner’s dilemma” that has plagued space safety for decades, allowing the U.S. to become an “open partner” and a global leader in space sustainability.

The Global Vision: TraCSS as an International Standard

The ultimate “endgame” for TraCSS is not to be a standalone, proprietary American system. The OSC’s “Vision for Global SSA Coordination” is not for one system to “rule them all.” Instead, the vision is for a federated network – a “global, coordinated system of SSA providers” with “a series of national or regional hubs” all working together.

In this future, TraCSS would be the U.S. “hub.” Europe’s EUSST would be its hub. Other nations would run their own. And all these hubs would be “speaking the same language” and sharing data seamlessly to create a “system of systems” that provides a unified, reliable safety picture for all operators, everywhere.

This long-term vision is being built on three pillars: a transparent data policy, active international diplomacy, and a commitment to common technical standards.

The TraCSS Data Policy: A New Standard in Transparency

To build the trust required for this global network, the OSC has established a data policy built on “openness and transparency.” Released in March 2025, the TraCSS Data and Information Policy is a foundational document.

It states that the “majority of data, information, and products generated… by the TraCSS system will be made public.” This open-data approach is designed to:

• Promote Safety: Allowing all operators, academics, and researchers to access and analyze basic safety data.
• Support the Commercial Sector: This is a key “pro-growth” component. The policy’s goal is to allow commercial companies to take the “free” basic data from TraCSS and “build on” it. They can use this government-provided “feed” to create their own “innovative new products and services” – for-profit, value-added services like advanced risk-analysis, mission-planning software, or satellite-insurance products.

This policy is paired with a legally essential “User Agreement.” This agreement specifies that the TraCSS service is provided “as is” and “without any warranties,” including any guarantee that the data will be “error free” or that access will be “uninterrupted.”

This “as-is” clause is not a “bug”; it’s the legal cornerstone of the entire public-good model. The U.S. Government retains sovereign immunity and “is immune from any suit” arising from the use of TraCSS data.

This waiver is what makes the “free of direct user fees” mandate possible. If the U.S. government could be sued for billions by a company (“Your free warning was wrong, and my $500M satellite is dead”), the entire TraCSS model would be legally and financially unviable. The government is not becoming an “insurer” or “mission control” for private companies. It is providing a “digital lighthouse”: a free, public data feed that all “ships” (satellites) can use to navigate at their own risk. This “as-is” clause is the legal foundation that enablesthe “open data” policy and the entire “public good” service.

Building Bridges: Coordinating with EUSST and COPUOS

The OSC is not waiting until TraCSS is “finished” to start its diplomacy. It is “co-developing” the system with its international diplomacy, ensuring technical and political interoperability from day one.

The OSC is an active participant in all major international space forums. This work is twofold:

1. Bilateral Coordination (EUSST): The OSC is in “close collaboration” with its direct counterpart, the European Union’s Space Surveillance and Tracking (EUSST) program. The two organizations are running “joint studies” to compare their services and test how they can best “improve results when combining U.S. and European SSA information.” This is the practical, hands-on work of building the “federated network” and ensuring operators don’t receive “conflicting information” from the two hubs.
2. Multilateral Diplomacy (UN COPUOS): The OSC is an active participant in the United Nations Committee on the Peaceful Uses of Outer Space (COPUOS). This is the diplomatic “top-level” where the global “rules of the road” are written. The OSC’s work in COPUOS is to align the TraCSS mission with the UN’s “Guidelines for the Long-term Sustainability (LTS) of Outer Space Activities,” which form the diplomatic basis for global data sharing and conjunction assessment.

This parallel “tech + diplomacy” development is the only way to ensure the final system is not just technically sound, but politically and internationally trusted.

Fostering Common Standards: The Role of CCSDS and ISO

For a “global coordinated system” of “regional hubs” to work, everyone’s computers must be able to talk to each other. This requires “common, internationally recognized standards.”

This is the final, technical pillar of the global vision. Instead of creating a new, proprietary, “Made in the USA” data format, the OSC made the strategic decision to adopt existing, open, international standards.

The two key standards organizations are:

• CCSDS (Consultative Committee on Space Data Systems): This is the “most widely adopted standard in the SSA community today.” The TraCSS Conjunction Data Message (CDM) is built on this open, voluntary, consensus-based standard.
• ISO (International Organization for Standardization): This body provides complementary standards for space systems.

This choice is a powerful diplomatic statement of cooperation over control.

The OSC could have tried to create a proprietary “TraCSS format” and used its market power (with 80% of operators in its beta) to force the world to adopt it. It explicitly chose not to.

By choosing to build its system on the existing international CCSDS standard, the U.S. is signaling that TraCSS is intended to be a partner in a global network, not the center of it. This lowers the barrier to entry for international partners (like EUSST) and commercial industry, reinforcing the core message of “transparency,” “openness,” and “collaboration.” It’s the technical-diplomatic equivalent of showing up to the United Nations and choosing to speak the common, shared language.

Summary

The region of space surrounding our planet has changed. What was once a vast, empty frontier has become a congested, complex, and hazardous operational environment, stressed by decades of legacy debris and the explosive growth of a new commercial space economy. The old way of managing this domain – a passive, military-run catalog – is no longer sufficient to protect the future of space.

The Traffic Coordination System for Space (TraCSS) represents a fundamental and necessary evolution. It is the tangible implementation of a new U.S. national policy, one that re-defines basic space safety as a civil-led, public good, essential for promoting economic growth and ensuring long-term space sustainability.

The strategic transition of this mission from the Department of Defense to the Department of Commerce’s NOAA is a “win-win-win.” It unburdens the military to focus on its core national security mission. It places the 24/7 public safety service in the hands of a trusted, experienced civil agency. And, most importantly, it unlocks a new era of international and commercial cooperation by creating a transparent, neutral “digital lighthouse” that all operators can trust with their data.

The system’s innovative, cloud-based, and modular architecture (OASIS, SKYLINE, HORIZON) creates a flexible “public-private ecosystem.” TraCSS is not a monolithic government tool. It is a “system of systems” that expertly integrates the “gold standard” data of the DoD, the speed and innovation of the commercial SSA industry, and the invaluable “intent” data from satellite operators themselves. This “Waze-for-Space” model creates a virtuous cycle, where sharing data makes the entire system smarter, which in turn provides better, more actionable alerts to all.

Despite facing significant political and financial turbulence, the TraCSS program has been validated by the unified support of its key stakeholders – the military and the commercial industry. Its “Crawl, Walk, Run” rollout is on schedule, with the system already safeguarding 80% of the world’s active satellites and on track for a full public release in January 2026.

TraCSS is more than just an American “collision avoidance” system. It is the foundational node of a new, global “system of systems.” Through its commitment to an open-data policy, active international diplomacy, and common technical standards, TraCSS is laying the groundwork for a future where all space-faring nations and companies can coordinate their activities seamlessly – the essential, sustainable infrastructure for the next 50 years of the space economy.