What Is a Rejection Rate in Custom Data Collection?

Every capture program records more than it delivers. Some episodes fail a check and are left out, and the rejection rate is the share of checked episodes that were. Name the denominator (episodes, hours or frames) before trusting a figure. A low rate does not prove clean data, because a lenient gate also gives a low rate. What matters is the rule behind the number. Firsthand states those rules but not the rate itself, so every figure the site does not give is marked Not stated.

Every episode is machine-checked at ingest, then reviewed by a person against the task spec. The capture page lists six reject reasons: a sync breach, calibration drift, occlusion, invalid depth, a consent gap and a spec miss. The quality-gate entry adds coverage, frame-level labels and missing or misaligned streams. The first table gives each condition. A share of episodes rejected, a pass rate and a yield figure are Not stated.

A rejected episode goes to the reject log with its reason and does not count as a validated hour. On custom collection, rejected episodes are recaptured at Firsthand’s cost, and billing is per validated hour, so rejected footage is not billed.

A sync or calibration failure on a repeatable task is typically recaptured, because timing and geometry cannot be restored in post-processing. A consent gap is excluded, not patched. The rule for choosing recapture over dropping is Not stated.

A rejection rate is only as trustworthy as the log behind it. Without one, a buyer sees the validated total and cannot tell how much was discarded or why. The site states that the reject log ships with every batch with reasons, and that each episode’s meta.json carries a reject_flags field. The gap between raw and validated hours is the logged footage.

Read the reasons against the criteria in the spec. The log’s full field list and file format are Not stated.

A quality gate is the check, a rejection criterion is the condition that fails it, and acceptance criteria are the same tests written into a spec before capture. Re-capture follows a failure. The rejection rate is the outcome measure. The site states rules for the first four and no figure for the last.

Start with the rule, not the rate. Ask which checks reject an episode, what the thresholds are, what happens to a rejected episode and who pays. Ask whether a reject log ships with each batch. Only then ask for a rate, and for its denominator and the task it covers.

Firsthand states no rate, so measure it: the site describes a Spec Pilot as a small first batch against the written spec that surfaces the real reject rate before full volume.

Request a custom dataset and write the gates into the spec: checks, thresholds, reject rule and recapture handling. The site states a median of 48 hours from a signed spec to a first validated batch where coverage is already deep, and three to four weeks where contributors must be recruited.

The clock ends at a validated batch, so a task that rejects often takes longer to reach its target. A guaranteed rate is Not stated, so agree it before capture.

What is a rejection rate in custom data collection?

The share of captured episodes that fail quality checks and are excluded from a delivered dataset. Name the denominator before comparing any figure.

Does Firsthand state a rejection rate?

No. The site states the reject criteria and the reject log, but no share rejected, pass rate or yield.

Which criteria reject an episode?

A sync breach, calibration drift, occlusion, invalid depth, a consent gap and a spec miss.

What happens to a rejected episode?

It goes to the reject log with a reason, does not count as a validated hour, and is recaptured at Firsthand’s cost.

Am I billed for rejected episodes?

Billing is per validated hour, so rejected footage is not billed. Credit or refund terms are Not stated.

Is a lower rejection rate always better?

Not by itself. A lenient gate also gives a low rate, so read the criteria behind the number.

How do I find the real rejection rate for my task?

Measure it with a Spec Pilot, a small first batch against the written spec.

How do I request custom collection with stated quality gates?

Request a custom dataset and write the checks, thresholds, reject rule and recapture handling into the spec.