# Capture Desk

> A single black flicker frame is visible for about 17 milliseconds. Recorded at 2fps you
> catch it about one time in twenty-nine - so a clean recording is the expected result
> whether or not the flicker is there. Five lanes over one capture plan, plus a free
> browser-side calculator that computes the odds before the recording is spent.

URL: https://capture-desk.skillsafe.ai/
API: https://capture-desk.skillsafe.ai/api.html

Derived from oxbshw/watch-skill (https://github.com/oxbshw/watch-skill), MIT: its
`the-loop` record-critique-iterate cycle, its bounded `loop monitor` with an interval and
a check limit, and the design rule its agent guide states outright - absent evidence is
never a pass. This app is what that rule looks like as arithmetic.
Not affiliated with or endorsed by oxbshw.

## What the free calculator does

It runs entirely in the browser, on the plan you type, with no account and no credits.

1. **Parses** a capture plan (duration, fps or monitor interval, per-channel rates) and a
   catch list where every line carries its own duration, occurrence count and channel.
2. **Computes the gap between samples** for each channel. A recording gets it from fps; a
   monitor gets it from `interval`. OCR or DOM every Nth frame samples N times slower than
   the frame rate, and audio, when on, is continuous and has no gap at all.
3. **Prices each phenomenon**: `min(1, d / i)` for one occurrence, `1 - (1 - d/i)^n` over
   n of them, plus the sample count inside a steady state and the minimum frame rate that
   would make it unmissable.
4. **Inverts the burden on never-happens claims.** Seeing a thing once needs one lucky
   sample; saying it never happened needs coverage that could not have missed it. Below
   full coverage the claim can only ever fail, never pass, and the panel says so.
5. **Names the one line setting the rate** for the whole capture, and prices the plan
   without it - because that line is rarely the one anyone would have paid for on purpose.

## The arithmetic, in full

A phenomenon visible for `d` seconds, sampled every `i` seconds with unknown phase, lands
in at least one sample with probability `min(1, d / i)`. Over `n` occurrences:
`1 - (1 - d/i)^n`.

- `d >= i` is guaranteed. Nothing longer than the gap gets between two samples. This is
  the only regime in which a not-seen result means anything.
- `d < i` is a lottery, and the same build recorded twice gives different answers.
- The minimum honest rate is `1 / d`. For a frame of a 60Hz display, about 59fps.

## The channels

- `frames` - the recording itself, sampled at the frame rate
- `ocr` - text read off the frames, usually every Nth, which derates it
- `audio` - continuous when on, so anything audible of any length is caught
- `dom` - structural snapshots of a web target, sampled like OCR is

The asymmetry between audio and the rest is worth knowing early. A 40ms click is caught
every time by audio and essentially never by frames at 2fps, and the difference is not the
event, it is which instrument was pointed at it.

## Monitors

A monitor has no frame rate. `interval` is the gap between samples, and `interval` times
`max-checks` is how long it watches at all. If that product is shorter than the window the
condition could occur in, the monitor stops early and reports not-seen for a stretch it
never looked at - which is the worst shape a negative result can have, because nothing in
the output says so. Both bounds are checked, and they pull against each other: tightening
the interval to catch brief things shortens the window the same budget can cover.

## The lanes

- `plan` - turn a goal into a capture plan with a rate, the channels it needs, and a catch
  list where every line carries its own duration
- `audit` - the paid read of the free panel: every phenomenon priced, every never-claim
  tested, the plan rewritten
- `budget` - what the rate is costing you, with the plan priced with and without the line
  that sets it
- `read` - what a capture that already ran is allowed to prove, separating what it saw
  from what it merely did not see
- `monitor` - design a bounded watcher and say what the two bounds can and cannot
  guarantee

## What it does not do

It does not record, watch or judge anything. The numbers are only as good as the durations
you give it: a phenomenon whose length you guessed at is a probability you guessed at. It
cannot tell you whether a phenomenon is worth catching - only what catching it costs.