One potential recipient asks for a small evaluation of your internal procedures. Another wants years of operational records and says the opportunity could be much larger.

The second conversation sounds more exciting. It may also require much more preparation, broader review, and a commitment your team cannot yet estimate.

Compare the actual proposals before comparing the enthusiasm around them. A short decision memo can show which opportunity deserves the next hour of work, even when neither has reached a formal offer.

The two opportunities below are fictional. They illustrate a comparison method, not real buyers, pricing, or likely deal outcomes.

Describe each opportunity at the same level

Imagine a company that installs and services specialized equipment.

Opportunity A concerns a limited evaluation of company-authored troubleshooting procedures. The recipient has described its question, requested a bounded category, and proposed a review meeting after a sample evaluation.

Opportunity B concerns service histories spanning several years. The recipient has expressed interest in decisions and later outcomes, but has not specified the required fields, access conditions, or evaluation output.

Neither description establishes that sharing is permissible or a deal will follow. They simply show that A is more defined at this stage.

Do not compare a detailed proposal from A with an optimistic guess about B. Put unknowns into B’s column as unknowns. The fair next step may be asking B for clarification rather than ranking it lower permanently.

Separate basic conditions from preferences

Some questions need a satisfactory answer before the company can proceed. Examples might include identifying the recipient, defining the proposed use, and completing the reviews needed for that scope.

Other factors are preferences: whether the work fits team availability, whether the requested format is convenient, or whether the evaluation could answer a question the business already wants to investigate.

Keep those groups separate. A convenient export should not compensate for an unresolved permission question. Likewise, an attractive commercial possibility does not make an undefined recipient or access path clearer.

This does not require a numerical scoring model. A simple note reading “cannot assess until the proposed use is specified” can be more honest than assigning an arbitrary two out of five.

Compare the work the company would actually perform

For A, the operations lead expects to verify procedure versions, confirm authorship facts, prepare a field description, and participate in the appropriate review. The estimate remains preliminary.

For B, the team would first need to investigate whether old records retain the requested relationships. It may also need to consult several system owners and reviewers before estimating preparation work.

Record the next task, responsible role, likely effort range if known, and the assumption behind it. Do not compare “small sample” with “large archive” as if size alone determines the workload.

A small sample assembled from several poorly connected systems can require substantial work. A larger category may be straightforward to describe at company level while remaining unsuitable to share. The comparison needs evidence about the proposed task, not a shortcut based on file count.

Keep commercial statements in their actual state

Write down what the recipient has actually proposed.

Useful distinctions include an expression of interest, a request for evaluation, proposed commercial terms, and an executed agreement. A budget mentioned in conversation is not collected revenue. A request for more information is not acceptance of your records.

If a proposal includes payment, record the amount or mechanism as proposed, the event that would trigger payment, outstanding conditions, and who would bear preparation costs. Have the appropriate reviewers assess the actual terms.

Avoid filling a blank with a public market example. A reported transaction involving another company does not establish what this recipient will pay for your records.

Our fictional comparison contains no price for either opportunity. That makes the next commercial question visible rather than disguising it with an invented forecast.

Identify the cheapest useful next question

For A, the most useful next action might be confirming whether historical procedure versions are retained and relevant to the proposed evaluation.

For B, it might be asking the recipient to specify the decision it wants to make and the categories it believes are necessary. That clarification could narrow the request before anyone investigates a large archive.

Choose the question that could materially change the decision with a reasonable amount of work. Sometimes the right action is a short clarification for both opportunities. Sometimes the company has capacity for only one investigation.

Record why the team chose a route. “A has a defined evaluation question and a manageable next check” is a defensible explanation. “A is definitely worth more” would require evidence the comparison does not provide.

Write the decision so it can change

Use a dated conclusion with a revisit condition:

We will investigate A’s retained procedure versions first. B remains open pending a defined evaluation question and scope. Revisit when that information arrives or the investigation changes our estimate of A’s work.

This keeps the decision proportional to the evidence. Choosing what to investigate first is not the same as signing an exclusive commitment or rejecting every other route.

Copy this comparison memo

For each opportunity, record:

• The recipient and current conversation stage.
• The question, proposed use, categories, and scope.
• Conditions that must be resolved before proceeding.
• The next task, responsible role, and known effort.
• Commercial statements and their exact status.
• Important unknowns and who can answer them.
• The smallest useful next action.

Then write the company’s choice, reason, and revisit condition.

Origin Data Partners helps organize company-level information and relevant discussions. Your comparison should remain anchored to the specific opportunities in front of your company. A clearer next decision is more useful than an impressive-looking ranking built from assumptions.

The recipient says the sample looks promising. The company asks whether that means it should prepare a larger batch. Neither side has agreed what “promising” means.

A data evaluation needs a result that can support a decision. That result might be confirmation that a proposed record structure is workable, a finding that important context is missing, or evidence that a different scope should be considered.

Define those outcomes before the evaluation begins. Otherwise, an encouraging adjective can become the only evidence for another round of work.

Choose one decision the evaluation can actually support

Consider a fictional facilities-services company discussing maintenance histories. The recipient wants to know whether it can distinguish the initial observation, the chosen action, and the later test result in each example.

That is a question about reconstructing the record. It is different from asking whether training on those records improves a model, whether the archive can be licensed, or what it should cost.

Keep the decision matched to the work. A structural review can inform whether a larger structural review is worthwhile. It cannot establish a performance claim that was never tested.

Write the intended next decision in plain language:

Decide whether the proposed maintenance-record structure is clear enough to justify discussing a separately scoped next evaluation.

That statement gives the pilot a useful endpoint without promising a commercial result.

Turn the question into observable checks

The fictional parties propose three checks for each reviewed example:

• Can the reviewer identify the information available before the selected action?
• Can the reviewer identify the action recorded by the service team?
• Can the reviewer distinguish any later test result from the earlier information?

For each check, allow “yes,” “no,” or “uncertain,” with a reason. Do not force a reviewer to choose yes or no when timestamps or field meanings are ambiguous.

Define the terms before the review. Does a later note saying “fixed” count as a test result, or does the proposed use require an observation of a specific test? Different evaluation questions may need different definitions.

A definition is part of the pilot design. It should not be changed after reviewing the records simply to improve the result.

Agree how disagreements will be handled

The operating lead may understand a shorthand note that the recipient cannot interpret. That disagreement is valuable evidence.

Record the original interpretation, the clarification, and whether the clarification changes the result. If the explanation depends on knowledge that is not retained in the records, say so. It may affect how much preparation a larger evaluation would require.

For a small pilot, the parties might review a few ambiguous examples together after the appropriate access is agreed. The purpose is to test the definitions and understand limitations, not to coach the reviewer into marking every case as successful.

Keep any revised criteria dated. If the criteria change materially, distinguish findings under the original version from findings under the revised version.

Require a report with denominators and reasons

Suppose the fictional recipient reviews thirty examples. Its primary outcomes are:

• Eighteen meet all three reconstruction checks.
• Seven have uncertain ordering of observations and actions.
• Five lack enough recorded context to identify the action clearly.

The categories are mutually exclusive in this illustration, and 18 + 7 + 5 = 30. Additional issue flags could still be retained for cases with more than one problem.

The report should name the sample, criteria version, review method, and limitations. It should also explain how cases were selected. A carefully chosen demonstration set supports different conclusions from an appropriately designed study of the wider archive.

“Sixty percent passed” discards most of the useful information. The timing uncertainty might be resolved by checking a retained event field. Missing action context might require a different record category. Those imply different next steps.

Decide what each finding would trigger

Before the review, discuss plausible outcomes and the action each would support.

If field meanings are unclear, the next step might be a revised dictionary. If necessary context is absent, the company may stop that route. If the structure works for the reviewed examples, the parties may consider a separately defined next stage.

Do not invent a universal threshold such as “eighty percent means the data is licensable.” Any acceptance criterion needs to fit the recipient’s actual purpose and the company’s decision. Some limitations may matter much more than the average pass rate suggests.

Record commercial interest separately. A technically usable sample does not establish willingness to pay, agreement on terms, or permission for broader use.

Define completion as well as success

The pilot is complete when the agreed work and report have been delivered and the next decision has been recorded. Completion does not require a positive result.

Set a review point and identify who can choose to stop, clarify a bounded question, or discuss another stage. If the recipient asks for more records before explaining the initial findings, refer back to the agreed output.

Keep evaluation access and any subsequent license distinct. Origin’s process overview describes those as separate decisions for the company.

Copy this evaluation scorecard

Decision: What will the company and recipient decide after the review?

Checks: What observable evidence will be assessed?

Definitions: What counts as yes, no, or uncertain?

Method: Who reviews which sample under which criteria version?

Report: What counts, reasons, disagreements, and limitations will be returned?

Next action: What would justify stopping, clarifying, or discussing another stage?

Completion: What work must be finished before the pilot is closed?

Ask for the scorecard before the sample is prepared. It gives both sides a way to learn something specific, including when the most useful finding is that the proposed route should not continue.

An operations lead says the archive contains contractor notes. A system owner says some attachments came from customers. A potential recipient asks whether it can use the material for model training.

Those are related facts, but they are not one question. Sending all three to a reviewer with “Is this okay?” makes the review harder than it needs to be.

A question register separates the proposed activity, the uncertainty, the evidence needed, and the responsible decision. It helps a business organize a review without pretending that the worksheet itself supplies legal, privacy, security, or commercial answers.

Start with the proposed activity

“Can we license our data?” is too broad to guide a specific review.

Describe the stage under consideration: an initial company introduction, a limited sample evaluation, a proposed license, or a change to an existing scope. Then identify the relevant record categories, recipient, purpose, and proposed access.

In our fictional example, an engineering services company is considering a small evaluation of internal project retrospectives. The proposed recipient wants to assess whether the records explain how teams handled design changes. No sample has been approved or transferred.

The review should address that proposal. It should not silently expand into a conclusion about every project file the company holds.

Give each row one decision-bearing question

Separate the initial concerns into questions that can be investigated.

Contractor material: Which agreements and authorship facts should the appropriate reviewer examine for the proposed use of contractor contributions?

Customer material: Which parts of a retrospective reproduce customer-supplied content, and what restrictions or review requirements apply to the proposed scope?

Recipient purpose: Does the request cover evaluation only, or does it propose training or another use that needs separate consideration?

Each question has a different factual input. The operating team can identify where contractor contributions appear. It should not improvise the contractual conclusion. The recipient must clarify its intended use; the company should not infer it from a general description of the recipient’s business.

Write questions in neutral language. “Confirm that we own everything” presupposes an answer. “What evidence is needed to assess the proposed use?” leaves room for a different conclusion.

Attach evidence without creating a second uncontrolled archive

The register should point authorized reviewers to the relevant evidence through the company’s normal internal process. It does not need copied customer content, credentials, or large bundles of files pasted into every row.

For the contractor question, the entry might identify the agreement category, the responsible internal team, and the locations that an authorized reviewer should consult. Mark missing documents as missing.

Keep observations separate from interpretations:

Observation: several reviewed retrospectives identify an external contributor.

Unresolved question: which agreements and circumstances govern the proposed use of those contributions?

The observation is not itself a rights conclusion. A clear distinction lets reviewers use the operating team’s knowledge without inheriting an unsupported assumption.

Assign an owner for the next action

A question can involve several specialists, but it still needs someone responsible for moving it forward.

For the fictional retrospective evaluation, the delivery lead gathers category-level authorship facts. The appropriate legal reviewer assesses the relevant agreements and proposed use. The security reviewer addresses the delivery and access proposal. The commercial lead clarifies evaluation work, costs, and next-stage expectations.

Choose roles that match your company. These are illustrative assignments, not a required organizational structure.

Record what the next action is and when the team expects to revisit it. “Legal review pending” can remain unchanged for weeks. “Operating lead to identify the relevant agreement set before legal review begins” explains the actual dependency.

Use statuses that preserve uncertainty

Suggested statuses are “needs clarification,” “evidence being gathered,” “with reviewer,” “decision recorded,” and “on hold.” Add a brief reason when something is on hold.

Avoid a single green “approved” cell with no explanation. A reviewer may approve a narrower scope, approve subject to conditions, or conclude that more information is needed.

Record the decision in the reviewer’s own documented terms, including its scope and conditions. Do not paraphrase a conditional answer into an unrestricted permission.

For example, “The proposed evaluation may proceed under the separately documented conditions for the reviewed categories” cannot safely be shortened to “All project records cleared.” The narrower wording is the useful result.

Reopen questions when the proposal changes

Suppose the recipient adds customer attachments to its request. The original retrospective review may not cover them.

Create a change entry showing the old scope, requested addition, reason, and affected questions. Ask the responsible reviewers which earlier decisions remain applicable. Keep the prior decision as history rather than overwriting it with a broader label.

This also helps the operating team understand why a review is being revisited. The issue is a changed proposal, not necessarily a failure of the earlier review.

Copy this register entry

Proposal and version: Which activity and dated scope are being reviewed?

Question: What specific uncertainty could change the decision?

Known facts: What has been checked, and by whom?

Evidence needed: What is missing, and who can obtain it?

Responsible reviewer: Who should assess this question?

Next action and date: What happens next?

Decision and conditions: What was actually concluded, for which scope?

Revisit trigger: What change would require another look?

Origin’s company data inventory template can help identify the categories and internal roles before a specific proposal exists. The question register takes the next step: it ties unresolved matters to the particular activity your company is considering.

The register is working properly when the team can identify the unresolved decision, the evidence needed, and the person responsible for the next action without searching through a month of email.

For most of the last three years, the public story of AI data licensing was about publishers and platforms. Newsrooms licensed archives, image libraries licensed stock, and social networks licensed posts. That’s still where the biggest disclosed checks sit. But 2025 and 2026 made a quieter category visible: the operating records ordinary companies already keep.

Support tickets. Work orders. Maintenance logs. Internal chat. Code history. Claim files. Call recordings. None of it can be scraped from the open web, and it’s expensive to recreate. That’s why AI developers pay for it.

Which company records do AI developers pay for?

Mostly records that show how work actually gets done: a problem appears, people act, systems update and an outcome is recorded. Support tickets, work orders, maintenance and parts records, claim files, call transcripts with QA scores, internal chat and email, and code with its history all appear in public deals or anonymized placements. Linked, multi-year histories are worth most.

The common thread is a dated chain: intake, work, outcome. A model that plans, troubleshoots, underwrites or dispatches needs examples of that chain, and published content doesn’t contain it.

Is there public proof that companies get paid for these records?

Yes, though most sales stay private. Origin Data Partners’ sourced AI data licensing deals tracker lists the company-record sales that became public, alongside publisher and platform deals. Three stand out as of its November 6, 2026 update.

• An airline’s internal communications. Google’s $10 million winning bid for Spirit Airlines’ de-identified business data (about 100 million emails and 500 million Teams chats, plus documents; passenger profiles excluded) was awaiting court approval, with the hearing moved to November 17, 2026 amid union, congressional and trade-group objections (court docket; Axios; WIRED).
• Shut-down startups’ workspaces. One wind-down firm reported nearly 100 deals in a year selling Slack and email archives for simulated workplaces, some reaching six figures (Forbes, via Newser, April 2026).
• A closed startup’s code. About $25,000 for a codebase, with workspace data likely around $15,000, pending (MIT Technology Review, October 2026).

Those aren’t forecasts for a mid-size services firm. They show the category exists.

What does each record type teach a model?

Each family of records captures a different kind of judgment. Tickets show diagnosis and customer communication. Work orders show physical troubleshooting. Claims show assessment under rules. Code history shows how software changes are reasoned about and reviewed. Buyers match record types to the agent or model they’re building.

Support tickets and service histories

How problems were described, triaged, escalated and resolved. Useful for customer-support agents and internal copilots, especially when tickets link to knowledge-base articles and final dispositions.

Work orders, field notes and job photos

Symptom, diagnosis, parts and outcome. In Origin’s anonymized placements, a 10-person field service contractor was paid $235,000 for work orders, technician notes, job photos and equipment service histories, and a 15-person construction contractor $320,000 for RFIs, change orders, daily logs, estimates and job photos.

Maintenance, quality and engineering change records

Task cards, logbooks, nonconformance reports and engineering orders. A 25-person aviation company was paid $537,000 for maintenance task cards, logbook entries, parts records and engineering orders; a 47-person manufacturer $730,000 for work instructions, quality and nonconformance reports, maintenance logs and engineering change records.

Claims, underwriting and other regulated workflows

De-identified insurance claim files from first notice to payout brought $1.3 million for a 57-person insurance firm; de-identified imaging studies with signed radiology reports brought $1.85 million for a 35-person imaging company. Regulated records are scarce because they’re expensive to collect ethically.

Calls, chats and QA scorecards

A 50-person call center was paid $905,000 for recorded customer calls, chat transcripts and QA scorecards. Consent rules make calls the hardest category; de-identified transcripts are often the workable product.

Team chat, email and internal documents

How decisions were really made. Valuable for agent training environments and the riskiest for privacy, as the airline objections show.

Code, runbooks and engineering history

Beyond the repository itself, buyers want linked issues, review comments and versioned runbooks: the operational history around software.

Video, driving and spatial data

Separate from back-office records, 2026 deals also show labs buying driving video, aerial and LiDAR data, and opted-in consumer video. Fleets with dashcam footage or factories with shop-floor video may fit physical-AI demand.

All anonymized figures above come from Origin’s case studies page (updated November 7, 2026). Each is one company’s outcome, not a quote for another.

How do the big publisher deals relate to ordinary companies?

They set buyer budgets and prove licensed data is normal, but they aren’t comparables. News Corp’s agreement with OpenAI was reported at more than $250 million over five years (WSJ, May 2024). Reddit disclosed $203 million in aggregate data-licensing contract value in IPO materials. Shutterstock reported $104 million of AI licensing revenue in 2023 (Bloomberg Law).

They also show what buyers can already get on the open market. That’s why proprietary workflow data competes on distinctiveness and rights, not on volume.

What should an owner check before exploring a deal?

Five things, all possible without exporting a file: which record categories and years you hold, who owns the rights, where personal data sits, whether records link problem to outcome, and an indicative value range. Keep files in your systems until a named recipient and written use are agreed.

1. Inventory categories, not files. Name the systems and years of history.
2. Ask who owns the rights. Customer contracts, employee policies and vendor terms matter as much as technical access.
3. Separate personal data early. Plan de-identification before anyone proposes a sample.
4. Prefer linked workflows. Problem, action and outcome beat orphaned PDFs.
5. Get an indicative range without uploading. Origin’s six-question estimate works from company-level answers only.

FAQ

Do AI companies buy data from small businesses? Yes, though usually through data programs or intermediaries rather than directly from large labs. Origin’s anonymized placements include 10- and 12-person companies.

What is the most valuable type of company data for AI? There’s no single answer. Linked, multi-year records from physical, regulated or engineering work (maintenance, claims, imaging, work orders) tend to rank highly because they’re scarce.

Do I have to hand over my data to find out what it’s worth? No. An indicative range can come from company-level answers about size, history, systems and rights.

Is selling company data to AI legal? It can be, when you hold the rights, handle personal data lawfully (usually by de-identifying it) and license under a written agreement. Ask counsel about your industry and jurisdictions.

Who pays Origin? Origin is free for data owners. It may receive compensation from the receiving company if a deal closes. Sellers negotiate and sign directly with buyers.

The Origin Data Partners team Origin Data Partners is an independent data licensing partner that helps companies license the records they already keep to AI developers. origindatapartners.com

“Could you send a few support tickets, including the attachments, so our team can take a look?”

The request sounds small. It leaves several important details open: which team, which tickets, which attachments, what they want to test, and what happens to the material afterward.

The next useful step is a clear request description. You can often prepare that description without copying a single record. Once the request is specific, the appropriate people can decide whether and how to proceed.

The fictional example in this guide concerns a software company’s support history. It illustrates a review method, not approval for any real transfer.

Write down the decision the sample should support

Ask the recipient to finish this sentence:

After reviewing the sample, we want to decide whether _____, using evidence of _____.

In the fictional request, the recipient wants to decide whether support investigations contain enough context to reconstruct a troubleshooting decision. It wants to see the information available at the time, the next action, and any later result recorded separately.

That answer immediately improves the request. An attachment that merely confirms an invoice may add nothing to the evaluation. A later root-cause summary might be relevant, but it should not be mixed with information available before the decision.

If the recipient cannot explain the purpose, keep that uncertainty visible. An undefined request does not become easier to assess because the requested number of records is small.

Describe exactly what one example would contain

“A ticket” is a container, not a precise scope.

List its proposed parts: issue summary, timestamps, internal investigation notes, customer messages, linked engineering discussion, attachments, and later status changes. For each part, record whether it is requested and why.

The fictional company proposes discussing a narrower structure first: issue category, a bounded set of internal notes, relevant event times, and a separately labeled later result. Customer messages and attachments remain outside this proposed structure while their relevance and review requirements are considered.

This is a scope proposal, not a claim that those remaining fields are automatically safe to share. Internal notes can contain sensitive details, private links, copied customer text, or other material that needs attention.

A fully invented example can help the parties agree on structure. It cannot establish that the real archive contains equivalent records or that sharing them is permissible.

Name the recipient and the access boundary

Replace “your team” with an identifiable organization and a description of who is expected to access the material.

Ask whether another organization, contractor, hosting service, or evaluation tool would receive it. The responsible reviewers need the proposed access path, not just the name of the person who sent the request.

Record the proposed delivery method and where the sample would be held. Also ask what retention period and end-of-evaluation handling are proposed. Those answers belong in the actual review and agreement; a planning worksheet does not create enforceable terms.

Do not assume that permission for an introduction extends to sample access. Origin’s licensing process treats those as separate decisions.

Route each uncertainty to the person who can resolve it

Avoid sending a vague message saying, “Can someone approve this data?”

Give the operating lead the question about field meaning and retained context. Give the system owner the question about extracting only the proposed fields. Route permissions, privacy, security, and contractual questions to the appropriate reviewers for the company and proposed use.

For example:

Can the proposed extraction separate internal investigation notes from attachments and customer messages? System owner to check before a preparation estimate is agreed.

That question is specific enough to answer. It also identifies a dependency: the company cannot reliably estimate the proposed work until it knows whether that separation is practical.

A review may conclude that the scope should change or the company should stop. Keep that possibility open. The purpose of review is a sound decision, not simply collecting enough checkmarks to justify the original request.

Define what happens when the request changes

Suppose the recipient later asks for the full conversation because the internal notes are difficult to interpret. That is a new scope question.

Record the requested addition and its purpose. Revisit the relevant review, preparation effort, and handling conditions. Do not treat the earlier decision as blanket approval for whatever helps the evaluation.

Use a version number or date on the request description. The company and recipient should be discussing the same version when they agree what is to be prepared.

Keep a clear distinction between “requested,” “under review,” “approved for this purpose,” and “delivered.” An approved outline is not evidence that the delivered package actually matched it.

Check the package against the decision

After authorization and preparation, compare the actual package with the agreed description. Confirm the categories, dates, fields, counts, exclusions, documentation, and intended recipient.

Record unresolved discrepancies before delivery. If the extraction unexpectedly includes extra fields, do not rely on the original request description to make them disappear.

This final comparison is a practical control for the handoff. It complements the substantive reviews; it does not replace them.

Copy this request review sheet

Purpose: What decision will the sample support?

Contents: What does one example contain, and what remains excluded?

Selection: Which population and selection rule apply?

Recipient: Which organization and people or services may access it?

Handling: What delivery, retention, and end-of-evaluation conditions are proposed?

Review: Which questions are assigned, to whom, and what is still unresolved?

Version: Which dated request was actually approved?

Package check: Does the prepared material match that decision?

A good response to “send a few examples” is a request both sides can describe accurately. Once the purpose and boundaries are clear, your team can assess the real work and make a deliberate decision about access.

A buyer asks, “Do your service records include outcomes?”

The owner says yes. The service manager hesitates. The system has a field called “completed,” but that field means the visit was closed administratively. It does not necessarily mean the equipment passed a test or stayed fixed.

That difference is exactly why an operating lead should help prepare a data licensing conversation. They can explain what the records mean in the actual workflow. A promising description becomes more useful when its limits are clear.

Here is a meeting format that brings that knowledge into the discussion without turning a first call into an improvised screen share of company records.

Give the operating lead a specific job

Ask them to help answer three questions:

• What decision or activity do these records describe?
• What does the system reliably capture, according to what the team has checked?
• Which parts of the description are uncertain or need another reviewer?

They are not being asked to decide a price, promise a delivery date, or settle permission to license every record. Those matters may involve different people.

Give the lead the meeting purpose in advance. “We are exploring whether retained troubleshooting histories are relevant to a potential recipient” is better preparation than “Please join a call about our data.”

Explain what the company intends to discuss at this stage. A company-level overview can cover record categories and workflow without displaying individual customer cases.

Prepare one workflow story

For a fictional equipment service business, the operating lead prepares this description:

A reported fault becomes a work order. The technician records observations and an action. Some visits include a test result. Follow-up visits may use a new work order, so the relationship needs checking.

That is enough to expose the key questions. The recipient can ask which observations precede the action, what a test result means, and whether later visits can be linked.

The lead should also describe an exception. For example, an urgent phone instruction may affect the technician’s decision without appearing in the work-order notes. That exception tells the recipient why the record is not a complete transcript of the work.

Use an invented case if an example would help explain the workflow. Label it as fictional. A prepared illustration is different from evidence about the completeness of the real archive.

Make a short vocabulary sheet

Choose the words most likely to be misunderstood. In our fictional service business:

Completed: the visit was closed in the scheduling process.

Resolved: a service employee selected that status; the basis may vary and needs checking.

Test result: an observation entered after an action; it may describe a pass, a failure, or an inconclusive result.

Repeat visit: another visit to the same site; it is not automatically the same fault.

The meanings above are invented for the example. Your team’s definitions may be different. The important step is to have the person who knows the workflow explain them before a recipient builds assumptions around the labels.

Do not spend the entire preparation session defining every field. Start with the terms that change how a case would be interpreted.

Sort answers into three states

Use a small preparation sheet with “checked,” “reported by the team,” and “unknown” beside each material claim.

For example, the service manager has checked that recent work orders contain an optional test-result field. A colleague remembers that an older system had something similar. Nobody has checked whether those older entries survived a migration.

The external description should preserve those differences:

We have confirmed the field in the current system. Earlier history has not yet been verified.

That answer is more useful than an enthusiastic “Yes, we have ten years of results.” It tells the recipient what can be discussed now and what a follow-up would need to establish.

The meeting host should make it easy to say “we need to check.” Do not pressure an operating lead to improvise a confident answer because a question sounds commercially important.

Give the call a practical agenda

For a first discussion, try this sequence:

• State the recipient’s question and the company’s proposed category.
• Walk through one workflow at company level.
• Explain the important field meanings and known exceptions.
• Discuss the retained period and any verified connections.
• List questions that require internal checking.
• Agree the next decision and who owns each follow-up.

This order prevents the meeting from jumping straight from “interesting records” to “send us everything.” If the recipient asks for access, record the request and route it through the separate scope and review process.

Decide beforehand who can make commitments. A subject-matter expert should not discover during the call that their explanation has been treated as approval to transfer material.

Send back a precise meeting note

The note should distinguish what was described, what the recipient asked, and what the company agreed to do. Interest in hearing more is not an offer or a commitment to license records.

For our fictional company, the next action might be: “Operations will check whether follow-up links exist for a defined recent period and report the finding at category level.” It should not become “Operations will deliver a linked dataset” unless that work was actually agreed and authorized.

Copy this preparation card

Meeting question: What does the recipient want to understand?

Workflow: How does one piece of work begin, proceed, and end?

Important terms: Which labels could be misunderstood?

Evidence state: What has been checked, what is reported, and what is unknown?

Boundaries: What may be discussed, and which requests need a separate decision?

Follow-up owner: Who can verify each unresolved point?

Origin Data Partners helps organize company-level information and relevant discussions. Your operating team’s contribution is the grounded explanation behind that overview: what the records mean, how the work really happens, and which questions still need an answer.

“It should only take an afternoon to export the records.”

That estimate may cover the export button. It may leave out choosing the right records, explaining unfamiliar fields, reviewing the proposed material, resolving questions, and preparing a second version after the recipient changes its request.

A useful estimate shows who will do each piece of work and what remains uncertain. It does not need elaborate project software. A one-page task sheet can expose the largest unknowns before the company commits to a deadline.

Start with a defined output

Consider a fictional software business assessing a small evaluation of internal support investigations. The proposed output is a reviewed sample in an agreed format, a field explanation, and a short note describing selection and known limitations.

That sentence excludes several possible assumptions. It does not promise a cleaned version of the whole archive, continuous updates, custom labels for every decision, or unlimited follow-up work.

Write the proposed output before estimating hours. If the recipient has not defined the evaluation question or required fields, estimate the scoping conversation first. Do not pretend that an undefined preparation job has a reliable total.

Also record what must be agreed before work starts: the recipient, purpose, sample boundaries, handling requirements, reviewers, and commercial conditions. Those decisions affect the work rather than sitting outside it.

Split preparation into visible tasks

Ask each responsible role to estimate its own contribution. In our fictional example, the preliminary ranges are:

• Confirm the selection rule and identify candidate cases: two to four hours.
• Check the proposed fields and extraction method: three to six hours.
• Conduct the agreed internal reviews: four to eight hours.
• Prepare the sample documentation and delivery package: two to three hours.
• Address one defined round of recipient questions: two to four hours.

The arithmetic gives thirteen to twenty-five hours of staff effort. These are invented planning figures, not industry benchmarks or a price for a real evaluation.

The range is more informative than “about two days” because it reveals where uncertainty sits. Field extraction and internal review have wider ranges than documentation. Those are good places to investigate before offering a firm commitment.

Keep responsibilities separate even when one person fills several roles. It should remain clear whether an estimate concerns system work, operating interpretation, or a specific review.

Separate effort from elapsed time

Thirteen staff hours do not mean delivery tomorrow afternoon.

The system administrator might have three hours available next week. A reviewer may need another team’s answer before completing a check. Work can also happen in parallel, so adding every task’s duration is not a reliable calendar schedule.

Give each task three fields: estimated effort, earliest available start, and dependency. For example:

Field review: three to six hours. Earliest start Wednesday. Requires the recipient to confirm whether revision history is in scope.

That entry explains the date risk. The team is waiting on a scope decision; working faster on unrelated tasks will not settle it.

When communicating externally, distinguish an estimate from a commitment. “Our current estimate is subject to the revision-history decision” gives the recipient something concrete to resolve.

Identify the assumptions that could break the estimate

Write an assumption next to each uncertain task.

The fictional administrator expects the proposed fields to be available in a standard report. The operating lead expects case references to connect reliably to internal investigation notes. The documentation estimate assumes one output format and one recipient review round.

Now test the assumption with the largest consequence. If a standard report omits revision history, a short internal check may reveal that before the team commits to preparing dozens of cases.

Do not bury a failed assumption inside a wider range. “Three to twenty hours” can conceal two different jobs: a standard export and a custom reconstruction. Describe those scenarios separately and identify what determines which one applies.

The estimate should also name tasks that have not been assessed. An unknown review requirement is not zero hours simply because nobody has estimated it yet.

Put a boundary around rework

Suppose the recipient later asks for linked engineering discussions. That request adds a new record category, another responsible team, and different review questions.

Treat it as a scope change. Record what was requested, why it is needed, which work would be added, and whether the existing schedule still makes sense.

The company can decide to revise the evaluation, propose a narrower alternative, or stop. A sample request should not quietly become an open-ended preparation project.

If there is payment for evaluation work, the responsible commercial and legal reviewers should settle what it covers and what triggers payment. This effort estimate is an internal planning tool. It does not establish a market price or a right to reimbursement.

Use a small estimate worksheet

Output: What exactly will be prepared and delivered?

Task and owner: Who performs each piece of work?

Effort range: What is the low and high estimate, and why?

Availability: When can that person actually start?

Dependency: Which decision or completed task is required first?

Assumption: What must be true for the estimate to hold?

Change trigger: Which new request would require a revised estimate?

Review point: When will the company decide whether to continue?

Origin’s licensing process separates an initial company discussion from later sample access and licensing decisions. Keep the work estimate attached to the particular stage being considered.

Before promising a delivery date, ask the team to point to the least certain line on the worksheet. Resolving that line often matters more than making the total look precise.

The operations manager remembers a beautifully documented service visit. The technician recorded every diagnostic step, the repair, and the follow-up test. It is the obvious record to show a potential data recipient.

It may also be a poor answer to the recipient’s actual question.

If the question is “Can one record contain this information?”, a carefully chosen example can help. If the question is “How often does the archive contain this information?”, choosing the best case hides what the recipient needs to learn.

Before choosing records for a licensing evaluation, decide which question the selection is supposed to answer. The method below is a planning exercise. Any real sample still needs an agreed scope and the appropriate review before it is shared.

Give the selection a job

Use one of three plain descriptions at the top of your sample plan.

A demonstration set shows a possible structure. You might deliberately choose a complete case to explain how a job, investigation, action, and result connect. Label it as a chosen example.

A variation set explores differences. You might include short and long cases, several work types, or records from before and after a system change. It can expose problems that a single example misses.

A prevalence study asks how common something is in a defined population. That needs an appropriately designed selection and analysis method. A convenient handful of records should not be presented as an estimate of the whole archive.

These are different assignments. Avoid switching from the first to the third after seeing encouraging results.

Define the pool before the sample

Consider a fictional maintenance company reviewing completed equipment jobs. Its team proposes a variation set to understand whether records from two branches use the same outcome fields.

The candidate pool is defined as completed jobs for one equipment category, at those two branches, during a stated six-month period. Open jobs, another equipment category, and records outside the period do not enter the pool.

That definition needs to be written down even if the system can produce the list easily. Otherwise, a reviewer may later assume that “maintenance records” means every branch, every category, and the company’s entire history.

Also define one unit. Is it a work order, a visit, or a service problem that may involve several visits? For this example, use one work order and record whether it links to a follow-up. Do not count attachments as additional examples.

Choose a rule that fits the question

The fictional team proposes twenty-four work orders: twelve from each branch, spread across the six months. It uses a recorded selection rule within those groups, established before reading the notes.

Those numbers are invented for the example. They are not a recommended sample size or a claim of statistical adequacy.

The useful feature is the visible design. The team has made branch and period coverage deliberate, and it can explain how records were selected within each group. A recipient can challenge that design before preparation begins.

For a demonstration set, the rule could instead say, “Choose one case that contains each proposed field.” That is acceptable when the purpose is explicit. The problem begins when the resulting polished example is used to imply typical completeness.

If the intended decision requires an estimate about thousands of records, have someone qualified design that study. Increasing a convenience sample from ten records to fifty does not, by itself, solve selection bias.

Decide how unavailable records are treated

Suppose three selected work orders cannot proceed: one is unavailable, one falls outside the agreed category after closer review, and one is held for a separate permissions question.

Do not quietly replace all three with attractive cases.

Keep a selection log showing the original candidate, the reason it did not proceed, and the replacement rule, if any. The recipient does not necessarily need private record identifiers; the internal preparation team does need enough traceability to explain what happened.

In the fictional plan, an out-of-category record is replaced using the same rule from the correct group. An unavailable record is recorded as unavailable. A record on hold stays on hold. Whether a replacement is appropriate depends on the evaluation question and agreed plan.

Report the stages separately: twenty-four original candidates selected, twenty-one of those proceeding, and one replacement added, giving twenty-two records for the planned review. Record any later delivery count separately. “We provided twenty-two examples” is not a complete account of the selection.

Keep difficult cases visible

Missing outcomes and ambiguous timing may be exactly what a variation review should reveal. Removing those cases because they look untidy can defeat the exercise.

Distinguish a record that cannot be shared under the agreed scope from a record that is allowed but incomplete. The former needs the responsible review decision. The latter may belong in the evaluation with its limitation visible.

Also preserve disagreements. If an operating lead calls a case complete and a recipient cannot reconstruct the decision, record the difference. It may reveal a definition problem that no amount of selecting better examples will fix.

Copy this selection note

Question: What should this sample help someone decide?

Purpose: Demonstration, variation review, or a properly designed estimate?

Candidate pool: Which records, dates, teams, and work types qualify for selection?

Unit: What counts as one example?

Rule: How will examples be selected before their contents are assessed?

Exceptions: What happens to unavailable, out-of-scope, or held records?

Counts: How many were selected, reviewed, excluded, replaced, and delivered?

Limits: Which conclusions would this selection not support?

A clear selection note belongs beside the sample description. If the candidate categories are still uncertain, Origin’s company data inventory template can help define them first.

The strongest sample is the one whose selection you can explain. A recipient should be able to see both why these records were chosen and what remains unknown about the records it has not seen.

Two service records have the same equipment reference, the same fault description, and dates three days apart. Is one a duplicate?

It might be an accidental copy. It might also be a return visit because the first repair did not resolve the fault. Removing the second record without checking would erase an important part of the history.

For a company exploring data licensing, duplicate review should begin with the meaning of a case. The goal is to describe repetition accurately and decide how it should be represented in a proposed evaluation. It is not to delete anything from the operational system.

The example below concerns a fictional equipment-service company and uses invented records and counts.

Decide what you are trying to count

One row, one document, one visit, and one customer problem are different units.

The fictional company retains work orders. A work order can have several visits, and a visit can generate multiple notes. Some older work orders also appear in a migration archive.

If the proposed evaluation concerns diagnostic decisions, the company may need to distinguish decisions or visits. If it concerns entire problem histories, several visits may belong together.

Write the intended unit at the top of the review. A repeated customer reference can be normal across visits and suspicious within a list that claims to contain one row per customer. The identifier alone does not decide the issue.

Make a small set of candidate matches

Ask the system owner which features can help locate possible repetition: source identifiers, migration references, timestamps, document titles, or similar text.

Use those features to create candidates for review. Treat a candidate match as a question, not a conclusion.

Exact text can repeat because staff use a template. A shared timestamp can arise from a batch import. Different text can describe the same event after an edit. Each clue needs its operational context.

Work within the company’s approved environment. For an initial investigation, keep candidate references and observations in an internal worksheet. There is no need to upload records to an outside matching service simply to understand how repetition occurs.

Use four categories for the review

For this exercise, classify candidate groups into four practical categories:

Repeated copy: more than one stored representation appears to describe the same event without an intentional new version or follow-up.

Revision: the same record was intentionally updated or summarized, with differences that may matter.

Related event: a new visit, test, or decision belongs to the same broader case.

Unresolved: the available evidence does not yet support a confident interpretation.

These categories are a working method, not a universal standard. Your business may need another category, such as a corrected record that formally replaces an earlier one. Define it before applying it widely.

Keep the evidence for each classification. “Looks similar” is rarely enough to explain why a record should disappear from an evaluation view.

Walk through a candidate group

In the fictional archive, three entries concern the same compressor fault:

• Entry A records a Monday diagnostic visit and a part replacement.
• Entry B has the same original visit reference but was created during a later migration.
• Entry C records a Thursday return visit after the reported symptom recurred.

The system owner verifies that B is an imported representation of A. C has its own visit reference and a dispatch note explicitly linking it to the earlier problem.

The group therefore contains a repeated representation and a related event. A proposed evaluation could avoid counting A and B as two independent visits while preserving C’s relationship to the first visit.

It should also record which representation supplies which fields. If B contains a later correction absent from A, the team needs to understand that difference before choosing a preferred view. “Keep the newest” is not a complete review rule.

Keep shared text from deciding the result

Suppose several visits use the same sentence: “Unit inspected and returned to service.” That repeated wording may reveal a documentation convention. It does not establish that the visits are copies of one another.

Check the event references, dates, recorded measurements, and workflow context. Conversely, two differently worded summaries may refer to the same visit.

The review should identify the evidence that distinguishes the events. If the records lack that evidence, preserve the uncertainty. Do not manufacture unique events from superficial wording differences or merge events solely because their descriptions match.

Report groups and records separately

Counts become confusing when a report switches between groups and individual records.

Imagine a fictional review of six candidate groups containing fourteen record representations. Two groups are repeated copies, two are revisions, one is related visits, and one remains unresolved. The group categories total six. They do not tell you how many representations should be excluded from a particular evaluation.

For that, document the decision for each group under the agreed unit of review. The same group could be represented differently in a visit-level evaluation and a study of revision history.

A small review also cannot establish the duplicate rate of the wider archive. State how the candidates were found and which periods or systems were examined.

Preserve an audit trail for any later preparation

If an approved sample is eventually prepared, keep a mapping between the original references and the chosen representation within the company’s controlled process.

Record why a copy was excluded, how a revision was handled, and which related events remain connected. Do not permanently delete source records as a side effect of preparing an evaluation view.

This record makes questions answerable later. If a recipient notices an unusual sequence, the team can explain whether it reflects a real return visit, a correction, or a remaining uncertainty.

A candidate-group worksheet

Intended unit: What is one example supposed to represent?

Candidate rule: Why were these records flagged together?

Evidence checked: References, versions, event times, or operational explanation.

Classification: Repeated copy, revision, related event, or unresolved.

Important differences: Which fields or relationships would be lost by merging?

Proposed treatment: How should this group appear for the specific evaluation?

Review owner: Who can confirm the classification or resolve the uncertainty?

Use Origin’s company record map to describe the relationships surrounding these groups. A repeated copy may add little to a proposed sample; a repeated visit may explain the outcome. The review should preserve that distinction before anyone decides what to include.

A field called “duration” contains the value 45. It could mean minutes on site, hours until closure, or seconds spent on a test. A field called “status” contains 3. Nobody outside the team knows whether that means completed, cancelled, or waiting for parts.

Those values are difficult to interpret even if every row is populated and perfectly formatted.

A data dictionary gives a reader the definitions needed to understand one record category. The strongest version explains the business event behind each field, its units and boundaries, and the uncertainties that remain.

Here is a practical way to build one using a fictional equipment-inspection archive. The example fields are invented; they are not a schema from a customer or a particular software product.

Begin with the record’s unit

Before defining individual fields, state what one row or document represents.

In the fictional archive, one inspection visit may contain several equipment tests. The company chooses one test as the unit for its first dictionary. Visit-level information is described separately.

This prevents a basic counting error. If a visit has five tests, a visit duration repeated on five test rows still describes one visit. Summing it across the rows would count the same time five times.

Write the relationship in plain language: “Several test records may share one visit reference. The visit duration applies to the whole visit, not separately to each test.” A reader should understand this without seeing any real identifiers.

Define the event or concept behind each field

Ask the person who uses the field in daily work what it actually represents. Then check available documentation or system behavior rather than treating the field name as its own definition.

For the fictional field test_completed_at, a useful definition is:

Time when the inspector marked the test complete in the application. It may differ from the time the physical measurement occurred.

That second sentence can matter as much as the first. A recipient interested in the order of physical events should not assume the application entry time proves that order.

Add a definition source and a responsible role. If the definition is based on a team explanation that has not been checked, label that status. A dictionary is allowed to contain open questions.

Make units and reference conditions explicit

For a measured value, record the unit and any condition necessary to interpret it.

The fictional field pressure_value needs more than “decimal number.” Does the associated unit field distinguish bar from psi? Is the value a gauge reading or an absolute-pressure measurement? Does a missing unit follow a documented rule, or is the unit unknown?

Do not fill these gaps from what is typical in the industry. Ask the equipment or operations lead to verify the archive’s actual convention.

For dates, record the format and time-zone meaning. For durations, record the start event, end event, unit, and whether pauses are included. A number can be technically valid while answering a different business question from the one the recipient expects.

Explain codes without inventing certainty

If a status uses codes, document the allowed values and who sets them.

In our invented example, the team believes the codes are “pending,” “recorded,” and “reviewed.” It discovers that an older form also used “closed,” but nobody has yet established whether that meant reviewed or merely no further action planned.

Keep the older code and its uncertainty in the dictionary. Do not silently translate it to the nearest modern category.

Where meanings changed over time, give the definition a period or version. If several branches used the same code differently, record that scope. A tidy list of current codes should not erase the archive’s history.

Give missing values their own explanation

An empty measurement may mean the test was not performed, the result was not entered, the value was excluded from a particular view, or the reviewer does not yet know.

Use only meanings supported by the actual system and workflow. If several states were stored identically, describe that ambiguity rather than inventing distinctions the data cannot make.

For the fictional archive, a test disposition field may explicitly say “not performed.” A blank measurement without that disposition remains unexplained. Neither should automatically become zero.

Also document placeholders such as a dash, a default date, or a code called “unknown.” A placeholder is a recorded value, but its presence does not establish that the underlying fact is known.

Test the dictionary with invented records

Create two or three entirely fictional examples designed to expose ambiguity. Include a normal value, a missing value, and a case where several records share a parent reference.

Ask a colleague unfamiliar with the archive to explain each example using only the dictionary. Which event do they think the timestamp represents? What would they count? What conclusion do they draw from the blank measurement?

Revise definitions where interpretations diverge. Do not fix the test by choosing only easy examples. The unclear case is often the one most worth documenting.

An invented example tests whether the explanation is understandable. It does not show that the real archive follows that explanation consistently; that needs a separate check.

Copy this field definition

Exact field name: The identifier as it appears in the relevant structure.

Business meaning: What event, measurement, or category does it represent?

Unit and format: Including time-zone meaning or reference conditions where relevant.

Allowed values: Codes and their verified meanings, with historical differences.

Missing-value behavior: What blanks, defaults, and placeholders do or do not mean.

Relationship: What other record it refers to and whether values repeat across rows.

Source and owner: Where the definition came from and which role can verify it.

Scope and uncertainty: Applicable period, system version, and unresolved questions.

Origin’s data dictionary template provides a working format for these definitions. Start with the fields that determine how a case is interpreted, then expand. A small dictionary that prevents a consequential misunderstanding is more useful than a long list of column names with their names repeated as definitions.