Delivery decisions
One-off dataset or ongoing data feed?
A fixed dataset and an ongoing feed create different work for the supplier. Define what must be delivered, corrected and maintained before comparing a payment or agreeing to provide updates.
Last checked
Agree the operating commitment alongside the proposed licence. Recurring delivery is not passive income just because the source system already exists.
Which delivery are you actually discussing?
Separate three practical options: a fixed collection covering a defined period, periodic new releases, and access through a continuing service. Do not let the phrase data feed conceal which of these is intended. Ask the prospective recipient to describe what they would receive and how often.
The W3C Data Catalog Vocabulary, version 3 provides distinct ways to describe datasets, distributions, data services and dataset series. This is useful terminology for scoping delivery, not a ready-made commercial agreement or a recommendation to build an API.
Fairlode's initial review does not require any of these delivery mechanisms. Start with a description and a requirement. Technical access comes later, only through a separately agreed process.
Make the boundary of a fixed collection explicit
For a one-off collection, specify the period covered, the included record types, the version and the main exclusions. Ask whether the recipient expects the archive as it stands or a newly prepared version meeting defined checks.
Discuss what happens if an error is discovered after delivery. Is a corrected copy expected, how would it be identified, and who would assess the issue? These are questions to agree, not assumptions that a one-off payment automatically settles.
An illustrative comparison is an archive ending at a stated cut-off against the same archive plus future records. The second is a broader operational commitment even if both start with an identical file. Keep future supply out of the description unless your business is prepared to discuss it.
List the work behind each update
Write down the tasks that recur: identifying new records, checking the permitted scope, preparing the release, reviewing exceptions, documenting changes and handling questions. Assign an internal owner and a backup before promising a timetable.
Ask what happens during holidays, system outages, supplier changes or a pause in the underlying activity. If records are produced irregularly, do not promise a fixed volume. Clarify whether an update means all records for the period, only changed records or a replacement of the previous collection.
Use a small internal rehearsal with synthetic material if the process is unfamiliar. It should test the proposed workflow without transferring business records or connecting a prospective buyer to production systems.
Plan versions and corrections
The W3C Data on the Web recommendations include version indicators and version histories. Applying that idea to a private commercial discussion does not mean publishing the data openly. It means being able to identify what was supplied and distinguish a replacement from a new release.
Our suggested release note records the version, period covered, changed fields, known limitations and whether it replaces an earlier delivery. Link the matching dictionary and provenance record so their descriptions do not drift apart.
Ask how corrections would be communicated and acknowledged. A file called latest is not a useful record of what somebody reviewed last month. Do not promise deletion of earlier copies or reversal of model use without separately reviewed terms that address the actual situation.
Compare acceptance conditions and ongoing effort
Ask what would count as an acceptable delivery and who makes that decision. Distinguish a technically readable file from material accepted for the recipient's intended task. Clarify how disagreements, rejected updates and requests for extra work would be handled before preparing a large collection.
For your internal comparison, list staff time, specialist review, preparation tools, delivery support and the work created by future changes. Ask which costs arise even if the discussion or review does not result in a licence. Do not count an indicative payment as revenue already secured.
Use the licensing-value questions to discuss scope and assumptions. There is no general rule that a feed is worth more than a fixed archive, or that either route will find a buyer.
Choose the smallest useful next step
Prepare a short comparison with one row for each delivery option your business could genuinely support. Record what it includes, what it excludes, its owner, unresolved permission questions and the next evidence needed. An option may remain unavailable if nobody can safely support it.
An initial conversation can stop at a non-confidential description. If there is a specific requirement, discuss whether a limited, separately approved review would answer the next question before considering ongoing supply. Do not build a public download, API or automated export merely to attract interest.
Use the buyer-checking guide and licensing checklist before moving further. Fairlode does not need files or system access for the first review. Keep technical delivery, licensing permission, buyer acceptance and actual payment as separate decisions.
General information, not legal advice, a valuation or a buyer offer. Illustrative examples are not customer case studies.
Sources and further reading
Sources checked 22 October 2026. Historical research is background, not evidence of current buyer demand.