Guetteur: a lookout that shows its work

Update: submitted and live, October 15

Guetteur is now submitted to the OpenCV AI Competition 2026 powered by AWS. The AWS dashboard, narrated demo, Devpost entry and MIT source repository are live.

API Gateway and Lambda arm64 run OpenCV 5 perception and receipt checks on built-in synthetic scenes. The local synthetic evaluation records 30/33 successful scenario runs, 21/21 honest ledgers proven and 24/24 tampered claims rejected under the documented test definitions. The final software test run passed 94 tests.

Physical baseline, walkthrough and item-removal depth recordings now exist, with capture integrity and clean shutdown verified. Calibration and real-world accuracy remain open. The dashboard simulates approval decisions; authenticated camera-to-cloud approvals are not deployed. See the current technical report.

Original preview: October 13

The dated text and diagram below describe the prototype at publication. References to AWS, the repository and physical capture as planned are historical; the update above supersedes them.

Guetteur is French for lookout: the one who watches so others don't have to. We have entered it in the OpenCV AI Competition 2026 as Team Drift. The rules ask for substantive OpenCV 5 analysis, a meaningful AWS component, and evaluation evidence that includes failures. The deadline is 26 October.

This is the entering post, written before the work is finished; the submission post comes later. It separates three states: built, planned and unmeasured.

The idea

Most camera AI does three things we dislike. It ships pictures somewhere else. It reports what it saw. And it asks you to take its word for it. Guetteur does the opposite on each count:

• The colour frames stay on the camera.
• An agent chooses what to look at next, based on what the evidence says.
• Every claim comes with a receipt.

The loop

The camera. We use a Luxonis OAK-D depth camera through our open-source oak-events tool. The colour sensor feeds the on-camera network and those frames are never linked to a host output. Guetteur works on depth only.

OpenCV 5. On the host, each zone of the depth map goes through a short chain: fill invalid stereo pixels with inpaint, denoise with medianBlur, compare against a temporal-median baseline scaled by a range-dependent noise model, clean up with morphologyEx, label blobs with connectedComponentsWithStats, and measure motion with calcOpticalFlowFarneback. The output is a small JSON observation.

The planner never sees pixels. It gets the observation and returns one action: carry on, recheck the zone with more frames and different parameters, pause the zone, compensate for drift, or ask a human. The action changes the next look, so visual evidence changes the next step, not just a log line. The planner today is a deterministic rule set. There is a slot for a language-model planner that must answer in the same action format; an answer outside the policy is rejected and the rule planner's choice is used instead. That slot is built. We have not yet run a language model in it.

The human gate. Anything that would leave the system waits for a person. If nobody answers, the answer is no.

One case that shows it

In one synthetic scene a low item, only 25 mm proud of a shelf, is taken. In any single frame the change is barely above the sensor noise: not enough to bother anyone. The planner sees contrast between "ignore" and "confident", so it calls for more frames. OpenCV re-runs on the integrated window, finds a clear change held for ten frames, and only then asks a human. A threshold-and-alert baseline run on the same scene raised nothing.

The receipts

A claim such as "a region of the shelf became 24 mm farther away and stayed that way" is saved as a small file that pins four things: what was asserted, where in the frame, which frames, and a digest of the input it was made against. A ledger then lists three receipts for it: the file's hash, a check written with numpy, and a check written with OpenCV. The two checks work separately and must agree. A vendored copy of the prove-it-done verifier reads the ledger and reports whether the step is proven.

Then we try to cheat. We make three tampered copies of one claim: the effect doubled, the region moved to the wrong pixels, the claim re-pointed at a different recording. We recompute the file hash so the hash still passes, which leaves only the two behavioural checks to catch the lie. In our demo run all three copies failed verification, with one receipt passing and two failing each time. That is one claim in one scene: the mechanism works, but we have not shown it is complete.

What is built, what is planned, what is unmeasured

We would rather say "synthetic" now than let a reader assume a camera was involved. The live evidence does not exist yet.

The pattern, if you are building something similar

• Give the planner a summary, not the pixels. It keeps the privacy boundary honest.
• Make "do nothing" and "ask a human" first-class actions, with a default of no.
• Write the claim, the check and the input down together, and check with two instruments.
• Attack your own receipts before anyone else does.

Independent project. Not affiliated with or endorsed by OpenCV.org, Amazon Web Services or Luxonis. OAK and DepthAI are Luxonis trademarks, used to say which hardware and SDK it works with.