Semantic Systems / Language / Glyphs
Approved OCDS Jurisdiction Expansion Assessment
Report summary
The current expansion request is not yet approvable as a keep decision because the submission does not identify the exact publisher jurisdiction, the exact HTTPS source host allowlist, or the named human reviewer required to finalize a feed decision. Public OCDS guidance supports validating a source
Key topics
- Semantic Systems / Language / Glyphs
- Semantic Systems
- Language
- Glyphs
- Research Archive
- Audit
- Architecture
- Governance
- Approved
Research provenance
For citation, use the report title and canonical URL. Archival presence does not establish authorship or promote report statements into portfolio evidence.
Source availability: 23 citation markers in the source export have no recoverable source links. Those markers are omitted from this reader; any supplied bibliography and ordinary links remain. Check the original sources before relying on the cited claims.
This page renders the archived Markdown as safe, formatted HTML. It is background research and does not become a portfolio claim without evidence review.
Full report
On this page
Executive conclusion
The current expansion request is not yet approvable as a keep decision because the submission does not identify the exact publisher jurisdiction, the exact HTTPS source host allowlist, or the named human reviewer required to finalize a feed decision. Public OCDS guidance supports validating a source by tracing releases and records, checking whether buyer, supplier, status, value, and milestone fields are actually populated, and reviewing source quality and update timing. The public OCP Data Registry also shows that publishers differ sharply in freshness and field completeness, so a source decision cannot be justified from “OCDS” alone. On the evidence available, the correct decision is change, not keep: require the exact configured publisher host and a named reviewer before continuing the feed.
That conclusion is stronger than a simple “not enough data” response. The public record shows that some jurisdictions are current and operationally useful, such as Kenya PPRA, Uruguay ARCE, Guatemala MINFIN, South Africa National Treasury, and UK Contracts Finder, while others are stale or explicitly no longer updated, such as Nepal PPMO, Nigeria Budeshi, Edo State, and Gombe State. Because source quality varies this much, continuing a feed without the exact jurisdiction would fail the user’s own guardrail to rely on an exact host allowlist and measured source quality rather than record volume alone.
What a valid OCDS source review must prove
OCDS publishes contracting data as releases and records. Releases are event-level snapshots for a contracting process, while a record indexes all releases for one process and can include a compiled release with the latest value of each field. That means a source review should validate not just that a page exists, but that the publisher has usable release or compiled-record provenance for the facts being normalized.
For the fields you asked to normalize, OCDS explicitly models buyer and supplier relationships in structured form. The OCDS schema says parties are gathered in a top-level parties section and cross-referenced elsewhere; tender data can reference the procuring entity and estimated tender value; awards carry status, date, value, and suppliers; and contracts are linked back to awards because supplier information is carried in the award.
The standard also gives the status vocabulary needed for deterministic state classification. tender.status uses a tender-status codelist, awards move through states like pending, active, cancelled, and unsuccessful, and milestones use statuses such as scheduled, met, notMet, and partiallyMet. Milestones are therefore not a vague enrichment field; they are a structured signal for workflow timeliness when the publisher actually includes them.
OCDS guidance on data quality says publications should at minimum be registered, reviewable, and appropriate to the schema. In practice, for a commercial feed, that translates into a concrete validation checklist: registered OCID prefix, accessible public files or API, reviewable structure, semantically correct buyer/supplier/value fields, and current enough retrieval dates to support the watchlist use case.
What the public OCDS ecosystem shows about source quality
The public OCP Data Registry demonstrates why the source must be identified exactly before approval. It lists both active and stale publishers side by side, with date ranges, update frequency, retrieval dates, source hosts, licenses, counts, and sometimes explicit data-quality findings. For example, Kenya PPRA is listed with daily updates and data through June 2026, while Nepal PPMO is listed as no longer updated by the publisher and stops in August 2018; Nigeria Budeshi stopped in November 2021; Edo State stops in December 2021; and Gombe State stops in May 2023.
The registry also shows that “recent” and “useful” are not interchangeable. The Netherlands Ministry of Economic Affairs and Climate Policy has data through March 2026 with retrieval in July 2026 but only every-three-months updates; South Africa National Treasury reaches July 2026 but with update frequency marked unknown; Portland, Oregon is weekly through March 2026; and Uruguay ARCE is real time through July 2026. Those differences matter if the intended commercial use is pursuit timing rather than long-horizon market research.
The same public registry shows that raw size is not enough. Some datasets are large but contain significant quality warnings; others are smaller but cleaner or more current. That is consistent with the user’s operating loop, which says to keep, change, or disable the feed based on measured source quality, not record volume alone. The public evidence supports that approach.
Worked public examples of source validation
Kenya PPRA as a current but field-limited example
Kenya’s PPRA publication is a good example of a source that is timely enough to matter commercially, but not automatically rich enough for every workflow. The public registry says Kenya PPRA publishes public procurement data through PPIP, covers national and county buyers with stated exclusions only for classified procurements, updates daily, and was last retrieved on July 6, 2026. It also provides a registered OCID prefix, ocds-5whusi, which is a positive provenance signal.
For the fields you asked about, Kenya has meaningful tender and award coverage in aggregate: 255,914 tenders, 109,061 awards, 109,061 contracts, and 79,769 suppliers. That is enough public evidence to say the jurisdiction produces a substantial stream of notices and awards. But the same source also says there are zero milestones, zero documents, no planning activities, and several data-quality issues: some awards and contracts appear as empty arrays, buyers lack organizational identifier schemes, suppliers use an invalid scheme, and some buyer and supplier names are missing from parties and only recoverable from embedded fields. That makes Kenya a plausible feed for notice and award monitoring, but a weak fit if milestone-driven workflow control is important.
Kenya also provides a good example of deterministic cost boundaries. The public registry lists the all-time JSON download at 42 MB, the 2026 JSON at 2 MB, the all-time CSV at 54 MB, and the 2026 CSV at 3 MB. Those are exact public transfer sizes, not estimates. If this were the configured publisher, a dry import could therefore be scoped precisely from public file sizes before any deeper commitment.
The classification for Kenya is also relatively clear from the public source. The registry explicitly says PPIP is designed to publish tender notices and contract awards, supported by an executive-order transparency requirement. That means the source contains both transactional signals and a policy signal. I did not find public evidence in the cited source that this feed is a grants feed, and the registry does not describe it as one.
UK Contracts Finder as a richer but quality-conditioned example
UK Contracts Finder represents a different tradeoff. Public registry data says it is used by non-devolved public sector contracting authorities to publish procurement opportunities and contract awards above defined thresholds, that the dataset runs from November 2016 through July 2026, updates in real time, and was last retrieved by the registry on July 7, 2026. The retrieved source host is the Contracts Finder OCDS API documentation endpoint on www.contractsfinder.service.gov.uk, and the publication carries an Open Government Licence.
Compared with Kenya, Contracts Finder is structurally richer in the fields relevant to your prompt. The registry shows 588,327 tenders, 433,897 awards, 567,368 suppliers, 21,337 planning activities, 1,171,453 documents, and 15,114 milestones. It also states that the publication follows the OCDS for the European Union Profile and uses several extensions. In other words, this is the kind of source that can support notice, award, and downstream milestone analysis better than a minimalist feed can.
However, Contracts Finder is not “clean by default.” The registry lists several quality issues: supplier identifier collisions can cause only one supplier to be retained where an award has multiple suppliers; important fields such as supplier names are sometimes empty; a minority of relevant dates are unrealistic; and some document URIs are invalid or only resolvable internally. That means a feed based on this source can still be commercially valuable, but only if downstream normalization handles supplier ambiguity, date validation, and document-link failures explicitly.
The deterministic costs are again public and exact. The registry lists the 2026 JSON download at 10 MB, the all-time JSON at 395 MB, the 2026 CSV at 13 MB, and the all-time CSV at 486 MB. Those figures are direct public evidence for transfer and storage sizing in a dry import.
Validated facts, unknowns, and decision logic for this request
For the configured source in this request, the strongest validated public fact is actually a limitation: the exact jurisdiction and exact publisher host were not supplied, so the source-specific provenance required by your operating loop cannot be checked. Without the exact host, I cannot validate the release-package endpoint, confirm whether the public source is an API or downloadable record package, verify whether the feed is notices only versus awards only versus mixed, or test whether buyer, supplier, value, and milestone fields are populated for the intended jurisdiction. That is a blocking unknown, not a minor omission.
The public evidence does let us state what must be captured once the exact source is provided. A compliant review should record: the source host and retrieved endpoint; whether the source publishes releases, records, or compiled releases; the OCID prefix if present; whether buyer, supplier, tender status, award status, tender value, award value, contract value, and milestones are structurally present; the publisher’s stated update frequency and latest observed retrieval date; and any public quality defects that would distort buyer matching, supplier matching, state classification, or value normalization.
The “notice, award, grant, policy signal, local contract” distinction also needs to be source-specific. Public sources show that some feeds are clearly notices-plus-awards with a policy backdrop, like Kenya PPRA and UK Contracts Finder; some are local-contract oriented, like the City of Portland feed listed in the registry; and some publishers are historical or discontinued, which may still have research value but would be poor candidates for active pursuit monitoring. For the present request, the exact category mix of the configured source remains unknown.
Deterministic cost view and required human sign-off
Because the exact publisher is missing, the only defensible costs I can show are deterministic public examples. Kenya PPRA has an all-time JSON footprint of 42 MB and a 2026 JSON footprint of 2 MB. UK Contracts Finder has an all-time JSON footprint of 395 MB and a 2026 JSON footprint of 10 MB. Those figures show that even among active public publishers, ingest cost can vary by roughly an order of magnitude, which is another reason an exact host and jurisdiction must be identified before approval.
Your guardrail also requires a named human decision. No named reviewer was provided in the request, so the operating loop cannot be completed. The next valid state is not a final keep decision; it is a gated handoff to a specifically named reviewer who owns the dry-import review, the disposition label, the pursuit-cost record, and the eventual keep/change/disable call. That requirement comes directly from your process and is reinforced by the public reality that source quality varies materially across publishers.
Decision: Change. Do not continue this feed as currently specified. Require, at minimum, the exact jurisdiction, the exact HTTPS publisher host allowlist, and a named human reviewer before running the six-step operating loop. Public OCDS evidence shows that some jurisdictions absolutely can justify an ongoing feed, but that decision must be source-specific, provenance-backed, and field-quality-validated. On the current evidence, a keep decision would be premature.
Named human decision: Unassigned — blocking issue. No final approval should be recorded until a specific reviewer is named.