Enterprise Data

Data Provenance & Security Whitepaper

Version 1.0 · 16 October 2026 · Assay Systems, Ottawa, Ontario, Canada

This paper is written for the engineers, security and legal reviewers of a company that takes the Assay Systems register under an Enterprise Data contract. It sets out where every record comes from, under which licence, how it is cleaned and de-duplicated, how it is protected and delivered, and the exact shape of the data.

Sources and licences
The data pipeline
De-duplication and entity resolution
Personal data
Security
Enterprise delivery and service levels
Response structure and JSON schemas

1. Sources and licences

Every record in the register is taken from a public procurement record that a government, or the public body it designates, publishes openly for reuse. Nothing is taken from behind a login, a paywall or a terms-of-use wall. Every row carries the URL of its source dataset, the licence it is published under and the publisher's own record reference, so any figure can be traced back to the government record it came from.

Publishers and licences

Country or region	Publisher	Licence
Canada – contracts	Government of Canada, proactive disclosure of contracts (open.canada.ca)	Open Government Licence – Canada 2.0
Canada – grants and contributions	Government of Canada (open.canada.ca)	Open Government Licence – Canada 2.0
United States	USAspending.gov	U.S. Government work, public domain (17 U.S.C. 105)
European Union and EEA countries	Tenders Electronic Daily (TED), Publications Office of the EU	Reuse under Commission Decision 2011/833/EU
Countries publishing in the Open Contracting Data Standard	National procurement authorities (OCDS publications)	The publisher's licence, named in each row: CC BY 4.0, CC BY-SA 4.0, ODbL 1.0, ODC PDDL 1.0 or a national open-data licence
Australia, United Kingdom, New Zealand, Norway	AusTender, Contracts Finder, GETS, Doffin	The publisher's open government licence, named in each row

Sources published under a non-commercial licence (for example CC BY-NC-SA 4.0) stay open on the public site as summaries and are excluded from every paid service, Enterprise Data included. Share-alike sources are delivered under the same licence, as that licence requires.

2. The data pipeline

The register is built by an automated pipeline with six stages. Each build writes a manifest that records what went in, what was removed and what failed a check.

Acquire. Official bulk files and APIs of each publisher are downloaded whole, on the publisher's own cycle: daily where the source is published daily, monthly where it is published monthly.
Normalise. Every country is mapped to one schema (section 7): buyer, supplier, value, currency as published, dates in ISO 8601, procedure, number of bids, commodity code.
De-duplicate. Amendments and repeated publications are collapsed; supplier spellings are merged (section 3).
Verify. Each line of the register is reconciled between the published pages and the data layer: the number of contracts must match exactly and the total value must agree within one percent. Lines that do not reconcile are flagged in the manifest.
Publish. The verified register is packed and published to the edge storage behind the site and the API.
Deliver. Through the API, as bulk files (gzip-compressed JSON Lines), or into the company's dedicated bucket (section 6). Every row is stamped with the date it was last updated.

3. De-duplication and entity resolution

Raw government contract data cannot be summed as published. The register corrects two structural problems before any figure is counted.

Amendments: one contract, one value

The Government of Canada publishes each amendment to a contract as a separate row, and the value on that row is the full value of the contract after the amendment, not the increment. Adding the rows counts the same contract several times.

Example from the published record: one contract signed on 5 October 2011 appears in four rows. Their sum is $1,088,662,391; the real value of the contract is $348,625,938, the last published figure. Across the federal register, summing raw rows overstates the value of contracts by 43 percent.

The register keys a contract by supplier, date signed, original value and buying department, and keeps the last published record in each key, which carries the final value. Grants and contributions are keyed by the agreement number, so a grant amended or republished under a new reference is still counted once.

Supplier names: one company, one record

The same supplier is written many ways in government records: case, punctuation, legal suffixes, truncation, misspellings. The register merges spellings only inside one financial key: the original value to the cent, the start date and the buying department must all match. Name similarity is used as a limit on a merge, never as proof of one.

Merges are graded exact or probable. In the Canadian register 6,420 families of spellings were merged this way, 5,934 exact and 486 probable. For example, five spellings of one detection-equipment supplier under one Canada Border Services Agency contract resolve to a single supplier record.

4. Personal data

Government registers sometimes name a private individual as a supplier. Rows naming private persons are removed from the paid data layer before delivery; the manifest records how many were removed.
The contact of a buying office is delivered only as the department itself publishes it: a procurement mailbox, not a person.
No data about the people who use the register is sold or shared. Payments are processed by Stripe; card details are never seen or kept by Assay Systems.

5. Security

Transport. The site and the API answer over HTTPS (TLS) only.
Access. Every key is issued on request, after review by hand, and sent only to the email address of the request. Keys are sent in the X-API-Key header and carry a tier that decides which data they reach.
Isolation. Enterprise keys are issued per company and are not shared with any other customer; a key used against its terms is closed.
Infrastructure. The register is served from a global edge network with built-in protection against denial-of-service traffic; the data layer is held in object storage, separate from the public pages.
Integrity. Every row names its source, licence and the publisher's record reference, so the delivered data can be checked against the government record at any time.

6. Enterprise delivery and service levels

Dedicated infrastructure. A private endpoint and a storage bucket set up for the company, with isolated keys and no rate limits.
Bulk files. The whole register for the countries in the contract as bulk files, followed by a delta feed: new awards, amendments and changed end dates.
Service level. Availability of 95 percent, measured monthly, is written into the Enterprise contract. For any month below it, a service credit of 5 percent of that month's fee is applied to the next invoice.
Contract. A written agreement, one quarter at a time, sets the countries, the lines, the delivery, the service level and the permitted use. Requests: Enterprise Data or contact@assay-systems.com.

7. Response structure and JSON schemas

Every API answer is JSON in UTF-8. A machine-readable list of the endpoints is at GET https://assay-systems.com/api/v1.

Envelope of every record answer

{
  "api": "assay-systems/v1",
  "key_tier": "none | open | commercial",
  "retrieved": "YYYY-MM-DDThh:mm:ssZ",
  "source": "Assay Systems register, https://assay-systems.com/register/",
  "data": { ...record... }
}

A record (/api/v1/supplier/{country}/{id}, /line/, /contract/, /grants/) holds id, type, country, name, url, register, line, summary, figures, sections and cite_as.

Contract row (paid layer and bulk files)

Field	Type	Meaning
`id`	string	Stable row identifier in the register
`country`	string	ISO 3166-1 alpha-2 code, lower case
`buyer`	string	Buying department or agency
`buyer_id`	string or null	Register identifier of the buyer
`office`	string or null	Buying office
`office_email`	string or null	Procurement mailbox, as published by the department
`office_phone`	string or null	Office telephone, as published
`supplier`	string	Supplier, after entity resolution
`supplier_id`	string or null	Register identifier of the supplier
`line`	string or null	Line of business in the register
`code`	string or null	Commodity or service code of the source
`description`	string or null	Description, as published
`value`	number	Final contract value, after amendments
`currency`	string	ISO 4217 code, as published
`signed`	date or null	Date signed, YYYY-MM-DD
`ends`	date or null	End date, YYYY-MM-DD
`procedure`	string or null	Procurement procedure (open, limited, sole source)
`bidders`	integer or null	Number of bids received
`record_ref`	string or null	The publisher's own record reference
`source_url`	string	Source dataset
`licence`	string	Licence of the source
`updated`	date	Date the row was last updated in the register

Paged answers wrap rows as {"source", "key_tier", "licence", "register", "built", "data": {...rows, page...}}. Bulk files carry the same rows, one JSON object per line, gzip-compressed, with a manifest.json per country.

Endpoints

GET /api/v1/countries · GET /api/v1/search?q=&country=&limit=
GET /api/v1/supplier/{country}/{id} · /line/{country}/{id} · /contract/{country}/{id} · /grants/{country}/{id}
GET /api/v1/uncontested · /uncontested/{country}[/{page}] · /page/{path under /register/}
Paid: GET /api/v1/line/{country}/{id}/contracts?page=&ends_before=&buyer= · /supplier/{country}/{id}/contracts?page= · /ending?country=&line=&before= · /solo · /solo/{country}?kind=pairs|locks|buyers