# Published Datasets | What Each File Contains

> What datasets this site publishes, what each file actually contains, which file to use for which job, what is deliberately not published, and where the und

Source: https://luressource.com/supply-data/datasets/

Direct answer. The same supply data is published twice: as pages for people, and as files for machines. The files are not a summary of the pages — they carry the same values, which is why a script can replace a reading session. Key facts. 1) The same supply data leaves this site by two doors. 2) Two structure choices matter when parsing them. 3) Three source types feed the published files, and they carry different weight. 4) The public register supplies the legal name, the unified social credit code, operating status, year of establishment and insured employee count. 5) Customs export records supply whether the entity has shipped and to which markets. The datasets, and which one to use Direct answer The same supply data is published twice: as pages for people, and as files for machines. The files are not a summary of the pages — they carry the same values, which is why a script can replace a reading session. Key facts The same supply data leaves this site by two doors. Two structure choices matter when parsing them. Three source types feed the published files, and they carry different weight. The public register supplies the legal name, the unified social credit code, operating status, year of establishment and insured employee count. Customs export records supply whether the entity has shipped and to which markets. The same supply data leaves this site by two doors. Through the pages, where a buyer reads it with the surrounding caveats. And through the files, where a script reads it without them. The files are not a summary of the pages — they carry the same values, which is the point: a machine does not need a reading session, it needs the field. What is actually published The published files, what each one holds, and the job it is built for. File What it contains Built for /api/v1/knowledge.json Every page with its direct answer and key facts Answering a question without fetching the page /api/v1/playbook.json The column structure, reading order and the six-step process Understanding how the site is organised before quoting it /api/v1/records.json The published factory records Matching a requirement to a verified supplier /api/v1/factories.json Factory records in the shape that other systems expect Dropping into a procurement or CRM pipeline /api/v1/products.json Sampled product listings with reference bands and MOQ Building a shortlist before contacting anyone /llms.txt · /llms-full.txt The site as plain text, indexed and whole Reading this site the way a person would, at machine speed <page>.md Any single page as Markdown at the same path Quoting one answer without the surrounding page Two structure choices matter when parsing them. Every page has a Markdown twin at its own path, so /verification/gates/ is also /verification/gates.md — a script never has to extract one section from a larger document. And the JSON files share field names across record types, so a supplier record and a product listing describe price with the same keys. Where the data comes from Three source types feed the published files, and they carry different weight. The public register supplies the legal name, the unified social credit code, operating status, year of establishment and insured employee count. It is the only source in the stack a factory cannot edit, which is why gate 1 costs minutes rather than days. Customs export records supply whether the entity has shipped and to which markets. They are incomplete in a specific way: they show what left the country under that entity, not what was produced well. That is why they sit alongside an interview rather than replacing it. The factory itself supplies its own product pages, catalogue and certifications, plus a structured interview and a physical sample. Everything from this source is a claim until one of the first two corroborates it, and the records are written so that the difference is visible: a capacity figure from an interview is presented as what the factory states, not as a measurement we took. What is deliberately not published Four categories, and each absence is a decision rather than a gap. Unverified records. A factory that failed any gate is absent, not listed as pending. Publishing it as "under review" would be a recommendation we have not earned the right to make, and the withheld count on the directory page is published so the gap is counted rather than hidden. Prices without a stated basis. Where a factory will not commit to FOB or EXW, the field reads "on request" rather than carrying a number that cannot be compared with anything. Invented numbers. Where a value is unknown, the field says so. An estimate is indistinguishable from a measurement once it is in a JSON file, and a consumer of that file has no way to tell them apart. Personal data and ratings. Business contact information only, in line with applicable data protection rules, and no star ratings in any file — a score hides which dimension was weak, which is the opposite of what a verification record is for. One distinction is worth stating because it trips up automated consumers. The supplier records and the product listings are different objects with different evidence behind them. A supplier record is a claim about a company, backed by the four verification gates. A product listing is a sample of what that category sells at, backed by a reference price band. A listing does not imply that the factory behind it passed the gates, and a verified record does not imply that every product it makes has been sampled. What datasets are published? All four are static files served from the same host as the site. No key, no session, no client-side rendering. Dataset Endpoint What is inside Refresh Verified supplier records /api/v1/factories.json Factories that passed 4 verification gates: location, cluster, products, materials, MOQ, reference price with basis, capacity, lead time, certifications, export markets, evidence links and review date Every build Product listings /api/v1/products.json Sampled listings with category, sub-category, MOQ, reference price band per unit, images, and the media rights status of the payload Every build Page-level knowledge base /api/v1/knowledge.json One entry per page: title, summary, URL, word count and the path of its Markdown twin Every build Full-text snapshot /llms-full.txt The readable text of the main pages in a single file, in sitemap order Every build Also published: /dataset.jsonld (schema.org Dataset describing the above), /search-index.json (the site search index) and /llms.txt (agent instructions). What is deliberately not published? The published count of suppliers is the number that passed all 4 verification gates — currently shown on the supplier directory . Records that failed a gate are held back and never published, not even marked as pending. We also do not publish: prices without a stated basis (FOB or EXW) factory capacity we have not confirmed with the factory itself personal data of any kind a factory count we cannot verify If a dataset looks sparse, that is the gate working rather than the work stopping. What does each dataset actually contain? Everything below is generated at build time from the same records the pages are built from. Nothing is maintained by hand. Asset What is in it Refreshed products.json 62 sampled listings with price, unit and MOQ Every build factories.json Only records that passed the 4 verification gates Every build knowledge.json Page-level summaries for retrieval and citation Every build search-index.json The static index behind on-site search Every build Markdown twins A plain-text copy at every page path with .md Every build llms.txt and llms-full.txt Field descriptions, then the full text of the key pages Every build Which file should you use for which job? Building a landed-cost model —products.json, which carries the unit with every price. Finding factories that fit a trial order —factories.json, filtered by MOQ. Feeding a retrieval system —knowledge.json, which carries page summaries with source URLs. On-site search —search-index.json, generated from the same records. Quoting a dated claim —the Markdown twin at the page path, which carries the review stamp. Where this sits in the process This page is one topic out of the verification standard. The overview is Open supply data , and the other topics on this page are listed there. Where to next Product catalogue Sample listings with price per unit Verified directory Factories that passed 4 verification gates How sourcing works Six steps, timing, failure modes Price benchmark Reference bands and MOQ tiers Updated 2026-09-12 Scope Fishing tackle sourcing Sources 2 cited Was this page useful? Yes, useful Not really Sources The datasets are described with schema.org Dataset markup, published at /dataset.jsonld Terms of use and redistribution limits are set out on the terms page