Raymond Osei is the chief AI officer for a state's executive branch. Last winter, a severe storm flooded three counties, and the governor's office wanted one thing: a single, current picture of who needed help and where. It did not exist. The emergency management agency had a damage-assessment AI. Health and human services had a vulnerable-populations registry. The transportation department had a road-closure model. All three worked. None of them could talk to each other. The damage model emitted addresses in one format, the registry used another, and the road model used map coordinates. Three teams spent 36 hours hand-copying data between spreadsheets to build a map the systems could have produced in minutes, had they been built to interoperate. Raymond watched a preventable crisis inside the crisis. His job now is to make sure the next storm finds his agencies wired to cooperate. This lesson is about AI interoperability: getting separately built government AI systems to share data, models and decisions safely across organizational lines.

A note on scope. The organizational side of this problem, the councils, the coordination bodies, the funding arrangements and the relationship work, is the subject of Cross-Agency AI Coordination, and that lesson is the companion to this one. What follows is the technical layer: the formats, interfaces, registries and controls that decide whether an agreement between two agencies can actually be executed by their systems.

Why Interoperability Is Hard in Government

The technical problem is real, but it is not the hard part. The hard part is that each agency is its own kingdom, with its own budget, its own data, its own legal authority and its own reasons to be cautious about sharing. Interoperability is 30 percent engineering and 70 percent agreement. Those two figures come from Raymond's own experience of the work rather than from a study, and they are worth holding because they predict where a project will stall. Teams staff the 30 percent generously and the 70 percent not at all.

The controlling analogy is shipping containers. Before the 1950s, every port loaded cargo its own way, and moving goods between ships, trains and trucks was slow, lossy and expensive. The standardized shipping container changed global trade not by inventing a new ship, but by agreeing on a box: fixed dimensions, standard corner fittings, anyone's crane could lift anyone's container. Government AI interoperability is the search for that box. The goal is not to merge agencies. It is to agree on the box, meaning the formats, the connections and the rules, so each agency keeps its own systems while they hand work to each other without a 36-hour spreadsheet relay.

Interoperability does not mean everyone uses the same system. It means everyone agrees on the same container, so different systems can hand things to each other safely. That distinction matters politically as well as technically, because an agency asked to adopt another agency's platform will resist, and reasonably so, while an agency asked to publish in a common format usually will not.

What You Lose When Systems Cannot Share

Consider a case the source material puts plainly. A federal agency builds an AI model to detect fraud. Another agency wants to use it for its own benefit fraud detection, and cannot. The model is deployed on a proprietary system. The interface is not documented. The model's underlying data is classified. And there is no agreement permitting sharing. Those four blockers are the interoperability problem in miniature, and notice that only two of them are technical. Multiply that by fifty agencies, each holding models that could be useful elsewhere, and the scale of the missed opportunity becomes visible.

Four costs follow. Duplicated effort: if every agency builds its own fraud detection model, the same problem gets solved fifty times, which is waste measured in budgets and in years. Weaker models: agencies that can properly share data train on larger datasets, and larger datasets generally produce better models. Slower adoption: when one agency solves a problem and cannot pass the solution on, every other agency pays to rebuild it. And weaker government overall, because citizens receive better service when multiple agencies can coordinate around shared AI rather than each holding a partial view.

Set against that, silos exist for reasons that are not stupid. Security, autonomy and accountability all argue for keeping systems separate, and each of those arguments is sometimes right. Interoperability is not about deleting the safeguards. It is about lowering the cost of doing the right thing, so that sharing safely is easier than not sharing at all.

The Four Layers You Have to Solve

Raymond's team learned to attack interoperability in four layers, from the bottom up: data exchange formats, interface standards, model sharing protocols, and interagency technical agreements. Skip a layer and the whole stack leaks. A perfectly documented interface over a schema nobody agreed on moves incorrect data faster. A signed agreement with no shared format produces a legal right to a file that neither side can read. The sections that follow take the layers in order, because that is also the order in which they should be built.

Layer One: Data Exchange Formats

If the damage-assessment AI exports addresses as free text and the registry expects structured fields, they cannot connect, no matter how good the network is. The fix is shared data standards: agreed field definitions, formats and meanings. Government does not have to invent these. The National Information Exchange Model is a long-standing federal and state standard specifically for exchanging data across agency boundaries in justice, emergency management and health. Adopting an existing standard beats negotiating a new one for every pair of agencies, and it beats it by an order of magnitude in elapsed time.

Underneath any standard sits a schema, defined once and used everywhere. The source material works a fraud indicators table as its example, and the discipline it shows is worth copying: every field carries a name, a type and a stated meaning. A transaction_id string as the unique identifier. An amount as a decimal. A merchant_category string holding a merchant category code. A time_of_day expressed as an hour. A days_since_last_transaction integer. An is_international boolean. An is_fraud boolean carrying the label where it is known. And a confidence float recording how sure a human reviewer was, where a human reviewed it.

That last field is the one teams forget, and it is the one that makes the data reusable. A label without a confidence is a label you cannot weight. Serialization standards such as Apache Parquet or Protocol Buffers let you define the schema once so that any system following the standard can read the data, which removes an entire category of integration work. The choice of serialization format matters far less than the fact that both sides read the same definition of what each field means.

Data Quality Contracts

A schema tells you the shape of the data. It tells you nothing about whether the data is any good, and a model trained on another agency's data inherits that agency's data quality problems along with its records. The remedy is an explicit quality contract accompanying the exchange, stating what the receiving side is entitled to expect. The source material's example contract is specific enough to be enforceable, which is the property to aim for.

It states that there are no nulls in the identifier, amount and merchant category fields. That amounts are greater than zero. That the hour field falls inside its valid range and the days-since field is not negative. That the fraud label is a boolean and is populated wherever the label is known. Then three guarantees that go beyond field validation: completeness, meaning at least 95 percent of columns populated; freshness, meaning data updated within 48 hours; and lineage, meaning a documented statement of which systems the data came from and what transformations were applied along the way. Those three figures are the source's own, and they are the shape of a contract rather than a universal standard, so set your own thresholds deliberately.

Lineage is the guarantee most often omitted and the one that matters most when something goes wrong. If a shared model starts behaving strangely well after deployment, the first question is whether the upstream data changed, and only a lineage record can answer it. Without one, the receiving agency is debugging a system whose inputs it cannot see.

Privacy Before Any Record Crosses

Before sharing data across agencies, you have to deal with personally identifiable information, and this is the layer where interoperability projects most often stop, correctly. The source material sets out four measures. Remove direct identifiers: names, Social Security numbers, addresses. Remove quasi-identifiers, meaning fields such as birth dates and postal codes whose combinations can re-identify a person. Apply differential privacy, adding statistical noise to prevent inference attacks. And aggregate wherever aggregation still serves the purpose, sharing summaries rather than individual records.

Aggregation is underrated. Rather than sharing individual benefit application records, an agency can share a statement of the form that a given share of applications in a given category and a given postal area were fraudulent. That is often enough to train or tune a model without exposing anyone. Where it is enough, take it, because it removes an entire class of risk rather than managing it.

State the limit honestly, because this is where reassurance does real damage. Removing direct identifiers reduces re-identification risk; it does not eliminate it. The combination of quasi-identifiers left in a dataset can identify individuals even when every obvious field has been stripped, which is precisely why the source lists quasi-identifiers as a separate step rather than folding them into the first. Treat a de-identified dataset as lower risk, never as anonymous, and have someone outside the team that prepared it test whether re-identification is possible before it leaves the building. The legal frame travels with the data too: any flow of records between agencies has to satisfy each agency's own legal authority and privacy obligations, including the federal Privacy Act and any data-specific statutes governing that program's records. That question goes to privacy officers and counsel before engineering starts, not after a pilot has been built.

Layer Two: Interface Standards

An application programming interface is the doorway one system uses to ask another for data or action. It is a contract: give me this, and I will return that. If every agency's doorway is a different shape, every integration is bespoke and brittle. Agreeing on common conventions for authentication, for how requests are framed and for how errors come back means a new agency can plug in without a custom project each time. The federal preference is well-documented interfaces following REST conventions with consistent authentication, so any authorized system can connect predictably.

For AI, that contract carries more than a simple data lookup. The source material's inference example sends the document to be classified along with a model_version and a confidence_threshold, and receives back the classification, a confidence score, a short explanation of which markers drove the result, the model version that actually answered, and a decision_id for audit. Four requirements fall out of that shape, and each is there for a governance reason rather than an engineering one.

Version the model, so callers know which version responded and can reproduce a past decision. Include metadata explaining why the model produced that result, because a receiving agency that cannot explain a decision to a citizen cannot defend it. Include an audit trail, since the decision identifier is what lets either agency trace a specific outcome back to a specific inference months later. And support caller-supplied confidence thresholds, so the consuming agency, which knows its own risk tolerance, decides what confidence is acceptable rather than inheriting the producing agency's judgment.

Training is a different shape of problem. If training a model takes hours, it cannot run synchronously over a request. The source material's asynchronous pattern posts the training data location, the model type and the hyperparameters together with a callback address, and receives back a job_id, a status of queued, and an estimated completion time. When the run finishes, the service calls the address it was given with the job identifier, the final status, the resulting model identifier and the evaluation metrics, which in the worked example are an accuracy, a precision and a recall figure reported together. Three requirements follow: return a job identifier immediately rather than blocking the caller, provide status updates so progress can be checked, and push notifications by callback rather than making the caller poll.

Reporting accuracy, precision and recall together rather than a single headline number is itself the governance point. A fraud model with high accuracy and poor recall misses most of the fraud while looking excellent on a slide, and an agency consuming another agency's model needs all three figures to know what it is actually receiving.

Layer Three: Model Sharing Protocols

Sometimes the valuable thing is not data but a model. A revenue department's fraud-detection model could help several other agencies. But lending a model raises questions that lending a file does not. Who is accountable if a borrowed model makes a wrong decision in another agency's context? Was it validated on that agency's population? A model sharing protocol answers these in advance, documenting what the model was trained on, where it is valid, who owns it, and how performance is monitored after it is lent out.

The mechanism that makes this tractable at scale is a registry: one place where models are registered and can be found. The source material lists what each entry holds, and the list is the useful part. A model identifier. The creating agency. What data it was trained on. Its performance metrics. Its approval status. Its license, meaning whether other agencies may use it at all. A pointer to the code repository where the source is available. And its documentation. A registry that supports querying by task, by data domain and by a minimum performance threshold turns discovery from a series of phone calls into a search.

Before another agency uses your model, it goes through approval, and the source names four reviews: legal reviews the agreement, security reviews whether the data was treated properly, a technical review confirms the model is adequately documented, and governance signs off. This is not fast; the source says it might take weeks. That is a real cost and it is worth paying, because the alternative is a model in production somewhere with nobody able to say who approved it or on what basis. What you can do is run the four reviews in parallel rather than in series, and keep a standing template so each one is reviewing a familiar document.

Models change, and old versions have to be retired deliberately. A sensible history reads as an initial release trained on a given year's data, a retrain with additional data, a fix to a preprocessing defect, and then a major architectural change, with each step numbered so a consumer can see how far it has moved from what they validated. Explicit deprecation matters more than the numbering scheme: if old versions stay in use after a new one lands, you have models behaving differently across agencies while everyone believes they are running the same thing. Announce deprecation, give consumers a window, and keep serving the old version until that window closes.

A powerful pattern sits alongside model sharing: sharing insights without sharing raw data. Techniques that let agencies train against or query a shared model while sensitive records stay in their home system matter enormously where privacy law forbids the underlying data from moving at all. Where the data cannot travel, the question becomes whether the computation can travel to it instead.

Layer Four: Interagency Technical Agreements

This is the layer agencies most often skip and most often regret. Before any data or model crosses a boundary, there must be a written agreement covering purpose, scope, security, retention and accountability. These are typically memoranda of understanding or interagency agreements, and they must satisfy each agency's legal authority and privacy obligations. Office of Management and Budget guidance on federal AI expects agencies to manage data governance and third-party dependencies, and an interagency agreement is how that duty travels across an organizational line.

The instrument choice, the funding mechanics and the negotiation itself belong to Cross-Agency AI Coordination and Data Sharing Agreements for AI, which work them properly. The point to carry here is a sequencing one. The agreement is not paperwork that follows a successful pilot. It is the thing that determines whether the pilot is lawful, and drafting it first surfaces the constraints that should have shaped the technical design anyway.

Who Is Accountable When Systems Share

The deepest interoperability risk is diffused accountability. When the emergency model feeds the registry, which feeds a benefits decision, and that decision is wrong, who is responsible? If the answer is everyone, the real answer is nobody. Raymond's rule is that every shared data flow and every shared model has one named accountable owner, documented in the agreement. Interoperability without clear ownership is just a bigger blast radius for the next failure.

This is also where civil rights and transparency duties travel across boundaries. A borrowed model that produces a rights-impacting decision in a new agency brings with it that agency's obligation to test for disparate impact and to give the public a way to appeal. Borrowing the model does not borrow an exemption. Nor does it borrow validity: a model trained on one agency's population may behave differently on another's, and re-validation by the receiving agency on its own data is a condition of use rather than a nice-to-have.

A Usable Artifact: Interagency AI Interoperability Checklist

Before two agencies connect AI systems, walk this checklist. Every no is a project task, not a footnote.

Where to Start

Start by identifying models with clear cross-agency value rather than trying to make everything shareable. Fraud detection, eligibility determination and document classification recur across government and have real demand, which means the second agency is already looking for what the first one built. Then build the infrastructure the sharing depends on: a model registry, an approval process, and interface standards. Doing this by hand for each pair of agencies has an overhead high enough that it will stop the moment the enthusiastic person moves on.

Then pilot with two agencies rather than fifty. One model, one consumer, one agreement, one full cycle through approval and re-validation. The pilot is where you find out how long the four reviews actually take in your government, which quality guarantees you cannot meet, and which part of the anonymization step nobody had budgeted for. Learn from it, fix the process, and only then expand.

Raymond used the checklist to wire the three storm-response systems together over the following year. Adopting a shared data standard solved the address-format problem. Documented interfaces replaced the spreadsheet relay. An interagency agreement, signed before the next storm season, named one accountable owner, his office, for the combined map. When the next major weather event hit, the unified picture the governor wanted appeared in eleven minutes rather than 36 hours. Same agencies, same systems, same data. The only thing that changed was the box they agreed to put it in.

Anti-Patterns

• Sharing a model without documentation. You hand over a model but never document what it was trained on, what it does, or how to use it. The receiving agency gets unexpected results and has no way to tell whether that is a defect or a misuse. Comprehensive documentation is not optional here: a model card, a training data description, the valid scope and worked usage examples travel with the model or the model does not travel.
• No governance for a shared model. You share a model, the other agency modifies it, and the modified version diverges from what you built. Both agencies now run different models while believing they run the same one, and a defect found in one is not fixed in the other. Establish clear ownership, require approval for modifications, and track versions on both sides of the exchange.
• Treating de-identified as anonymous. You share data you believed was anonymized, and quasi-identifiers in the remainder allow individuals to be re-identified. Removing names and identifiers reduces risk rather than removing it. Run a rigorous anonymization review, get validation from someone who did not prepare the dataset, and use differential privacy or aggregation where the residual risk is not acceptable.
• Breaking the interface without warning. You update your model's interface and every agency built against the old one breaks, usually during their busiest week. Version your interfaces, support more than one version at a time, and deprecate old versions slowly with an announced window rather than a surprise cutover.
• Skipping re-validation on the receiving side. A model that performed well on the lending agency's population is assumed to perform well on yours. It may not, and the failure will look like the receiving agency's fault because the decisions carry its name. Re-validate on your own data before production, and treat the lender's metrics as a reason to try rather than as evidence about your population.
• Building the connection before the agreement. The pilot works, everyone is pleased, and then counsel asks under what authority the records moved. The agreement is not a formality that follows a technical success; it defines what the technical design was allowed to do. Draft it first and let its constraints shape the architecture.
• Standardizing by mandating a platform. An agency told to abandon its systems for another agency's platform will resist, and it should. Interoperability asks for a common container, not a common warehouse. Standardize the formats, interfaces and rules, and leave each agency's internal choices alone.

Practice Prompts

• Assess your current interoperability state. How many other agencies could benefit from the models you operate? What would block them today, and is each blocker technical, legal or organizational? How many models do you currently consume from other agencies, and who validated them for your population?
• Design the interface for one of your critical models. What would a request and a response contain? What metadata would you return so a receiving agency could explain a decision to a citizen? What governance would you require before another agency could call it?
• Run a data sharing assessment for one dataset. What exactly would you share, what would need to be removed or aggregated, and what quality guarantees could you actually commit to for completeness, freshness and lineage?
• Write the quality contract for that dataset as if the receiving agency would hold you to it. Then check whether your current pipeline would pass it, and note every guarantee you had to weaken.
• Take one model your agency would like to borrow and walk the checklist in this lesson end to end, recording every no and who would own it. Estimate how long the four approval reviews would take in your government.

Reflection

If you could share exactly one model with other agencies, which would it be and why? What is preventing you from sharing it right now, and is that obstacle technical, legal, or simply that nobody has been tasked with removing it? Turn the question around: what would you need to ask another agency before you were willing to use their model in a decision that affects a resident, and could you answer those same questions about your own? Finally, who in your agency would actually have to approve sharing a model, and do they know that is their role?

Glossary

• Application programming interface. The documented doorway one system uses to ask another for data or action; effectively a contract stating what goes in and what comes back.
• Schema. The definition of a dataset's fields, their types and their meanings, defined once so that every system reading the data interprets it the same way.
• Data quality contract. An explicit statement of what the receiving side is entitled to expect, covering nulls, valid ranges, completeness, freshness and lineage.
• Lineage. The record of which systems data came from and what transformations were applied, without which a receiving agency cannot debug a model whose inputs changed.
• Model registry. A central repository of discoverable models with their metadata, training data description, performance metrics, license and approval status.
• Model card. Documentation for a model covering its purpose, training data, performance metrics and limitations, and the minimum that should travel with a shared model.
• Quasi-identifier. A field that is not identifying alone but which, combined with other available data, can re-identify an individual, such as a postal code with a birth date.
• Differential privacy. A statistical technique that adds noise to data to prevent individual-level inference while preserving useful aggregate statistics.
• Deprecation. The announced retirement of an old model or interface version, with a window during which it continues to work so consumers can migrate.
• National Information Exchange Model. A long-standing federal and state standard for exchanging data across agency boundaries in domains including justice, emergency management and health.

Related Lessons

• Cross-Agency AI Coordination is the companion lesson covering the organizational, legal and funding side of the same problem.
• Data Sharing Agreements for AI works the instrument that layer four depends on.
• Designing Agency-Wide AI Platforms covers the internal platform that makes an agency capable of exposing anything at all.
• Multi-Cloud, Multi-Model Strategy addresses the portability constraints that shape what can be shared.
• Data Mesh and Data Fabric for Government is the architectural pattern behind federated data ownership across agencies.
• Data Governance for AI covers the stewardship and quality practices a quality contract assumes are already in place.
• Privacy Engineering for AI goes deeper on the de-identification and differential privacy techniques referenced here.
• Cross-Agency Governance Coordination handles the governance structures that sit above multiple sharing arrangements.
• Vendor Lock-In Prevention addresses the proprietary deployment problem that blocked the fraud model in the opening case.
• Rights-Impacting and Safety-Impacting AI Safeguards defines the obligations a borrowed model carries into the receiving agency.

Closing

Government silos exist for good reasons. Security, autonomy and accountability are real values, and an interoperability program that treats them as obstacles will lose, deservedly. The work is not to remove the safeguards but to lower the cost of clearing them: a shared format so nobody negotiates a schema twice, a registry so discovery is a search rather than a rumor, an approval process that is predictable rather than fast, and an agreement template that counsel has seen before.

Raymond's eleven minutes were not bought with new technology. They were bought with agreed definitions, documented interfaces, a signed agreement and one named owner, assembled during a year when nothing was on fire. That is the actual lesson. The capability you want during the next emergency is built entirely out of decisions made when there was no emergency, and there is no version of this work that can be done at speed under pressure.

Key Takeaways

• Interoperability is mostly agreement, not engineering. The technical connection is the easy part; the formats, rules and ownership are the work, and they are the part nobody staffs.
• Agree on the container, not the warehouse. The goal is not to merge agencies or mandate a platform but to standardize formats and interfaces so independent systems can hand work to each other.
• Solve four layers, bottom up. Data formats, interface standards, model sharing protocols and interagency agreements. Skip one and the stack leaks in a way that looks like a different problem.
• Adopt existing standards. Established exchange models and well-documented conventions beat negotiating a new format for every pair of agencies by an order of magnitude in elapsed time.
• A schema is not a quality guarantee. Write an explicit contract covering nulls, valid ranges, completeness, freshness and lineage, or you inherit the other agency's data problems along with its data.
• De-identified is not anonymous. Quasi-identifiers can re-identify individuals after every obvious field is stripped. Test for it with someone outside the preparing team, and aggregate where aggregation still serves the purpose.
• Every inference should return a version, an explanation and a decision identifier. A receiving agency that cannot reproduce or explain a decision cannot defend it to the citizen it affected.
• A borrowed model must be re-validated. Performance on the lending agency's population is a reason to try it, not evidence about yours, and the decisions will carry your agency's name.
• Name one accountable owner. Every shared flow and model needs a single documented owner, or accountability diffuses into nobody while the blast radius grows.
• Write the agreement first. It defines what the technical design is allowed to do, and drafting it early surfaces the constraints that should have shaped the architecture.

Frequently Asked Questions

Do we have to adopt a common standard, or can we just build point-to-point connections?

You can build point-to-point connections, and the cost is invisible until the third or fourth one. Each bespoke integration is a separate negotiation, a separate mapping and a separate thing to maintain when either side changes, and the number of pairs grows much faster than the number of agencies. A shared standard converts that into one mapping per agency. The practical compromise is to build the first connection point-to-point if it is urgent, then treat the schema you agreed on as the beginning of the standard rather than a one-off.

Our data is too sensitive to leave our systems. Is interoperability off the table?

No, but the shape changes. Where records cannot move, three options remain: share aggregate statistics rather than individual records, share the model or the result rather than the data it was trained on, or use techniques that let computation run against data that stays in its home system. Each has limits and none of them removes the legal review. Start by asking exactly which fields cannot move and why, because teams often discover that the constraint applies to a subset of the data rather than the whole dataset.

How long should model approval take?

The source material says it might take weeks, and treats that as the price of accountability rather than a defect. What you can control is predictability and parallelism. Run the legal, security, technical and governance reviews at the same time rather than in sequence, publish what each reviewer needs so submissions arrive complete, and keep a template so every reviewer is reading a familiar document. An approval process that takes a predictable month is workable; one that takes an unpredictable quarter is one people route around.

If we borrow another agency's model and it produces a bad decision, who is responsible?

Answer that in the agreement before the first call, because the default answer is a dispute. The receiving agency generally owns the decisions made in its own name and the obligations attached to them, including testing for disparate impact and providing an appeal path, and the lending agency owns the accuracy of what it documented about the model. That split is workable only if the documentation is real and the receiving agency has re-validated on its own population. Name one accountable owner for the shared model in writing regardless.

Can we skip the registry and just keep a list?

A list is a fine start and it is where most agencies begin. It stops working at the point where people need to search by task, data domain and minimum performance rather than read the whole thing, and where approval status and license need to be authoritative rather than remembered. The real function of a registry is not storage but trust: a place where the answer to what this model is, who owns it and whether you may use it is the same for everyone asking. Build the list, then notice when it stops answering questions.