AGORA: an access profile for agent-ready government records

1. Introduction#

A public record is a fact a state has agreed to make available: whether a company is registered, whether a vehicle has an outstanding fine, which contracts an agency awarded last month, what a court decided in a case. Every modern open-data policy, from the Sebastopol principles of 2007 to the European High-Value Datasets Regulation of 2023, rests on the premise that the value of such records is realised only when someone other than the state can use them (Sebastopol 2007; EU 2023). The policies succeeded at their first objective. Most governments now run a national catalog, most catalogs speak a DCAT dialect, and the number of published datasets is counted in the tens of thousands per country (OECD 2023).

They did not succeed at the second. The literature on open-data utilisation has documented the same pattern for a decade: portals optimised for the number of datasets rather than for reuse, files that are stale or contextless, and a persistent absence of programmatic access (Janssen et al. 2012; Zuiderwijk and Janssen 2014; Attard et al. 2015; Safarov et al. 2017). A catalog entry says that a dataset exists and where a file can be downloaded. It does not let a program resolve one record, filter by a field, page through results, ask what changed since a given date, or know how fresh the answer is. Those are consumption questions, and no standard in wide use answers them for government records as a class.

Two things have changed since that literature was written. The first is the consumer. Software agents driven by large language models now retrieve public data on behalf of people, at a volume that has become measurable in web traffic (Cloudflare 2025), and they do so through structured tool interfaces rather than through a browser (Anthropic 2025; MCP 2026). An agent cannot fill a web form, wait for a certificate to render, and read the result; it needs a typed answer, a stable identifier and a timestamp. The second is that the cost of building a well-typed access layer over an existing system has fallen sharply, because the same language models can do most of the tedious part: reading a data dictionary, proposing a schema, writing the field annotations, mapping fields onto a domain standard. What has not fallen is the cost of being wrong, which is why the interesting engineering question is not whether a model can draft an interface but which checks decide whether the draft ships.

This paper is written from the position of an operator. Croma runs a public API that exposes official records from Colombia, Peru and Mexico to developers and agents through one contract: 80 endpoints over 46 sources at the time of writing, with an MCP server and a markdown rendering of every documentation page (Croma 2026). Building it meant confronting, source by source, the same handful of missing properties: no identifier that resolves, no query beyond a single lookup form, no way to learn what changed, no timestamp, no machine-readable error, no availability commitment. It also meant measuring, in production, what those absences cost the consumer. Over the 80 days reported here, the median request that had to be answered at the source's pace took 2.6 seconds and the slowest five percent took more than 27; one request in fourteen failed because the source did. The same contract, over the two sources we maintain as datasets under the profile described below, answered in 75 milliseconds at the median.

Contributions#

1. A layered map of the government open-data standards landscape (policy, catalog, API guidance, domain schema, platform, agent surface) that locates the consumption gap and explains why the mature layers cannot close it on their own (sections 2 and 3).
2. AGORA, a minimal access profile with eight requirements and three conformance levels, each requirement paired with the existing standard it composes and with a test a validator can run without human judgement (section 4, appendix A).
3. A reference implementation in production, described at the level of its contract and its two source archetypes, with latency, freshness and availability measurements from 25,153 requests (sections 5 and 7).
4. A publishing harness for institutions in which a language model proposes and a fixed set of gates disposes, with the gates specified as machine-checkable conditions and the model's authority bounded explicitly (section 6).
5. An assessment of 37 official sources in three countries against the profile's criteria, from public documentation, with the rubric and per-source evidence published alongside the paper (section 7, appendix C).
6. An adoption and governance path derived from the two domain standards that achieved global uptake, GTFS and OCDS, and adapted to the Latin American institutional landscape (section 8).

What this paper does not propose. It does not propose a new metadata vocabulary, a new domain schema, or a new transport. DCAT describes datasets well; OCDS, GTFS, BODS and Akoma Ntoso encode their domains well; OpenAPI and JSON Schema describe interfaces well. AGORA is a profile in the DCAT-AP sense of the word: a constrained, testable way of using standards that already exist, for a purpose they were not individually designed for.

2. Background: the standards landscape by layer#

The open-government-data field is not short of standards. It is short of a way to tell which of them bears on a given problem. We organise the landscape into six layers (figure 1), ordered from policy to consumer, and characterise each by what it decides and what it leaves undecided.

Figure 1. Six layers of the government open-data landscape. The mature layers decide why data is published, what datasets exist, how an agency should design an API, and how a domain is encoded. The access layer, which decides how one record is resolved, queried, followed over time and trusted, is where the profile in this paper sits. The agent layer above it is the newest consumer and the one least served today.

Layer 1: policy and governance#

The International Open Data Charter's six principles (open by default; timely and comprehensive; accessible and usable; comparable and interoperable; for improved governance and citizen engagement; for inclusive development and innovation) are the most widely adopted statement of intent, adopted by 29 national and 146 subnational governments at the time of writing (Open Data Charter 2015). They descend from the Sebastopol principles of 2007 and the Sunlight Foundation's ten principles of 2010, which already asked for machine-processable, timely, primary and permanent data. The FAIR principles, written for research data, supply the vocabulary most later work borrows: findable, accessible, interoperable, reusable (Wilkinson et al. 2016).

Three legal instruments turn intent into obligation and are worth singling out because they name the access layer directly. The European Union's Open Data Directive requires member states to make high-value datasets available free of charge, in machine-readable form, through APIs and, where the annex requires it, as a bulk download, under CC0 or CC BY 4.0 or an equivalent open licence; the implementing regulation of 2023 enumerates six thematic categories, including company registers and mobility, and applies from 9 June 2024 (EU 2019; EU 2023). The Interoperable Europe Act, in force since April 2024, makes interoperability assessments mandatory for public services that cross borders (EU 2024). In the United States, the OPEN Government Data Act obliges every federal agency to maintain a machine-readable inventory of its data assets (US 2019). In Latin America, the equivalents are transparency laws (Colombia's Ley 1712 of 2014, Mexico's Ley General de Transparencia of 2015, re-issued in 2025, and Peru's open-data strategy decree of 2017) and open-by-default decrees; they mandate publication and catalogs, but not, as of this writing, programmatic access.

Benchmarks reward what these instruments require. The OECD's OURdata Index scores availability, accessibility and government support for reuse across forty countries, and its 2023 edition found only 48% of high-value datasets available as open data (OECD 2023). None of the benchmarks scores whether a published dataset answers a per-record query. A government can therefore rank well while every one of its registries is reachable only through a web form, and several do.

Layer 2: catalog and metadata#

The W3C Data Catalog Vocabulary (DCAT), a Recommendation since 2014 and in its third version since August 2024, is the base vocabulary for describing datasets, their distributions and, since version 3, dataset series (W3C 2024). Europe's DCAT-AP profile, stewarded by the SEMIC action of the Interoperable Europe programme and at version 3.0.1 since October 2025, is the de facto continental dialect with national children in Germany, Italy and Switzerland and thematic children for geospatial and statistical data (SEMIC 2025). The United States publishes DCAT-US, the schema of every federal agency's data.json: version 1.1 remains in production and harvested, and version 3.0 is published with its implementation guidance still in draft (GSA 2026). Alongside DCAT sit Schema.org's Dataset type, which powers Google Dataset Search (Noy 2018), Berners-Lee's five-star deployment scheme, which still frames how publishers think about machine readability, and the Frictionless Data Package, a lightweight JSON descriptor favoured by data journalists and research groups (Frictionless 2024).

This layer answers the question what datasets exist and where is the file. It deliberately does not answer how do I get record 4711. A DCAT distribution has an access URL and a media type; it has no notion of a record, a key, a filter or a change. The DCAT-AP working group's own guidance treats data services as a distribution type, which is the closest the vocabulary comes, and even there the service's semantics are out of scope.

Layer 3: API design guidance#

The United Kingdom, Canada, Australia, Singapore and India, among others, publish API design standards for their agencies: REST by default, OpenAPI descriptions, versioning and deprecation rules, cross-government API catalogs (GDS 2024; Canada 2024; Australia 2024). Colombia's Ministry of ICT maintains a national interoperability framework and a common exchange language, a dictionary of data elements for inter-agency exchange (MinTIC 2026). These documents are good engineering advice and they raise the floor for agencies that build APIs. They are also, without exception, advisory, per agency and silent on the properties a consumer of a registry needs across agencies: identifier semantics, change feeds, provenance, the shape of a not-found answer. An agency that follows the UK guidance to the letter can still publish a company register with no way to ask what changed since Monday.

Two technical standards from this layer matter to the profile. OpenAPI 3.1 and JSON Schema 2020-12 give an interface a machine-readable description that agents can read directly. The IETF's Problem Details format gives errors a shape (RFC 9457), Web Linking gives discovery a header (RFC 8288), JSON canonicalisation gives a record a stable hash (RFC 8785), and the api-catalog well-known URI gives a host a place to list its interfaces (RFC 9727). The OGC API Features standard is the one example of a government-relevant, per-record, filterable access API with an OpenAPI description and stable item URLs, and it is the pattern the profile borrows most from (OGC 2022; ISO 2025).

Layer 4: domain schemas#

The standards that actually changed how governments publish are the domain schemas. The Open Contracting Data Standard (OCDS), launched in 2014, is implemented by more than fifty governments and its registry lists over a hundred publishers (OCP 2026). The General Transit Feed Specification (GTFS) is used by more than ten thousand transit agencies in over a hundred countries (GTFS 2026). The Beneficial Ownership Data Standard (BODS), the International Aid Transparency Initiative standard, the Fiscal Data Package, SDMX for statistics, Akoma Ntoso for legislation and judgments, and the European Case Law Identifier each did the same for one domain (Open Ownership 2025; OASIS 2018; EU 2011). Identifier schemes such as the Legal Entity Identifier and the org-id.guide registry of organisation identifier lists sit beside them (GLEIF 2026).

Two lessons from this layer shape everything that follows. First, the winners were small. GTFS began as a handful of CSV files that solved one consumer's problem, transit routing; OCDS is a JSON schema plus a validator. Second, they came with tooling and a neutral steward: GTFS dropped Google from its name to reduce vendor resistance, OCDS is stewarded by a non-profit and ships a validator, a data registry and a helpdesk. Neither imposed a transport, a catalog or a query language. That is why AGORA composes them rather than competing with them: a procurement record under the profile is an OCDS release; a judgment's identifier is an ECLI where the jurisdiction issues one.

Layer 5: platforms#

Governments deploy a small number of catalog platforms. CKAN, open source, powers data.gov, data.gov.uk, Brazil's dados.gov.br and Mexico's datos.gob.mx; DKAN, its Drupal relative, powers Peru's datosabiertos.gob.pe; Socrata (now Tyler Technologies' Data & Insights) powers Colombia's datos.gov.co and much of US state and local government; OpenDataSoft, ArcGIS Hub and uData serve the rest. Socrata is notable for shipping a per-dataset query API with field filters, paging and a system :updated_at column, which is why the Colombian sources hosted there score well on the profile's query criteria while the institutions' own systems do not (section 7). The platform layer is where the well-documented failure modes of open data live: vendor lock-in, stale files behind polished front ends, data without context, and fragmentation across jurisdictions.

Layer 6: agent surfaces#

The newest layer has almost no government presence. The Model Context Protocol (MCP), an open standard for connecting language-model agents to tools and data, was donated to the Linux Foundation's Agentic AI Foundation in December 2025 with more than ten thousand active public servers and 97 million monthly SDK downloads reported at the time; its specification is revised on a roughly quarterly cadence, most recently in July 2026 (Anthropic 2025; MCP 2026). Google's Data Commons ships an MCP server over public statistics (Google 2025). The llms.txt convention proposes a plain-text index a site publishes for language models (Howard 2024); as of mid-2026 a single US state, Maryland, had published one for its official portal, and the major model providers had not committed to reading them (StateScoop 2026; Technical.ly 2026). We are not aware of any national registry that publishes an MCP server, a markdown rendering of its records or a structured tool description for agents. This is the whitest space in the landscape, and the profile's R7 is written for it.

3. The consumption gap#

Reading the layers together, a pattern emerges. Layers 1 and 2 decide that data exists and describe it. Layer 4 decides what a record of a given domain contains. Layer 3 advises an agency on how to build an interface, without deciding what the interface guarantees. Layer 6 has consumers waiting for interfaces that do not exist. Between describing a dataset and encoding a record there is no layer that says, for government records as a class, what a consumer may rely on. We call this the consumption gap and characterise it by seven properties that a consumer needs and that no layer guarantees.

1. Record resolution. Given an identifier the state itself issues (a NIT, a RUC, a radicado, an OCID), obtain the record, or a definitive statement that there is none.
2. Field query. Filter by the fields the domain cares about, with bounded, pageable results, rather than through a single lookup form or a full download.
3. Change. Learn what changed since a point in time, without re-reading everything.
4. Freshness. Know when the answer was true: the record's own last change and the moment the snapshot was taken.
5. Provenance. Know which institution the record comes from, under what licence, and which version of the record this is.
6. Cross-registry identity. Recognise that a company in the procurement register and the same company in the tax register are one entity, through identifier namespaces rather than string matching.
7. Machine and agent access. Do all of the above from a program or an agent: a documented interface, machine-readable errors, declared rate limits, a tool description an agent can read.

Three kinds of evidence support the claim that this is where open data fails, and we present each in the sections that follow. The first is documentary: an assessment of 37 official sources in three countries against thirteen criteria derived from these seven properties (section 7.1). Its headline is that per-record programmatic access is documented by a minority of sources, change feeds and freshness metadata by almost none, and agent surfaces by none at all; where a source scores well it is because it publishes through a national catalog platform or a governed domain standard, not because the institution designed for consumption. The second is operational: eighty days of production traffic through a uniform contract over those sources (section 7.2). Its headline is that the consumer absorbs the variance of the source. The same request shape answers in a quarter of a second from one registry and in twenty-four seconds from another; one request in fourteen fails upstream. The third is structural: the profile's own conformance tests, which fail on most sources for the same three requirements (section 4).

Why the mature layers cannot close the gap. It is tempting to propose closing the gap by extension: add record-level properties to DCAT, add change-feed semantics to OCDS, add a mandatory API clause to every national guidance document. Each of these is being tried in isolation, and each is the wrong altitude. DCAT describes datasets and should keep doing so; a record-level query language does not belong in a catalog vocabulary. OCDS describes contracting and should keep doing so; a change feed is a property of any registry, not of procurement. National API guidance is per country by construction; a consumer that spans countries needs a contract that does not depend on which ministry wrote the guidance. What is needed is a thin layer with its own name, small enough that a domain standard can be embedded in it unchanged and a catalog can point at it unchanged. That is the design brief for AGORA.

Why now. The gap has existed since the first portal. Two things make it urgent. Agents are a consumer class that cannot route around missing structure the way a human with a browser can; for them the gap is not friction but a wall, and requests from AI crawlers reached 4.2% of HTML traffic seen by one large network in 2025, on par with the largest search crawler (Cloudflare 2025). And the tooling to close the gap has become cheap: a language model can draft a typed schema and its annotations from a data dictionary in minutes, so the binding constraint on an institution is no longer engineering hours but confidence that what ships is correct. The profile supplies the contract; the harness in section 6 supplies the confidence.

4. The AGORA access profile#

AGORA (Agent-ready Government Open Records Access) is an access profile: a constrained, testable way of publishing a registry so that a program or an agent can consume it without knowing which institution built it. It is specified as eight requirements, R1 to R8, grouped into three conformance levels (figure 2). Each requirement names the existing standard it composes, states what a publisher must do, and states the test a validator runs. The tests are the specification; the prose explains them.

Figure 2. The eight requirements of AGORA and the three conformance levels they form. Each level is a superset of the one below it. Level 1 makes a registry readable by a program; Level 2 makes it queryable and followable over time; Level 3 makes it consumable by an agent with no human in the loop.

4.1 Design principles#

Compose, do not compete. Every requirement is expressed in terms of a standard that already has a steward. Records are JSON Schema documents; interfaces are OpenAPI documents; datasets are DCAT resources; procurement records are OCDS releases; errors are Problem Details. The profile adds constraints and a few field names, nothing else. A publisher already conformant to a domain standard should reach Level 2 without changing a record.

Minimal, then testable. A requirement enters the profile only if a validator can decide it without human judgement. This rules out worthy properties, such as "data quality" or "completeness", that are not decidable from the outside, and it is why the profile has eight requirements rather than the thirty a checklist would accumulate. The GTFS and OCDS histories both say the same thing: the smallest specification with a validator wins.

Agent-ready without being agent-only. Every surface an agent needs is also a surface a developer needs. The MCP tool description in R7 is generated from the OpenAPI document; the markdown twin of a documentation page is the same content negotiated by media type; the llms.txt index points at the same URLs a human would bookmark. Nothing in the profile creates a second, agent-specific data path that could drift from the first.

Provenance by default. A record without a timestamp and a source is a rumour. The envelope in R5 is mandatory at every level, because it is the property whose absence the consumer can least work around and the one publishers most often omit (section 7.1).

The source's identifiers, not ours. The profile does not mint identifiers for records that already have one. A company is its registry number; a judgment is its radicado or its ECLI; a procurement process is its OCID. Where an identifier has no scheme, R2 asks the publisher to declare one, not the consumer to invent one.

4.2 Requirements#

R1. Typed records#

Composes JSON Schema 2020-12 and the domain schemas. Every record type the registry publishes has a JSON Schema. Every property carries a human-readable description and, where a value is coded, an enumeration or a reference to the code list. Field names are stable across versions; a renamed field is a new version. Where a governed domain schema exists for the record type (OCDS, BODS, GTFS, Akoma Ntoso, SDMX), the record either is an instance of it or carries a declared mapping to it.

Test. Fetch the schema from the interface description; validate a sample of records against it; every property has a non-empty description; every enumerated property lists its values.

R2. Resolvable identifiers#

Composes URIs, ECLI, OCID, LEI and org-id.guide. Every record has an identifier the publishing institution issues, and a canonical URL that resolves to the record (or to a definitive not-found answer). The identifier's scheme is declared: its namespace, its syntax, and the registry that issues it, using an org-id.guide code where one exists. Identifiers for the same entity in different registries are related by namespace, so that a consumer can state "the entity known to registry X as a" without string matching.

Test. For a sample of records, the canonical URL returns the record; a syntactically valid but unassigned identifier returns found: false with HTTP 200, not an error; the scheme declaration is present in the schema.

R3. Uniform query contract#

Composes OpenAPI 3.1 and the OGC API Features query pattern. The interface offers at least two operations per record type: lookup by identifier and search by declared fields. Search results are bounded (a declared maximum page size), paged by an opaque cursor, and sorted deterministically. Which fields are searchable is declared in the schema, not discovered by trial. A not-found lookup is an answer, not an error: it is the same shape as a found record with found set to false. Errors use Problem Details (RFC 9457).

Test. The OpenAPI document declares both operations; a search with a cursor from a previous page returns the next page and never a duplicate; a request past the page-size bound is rejected with a Problem Details body naming the bound.

R4. Change feed#

Composes a monotonic cursor over the record's own timestamps. Every record carries _updated_at, the instant the publisher last changed it. Search accepts updated_after, returning only records changed since that instant, in ascending order of change, so that a consumer can replay the registry from any point without re-reading it. Deletions are records too: a tombstone with _deleted_at appears in the feed.

Test. Two searches with updated_after set to t1 < t2 return sets where the second is a subset of the first; every returned record has _updated_at greater than the parameter; the feed is stable under repetition.

R5. Provenance envelope#

Composes PROV-O concepts and DCAT licence metadata. Every response wraps its payload in an envelope that states: source (the institution, as an org-id.guide identifier where possible), as_of (the instant the underlying data was last synchronised or, for a live lookup, the instant of retrieval), record_version (a hash of the canonical record, JCS-serialised per RFC 8785), and license (a URI). The distinction between "last changed" (R4) and "last checked" (as_of) is deliberate: the first is a fact about the record, the second about the publisher's process, and consumers need both.

Test. Every response carries all four fields; as_of is never later than the response time; two responses for the same record with equal record_version are byte-identical after canonicalisation.

R6. Bulk access#

Composes DCAT distributions and dataset series. The complete set of records of each type is available as a versioned bulk export, described as a DCAT distribution with dct:modified and a checksum, and the export is derivable from the change feed (or the feed from the export): the two are two views of one dataset, not two datasets.

Test. The DCAT description is reachable from the interface description; the export's record count equals the count reported by the search operation at the same as_of; a random sample of exported records matches the lookup operation.

R7. Agent surfaces#

Composes MCP, llms.txt, RFC 9727 api-catalog and content negotiation. The publisher exposes (i) an MCP server whose tools are generated from the OpenAPI document, one tool per operation, with the schema's descriptions as the tool descriptions; (ii) a markdown rendering of every documentation page and of every record, negotiated with Accept: text/markdown at the same URL and also available at a .md suffix; (iii) an llms.txt index at the host root that lists the interface description, the catalog, the documentation and the feed; and (iv) an api-catalog well-known resource (RFC 9727). A tool description states what a not-found answer means, so that an agent does not retry a definitive negative.

Test. The MCP server's tool list is isomorphic to the OpenAPI operations; every documentation URL answers markdown under negotiation; /llms.txt and /.well-known/api-catalog resolve and their links resolve.

R8. Operational contract#

Composes OpenAPI, RFC 9457 and rate-limit headers. The publisher declares rate limits in response headers, a versioning and deprecation policy with a minimum notice period, an availability commitment and a status page, and a contact. Every error is a Problem Details document with a stable machine-readable type. A request that cannot be answered within a declared bound is accepted for asynchronous completion (HTTP 202 with a status URL) rather than left to time out.

Test. Rate-limit headers are present on every response; the deprecation policy is linked from the interface description; the status page resolves; an induced error returns Problem Details.

4.3 Conformance levels#

Table 1. Conformance levels. Each level is a superset of the previous one; a validator reports the highest level all of whose tests pass. R5 (envelope) and R2 (identifiers) are in Level 1 on purpose: they are the properties whose absence a consumer can least repair after the fact.

The three levels are ordered by what they let a consumer stop doing. At Level 1 the consumer stops parsing HTML and guessing at freshness. At Level 2 it stops downloading the whole registry to answer one question and stops diffing snapshots to learn what changed. At Level 3 it stops needing a developer to write the integration at all. The levels also order the effort for a publisher: Level 1 is achievable from a bulk file and a schema, which most national catalogs already host; Level 2 needs a service; Level 3 is generated from Level 2 by tooling.

4.4 The envelope#

The envelope is the one concrete wire format the profile introduces, and it is small (the JSON Schema is in appendix B). It separates the record from the statements about the record, so that a domain-standard payload can be embedded unchanged: an OCDS release goes in data exactly as OCDS specifies it, and the envelope says where it came from and when.

{
  "found": true,
  "source": { "id": "PE-OECE", "name": "OECE", "org_id": "XI-PB-PE-OECE" },
  "as_of": "2026-08-26T08:15:00Z",
  "record_version": "sha256:9f2c...e1",
  "license": "https://creativecommons.org/licenses/by/4.0/",
  "data": {
    "ocid": "ocds-dgv273-seacev3-873200",
    "_updated_at": "2026-08-21T14:02:11Z",
    "tender": { "title": "...", "status": "complete" }
  }
}

A not-found answer has the same envelope with found: false and no data. This is the single most consequential rule in the profile for agents: a definitive negative that arrives as HTTP 200 is an answer an agent can act on, while a 404 is indistinguishable from a broken URL and will be retried or reported as a failure. The reference implementation's tool descriptions state this explicitly, and it removed an entire class of agent misbehaviour we observed before adopting it.

4.5 Relationship to existing standards#

Table 2. What each requirement composes and what it adds. The profile introduces one wire structure (the envelope) and three field names; everything else is a constraint on how an existing standard is used.

In every row the addition is a constraint or a field name, never a competing vocabulary. A DCAT-AP catalog can describe a profile-conformant registry as a dcat:DataService with its distributions, and the profile's validator can be run from the catalog entry. An OCDS publisher becomes Level 1 by adding the envelope and a schema pointer, and Level 2 by adding updated_after to its existing release search, which the OCDS record package model already anticipates. The profile is, in that sense, the layer OCDS and DCAT have been assuming exists.

5. Reference implementation#

The profile was not designed on paper and then built. It was extracted from a platform that had to expose several dozen registries through one contract and kept meeting the same absences. This section describes that platform at the level of its contract, so that the measurements in section 7 can be read, and so that a second implementer has something concrete to compare against. Product detail is out of scope; the public documentation covers it.

5.1 Scope#

At the time of writing the platform exposes 80 endpoints: 75 over 46 official or quasi-official sources in Colombia (38 endpoints), Mexico (25) and Peru (12), and five borderless content endpoints (web search, extraction and research) that are outside this paper's scope. The sources span the registries a lender, a compliance team or a journalist consults in practice: company and taxpayer registers, vehicle and traffic-fine registries, court dockets and case law, procurement, disciplinary and fiscal sanctions, financial statements, official gazettes, regulatory circulars, federal legislation and prosecutors' bulletins. Each endpoint is a lookup or a search in the sense of R3, described in one OpenAPI 3.1 document, and every record type has a JSON Schema with described fields in the sense of R1.

5.2 Two source archetypes#

Sources fall into two archetypes, and the distinction is the single most important fact about the measurements that follow.

Answered at the source's pace. For most sources, a request is answered by consulting the institution's own system at request time. The platform contributes the contract: a typed record, the envelope, a definitive not-found, a machine-readable error with a stable code on failure, declared rate limits, and asynchronous completion when the source is slow (the request is accepted with HTTP 202 and a status URL, which the consumer polls). What the platform cannot contribute is speed or availability beyond the source's own: if the institution's system takes twenty seconds or is down, the consumer sees twenty seconds or a source_unavailable error. Seventy-two endpoints fell in this archetype during the measurement window.

Answered from a dataset maintained under the profile. For a source whose records can be enumerated, the platform maintains the complete set of records as a dataset: typed by the schema, synchronised on the source's own publication cadence, with every record carrying _updated_at and every response carrying as_of. Lookups and searches are answered from the dataset. Search accepts the fields the domain cares about rather than the ones the source's form happens to offer, and updated_after returns only what changed. During the window this archetype covered Peru's public procurement (OECE, published by the institution under OCDS) and, from the last day of the window, the 311,878 tesis of Mexico's Supreme Court. This archetype is what a Level 2 publisher looks like from the outside; the platform stands in for the institution until the institution publishes under the profile itself.

Figure 3. Reference architecture. One contract fronts two archetypes: sources answered at their own pace at request time, and datasets maintained under the profile. The agent surfaces (MCP tools, markdown twins, llms.txt, api-catalog) are generated from the contract, never hand-written, so they cannot drift from it.

5.3 The contract as implemented#

• Records and identifiers (R1, R2). Every endpoint's response schema is a typed record with described fields; identifiers are the institution's own (NIT, RUC, radicado, OCID, registration number). A syntactically valid identifier with no record returns found: false with HTTP 200. The documentation states, per endpoint, that this is a definitive answer and not an error; the MCP server's instructions repeat it.
• Query (R3). Lookup by identifier and search by declared fields, with bounded page sizes. Errors are a fixed envelope with a stable machine-readable code. Batch variants exist where consumers asked for them.
• Change (R4). Dataset-backed endpoints accept updated_after and expose _updated_at. Source-paced endpoints cannot offer it, because the source does not; this is the requirement that most clearly separates the archetypes.
• Envelope (R5). Every endpoint is bound to one named source in its description. Dataset-backed responses carry as_of and the record's own timestamp; source-paced responses are answered at retrieval time and do not yet carry an explicit as_of. Responses may be reused within a declared freshness window, and a reused response says so in a header.
• Agent surfaces (R7). One MCP server exposes every endpoint as a tool, with tool descriptions generated from the same schema descriptions the OpenAPI document carries. Every documentation page and every changelog entry answers markdown at its own URL under content negotiation and at a .md suffix; the site publishes llms.txt, an api-catalog well-known resource, and Link headers pointing at all of them.
• Operations (R8). Rate limits are declared in headers, with a daily policy per key; a versioning and deprecation policy is published; a status page exists; slow sources are answered asynchronously.

5.4 What the implementation does not yet satisfy#

The platform is not a full Level 3 publisher and this paper does not claim it is. Bulk export (R6) exists for the dataset archetype only; source-paced endpoints cannot offer it by construction. The envelope (R5) is complete only for dataset-backed responses: source-paced responses lack an explicit as_of, and record_version (a canonical hash) is not yet emitted by either. Errors carry stable codes in a fixed envelope but are not yet RFC 9457 Problem Details (R3, R8). Cross-registry identifier namespaces (R2, the org-id.guide declaration) are documented per endpoint rather than declared in the schema. Each of these is scheduled, and each is a smaller change than the ones already made; we list them because a reference implementation that overstated its conformance would undermine the validator it argues for.

6. A publishing harness for institutions#

The profile says what a conformant registry looks like. This section is about how an institution gets there, and specifically about how a language model can do most of the work without being trusted to decide whether the work is right. The design comes from our own onboarding loop, which has taken several dozen sources from "a system with a data dictionary" to "a conformant, documented, agent-visible endpoint", and which changed shape once we stopped asking the model to build things and started asking it to propose things for a fixed set of gates to accept or reject.

6.1 The shape of the problem#

An institution that wants to publish a registry under the profile starts from one of three positions: a database or internal API with a data dictionary (the common case), an existing public export or catalog entry (a bulk CSV on the national portal), or an existing public interface that predates the profile (a search form, a SOAP service). In all three, the expensive steps are the same: understanding the record, writing the schema and its descriptions, deciding the identifier scheme, mapping onto a domain standard where one applies, generating the interface and its documentation, and verifying that all of it is true of the live system. The first four are language tasks over documents the institution already has; a model does them well and fast. The last is not a language task, and it is where errors become consequences.

6.2 The pipeline#

Figure 4. The publishing harness. Six stages; the model proposes in the first three and the last is monitoring. Between stages sit gates that are machine-checkable conditions on artifacts, not judgements about text. A proposal that fails a gate goes back to the model with the failure attached; nothing reaches the publish stage that has not passed every gate, and a human reviews the gate reports, not the model's prose.

1. Discover. Inputs: the institution's data dictionary, sample records, existing documentation, and (if one exists) the current public interface. The model produces a source brief: the record types present, the identifier each carries and who issues it, the fields and their apparent types and code lists, the update cadence as far as it can be inferred, and the not-found behaviour of the existing system. The brief is a document for people; it is also the input the next stage is held to.

2. Model. The model proposes a JSON Schema per record type with a description for every field, an identifier-scheme declaration, and, where a governed domain schema applies, a field-level mapping to it (this procurement record's fecha_adjudicacion is OCDS awards[].date). The proposal is annotated: every description cites the dictionary entry or sample it came from. Gate: the schema validates the samples; every field has a description; the mapping's target fields exist in the domain schema's own definition; enumerations cover every value seen in the samples.

3. Generate. From the accepted schema the harness generates, deterministically, the OpenAPI document, the envelope wrapper, the error vocabulary, the MCP tool manifest, the markdown documentation and the llms.txt entry. The model's role is limited to prose the generator cannot write: worked examples and the plain-language description of the registry. Gate: the generated artifacts are consistent with each other by construction (they share a source); the model's prose is checked against a fixed vocabulary that excludes anything the institution does not want published, and against placeholder rules for personal identifiers in examples.

4. Verify. The conformance tests from section 4.2 run against the live interface: lookups by known identifiers, a not-found probe with a valid-but-unassigned identifier, cursor paging, updated_after replay, envelope fields, rate-limit headers, the markdown negotiation, the MCP tool list against the OpenAPI operations. Gate: every test for the target level passes. This gate is the harness's centre of gravity: it cannot be argued with, it produces the report a human reads, and it is what the model is trying to satisfy in the earlier stages.

5. Publish. The artifacts are deployed; the catalog entry (DCAT) is written or updated to point at the interface; the change is announced through the feed. Gate: the published URLs resolve and the validator passes against the public address, not the staging one.

6. Monitor. The conformance tests run continuously as canaries; the record schema is checked against a sample of live records for drift (a field that changed type, a new enumeration value, a changed not-found shape); freshness is checked against the declared cadence. A failure opens a report that re-enters the loop at the stage it implicates.

6.3 What the model may and may not do#

Table 3. The model's authority by stage. The pattern is uniform: the model proposes over documents and revises against reports; the harness generates and verifies; people approve gate reports.

The principle behind the boundary is that a model is a good author and a poor witness: it can write a schema that is plausible, complete and well-described far faster than a person, and it cannot be relied on to know whether the schema is true of the system. The harness therefore never lets the model be the last step. Every artifact that ships is either generated deterministically from something a gate accepted, or is prose that a fixed vocabulary check passed. The tests are the institution's, not the model's; a proposal that fails is returned with the failure attached, and the model revises. This is the same loop a careful engineer runs; the difference is that the loop is explicit, the gates are named, and the model cannot skip one.

6.4 Observations from use#

Three things from our own use of this loop are worth recording, with the caveat that they are an operator's observations and not a controlled study.

First, the binding constraint moved. Before the gates were explicit, the slow step in adding a source was writing and reviewing the connector; after, it was the verification step waiting on the institution's system, which is to say the source's own pace and availability. The engineering effort per source fell from days to hours; the elapsed time did not fall as much, for reasons the source controls.

Second, the gates caught what review did not. The three failures the verify stage catches most often are a not-found shape that differs from the documented one (the system returns an empty list for one identifier format and an error for another), a field whose sample values were all of one type but whose live values are not, and a page size that the documentation states and the system does not honour. Each of these had, before the gates, reached consumers.

Third, the vocabulary gate matters more than it looks. An institution has things it does not want said about its systems, and a model writing documentation will say them, helpfully and accurately, unless prevented. A fixed list of excluded terms, applied to every generated sentence, is a blunt instrument and the right one: it is the one check that has never had a false negative.

6.5 Cost#

For an institution the marginal cost of a registry under the harness is dominated by two things it already pays for: the people who know the data, and the system that serves it. The model's contribution is bounded by the number of fields (descriptions and mappings) and is cheap at current prices; the generator's is fixed; the verifier's is proportional to the number of tests, which is small and does not grow with the registry. The cost that does not fall is institutional: deciding that a registry is public, that its identifiers are stable, that its not-found answer is definitive, and that it will stay up. The harness makes those decisions visible and checkable. It does not make them.

7. Evaluation#

We evaluate the claim that the consumption gap is where open data fails, and the profile's fitness to close it, with two kinds of evidence: a documentary assessment of 37 official sources against criteria derived from the profile, and production measurements from the reference implementation over 80 days.

7.1 Source assessment#

Method. We selected the 37 sources behind the reference implementation's endpoints in Colombia (20), Peru (8) and Mexico (9): the registries a consumer in those countries actually asks for, rather than a sample of catalog entries. Each was assessed on 26 August 2026 against thirteen criteria (table 4) derived from the seven gap properties and the eight requirements, using only public documentation: the institution's site, the national open-data portal, published data dictionaries and reputable press. Each cell is one of yes, partial, no or unknown, with a note and an evidence URL; unknown was used whenever documentation could not establish the answer, and never inferred. Assessors did not probe any system beyond reading documentation. The full table with evidence is in appendix C and in the ancillary files published with the paper. Confidence is recorded per source; eight sources are at medium or low confidence because official pages could not be fetched (certificate or access errors) and the assessment leaned on search excerpts.

Table 4. Assessment criteria. C1 to C4 and C6 to C8 map onto R1 to R5; C5 onto R6; C10 onto R7; C9, C11 and C13 onto R8; C12 onto the catalog layer the profile composes.

Results. Figure 5 shows every source against every criterion, and figure 6 the totals per criterion.

Figure 5. Thirty-seven official sources in Colombia, Peru and Mexico against the thirteen criteria, from public documentation on 26 August 2026. Sources are ordered by score (yes = 1, partial = 0.5). The four sources at the top publish through a national catalog platform with a query API (Socrata's SODA on datos.gov.co) or under a governed domain standard (OCDS); the block at the bottom is single-record lookup forms. Column C10, agent surfaces, is empty. The full matrix is in appendix C.

Figure 6. Per-criterion totals across the 37 sources. Change feeds (C6) and agent surfaces (C10) are the rarest capabilities; freshness (C7) is mostly partial (a dataset-level date rather than a record-level one) or unknown; identifiers (C3) are mostly partial (a stable URL pattern that the institution does not document as such).

Four findings stand out.

Programmatic access is a minority property, and where it exists it is inherited. Six of 37 sources (16%) document an API for the assessed service and a further six a partial one. Of the six, four are Colombian datasets on datos.gov.co, whose Socrata platform provides a query API, field filters, paging and a system :updated_at column to every dataset it hosts; one is Peru's OECE, which publishes procurement under OCDS with a release API and yearly bulk files; one is Mexico's official gazette, the DOF, whose SIDOF system documents JSON services and a status dashboard. No institution in the sample designed and documented a per-record API for its own lookup service; every yes on C1 is a property of a platform or a domain standard the institution adopted. The four top-scoring sources (SECOP, Procuraduría, Supersociedades, RUES; 9.5 to 11.5 of 13) are exactly the four whose data is on datos.gov.co, and the fifth (OECE, 9.5) is the OCDS publisher. This is the strongest single piece of evidence for the profile's composition principle: the way to get a registry to Level 2 is to attach it to something that already has the properties, not to ask the institution to invent them.

Change and freshness are the rarest capabilities. One source (SECOP, via Socrata's :updated_at) offers a documented way to retrieve only what changed; nineteen offer something partial (a dataset-level last-modified date, or a date field in the record that a consumer can filter on with care); fifteen offer nothing. Record-level freshness (C7) is documented by eight, partially by eighteen, and unknown for ten, the highest unknown count of any criterion, which is itself a finding: the documentation does not say when the answer was true. These are the two requirements (R4, R5) that a consumer can least work around, and they are the two a platform like Socrata supplies for free and an institution's own form never does.

Agent surfaces are absent. No source in three countries publishes an llms.txt, an MCP server, a markdown rendering or any structured data meant for AI consumption; probes returned 404s or application shells. The three unknowns are hosts that could not be fetched. This matches the state of the field in section 2 and is the empty column the profile's R7 is written to fill. It is also the cheapest column to fill: everything in R7 is generated from the OpenAPI document and the schema, so a Level 2 publisher is one build step from Level 3.

The bottom of the table is the interactive form. Eight sources score at or below one point: the vehicle-fine and insurance lookups in Peru, the police and court dockets in Colombia, and a state prosecutor's bulletin in Mexico. Each is a page where a person types one identifier and reads one answer, with no API, no bulk, no schema, no timestamp and, for several, a per-session human verification step. These are among the most consulted registries in their countries. They are also, from the consumer's side, the sources with the highest latency and failure rates in section 7.2. The two facts are the same fact.

Per country, Colombia scores highest on average because of the catalog platform; Mexico has the most open access (C9: nine of nine) but the fewest query interfaces; Peru has the single best publisher (OECE) and the weakest tail. Licence terms (C13) are explicit for nine sources, partial for fourteen and unknown for ten; three national portals default to CC BY or CC BY-SA at the dataset level, which is what the yes and partial cells mostly reflect.

7.2 Production measurements#

Method. The reference implementation logs, for every authenticated request, the endpoint, the HTTP status, the end-to-end duration, whether the response was reused within its freshness window, and an error code when the status is 400 or above. No request or response bodies are logged. We report the window from 8 June to 26 August 2026 (80 days): 25,153 requests, of which 20,598 answered 200, 922 answered 202 (accepted for asynchronous completion), 1,833 answered 500 to 503 (the source failed or was unavailable), and 1,800 answered a client error (invalid input, unauthorised, or rate-limited). Durations are server-side, from request receipt to response, so they exclude the consumer's network but include the source's. We classify endpoints into the two archetypes of section 5.2: 72 source-paced lookup endpoints with at least one success, and the dataset-backed OECE endpoints (the SCJN dataset went live on the last day of the window and contributes two requests, which we exclude). Status polls for asynchronous jobs and the five content endpoints are reported separately and not used in the comparison.

Table 5. Latency by class. Server-side durations, HTTP 200 only, 8 June to 26 August 2026. Source-paced lookups additionally produced 922 asynchronous acceptances (202) and 1,225 upstream failures (500 to 503). The same contract answers in 75 ms at the median from a dataset maintained under the profile and in 2.6 s at the median, 27.9 s at the 95th percentile, when the source answers at its own pace.

Figure 7. Distribution of server-side latency for successful source-paced lookups answered by the source (top; the last bin collects everything above 30 s, 636 requests, 4.3%) and for lookups answered from the OECE dataset (bottom, in 50 ms bins). The axes differ by two orders of magnitude.

Figure 8. Median latency per source-paced endpoint, for the 52 endpoints with at least ten successful source-answered requests. Thirty-two endpoints answer in under five seconds at the median; twenty take longer, and six take more than twenty seconds. The consumer of a uniform contract inherits this spread from the sources.

The consumer inherits the source's variance. Across the 72 source-paced endpoints, the median latency of the median request was 2.6 s and the 95th percentile 27.9 s; 636 successful requests (4.3%) took longer than 30 s. Per endpoint (figure 8), medians range from a quarter of a second (an environmental sensor network that publishes a documented data API) to 24 s (a police certificate service that is an interactive form), with six of 52 endpoints above 20 s at the median. These are the same registries that sit at the bottom of figure 5. Nothing in the contract can hide this; asynchronous completion (922 requests) makes it survivable for the consumer but does not make it fast.

A dataset under the profile removes it. The 84 successful requests answered from the OECE dataset had a median of 75 ms and a 95th percentile of 366 ms, thirty-five times faster at the median than source-paced lookups and seventy-five times at the tail, with no upstream failures. Responses reused within their freshness window (2,888) show the same order of magnitude (100 ms median). The point is not that a database is faster than a web form; it is that the profile's R4 and R5 are what make a maintained dataset legitimate: a consumer can see as_of, can ask updated_after, and therefore does not need to go to the source for every question. A dataset without those two fields is a stale copy; with them it is a publication.

Availability is the source's. Of 25,153 requests, 1,833 (7.3%) failed with a 5xx status; the top error codes name the source (procurement, disciplinary records, company register, court docket, fiscal records) or a content provider. Against the source-paced successes alone, the upstream failure rate was 6.5%; against the dataset, zero. One request in fourteen is the cost, to a consumer, of a registry that has no availability commitment (C11: one yes in 37), and it is a cost the consumer pays in retries, timeouts and, for agents, in wrong conclusions drawn from a failed call.

7.3 Threats to validity#

The source assessment is documentary. It measures what institutions publish about their services, which is the right object for a profile whose Level 3 is about discoverability, but it can under-state capability that exists undocumented and over-state capability that is documented and broken. Ten cells are unknown for the freshness criterion alone. Eight sources are at medium or low confidence because official hosts refused automated fetches, an irony we note. The rubric was applied by one assessor per country with a fixed instruction set; a second assessor would move some partial cells in both directions, and we publish the evidence so that they can.

The production measurements are from one operator's traffic, shaped by that operator's customers (predominantly Colombian financial-services consumers, hence the weight of Colombian endpoints) and by its own engineering. The dataset class is small (n = 84) and covers one source; the comparison is between archetypes, not a controlled experiment, and the difference is large enough that the small sample does not threaten the direction of the result. Durations exclude the consumer's network. Requests that were rate-limited (1,316) or malformed are excluded from latency but included in the totals.

Finally, the author operates the reference implementation and has an interest in the profile's adoption. We have tried to make that a strength rather than a weakness by reporting what the implementation does not satisfy (section 5.4) and by publishing the aggregated data behind every number in this section as ancillary files (per-class and per-bin distributions; per-endpoint traffic is not published).

8. Adoption and governance#

A profile that nobody publishes under is a paper. This section sets out how AGORA could be adopted, drawn from the two domain standards that achieved global uptake and adjusted for the institutions of the region where the reference implementation runs.

Lessons from GTFS and OCDS. GTFS began in 2005 as a data exchange between one transit agency, TriMet in Portland, and one consumer, Google Maps; it was a handful of CSV files that solved routing, and it spread because developers built applications on it and agencies wanted to be in them. Its name changed from Google to General Transit Feed Specification in 2010, which its stewards credit with reducing resistance from agencies and vendors wary of one company owning their data format. OCDS launched in 2014 with a JSON schema, a validator and a helpdesk, stewarded by a non-profit funded by philanthropy, and it spread through flagship publishers whose data others wanted to compare. Both standards stayed small, both shipped tooling before they sought mandates, and both moved to a neutral steward before they were widely adopted. Neither began as a specification looking for an implementation. We take these as the three conditions for the profile.

Stage one: reference implementation and validators. The profile's first form is running software, not a document: the reference implementation, a conformance validator that any publisher can run against any interface, and a badge the validator issues per level. The validator is the specification; publishing it first keeps the prose honest. In this stage the profile adopts every relevant domain standard on output, so that an OCDS or ECLI publisher sees the profile as a way of being read by agents rather than as a competitor, and it publishes the agent surfaces (R7) for every source it covers, because those are the surfaces with no government competition today.

Stage two: a minimal open specification. Once the validator has run against a dozen publishers and the requirements have survived contact with them, the profile is written down as a specification: the eight requirements, the envelope schema, the test definitions, and the composition table, under CC0 or CC BY 4.0, with the reference implementation and validator under an OSI licence. The specification stays at the altitude of section 4.2: it names what a validator can check and nothing else. Proposals to add quality, completeness or semantics requirements are, by policy, redirected to the domain standards where they belong.

Stage three: neutral stewardship. A standard controlled by one company will not be adopted by governments, and should not be. The profile's stewardship passes to a working group with publishers, consumers and civil-society members, hosted by a body governments already trust. In Latin America the candidates exist: the Latin American Open Data Initiative (ILDA), which co-runs the regional OCDS helpdesk; Red GEALC, the digital-government network of the Organization of American States; the Inter-American Development Bank's digital-government programmes; and the national digital-government offices that already run the catalogs (MinTIC in Colombia, PCM's Secretaría de Gobierno y Transformación Digital in Peru, the ATDT in Mexico). The profile's name is neutral by design and carries no operator's brand.

Demand first. GTFS and OCDS were pulled by consumers, not pushed by mandates. The profile's consumers are already present: lenders, insurers, compliance and KYC teams, journalists, civic technologists and, now, every agent framework that can read an MCP tool list. The adoption strategy is therefore to make those consumers visible to publishers, through the reference implementation's usage and through the validator's badge, so that an institution sees a queue of applications waiting on its registry rather than a request to do work.

Alignment with mandates. Where mandates exist, the profile is the form of compliance. The European High-Value Datasets regulation requires APIs and bulk download for company registers and mobility data; Level 2 satisfies both clauses and adds what the regulation leaves unspecified (identifiers, change, provenance). The OPEN Government Data Act requires inventories; the profile's DCAT description is one. In Colombia, Peru and Mexico the transparency laws and open-data decrees require publication and catalogs; the profile gives the catalogs something to point at. Mexico's 2025 open-data guidelines for the federal administration are the most recent instrument in the region and the natural place for a Level 1 requirement to appear.

What would change this strategy. Three developments would. If a government or the European Union publishes an official cross-registry access or agent standard, the profile's work becomes conformance and tooling for that standard rather than a parallel specification. If DCAT-AP or DCAT-US adds record-level query and change semantics, the profile becomes a DCAT-AP extension. If OCDS, BODS or Akoma Ntoso coverage in the region deepens to the point where most registries are published under a domain standard, the profile's value concentrates in R4, R5 and R7, the parts those standards do not cover, and it should shrink accordingly.

9. Limitations and future work#

The profile is untested outside its author's implementation. Every requirement has been exercised by one operator against several dozen sources in three countries. It has not been implemented by a government, and the harness has not been run inside an institution on its own systems. The two are the obvious next steps, and the first pilot will change the profile.

Entity resolution is declared, not solved. R2 asks publishers to declare identifier namespaces so that consumers can relate records across registries without string matching. It does not resolve entities: the profile deliberately stops at "registry X calls this a" and leaves "a in X is b in Y" to a resolution service, because a wrong merge is worse than no merge and the property is not testable from outside. A profile for resolution services, composed over LEI and org-id.guide, is future work.

Personal data. Many of the registries in the assessment concern people: disciplinary records, criminal certificates, vital status, affiliations. The profile's bulk requirement (R6) and change feed (R4) are not appropriate for every such registry, and a conformant publisher of personal records may legitimately stop at lookup-by-identifier with rate limits and purpose declarations. The profile should acquire a personal-data annex that says which requirements a lawful basis relaxes, written with data-protection authorities rather than for them.

The assessment is a snapshot by three assessors. Its value is in the evidence trail and the rubric, which we publish so that it can be re-run, disputed and extended. A community-maintained assessment with a second rater per cell would be a better instrument.

The production evidence is one operator's. The dataset class is small and the traffic mix is that operator's customers. A second implementer's numbers would be the most useful thing a reader could contribute.

Agents as evaluators. The strongest test of Level 3 is whether an agent, given a question and the surfaces in R7, answers it correctly and cites the record. We have observed this qualitatively and have not measured it. A benchmark of registry questions with ground truth, run against publishers at each level, is the evaluation this paper should have had and the next one will.

10. Conclusion#

The open-data movement built the layers it set out to build. Governments publish; catalogs describe; domain standards encode. What it did not build, because no single layer owned it, is the contract a consumer needs to use one record: resolve it, query it, follow it, trust its timestamp, and do so from a program. That gap was tolerable while the consumer was a person with a browser and time. It is not tolerable for an agent, and agents are now a measurable share of the traffic public data receives.

AGORA is a small answer to a large gap. Eight requirements, three levels, one envelope, and a validator, composed over the standards that already exist rather than beside them. The reference implementation shows that the contract can be held uniformly across 46 sources that share nothing else, and the production measurements show what the contract cannot hide: a registry answered at a web form's pace is thirty-five times slower at the median and seventy-five times slower at the tail than the same registry published under the profile, and fails one time in fourteen. The assessment of 37 sources shows that the properties the profile asks for are rare, that where they exist they were inherited from a platform or a domain standard, and that the agent surfaces are missing everywhere.

The harness is the part we expect to matter most in practice. The cost of writing a typed, documented, agent-visible interface over a registry has collapsed; the cost of being wrong has not. Letting a model propose and a fixed set of gates dispose is how an institution can have the first without paying the second. The gates are the profile's tests. That is the whole design: a specification small enough to be a validator, a validator strict enough to be a gate, and a loop in which the machine that writes is never the machine that decides.

Appendix A. Conformance checklist#

Appendix B. Envelope schema#

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "title": "AGORA response envelope",
  "type": "object",
  "required": ["found", "source", "as_of", "license"],
  "properties": {
    "found": { "type": "boolean", "description": "Whether a record exists for the request. false is a definitive answer, not an error." },
    "source": {
      "type": "object", "required": ["id", "name"],
      "properties": {
        "id": { "type": "string", "description": "Publisher identifier, stable across records." },
        "name": { "type": "string" },
        "org_id": { "type": "string", "description": "org-id.guide identifier of the institution, when one exists." }
      }
    },
    "as_of": { "type": "string", "format": "date-time", "description": "Instant the underlying data was last synchronised, or the instant of retrieval for a live lookup." },
    "record_version": { "type": "string", "pattern": "^sha256:[0-9a-f]{64}$", "description": "Hash of the JCS-canonicalised data member. Required when found is true." },
    "license": { "type": "string", "format": "uri" },
    "data": {
      "type": "object", "description": "The record, conforming to its declared schema. Absent when found is false.",
      "properties": {
        "_updated_at": { "type": "string", "format": "date-time", "description": "Instant the publisher last changed this record. Required at Level 2." },
        "_deleted_at": { "type": "string", "format": "date-time", "description": "Present on tombstones in the change feed." }
      }
    }
  },
  "if": { "properties": { "found": { "const": true } } },
  "then": { "required": ["record_version", "data"] }
}

Appendix C. Source assessment matrix#

Y = yes, P = partial, N = no, ? = unknown. Score counts yes as 1 and partial as 0.5. The per-cell notes and evidence URLs are published as an ancillary file with the paper; the assessment date is 26 August 2026.

The three national catalogs were characterised alongside the sources. datos.gov.co is a Socrata (Tyler Technologies Data & Insights) instance publishing a DCAT-US data.json, a per-dataset query API with field filters, paging and a system :updated_at column, and CC BY-SA 4.0 on every sampled dataset; its discovery API reported 8,391 datasets. datosabiertos.gob.pe is a DKAN (Drupal) instance with a CKAN-compatible catalog API, governed by PCM's Secretaría de Gobierno y Transformación Digital under DS 016-2017-PCM, DL 1412 and later norms, with no portal-wide default licence; its homepage reported 4,668 datasets from 390 entities. datos.gob.mx is a CKAN 2.11 instance governed by the Agencia de Transformación Digital y Telecomunicaciones under the September 2025 lineamientos, with a working but undocumented CKAN action API and CC BY 4.0 on datasets; its CKAN API reported 1,730 datasets against a homepage claim of 7,420.

References#

• Anthropic (2025). Donating the Model Context Protocol and establishing the Agentic AI Foundation. 9 December 2025. https://www.anthropic.com/news/donating-the-model-context-protocol-and-establishing-of-the-agentic-ai-foundation
• Attard, J., Orlandi, F., Scerri, S. and Auer, S. (2015). A systematic review of open government data initiatives. Government Information Quarterly 32(4), 399-418. https://doi.org/10.1016/j.giq.2015.07.006
• Australian Government (2024). API Design Standard. https://api.gov.au/
• Berners-Lee, T. (2006, 2010). Linked Data. W3C Design Issues; five-star scheme added 2010. https://www.w3.org/DesignIssues/LinkedData.html
• Cloudflare (2025). 2025 Cloudflare Radar Year in Review. https://blog.cloudflare.com/radar-2025-year-in-review/
• Congreso de Colombia (2014). Ley 1712 de 2014, Ley de Transparencia y del Derecho de Acceso a la Información Pública Nacional. Diario Oficial 49.084.
• Council of the European Union (2011). Council conclusions inviting the introduction of the European Case Law Identifier (ECLI). OJ C 127, 29 April 2011.
• Croma (2026). Croma API documentation. https://docs.usecroma.com
• European Union (2019). Directive (EU) 2019/1024 on open data and the re-use of public sector information. OJ L 172.
• European Union (2023). Commission Implementing Regulation (EU) 2023/138 laying down a list of specific high-value datasets. OJ L 19.
• European Union (2024). Regulation (EU) 2024/903 laying down measures for a high level of public sector interoperability (Interoperable Europe Act). OJ L, 2024/903.
• Frictionless Data (2024). Data Package (v2) is released. https://datapackage.org/blog/2024-06-26-v2-release/
• GLEIF (2026). ISO 17442: the LEI code structure. https://www.gleif.org/en/about-lei/iso-17442-the-lei-code-structure
• Google (2025). Introducing the Data Commons Model Context Protocol (MCP) Server. Google Developers Blog, 24 September 2025. https://developers.googleblog.com/en/datacommonsmcp/
• Government Digital Service (2024). API design guidance. https://www.gov.uk/government/collections/api-design-guidance
• GSA (2026). DCAT-US Schema v3.0 and v1.1. resources.data.gov. https://resources.data.gov/resources/dcat-us3/
• GTFS (2026). General Transit Feed Specification. https://gtfs.org/
• Howard, J. (2024). The /llms.txt file. 3 September 2024. https://llmstxt.org/
• ISO (2025). ISO 19168-1:2025 Geographic information. Geospatial API for features. Part 1: Core.
• Janssen, M., Charalabidis, Y. and Zuiderwijk, A. (2012). Benefits, adoption barriers and myths of open data and open government. Information Systems Management 29(4), 258-268. https://doi.org/10.1080/10580530.2012.716740
• MCP (2026). Model Context Protocol specification, version 2026-07-28. https://modelcontextprotocol.io/specification/2026-07-28/changelog
• México (2015). Decreto por el que se establece la regulación en materia de Datos Abiertos. DOF, 20 February 2015.
• México (2025). Ley General de Transparencia y Acceso a la Información Pública. DOF, 20 March 2025; Lineamientos en materia de Datos Abiertos de la Administración Pública Federal. DOF, 11 September 2025.
• MinTIC (2026). Lenguaje Común de Intercambio de Información. https://lenguaje.mintic.gov.co/
• Nottingham, M. (2017). RFC 8288: Web Linking. IETF.
• Nottingham, M., Wilde, E. and Dalal, S. (2023). RFC 9457: Problem Details for HTTP APIs. IETF.
• Noy, N. (2018). Making it easier to discover datasets. Google, 5 September 2018.
• OASIS (2018). Akoma Ntoso Version 1.0, Part 1: XML Vocabulary. OASIS Standard, 29 August 2018.
• OECD (2023). 2023 OECD Open, Useful and Re-usable data (OURdata) Index: results and key findings. https://doi.org/10.1787/a37f51c3-en
• OGC (2022). OGC API - Features - Part 1: Core, version 1.0.1. OGC 17-069r4.
• Open Contracting Partnership (2026). The Open Contracting Data Standard. https://standard.open-contracting.org
• Open Data Charter (2015). Principles. https://opendatacharter.org/principles/
• Open Ownership (2025). Pausing development of the Beneficial Ownership Data Standard. 18 November 2025.
• OpenAPI Initiative (2021). OpenAPI Specification v3.1.0.
• Perú (2017). Decreto Supremo N° 016-2017-PCM, Estrategia Nacional de Datos Abiertos Gubernamentales 2017-2021. El Peruano, 12 February 2017.
• Perú (2018). Decreto Legislativo N° 1412, Ley de Gobierno Digital. El Peruano, 13 September 2018.
• Rundgren, A., Jordan, B. and Erdtman, S. (2020). RFC 8785: JSON Canonicalization Scheme (JCS). IETF.
• Safarov, I., Meijer, A. and Grimmelikhuijsen, S. (2017). Utilization of open government data: a systematic literature review of types, conditions, effects and users. Information Polity 22(1), 1-24. https://doi.org/10.3233/IP-160012
• Sebastopol (2007). The 8 Principles of Open Government Data. https://opengovdata.org/
• SEMIC (2025). DCAT-AP 3.0.1. SEMIC Recommendation, 27 October 2025. https://semiceu.github.io/DCAT-AP/releases/3.0.1/
• Smith, K. (2025). RFC 9727: api-catalog: a well-known URI and link relation to help discovery of APIs. IETF.
• StateScoop (2026). Maryland is the only state with an llms.txt file. 12 January 2026. https://statescoop.com/llmstxt-government-websites-ai/
• Sunlight Foundation (2010). Ten Principles for Opening Up Government Information.
• Technical.ly (2026). Maryland uses llms.txt to guide AI chatbots. https://technical.ly/civics/maryland-uses-llms-txt-to-guide-ai-chatbots/
• Treasury Board of Canada Secretariat (2024). Government of Canada Standards on APIs.
• United States (2019). Foundations for Evidence-Based Policymaking Act of 2018, Title II: OPEN Government Data Act. Public Law 115-435.
• W3C (2013). PROV-O: The PROV Ontology. W3C Recommendation, 30 April 2013.
• W3C (2024). Data Catalog Vocabulary (DCAT), Version 3. W3C Recommendation, 22 August 2024. https://www.w3.org/TR/vocab-dcat-3/
• Wilkinson, M. D. et al. (2016). The FAIR Guiding Principles for scientific data management and stewardship. Scientific Data 3, 160018. https://doi.org/10.1038/sdata.2016.18
• Zuiderwijk, A. and Janssen, M. (2014). Open data policies, their implementation and impact: a framework for comparison. Government Information Quarterly 31(1), 17-29. https://doi.org/10.1016/j.giq.2013.04.003