How an answer is produced, and what stops a bad one.

In the product today

One question, six steps

1. 1Stills

   Ten stills are cut from the clip in the browser. Faces are masked on the device before anything is sent; the video itself never leaves.

2. 2Guard

   The server accepts only same-origin requests, ten JPEG stills of one clip under size limits, and sample stills byte-identical to the committed ones.

3. 3Instant path

   A recorded answer, or the clip's event record, answers without any model call.

4. 4Live model

   Otherwise one vision-model call, inside a site-wide daily budget, routed to zero-retention endpoints, with a hard timeout and bounded output.

5. 5Gate

   Deterministic checks decide the verdict: cleared, held, not actionable, abstained or unverified.

6. 6Question log

   Every answer shown is appended to a hash-chained log with its source and verdict.

Vision model on this deployment: openai/gpt-4o, replaceable per deployment without code changes. Current prompts: answers ask-v3-2026-09-26, event records extract-v1-2026-09-26. Every recording states the prompt that produced it; the answers on the Evidence tab came from the earlier ask-v2.

Controls

What surrounds the paid model

A public page in front of a vision model is a cost and privacy surface. These are the controls, and which of them run today.

• Spend ceilingEvery live call is counted against a durable daily budget per visitor, per product and site-wide; when it is spent, the product answers from its recorded evidence and says so.Running
• Request guardSame-origin only; at most ten JPEG stills of one clip, each under 300 KB and 1,280 px; questions of 300 characters or fewer.Running
• Sample integrityStills claimed to come from a sample clip must match its committed SHA-256 hashes, so labels and duration are the server's, never the client's.Running
• Data routingModel calls are routed to zero-data-retention endpoints first, and never to endpoints that train on or collect the data.Running
• Error hygieneProvider errors are logged on the server only; the page receives a fixed, plain message.Running
• Face maskingAn on-device face detector masks faces before any upload still is sent; if it cannot load, nothing is sent without the visitor's consent.Running
• Prompt scopeThe model is told to ignore instructions inside the question or the frames; answers render as text, never as markup.Running
• Edge processingRaw video stays on site; only masked events and pointers leave.Design
• Role-based access and SSOQuestions and playback scoped by role; works-council viewers see aggregates only.Design
• Anchored audit logThe question log's chain head anchored in write-once storage, so recomputing hashes is detectable.Design

Event ontology

What counts, and what must not

Nine typed events, each with an observable cue and a guard against the confusion vision models make most. The same definitions go into the model's instructions and into the event record the gate checks.

Production design

Extract events once on site, query them many times

Not running in this web product. The design a plant deployment grows into: perception and masking at the edge, so only events and pointers leave the site.

Requirements

Must-haves, and where each one stands

Build or buy

Buy perception, build judgement

• Perception modelsBuyImproving fast and commoditising; keep the model layer swappable.
• Event ontology and guardsBuildThe domain judgement that decides what counts.
• Evidence gate and evaluation setBuildThe product: what makes an answer defensible.
• Edge runtime and maskingBuild on standard partsRegulatory necessity; commodity detectors, owned orchestration.
• Event store and queryBuy infra, build glueStandard storage; the question-to-event mapping is ours.
• EHS and MES integrationsBuildWhere answers become corrective actions; drives retention.

Status

What runs today, and what is design