For the past several months, much of our work at Aigistry has moved away from writing about how government information should be structured for artificial intelligence and toward the less glamorous task of actually building the infrastructure.
That distinction matters.
It is relatively easy to describe a machine-readable government information layer in theory. It is considerably harder to build one that can continuously ingest information from different government sources, preserve the identity of the issuing authority, normalize records without erasing important distinctions, and expose the result in a form intended for automated systems rather than human readers.
That is what we have been working on with the National AI Feed. And after processing tens of thousands of government records, some of the most useful lessons have been surprisingly basic.
Government Information Is Already Machine-Readable — Sort Of
There is no shortage of government data on the internet. Federal agencies publish APIs, RSS and Atom feeds, XML files, JSON endpoints, bulk datasets, press releases, court records, alerts, and specialized data services. Some are excellent.
The problem is that there is no common publishing architecture connecting them. One source might identify an agency explicitly in every record. Another assumes you know the source because you requested a particular endpoint.
One might provide a precise publication timestamp. Another provides a date. Another provides several dates whose meanings are not immediately obvious. Jurisdiction may be explicit, implicit, or absent. A canonical source URL may be provided, constructed, redirected, or buried inside another field.
For a developer building against one government API, these inconsistencies are manageable. You read the documentation and write an integration specifically for that source. For a system attempting to represent information across many government authorities, they become an architectural problem.
The Feed Isn't Really About Aggregation
At first glance, a national government feed sounds like an aggregation project. Fetch information from a collection of sources, normalize it, and put everything into one large JSON file.
But aggregation is the easy part.
The more important problem is preserving authority. Consider two records containing nearly identical language.
One was issued by a federal agency. Another was published by a state agency. A third might be a court filing. A fourth could be a local government communication eventually submitted through a GovTech platform.
To a human looking at four different government websites, the distinction is obvious. Once those records enter automated retrieval systems, the visual context disappears. That means source identity cannot merely surround the information. It has to travel with it.
The basic unit of the National AI Feed therefore isn't a webpage. It's a record.
Conceptually, a record looks something like this:
{
"authority_name": "Example Government Authority",
"authority_type": "Federal Agency",
"jurisdiction_level": "Federal",
"jurisdiction_name": "United States",
"title": "Example Publication",
"body": "Publication content...",
"source_url": "https://example.gov/publication",
"published_at": "2026-08-14T14:30:00Z"
}
The exact implementation can become more sophisticated, but the principle is straightforward:
The information should not need its original webpage to explain who issued it.
Normalization Has a Limit
One of the first instincts when building a large feed is to normalize everything. That's useful, up to a point.
Common field names make records easier to process. Consistent timestamps make sorting possible. Standardized jurisdiction fields make filtering predictable. But excessive normalization can destroy useful information.
A court document isn't the same thing as an agency alert. A weather product isn't the same thing as a consumer safety notice. A government publication shouldn't be forced into a generic content model simply because it makes the database prettier.
We've found it more useful to normalize the properties necessary for identification and retrieval while preserving the source material and its original meaning.
In other words:
Normalize the envelope, not the government.
That distinction has become one of the most important design principles behind the feed.
Provenance Has to Be Boring
Developers tend to become interested in provenance when something goes wrong. For AI-oriented infrastructure, it needs to be present before anything goes wrong.
A machine-readable government record should make basic questions easy to answer:
- Who issued this?
- What jurisdiction does that authority represent?
- Where did the record originate?
- When was it published?
- When did the feed process it?
- Has the record changed?
- Can its integrity be verified?
None of these questions requires artificial intelligence. That's the point. The more of this work that can be handled deterministically by the publishing infrastructure, the less an AI system has to infer later.
For records published directly through the Aigistry provider infrastructure, this extends to cryptographic provenance. Publications can be hashed and digitally signed so that integrity becomes a property of the record rather than a claim made about it later.
AI doesn't need to believe that a record came through a particular publishing path when the infrastructure can provide evidence of that path.
We Also Learned That Not All Records Have the Same Trust Relationship This led to another architectural decision.
The National AI Feed contains information obtained through different mechanisms, and those mechanisms should not be blurred together. Some government information can be indexed from authoritative public government sources. Other information can be published into the infrastructure through an authorized GovTech provider acting for a specific government authority.
Those are both useful records. They are not the same relationship. So we keep those concepts distinct. An indexed record means the system retrieved information from an identified government source. A registered publication has a direct relationship to an Authority Record and the provider publishing on its behalf.
That distinction allows the feed to expand without pretending that discovery and direct publication are equivalent. This sounds obvious when written down. It becomes much more important when you're designing a system that could eventually contain millions of records.
The Website and the Feed Have Different Jobs
Another lesson has been organizational rather than technical. A government website exists primarily to communicate with people. It needs navigation, accessibility, branding, explanatory context, contact information, and an interface designed around human behavior.
A machine-readable feed doesn't need any of that. It needs predictable structure.
This means the National AI Feed isn't intended to replace agency websites, open-data portals, APIs, alerting platforms, or content management systems. Those systems already perform their respective jobs.
The feed sits downstream.
A government communicator can continue publishing through the software they already use. A GovTech provider can add the National AI Feed as another publishing destination in much the same way that platforms already distribute information to websites, email, SMS, social media, or mobile applications.
The workflow doesn't need to become an AI workflow. The publishing infrastructure does.
APIs Aren't the Whole Answer Either
Building the feed has also reinforced an important distinction between an API and a publishing layer. Government APIs are extremely valuable. We use them. But APIs are generally designed around the requirements of the system providing the data. Endpoint structures differ. Schemas differ. Authentication requirements differ. Update behavior differs. Documentation differs.
That's perfectly reasonable.
The National AI Feed addresses a different problem. Instead of asking every downstream system to understand the publishing architecture of every government source individually, it provides a common representation in which several critical properties remain predictable.
Government Source
↓
Source Integration
↓
Normalized Record
↓
Authority + Jurisdiction + Provenance
↓
National AI Feed
↓
AI / Retrieval / Search / Agent Systems
It doesn't eliminate the underlying APIs. It creates a consistent downstream layer across them.
The Hard Part Isn't JSON
Nothing about producing JSON is technically remarkable. The difficult questions are institutional. What qualifies as an authoritative government source?
How do you represent jurisdiction consistently? How do you distinguish indexed public information from information published through an authorized provider? How do you preserve provenance as records move through multiple systems? How do you prevent a national feed from becoming another publishing platform agencies have to manage? How do you scale participation without creating thousands of new government accounts?
Those questions have shaped the architecture far more than the choice of programming language, database, or server. Our answer has increasingly been to keep the system narrow. Government authorities remain the authoritative sources. GovTech providers retain their existing customer relationships and publishing workflows.
The National AI Feed provides a shared downstream machine-readable layer. And AI systems remain consumers of the information, not arbiters of who the authority is.
What Tens of Thousands of Records Changed for Us
The biggest change from operating the feed has been conceptual. When we started working on AI Citation Registries, much of the discussion centered on how AI systems could better identify and attribute authoritative government information. That remains the objective.
But running an actual feed shifts the question.
Instead of asking:
How can an AI system determine which government information is authoritative?
we can ask:
Why should the AI system have to determine that at all?
Government already knows which agency issued a publication. The publishing platform knows which customer submitted it. The source system knows when it was published. The infrastructure can preserve the source URL.
The registry can preserve the relationship between the publication and the government authority. Those facts exist before an AI system ever encounters the information. Encoding them upstream is a much simpler engineering problem than reconstructing them downstream.
Where This Goes Next
The National AI Feed is still evolving. We are continuing to add government sources, refine the processing engine, expand the provider API, and work through the practical edge cases that only appear when a theoretical architecture starts processing real government information continuously.
But one principle has survived every iteration:
AI attribution is easier when authority is explicit before retrieval begins.
We don't need government communicators to learn prompt engineering. We don't need agencies to rebuild their websites for AI. And we don't need every GovTech company to invent a separate AI publishing standard.
We need a small, predictable machine-readable layer that allows the identity of the authority, the jurisdiction, the publication, the timestamp, and its provenance to remain attached to the information as it moves downstream.
That's a much less exciting proposition than trying to make AI smarter. From an infrastructure perspective, it may also be the more practical one.
Top comments (0)