The P25 decision is not a radio purchase. It is a 20-year infrastructure commitment.
From the engineering side, P25 is one of those topics where the marketing language is technically true but operationally incomplete. Yes, P25 is an open public safety radio standard. Yes, it was designed to improve interoperability. Yes, multiple vendors can build P25-compliant equipment. An agency does not deploy “a standard.” It deploys tower sites, controllers, master sites, consoles, subscriber units, microwave, encryption, key management, interfaces, governance, maintenance contracts, mutual aid procedures, and vendor roadmaps.
That is where the real decision lives.
A public safety agency thinking about P25 in 2025 or 2026 is not asking, “Which radios should we buy?” It is asking a much larger question, whether the agency's leadership has named it that way or not. What communications architecture are we willing to live with, pay for, defend, and depend on for the next 15 to 20 years?
Most RFPs do not ask that question clearly enough. This Insight is about why that matters, what most agencies misunderstand about P25, where the real costs hide, where interoperability still breaks, when broadband convergence changes the calculation, and what the audit-defensible P25 procurement looks like in 2026.
What P25 Is, And What It Is Not
P25, or Project 25, is a suite of standards for public safety land mobile radio systems. APCO describes Project 25 as defining the system interfaces used to build P25 communications networks, with the TIA-102 standards defining the messages and procedures required for P25 features to operate across those interfaces. The important nuance for any agency about to issue an RFP is in those two sentences. Project 25 does not define equipment. It defines messages, procedures, and interfaces.
That distinction matters because a vendor can sell P25-compliant equipment while still creating a highly vendor-specific operational environment.
P25 supports different system types. The Project 25 user-needs documentation identifies P25 conventional systems as FDMA Phase 1 only, while P25 trunking may be FDMA Phase 1 or TDMA Phase 2. Phase 1 uses 12.5 kHz traffic and control channels. Phase 2 trunking uses TDMA to support two near-simultaneous conversations on a single 12.5 kHz channel.
The plain-language version. Phase 1 FDMA means one voice path per 12.5 kHz channel. Phase 2 TDMA means two logical voice paths inside one 12.5 kHz channel. Conventional means simpler channel-based operation, usually with less system intelligence. Trunked means a controller assigns channels dynamically across talkgroups and users.
The mistake agencies make is assuming “P25 compliant” means “everything will interoperate cleanly.” It does not always work that way.
NIST's P25 Compliance Assessment Program exists because interoperability claims needed an independent way to be tested. NIST has noted that some radios sold under the P25 label did not meet all standards requirements, and P25 CAP was developed to provide an independent compliance assessment process. The Department of Homeland Security manages the program, accredited labs perform the testing, and grant-funded purchases of P25 equipment are tied to CAP documentation requirements precisely because the label on the box has not always matched the behavior in the field.
That is the first thing an agency needs to understand before issuing an RFP. P25 compliance is the beginning of the technical discussion, not the end of it. The RFP needs to ask which P25 interfaces are supported, which features have been CAP tested, which interoperability profiles apply, what subscriber vendors have been tested, what encryption and key management features are supported, what ISSI and CSSI capabilities exist, and which features are standard versus proprietary.
P25 gives the industry a common language. It does not guarantee every vendor speaks that language with the same accent, the same vocabulary, or the same behavior under stress.
Why The P25 Conversation Is Happening Right Now
The timing is not accidental.
Many agencies are sitting on aging analog, legacy digital, SmartNet, EDACS, OpenSky, early P25 Phase 1, or hybrid systems that are reaching end of support. The old infrastructure is expensive to maintain. Replacement parts are harder to source. Radio shop personnel are aging out. Vendors are pushing modernization paths toward Phase 2, regional cores, hosted services, lifecycle service contracts, and integrated broadband offerings.
Several pieces of regulatory history still shape what agencies are looking at today.
The FCC narrowbanding deadline hit on January 1, 2013, when VHF and UHF public safety and business or industrial systems had to stop operating 25 kHz equipment and move to at least 12.5 kHz efficiency. That migration is old news now. It still explains why many agencies made earlier incremental moves instead of full architectural replacement decisions, and why the modernization debt is showing up in 2025 and 2026 as a larger bill than it would have been if a full system replacement had been done earlier.
The 800 MHz rebanding effort also shaped the current landscape. The FCC terminated the 800 MHz rebanding program in 2021 after more than 2,100 licensees relocated to new channels to address harmful interference caused by proximity to commercial cellular architecture. That program consumed years of public safety engineering bandwidth and channel planning effort that could otherwise have gone into modernization.
The T-Band uncertainty also affected major metropolitan agencies. Congress originally required the FCC to reallocate and auction public safety T-Band spectrum, but the Don't Break Up the T-Band Act later repealed that mandate. The FCC acknowledged in 2022 that the 2020 law repealed the T-Band mandate. That removed a near-term forcing function for the largest metro agencies, but it did not eliminate the long-term modernization pressure.
Now add the current technology pressure. FirstNet, LTE, 5G, and mission-critical push-to-talk.
The FirstNet Authority was created after September 11, 2001 to establish a nationwide public safety broadband network. Congress allocated 20 MHz of spectrum and $7 billion to create the network. The FirstNet Authority awarded AT&T a 25-year contract in 2017, and by 2024 announced plans to reinvest up to $8 billion over ten years to expand and evolve the network. That changes the conversation.
Agencies are now asking whether they should invest tens or hundreds of millions of dollars into a 20-year LMR system at the exact moment broadband voice, LTE coverage, FirstNet PTT, MCPTT, and 5G continue to mature.
The honest engineering answer is that LMR is not dead. The old assumption that every agency should solve every communications problem with more LMR infrastructure is no longer defensible.
Vendor Dominance And What It Does To The Agency
Motorola Solutions is the dominant P25 infrastructure vendor in the United States public safety market. L3Harris is the major second player, formed from the 2019 Harris and L3 Technologies merger that consolidated significant communications portfolios under one corporate roof. Tait Communications, JVC Kenwood, EF Johnson, JPS Interoperability, Zetron, and others have roles in specific market segments. Most agencies looking at major trunked P25 infrastructure are functionally looking at a very small competitive field.
I would be careful about citing an exact market-share percentage. From a practical engineering and procurement standpoint, the dominance is visible in the installed base, regional master sites, subscriber fleets, maintenance agreements, console integrations, programming infrastructure, encryption ecosystems, and radio-shop familiarity. Walk into a public safety radio shop anywhere in the country and the muscle memory is built around one or two vendor environments. The technicians know the toolsets, the programming software, the firmware behavior, the service procedures. That familiarity is real value. It is also a procurement variable that quietly tilts every future decision.
The effect is simple. Competition exists. It is not always equal competition.
A new vendor may technically meet P25 standards but still face a steep practical disadvantage if the agency is already inside a Motorola ASTRO ecosystem, a regional master site, a countywide Motorola subscriber fleet, or a shared maintenance model. The same dynamic applies in a Harris or L3Harris environment. The standards are open. The operational environment is not.
This is where agencies feel the ecosystem tax.
Public reporting in Orange County, California documented this pattern at scale. Voice of OC reported that the Orange County Motorola radio system, used by all county law enforcement agencies, had not received an independent review for fifteen years despite more than $100 million in costs over that period. Handheld radios were priced as high as $5,800 each. Motorcycle radios reached $9,200. The county was preparing to approve $29 million in additional no-bid contracts with Motorola to finish a $140 million project replacing 1990s-era equipment. That does not automatically mean the vendor was wrong or the county acted improperly. It shows exactly why long-term independent review matters. A radio ecosystem can become so embedded that the agency stops asking whether the price reflects value or simply reflects the absence of a realistic alternative.
The Palm Beach County OpenSky history is another important example, and it cuts in the other direction. The county Office of Inspector General reviewed the OpenSky acquisition and implementation, including planning, management, operability, maintenance, support, and federal, county, and municipal funds. Pennsylvania's PA-STARNet history is also instructive. The state auditor described Pennsylvania's prior OpenSky system as having nearly twenty years of unreliable performance before the move to P25. Those cases cut both ways. They show that proprietary or poorly governed radio decisions can become long-running operational burdens. They also show why agencies often swing back toward P25 and large incumbent vendors. When a public safety organization has been burned by a radio platform, reliability starts to matter more than theoretical competition. That is rational. It is also exactly the environment in which incumbent dominance compounds.
The question is not whether Motorola, L3Harris, or any other vendor can build a working P25 system. They can. The question is whether the agency still has enough leverage to make the vendor prove value, price fairly, document risk, and accept accountability.
What An Agency Is Really Committing To
A P25 migration is not a radio replacement. It is an infrastructure decision.
When an agency says “we are moving to P25,” it may be committing to all of the following: tower sites and leases. RF coverage design. Simulcast or multicast architecture. Master site equipment. Core controllers. Console subsystems. Dispatch positions. Microwave or fiber backhaul. Shelter, generator, UPS, HVAC, grounding, and site-hardening work. Subscriber units. Programming software. Fleet mapping. Talkgroup governance. Encryption. Key management facility. Over-the-air rekeying. ISSI connections. CSSI console integration. Logging recorder integration. CAD interface impacts. Mutual aid channels. NPSPAC planning. Maintenance contracts. Upgrade paths. Lifecycle refresh obligations.
That is one decision. It cascades for two decades.
The P25 Best Practice guide is direct that system architecture must be defined around coverage, capacity, resilience, interoperability, and dispatch operations, and that coverage engineering may be one of the most complex parts of radio specification and design. It also notes the common public safety objective of DAQ 3.4 voice quality at 95 percent reliability, which is where the design discussion gets very real, very quickly. Every percentage point of coverage costs money. Every additional site costs money. Every redundancy decision costs money. The architecture conversation is the budget conversation.
The three common migration paths are fundamentally different.
Building a new system from scratch
This gives the agency the most control but typically the highest capital burden. The agency must design the network, build or reuse sites, acquire or license frequencies, procure consoles, select subscribers, build governance, and operate the lifecycle. This path makes sense when the agency has unique coverage needs, cannot rely on a regional system, needs control over operations, or has the scale and funding to own the architecture.
Joining a regional system
This may reduce capital cost and improve interoperability. It also reduces control. The agency inherits regional governance, regional standards, vendor dependencies, talkgroup policies, cost-sharing models, upgrade schedules, and sometimes political constraints. The Santa Monica staff report is a useful example of a documented regional-interoperability case. The city described a two-phase interoperable trunked radio project that would allow participation in the ICIS Master Site and countywide communication on ICIS and LA-RICS systems. It documented replacement or upgrade of existing radios, CAD and logging interfaces, and site preparation. That is the kind of technical and operational basis that can justify a constrained procurement path.
Upgrading inside an existing vendor ecosystem
This is often the least disruptive path. It can also be the most lock-in-heavy. The agency may keep its radio shop workflow, subscriber fleet, programming tools, encryption strategy, and maintenance model. That may be reasonable. It may also mean the agency never receives a clean market test, never validates that the incumbent's pricing reflects current market value, and never builds the procurement file that would survive an audit.
The hidden costs in any of these paths are rarely in the headline contract. They live in the ten-year maintenance, subscriber refresh cycles, software upgrades, encryption licenses, console refreshes, site leases, microwave modernization, generator replacements, battery plants, warranty extensions, user training, programming support, and change orders. The total cost of ownership over fifteen years is often two to three times the initial capital expenditure. Agencies that do not model that number on the front end pay for the gap on the back end.
In a P25 migration, the radio is the visible purchase. The architecture is the real commitment.
Did P25 Solve Interoperability?
Partially. That is the honest answer.
P25 has absolutely improved interoperability compared with the pre-standard, proprietary, stove-piped environment that came before it. The standards, the common air interface, CAP testing, mutual aid planning, and interfaces like ISSI and CSSI have created real interoperability pathways that did not exist a generation ago. NIST states that P25 standards were developed so radios and components could interoperate regardless of manufacturer, and P25 CAP gives agencies a traceable way to verify compliance information for equipment they buy.
Operational interoperability is not the same as standards compliance.
ISSI, the Inter-RF Subsystem Interface, can connect P25 trunked systems across vendors and across jurisdictions. CSSI, the Console Subsystem Interface, can connect dispatch console subsystems to RF networks. Mutual aid channels can provide fallback voice paths. NPSPAC channels can support regional incidents. Regional systems can improve shared communication. None of those mechanisms automatically answer the operational question every incident commander eventually has to answer.
Can my dispatcher, my field units, my mutual aid partners, and my incident command structure communicate when the incident is moving, the radio system is loaded, the talkgroups are unfamiliar, encryption is active, and the people involved are under stress?
The gap lives in the operational details. Encryption key mismatches. Talkgroup governance differences. Incompatible fleet maps. Different radio templates. Training gaps. Dispatch patch limitations. Roaming rules. Console permissions. Optional P25 feature support. Vendor-specific implementation differences. ISSI and CSSI licensing constraints. Regional political boundaries. Overloaded systems. Coverage holes. Mutual aid users who do not know the plan, do not know the talkgroup name, and do not know which key to load. Every one of these gaps has been documented in after-action reports from major incidents going back twenty years.
Project 25's 2025 standards update shows that ISSI and CSSI interoperability and conformance testing remains active work, including new tests for vocoder combinations and supplementary data services. That is good progress. It also proves the point. Interoperability is still being refined, more than two decades after the standards work began.
Interoperability is not proven when two systems can connect in a lab. It is proven when two agencies can communicate during an incident without improvising the plan.
That is the test every interoperability decision should be measured against. Not the demo. Not the standards documentation. Not the marketing slide. The actual incident, with the actual people, on the actual day they need it.
FirstNet, LTE, And The LMR Question Vendors Do Not Want Asked
This is the question vendors do not want agencies asking too directly. Are we about to spend twenty-year money on an LMR system at the exact moment broadband voice is becoming operationally credible?
The honest engineering answer is not “replace LMR with FirstNet.” The honest engineering answer is more nuanced. LMR remains essential for many mission-critical voice environments. FirstNet and LTE push-to-talk are now mature enough that every P25 modernization should include a serious hybrid architecture analysis as part of the pre-RFP work.
FirstNet push-to-talk can extend and expand communications, integrate with LMR through gateways, help inside buildings where broadband often outperforms radio, reduce traffic on radio systems, and create redundancy across networks that fail differently. The FirstNet Authority frames PTT over FirstNet as supplementing LMR, describing it as another tool in the communications toolbox rather than a replacement. FirstNet's own product materials describe nationwide PTT, messaging, video, location services, mutual aid requests, LMR interoperability, dispatch console integration, and RoIP gateways that allow LMR and FirstNet PTT users to communicate.
Where is LTE and FirstNet viable as a primary or significant path?
It is increasingly viable for administrative users, command staff, emergency management coordinators, public works crews, utilities, school resource partners, event staff, volunteers, mutual aid coordination, non-emergency traffic, off-footprint communication, data and video and location and situational awareness, backup communications, and small agencies with excellent broadband coverage and lower tactical voice risk.
Where does LMR remain essential?
LMR remains essential for fireground operations where coordinated tactical voice is non-negotiable. Law enforcement tactical operations where direct, talkaround, off-network communication is required. Rural and remote coverage where LTE is weak. Hardened local control where commercial network dependencies are unacceptable. Simplex operations where infrastructure failure cannot interrupt voice. High-reliability dispatch voice that has decades of muscle memory behind it. Jurisdictions with proven LMR coverage and uncertain broadband coverage. Environments where device-to-device communication and immediate group voice are non-negotiable.
The best model for many agencies is hybrid. LMR for mission-critical group voice and tactical reliability. FirstNet or LTE for data, video, location, command coordination, mutual aid extension, non-primary users, redundancy, and selective PTT augmentation. The two networks have different failure modes. Building both into the agency's communications architecture means the agency can lose one and still operate on the other.
The mistake is treating this as a religious debate. It is an engineering decision. The agency that approaches the LMR-versus-broadband question with ideology pays for the ideology. The agency that approaches it with traffic analysis, failure-mode analysis, coverage analysis, and total cost analysis builds the right hybrid architecture for its actual operational profile.
The future is not LMR or LTE. The future is knowing which traffic belongs on which network, under which failure condition, and with which operational consequence.
P25 Procurement Traps
P25 procurement has its own set of traps. They are different from the general procurement traps covered in our procurement integrity Insights. They are specific to land mobile radio, and they are widely repeated across agencies that did not know what to look for.
Brand-name specifications dressed as technical requirements
An RFP may not say “Motorola only” or “Harris only,” but the specifications can still describe a single vendor's catalog. Subscriber features, programming tool requirements, encryption behavior, console integration assumptions, regional master-site requirements, and maintenance assumptions can be written so narrowly that competition is functionally eliminated without the document ever saying so. The procurement looks competitive on paper. It is not competitive in practice.
For federal grant-funded procurements, 2 CFR 200.319 requires full and open competition and warns explicitly against procurement practices that restrict competition. It also states that contractors who help draft specifications or requirements must be excluded from competing for the resulting procurement, to avoid creating an unfair competitive advantage. That standard is regularly violated when the incumbent vendor has been intimately involved in the agency's pre-RFP requirements work.
ISSI requirements that are really incumbent requirements
An ISSI requirement can be entirely legitimate. It can also be used to force a vendor path. The question is whether the ISSI requirement is based on documented operational interoperability needs that have been tested against actual incident scenarios, or whether it is being used to avoid evaluating alternatives. The difference is in the file. An agency that can produce the interoperability matrix, the talkgroup linkage analysis, the encryption posture, and the operational use cases that drive the ISSI requirement is on defensible ground. An agency that has “ISSI compatible with the regional master site” as a line item with no supporting analysis has built a brand-name spec.
Subscriber unit specifications that mirror the incumbent catalog
This is common. The RFP lists exact features that match the existing radio shop's preferred model. Sometimes the feature is genuinely needed for operational reasons. Sometimes it is familiar. The discipline is to validate which is which. Every subscriber spec should be traceable to an operational requirement. If the trace runs to “this is what we have always used,” the spec needs to be reworked or removed.
Regional system participation as a procurement shortcut
Joining a regional system may be the right answer. “The region uses this vendor” is not the same as “we have no procurement decision to make.” The agency still needs to document why joining that system is operationally necessary, what alternatives were considered, what costs are being accepted, what governance rights the agency gains or loses, and how the regional decision aligns with the agency's 15-year communications architecture. The Santa Monica case is a useful example of doing this work properly. The lazy version is treating regional system membership as a procurement bypass rather than a procurement decision in its own right.
Weak sole-source documentation
Noncompetitive procurement under 2 CFR 200.320 is limited to specific circumstances: true single-source availability, public exigency or emergency, written approval by the federal agency or pass-through entity, inadequate competition after soliciting an adequate number of qualified sources, or micro-purchase circumstances. Procurement records have to detail the history of the transaction, including procurement method rationale, contract type, contractor selection or rejection, and the basis for contract price.
A defensible P25 procurement file is built on evidence, not preference. It includes an operational needs assessment, current-state inventory, coverage analysis, capacity analysis, interoperability matrix, regional system analysis, LTE and FirstNet hybrid analysis, alternatives analysis, lifecycle cost model, vendor-neutral requirements language, P25 CAP documentation requirements, ISSI and CSSI requirements tied to operational use cases, subscriber equivalency language, encryption and key management requirements, an evaluation framework, demonstration and test scripts, a price reasonableness analysis, a traceability matrix, conflict-of-interest disclosures, and a sole-source justification if applicable.
The Santa Monica case is a useful example of a defensible sole-source posture because the staff report documented regional ICIS and LA-RICS connectivity, supported and unsupported equipment, interface impacts, and phased implementation costs. The lazy version sounds different. “We have always run Motorola, the radio shop wants Motorola, and the regional system is Motorola.” That may all be true. It is not enough.
A legitimate P25 sole source is built on documented interoperability, lifecycle, and operational constraints. A lazy P25 sole source is built on habit.
The Question Every P25 Migration Eventually Reaches
The uncomfortable question is this. Are we making the best communications architecture decision for the agency's next 15 years, or are we simply buying the most familiar path from the incumbent ecosystem?
That question breaks into several harder questions, and Sentinel coaches agencies to put every one of them on the table.
Does the vendor's pricing reflect value, or does it reflect the absence of meaningful competition?
Is regional system participation truly mandatory, or just politically easier?
Does the agency actually need Phase 2 now, or is it being pushed because Phase 2 fits the vendor's refresh cycle?
Are we replacing infrastructure because the mission requires it, or because support is being sunset?
Are we buying radios for every user who currently has one, or should some users move to LTE PTT?
Are we preserving LMR for mission-critical voice while offloading other traffic to broadband?
Is the radio shop recommending what is best for the agency, or what is familiar to the radio shop?
Do elected officials understand that this is a 15-to-20-year architecture decision, not a one-time capital purchase?
If the vendor changed tomorrow, would the agency still understand its own system well enough to govern it?
That last question is the one every P25 decision should pass. Can the agency explain and govern its radio architecture independently of the vendor?
If the answer is no, the agency does not have a radio strategy. It has a vendor relationship.
What Sentinel Does For An Agency Facing A P25 Migration
Sentinel does not arrive at a P25 conversation with a vendor preference. We arrive with engineering questions the agency has not been pushed to answer yet.
Our role on a P25 engagement is not to argue with vendors. It is to force the right engineering, operational, procurement, and governance questions to the surface before the agency locks itself into a 20-year decision. Five specific practices anchor this work.
Sentinel separates the standard from the system. We help agencies understand what P25 compliance actually means in their specific context, which interfaces matter for their interoperability profile, which vendor features are proprietary versus standards-based, which requirements are truly operational versus inherited from the incumbent environment, and which CAP-tested features should be required in the RFP. We do this work before the RFP is drafted, not after vendor proposals arrive.
Sentinel builds the pre-RFP engineering question set. Before the RFP is written, we help define the coverage requirements, the user groups, the talkgroup design principles, the mutual aid needs, the regional system obligations, the encryption and key management posture, the dispatch console needs, the CAD and logging and interface impacts, the LTE and FirstNet augmentation options, the lifecycle cost assumptions, and the procurement risks. That question set becomes the spine of the RFP and the spine of the evaluation framework.
Sentinel tests whether interoperability is real. We do not accept “interoperable” as a brochure word. We ask which systems, which talkgroups, which interfaces, which encryption keys, which consoles, which patches, which failover paths, which training programs, and which incident use cases prove the interoperability claim. The standard for a Sentinel-governed P25 procurement is that interoperability has to survive an incident, not just a vendor demonstration.
Sentinel keeps the procurement defensible. We help agencies avoid brand-name specifications disguised as technical requirements. We build traceability between operational need and technical requirement so the procurement file can withstand the inspector general, the council, the federal grant auditor, and the public records request. We preserve competition where competition is actually possible and we document the genuine constraint where it is not.
Sentinel gives leadership the honest architecture view. The goal is not to make the radio shop happy, the vendor happy, or the regional system happy. The goal is to give executive leadership a defensible answer to one question. What are we buying, why are we buying it, what alternatives did we consider, what are the long-term costs, and how does this decision support public safety operations for the next decade and beyond? The agency that can answer that question in fifteen minutes during a council session has built the file correctly. The agency that cannot has not.
This work runs through every Sentinel discipline. Sentinel Delivery Framework™ (SDF) governs the program management. Sentinel Readiness Method™ (SRM) governs the change management for the workforce that has to live with whatever the program delivers. Sentinel Value Assurance™ (SVA) governs the post-deployment work that holds the vendor accountable to the original commitments. The P25 procurement is the front door. The Sentinel framework is what makes sure the building still works fifteen years later.
Sentinel governs the architecture. We never sell the platforms. Independent. Practitioner-led. Vendor-neutral. Built for the radio shop, the dispatch console, the field unit, the regional partner, and the agency leadership that has to defend the decision after the contract is signed.
P25 Should Give Agencies More Control, Not Less
P25 remains one of the most important public safety communications standards in the country. It has improved interoperability. It has pushed the market toward standards-based equipment. It has helped agencies move away from isolated proprietary systems. None of that should be diminished, and Sentinel does not diminish it.
P25 is not magic.
It does not eliminate vendor lock-in by itself. It does not make every radio talk to every system under every condition. It does not answer whether an agency should build, join, upgrade, or hybridize. It does not decide how much LMR capacity an agency needs in a FirstNet and 5G world. It does not protect the agency from writing an RFP that quietly hands the award to the incumbent before the evaluation committee ever convenes.
That work still has to be done. It has to be done before the contract is signed. And it has to be done by someone whose loyalty is to the agency, not to the manufacturer whose logo is on the box.
If you are an agency facing a P25 decision in the next 18 to 36 months, the most important decision in front of you is not which vendor to choose. The most important decision is whether your procurement file, your interoperability strategy, your hybrid architecture analysis, and your governance posture will hold up when the auditor, the council member, the federal grant reviewer, or the public records requester eventually asks why you made the choice you made.
P25 should give agencies more control, not less. If the migration leaves the agency more dependent on one vendor, less clear about its architecture, and unable to explain its interoperability strategy without the vendor in the room, then the agency did not buy a standard. It bought a cage with a standards label on the door.
That is the difference Sentinel exists to make.