Pulse LabsDataShare requirements
Pulse Labs / Data sourcing & licensingFor labs & data teams

Data from the businesses
that create it.

Existing relationships with hundreds of businesses.Across North America, the UK and Australia.

We use those relationships to identify data owners for your brief. Define the task, the records and the context you need. We work through source fit, permissions and the delivery specification with you.

Share your requirements

For training corpora, domain adaptation and evaluation. Start with your specification.

Task & unit

Documents, linked cases, studies or work episodes.

Coverage & context

Source diversity, history, metadata and record links.

Rights & acceptance

Permitted use, sample criteria and delivery terms.

01 / Define the collectionYour requirements come first

What data
does your project need?

Specify the unit your team will use: a document, a complete conversation, a linked work episode or a clinical study. Then define the context that must survive extraction and preparation.

Domain specification / 01

Company workflows

A conversation becomes more useful when it connects to the document, ticket or decision it concerns. Specify the workflow you need to reconstruct, rather than a message count alone.

Unit of data
A linked work episode: request, supporting records, decisions and outcome.
Context to preserve
Thread and reply structure, event timestamps, document versions, task references and consistent pseudonymous identifiers across the approved collection.
Sample review
Check for orphaned attachments, missing replies, automation noise and broken links after redaction. An archive is not an executable agent environment; tool states, actions and success criteria require separate scoping.
Discuss this requirement
Domain specification / 02

Software & code

Code for corpus training and code for task evaluation need different packages. For a repair task, define the starting revision, the issue to solve and how success will be tested.

Unit of data
A repository snapshot, or an issue linked to a code change and its tests.
Context to preserve
Commit ancestry, issue and pull-request references, relevant documentation, dependency versions, build instructions and available test results.
Sample review
Separate generated or vendored code from original work. Check build reproducibility, secret removal and rights to dependencies. For evaluation, keep solution patches and later discussions out of the task input.
Discuss this requirement
Domain specification / 03

Sales & support

A closed ticket is not necessarily a solved problem. Define whether the target is a reply, an escalation decision, a troubleshooting sequence or a verified resolution.

Unit of data
A complete case or conversation, with its handling history and disposition.
Context to preserve
Ordered turns, channel, language, handoffs, product context and links between the case, account history and outcome where permitted.
Sample review
Distinguish human replies from bots and templates. Check reopened cases, missing attachments and inconsistent outcome labels. Group related conversations when constructing evaluation splits.
Discuss this requirement
Domain specification / 04

Finance & insurance

Amounts need their accounting context. Specify whether you need extraction examples, reconciliations, underwriting decisions or claim histories; these are different units of work.

Unit of data
A transaction, reporting period or claim linked to its supporting evidence.
Context to preserve
Currency, units, period, entity scope, document dates, adjustments and the links from entries or decisions to source documents.
Sample review
Separate draft from finalized records and identify restatements. Check reconciliation gaps and outcome timing. For predictive evaluation, exclude information that only became available after the decision.
Discuss this requirement
Domain specification / 05

Legal & professional

A final document alone may omit the reasoning behind it. Define the jurisdiction, practice area and task: drafting, comparison, extraction or research grounded in source material.

Unit of data
A document version, matter or engagement with its relevant context.
Context to preserve
Document type, dates, version sequence, clause structure, citations and links to approved reference material or supporting work.
Sample review
Distinguish drafts, templates and executed documents. Check OCR and table integrity. Identify privilege, confidentiality and third-party rights issues before selecting material for review.
Discuss this requirement
Domain specification / 06

Commerce & logistics

A sale, return and delivery are different events. State which decision or sequence matters, and whether the collection must support joins across commerce, inventory and fulfillment systems.

Unit of data
An order line, shipment or inventory event linked through its lifecycle.
Context to preserve
Stable product and order identifiers, event time and timezone, quantity, currency, status transitions and links to returns or exceptions.
Sample review
Check canceled and partially fulfilled orders, changed identifiers, repeated events and incomplete shipment histories. For forecasting, define an observation cutoff so later returns or delivery outcomes do not leak into inputs.
Discuss this requirement
Domain specification / 07

Industrial & design

Define the discipline and the downstream task. A native CAD assembly, a rendered drawing and a maintenance history carry different information and need different acceptance checks.

Unit of data
A design revision, work order or inspection linked to the relevant asset.
Context to preserve
Native file versions, dimensions and units, assembly references, revision history, asset identifiers and links to specifications or inspection findings.
Sample review
Check missing dependencies, incompatible formats and mismatched revisions. Record whether a result is a simulation, inspection or observed field outcome. Scope third-party design rights with the source owner.
Discuss this requirement
Domain specification / 08

Healthcare & imaging

Define the cohort by modality, anatomy, finding and clinical setting. Specify whether labels come from a report, a reader annotation or a confirmed outcome; those are different reference standards.

Unit of data
A patient, study or series, with the matching report and required metadata.
Context to preserve
DICOM study and series relationships, report linkage, acquisition parameters, scanner information and permitted longitudinal links where the source supports them.
Sample review
Check incomplete series, duplicate studies and missing reports. Specify de-identification review for headers, free text and burned-in pixel text. Agree patient-level separation and any site or time holdouts for evaluation.
Discuss this requirement
Domain specification / 09

Writing & research

Specify subject depth, language and publication period, then whether the task needs full documents, passages or text linked to tables and figures. Record prior public availability.

Unit of data
A complete work or section with its document hierarchy and provenance.
Context to preserve
Titles, authorship where permitted, publication dates, section order, citations, tables, figures and edition or revision identifiers.
Sample review
Check OCR quality, reading order, boilerplate and duplicate editions. Distinguish source text from generated summaries. Identify publisher, author and embedded third-party rights before agreeing a license.
Discuss this requirement
Domain specification / 10

Audio, images & video

Define the task and acquisition conditions. Speech recognition, speaker attribution, visual grounding and temporal reasoning require different metadata and annotation granularity.

Unit of data
An original recording, clip or image with aligned descriptive context.
Context to preserve
Capture settings, language, timestamps, transcript or caption alignment, speaker or scene segmentation and links to related records where permitted.
Sample review
Check clipped or corrupted files, sync drift, near-duplicates and annotation origin. Record participant permissions and third-party content restrictions. Group related speakers or recordings when an independent evaluation requires it.
Discuss this requirement

These are sourcing specifications. Available sources, fields, permissions and preparation requirements are confirmed against your brief.

02 / From brief to reviewA defined process

From a source record
to a reviewable dataset.

Our role is to connect your data requirement with relevant businesses and work through feasibility with the owner. Scope extraction, preparation and specialist review explicitly, including who performs each step.

  1. 01

    Define the task and acceptance criteria.

    Set the unit of data, inclusion and exclusion rules, required context and permitted use. Distinguish minimum requirements from preferences. Define how your team will decide whether a sample is useful.

    Output: a sourcing specification
  2. 02

    Establish source feasibility.

    Work with the business to establish systems, retention periods, record counts, linkage and licensing authority. Separate what is confirmed from what still needs inspection; a count of files alone does not establish a fit.

    Output: source profile and known gaps
  3. 03

    Review a representative sample.

    Agree sampling and access terms, then assess the sample against the specification. Review coverage, field completeness, duplicates, linkage and domain-specific issues. Record exclusions and required preparation before scaling.

    Output: sample findings and a go/no-go decision
  4. 04

    Agree the release specification.

    Define the license, schema, transformations, version, delivery manifest and acceptance process. Assign responsibility for extraction, annotation or de-identification where required. Set terms for corrections and subsequent releases.

    Output: license, delivery scope and responsibilities
03 / What needs to be clearBefore a purchase

A dataset your team
can assess.

The review package should make the collection inspectable before a full purchase. Agree the following with the source owner, and identify anything still unverified.

Source & exposure
Originating business and systems, collection period, licensing authority, known public availability and prior licensing. Note any limits to what can be established.
Composition & coverage
Counts by the agreed unit, source, period, language and relevant cohort. Document selection rules, missing segments and whether the sample reflects the wider collection.
Schema & relationships
Field definitions, types, units, identifiers and join keys. Describe record linkage, timestamp handling, schema changes and relationships lost during export or redaction.
Quality & annotations
Completeness, duplicate checks, parsing errors and sample rejection reasons. Identify how labels were created, by whom, under which instructions and with what review.
Rights & preparation
Intended use, term, exclusivity, onward sharing and exclusions. Document agreed transformations and the review of sensitive fields; mark unresolved permissions.
Version & delivery
Release identifier, file manifest, checksums, format and transfer method. Define acceptance, corrections, refresh cadence and responsibilities for each preparation step.
04 / Buyer questionsBefore you send the brief

The details
worth asking.

What do your business relationships give us access to?

They give us an existing route to businesses that may hold relevant records and to the people who can assess a licensing request. A relationship is not a data license. We confirm collection fit, authority and permitted use with each prospective source.

Do you supply raw records, curated datasets or task environments?

The delivery format is part of the brief. Source archives, normalized records, annotated examples and executable task environments involve different work. We establish which pieces already exist, what preparation is needed and who will perform it before proposing a scope.

How do you approach training and evaluation data differently?

Training briefs may prioritize coverage, diversity and scale. Evaluation briefs also need defined tasks, reference answers or outcomes, and separation from development data. Specify the required holdout unit, such as a company, repository, patient or time period. Prior licensing and known public exposure should be recorded; an unseen-data guarantee should not be assumed.

What should a sample establish?

Whether the proposed source can meet the specification. Agree how the sample is drawn, then inspect required fields, linked records, missingness, duplicate handling and domain-specific quality. A selected showcase is not a substitute for a representative sample.

How are rights and sensitive fields handled?

Identify the source owner, licensing authority, third-party contributions and intended uses. Define exclusions and the preparation or de-identification review needed for that collection. Any sample access, storage, onward sharing and retention terms must be agreed before transfer.

Can we request repeat deliveries or exclusivity?

Yes. State the refresh frequency, incremental volume and exclusivity scope in your brief. Feasibility depends on the owner and source system. Agree versioning, additions, corrections and the treatment of withdrawn records in the delivery terms.

How are cost and timing established?

Against the scoped work: source identification, license, extraction, preparation, annotation if required, and delivery. We establish responsibilities, dependencies and acceptance criteria before agreeing fees or dates. Availability must be confirmed for the specific brief.

Start a sourcing conversationFor labs, research teams & data buyers

Tell us what
you need.

Share your requirements

A useful first brief includes:

  • Task, intended use and unit of data
  • Required fields, record links and source coverage
  • Target volume, exclusions and sample criteria
  • Format, timeline and budget, if known

Send the specification you already use. We’ll assess potential sources through our business relationships and identify the questions that need resolving.

Have data to license instead? Start here ↗