How a clip is judged, and what a partner is told

The verdicts

A clip carries one of three verdicts and there is no fourth: accepted, rejected, pending. The app prints a rejected clip as NOT ACCEPTED, and says of a pending one that it is waiting to be reviewed. Waiting is a real state rather than a gap. A partner's clip list is built by joining what they sent to what has been judged, so a clip nobody has looked at yet still appears, marked as waiting, instead of dropping out of their record.

Two paths write a verdict today with nobody involved. The first is a single-shot upload route, kept for small files and for the test harness and explicitly not for field capture: it runs one decode pass over the file — mean sharpness, mean brightness, and whether the decode reached the last frame — and records an accepted verdict when all three clear their thresholds. The second is segmentation, and it is the one a Capture Partner's Recording actually meets: as it cuts a Recording into Clips it records an accepted verdict against every Clip it cuts. A third writer, the old standalone QA stage, is kept reachable so that an older job row does not crash the queue, and it sits in neither live sequence.

That second path decides what the word accepted means on most rows, so it is worth being exact. The verdict segmentation writes carries no rejection reason, and it is written at the moment the Clip is minted, before anything else runs on it. It records that the cutter judged that stretch of footage usable. It does not record that a person watched it, and it does not record that anyone found it good enough to hand to a Commissioning lab.

A span the cutter judged unusable never becomes a Clip, so it never gets a verdict row at all. Its reason goes into the segmentation summary saved beside the Recording, in a separate vocabulary of five values, of which exactly one name — low light — also appears among the nine. The nine govern clips. The five govern spans. They are not the same list, and a count taken from one does not describe the other.

A verdict can be replaced. Recording a second verdict against the same clip id overwrites the first, deliberately, because a re-review supersedes an earlier judgement and QA is an operational measurement. The consent ledger is the record that keeps every entry it was ever given; this one keeps the current answer rather than the sequence of answers that produced it.

The nine rejection reasons

Nine reasons exist and the list is closed. A reason outside it cannot be recorded, which is what makes a breakdown countable: a rejection rate on its own tells us nothing we can act on, and the same rate describes completely different problems depending on which of the nine dominates.

They divide three ways, three each. Three can be settled without a person. Two of those are arithmetic — a mean Laplacian variance under 80 reads as blur, a mean grey level under 30 on the 0–255 scale reads as too dark — and the third asks only whether the decode reached the last frame. Three need a person, because no threshold decides whether both hands stayed in shot, whether the briefed task is the one that was performed, or whether the action was complete. The last three name a failure on our side of the line rather than a judgement about the recording.

The nine live in exactly one place: a table in the engine, where each reason carries the label a Capture Partner reads and the single line telling them what to do differently. The list below is generated from that table on every build, and a check refuses a push when the two disagree. The one field the engine holds that is not shown is our own internal note on what each reason means for us to fix — it is not what a partner reads, and the generator excludes it.

Only three of the nine are ever written by code, and they are the three that decode pass can derive. Nothing in the engine assigns the other six anywhere; they arrive only when a person records one by hand. One of them never arrives — a duplicate upload is caught at ingestion by content addressing, which derives the same identifier from the same bytes and reports a duplicate instead of writing a second row, so nothing is ever recorded against the partner for it.

Each of the nine carries a third field beside those two. It is written for us rather than for the partner, it names something at our end, and it stays internal. The engine builds the partner-facing version out of the label and the guidance alone, by construction rather than by remembering to remove the third field at each point of use. This page does not print it either.

What a Capture Partner sees

The signed-in app lists the clips a Capture Partner sent, newest first, each with its clip id, the day it went and the brief it was recorded against. The list reads up to five hundred rows from the provenance table. A rejection renders as two lines, the label and then the guidance, so it reads as instruction rather than as a verdict to absorb.

Two internal fields stop at that boundary. The reviewer's free-text note is written for a colleague, and a note about a person is not feedback to them. The taxonomy's third field is ours to carry. The engine removes both in the controller rather than in the store, so our own internal book reads the same rows and still sees the full record. Two independent suites assert the removal, and the browser one feeds a response carrying both fields on purpose — proving the screen would not render them even if the engine sent them.

The acceptance figure on that screen arrives as nothing at all until at least one of that partner's clips has been judged, by the automatic pass or by a person, and the branch that handles nothing runs before any arithmetic. A partner with five clips still waiting has no rate. Printing nought per cent would tell them they had failed five times. Clips still waiting count neither way: they cannot raise the figure and they cannot lower it. Where a rate does appear it is labelled derived, not measured.

Each clip in that list carries a control that re-runs the automatic pass over that one clip and hands back its sharpness, brightness and decode figures. It answers the question a turned-down partner actually has — how far off was this — which a category on its own does not. A partner can reach only their own clips, and asking for somebody else's returns a not-found rather than a refusal, because a refusal would confirm the clip exists.

The human hold

A Recording the cutter reduced to zero usable spans is not settled. The job moves into a state that is deliberately not terminal, carries no completion time, and stays counted as in flight. Nothing accrues against it, because an entitlement is derived only from accepted clips and there are none to derive from.

The reason is measurement rather than sentiment. A fault in the cutter and a genuinely unusable Recording look identical from outside; the second is rare, and the first is exactly what a cutter does when it breaks. Review is how we find out which one we are looking at. The cutter also refuses rather than reporting zero when it cannot run at all — the failure propagates and the stage retries — so a crash never presents itself as an hour of somebody's work being worth nothing.

Redaction runs before this point. Anyone who reviews the footage therefore reads the redacted copy, and if that copy is missing the stage raises an error and says to re-run redaction rather than reaching for the original.

Who decides a clip that is questioned

One route lets a person write a verdict, and it requires an admin or reviewer role. It is how the three reasons no machine can judge get recorded, and how an automatic verdict is corrected. Recording a second verdict against the same clip id replaces the first.

A Capture Partner raises a clip from the app itself. The help panel carries a category reading “A clip was not accepted and I think that is wrong”, with a field for the clip id — which exists because that message is unanswerable without knowing which clip. Identity comes from the sign-in token rather than from anything typed into the form, so the message attaches to a real account and a name or address in the body is ignored.

No route a partner can reach changes a verdict. A person reads the message and records any new verdict by hand, through the reviewer route above.

The acceptance rate

An acceptance rate describes a Capture Partner cohort recording against a commissioned Capture Brief. A figure may be called measured only when it comes from a committed artifact, and QA verdicts are written to a runtime database that is not in version control, so no rate computed from it is published here.

With no verdicts to count, the report returns no rate and labels itself none rather than measured. The partner's own screen runs the same check before any arithmetic, because a zero would be a claim about work nobody judged.

An automatic verdict counts toward the rate exactly as a reviewed one does, and segmentation writes an accepted verdict for every Clip it cuts, so a rate over automatic verdicts alone would report how much footage the cutter kept.

When a rate is computed it carries a 95% Wilson score interval, and a flag stays false until that interval narrows to five percentage points either side or better — five, because the band we are trying to locate ourselves in is twenty points wide, and anything looser cannot tell its two ends apart. Wilson rather than the normal approximation, because the normal method reports a zero-width interval when ten clips out of ten pass. Certainty, from ten data points, is the most dangerous output the function could produce. Wilson on the same ten returns 72.25% to 100%, give or take 13.88 points — still nearly three times too wide to price against.

The three automatic gates, exactly. Sharpness and brightness are means over an evenly spaced sample of frames rather than over every frame of a long file: the step is the frame count divided by fifty, so a long recording contributes about fifty samples and one under a hundred frames contributes all of them. The brightness gate reads a mean grey level on the 0–255 scale, stored in a field named for lux; no illuminance is measured. The dropped-frame check counts only a decode that stops before the last frame, as one dropped frame, against a five per cent threshold, so it fails only a recording shorter than twenty frames.