How to Specify a Custom Human Video Dataset Capture Protocol

A custom human video dataset capture protocol turns a model workflow into recordable events, metadata and acceptance rules. A useful first brief does not need to solve every production question. It should explain what the data must help you train, evaluate or compare, what material needs to be captured and which constraints matter before production begins.

Complete what you already know. Mark uncertain fields as to be agreed. We can resolve open production questions during scoping.

First decide which capture path you need

A new production is not always the only option.

• Ready dataset: an existing package covers the required data, and its applicable license fits the intended use.
• Extension of an existing protocol: the structure is close, but you need additional participants, repetitions, environments or agreed variants.
• New custom capture: the required workflow, recording setup, participant profile or acceptance logic needs a separate protocol.

Start by reviewing the available datasets. If none is a suitable fit, use the template below for a custom-capture request.

Copyable custom dataset brief

Copy these headings into an email or working document. Short answers are enough for an initial review.

1. Intended model workflow

Describe what the dataset should help your team train, evaluate, compare or validate.

Include where relevant:

• the model or system category;
• the decision or behaviour the data should support;
• whether the data is for training, fine-tuning, evaluation or internal comparison;
• known failure cases or coverage gaps;
• how your team expects to determine whether the data is useful.

Your answer:

2. Existing data and the gap to fill

Tell us whether you already have a baseline dataset, sample or internal specification.

Include:

• what is already available;
• what is missing or inadequate;
• whether an existing Continental People protocol appears close;
• whether you expect a ready package, an extension or a new capture.

Your answer:

3. Required scale and unit of delivery

State the most useful unit for estimating the project.

This may be:

• participants;
• physical events;
• accepted clips;
• prompts × conditions × repetitions;
• unique recorded time;
• sessions or environments.

Separate target coverage from approximate file count. One physical event can produce several files when multiple cameras or audio sources are used.

Your answer:

4. Actions, prompts and repetitions

Describe the material participants should perform or produce.

Include:

• action or prompt taxonomy;
• required start and end states;
• variants and repetitions;
• success, failure or edge cases;
• timing or pacing requirements;
• whether actions must be continuous or separated into clips;
• continuity requirements across sessions.

If the taxonomy is not final, provide representative examples and explain which distinctions matter to the model.

Your answer:

5. Participant profile

Describe the people needed for the use case without sending personal identity documents at the enquiry stage. Describe cohort-level requirements only. Do not send participant names, medical records or other sensitive personal data with the initial enquiry.

Include:

• approximate participant count;
• age range or other relevant representation requirements;
• required skills, appearance, mobility or performance experience;
• whether faces, full bodies, hands or only limited regions must be visible;
• whether the same participants must return for multiple sessions;
• any exclusion or safety criteria relevant to the activity.

Explain why a participant requirement matters to the intended workflow. Recruitment feasibility is confirmed during scoping.

Your answer:

6. Environments, objects and continuity

Describe where and with what the actions should be recorded.

Include:

• studio, indoor, workplace or field environment;
• background and lighting requirements;
• objects, tools, furniture or consumables;
• wardrobe or appearance controls;
• branding, labels or third-party material that should be included or excluded;
• continuity requirements between participants, views or sessions.

Your answer:

7. Cameras, audio and optional measurements

State the capture characteristics that matter to the model, rather than specifying equipment without a workflow reason.

Include where relevant:

• camera views and framing;
• resolution, frame rate and orientation;
• fixed or moving camera;
• synchronization requirements;
• motion blur, focus and visibility constraints;
• whether audio is required, optional or must be excluded;
• microphone, channel or synchronization requirements;
• any requested sensors or additional measurements.

Optional sensors and non-standard capture systems are subject to technical feasibility review. Listing a device or signal in the brief does not imply that it is supported until the written scope is agreed.

Your answer:

8. Metadata and annotations

Separate capture metadata from derived labels.

Possible capture metadata includes:

• participant production ID;
• event, prompt, variant and repetition ID;
• camera view;
• environment or lighting condition;
• session and take status.

If you need annotations, describe:

• the requested label or annotation type;
• the required format or schema;
• whether labels are created during capture or after delivery;
• who produces, reviews and validates them;
• any accuracy or inter-annotator requirements.

Examples may include action labels, temporal segments, keypoints or landmarks, but availability and validation responsibility are confirmed only during scoping. Do not assume a requested annotation is included unless it appears in the agreed order and package specification.

Your answer:

9. Intended use and participant-permission scope

Describe the actual material and use case so that participant-facing permissions and buyer-facing terms can be scoped accurately.

State:

• whether the capture records faces, bodies, hands, speech, voice or participant-created works;
• who needs access to raw media;
• whether the material remains private or any preview must be public;
• anticipated training, evaluation, deployment and derivative uses;
• whether raw media must be shared beyond the purchasing organization;
• any retention, deletion or geographic constraints known to your team.

Do not assume that a general participant release or dataset license covers identification, biometric processing, voice synthesis, impersonation, surveillance, re-identification or sensitive-trait inference. Such uses require separate feasibility, contractual, permission and legal review, may be restricted regardless of participant agreement and may be outside the accepted project scope.

The brief records a request. Permitted uses and restrictions are defined only by the applicable order and license documentation.

Your answer:

10. Pilot, QA and acceptance

Define acceptance before full production where possible.

Include:

• whether a pilot or sample approval is required;
• technical checks such as file readability, resolution, frame rate, focus, exposure, framing, synchronization and audio;
• content checks for correct actions, prompts, variants and repetitions;
• coverage rules for required protocol combinations;
• accepted, rejected and ambiguous-take logic;
• allowable tolerances or documented deviations;
• reshoot window and approval milestones;
• who has authority to accept the pilot and final package.

A technically valid clip can still fail content or coverage QA. Describe the distinctions that matter to your use case.

Your answer:

11. Package, version and delivery requirements

Describe the handoff your technical team expects.

Include:

• preferred media container, codec and resolution;
• folder or object structure;
• manifest and metadata formats;
• README or data-dictionary requirements;
• checksum or integrity requirements;
• package-version and change-record expectations;
• private delivery and recipient-access constraints;
• any internal security or vendor-onboarding requirements.

A checksum can verify that a file has not changed; it does not prove label accuracy, permissions or suitability for a model.

Your answer:

12. Schedule and commercial priorities

State:

• desired pilot date;
• target final-delivery window;
• internal decision or procurement deadline;
• fixed requirements;
• negotiable requirements;
• the preferred trade-off if scale, schedule and capture complexity conflict;
• an approximate budget framework, if available.

An approximate range is optional, but it can prevent a technically valid proposal from being designed around the wrong commercial assumptions.

Your answer:

What happens after you send the brief

1. Fit review. We check whether a ready dataset, an extension or a new capture is the most appropriate path.
2. Clarification and feasibility. We identify unresolved production, metadata, permission, annotation and delivery questions.
3. Written scope. If the project is feasible, the proposed protocol, package, milestones, commercial terms and applicable rights are documented. A pilot can be included where agreed.
4. Capture and QA. Production is evaluated against the agreed technical, content and coverage criteria, with targeted reshoots where the production plan permits them.
5. Version freeze and delivery. The approved package is reconciled, versioned and transferred privately to approved recipients under the applicable order and license.

Submitting a brief is a request for scoping. It is not an accepted order or a commitment to deliver every requested participant profile, device, annotation, permission or schedule.

For more detail on the production evidence behind a delivered package, read How We Capture, QA and Version Human Video Datasets for AI.

Before accepting human training data, use the model releases buyer due-diligence checklist to compare participant permissions, buyer terms and delivery evidence.

Frequently asked questions

Do I need to complete every field?

No. Complete what you know and mark the rest as to be agreed. Intended use, essential actions and acceptance priorities are more useful at the first stage than guessed technical specifications.

Can an existing dataset be extended?

Potentially. If an existing protocol is close to the requirement, we assess whether additional participants, repetitions or conditions can form a compatible extension. Compatibility, versioning and rights still need to be defined; an extension is not assumed to be interchangeable with the original package.

Can annotations or sensors be included?

They can be requested in the brief. Technical feasibility, production method, validation responsibility, schedule and commercial terms are confirmed during scoping. They are not included by default.

Does a custom capture include every requested permission?

No. Describe the intended use accurately, including any sensitive processing. Participant permission, contractual scope and legal permissibility are separate questions. A requested use may require additional review or may not be accepted.

Can we approve a pilot before full production?

A pilot can be proposed when it materially reduces production risk. The written scope should identify what the pilot tests, who approves it and which changes remain possible after approval.

Who owns the raw media?

Ownership, access and permitted use are defined by the applicable order and license. The brief itself does not transfer ownership or grant rights.

How is the package delivered?

The current process uses manual request review and private delivery. The exact media, metadata, version, access method and documentation are specified for the applicable order.

Turn the requirement into a workable protocol

Have a defined use case or only an early data gap? Complete what you know in the template and send it for scoping.