Capture contract
Define accepted devices, sites, orientation, resolution, lighting, motion, obstruction, event metadata, quality gates, and the safe route for unusable input.
Captured evidence to reviewed action
Computer vision systems for reviewed operational decisions
BluePi builds computer vision as a controlled path from image or video capture to a business action. The system makes capture quality, model version, confidence, review status, workflow effect, and corrected outcome visible.
Computer vision inside an operating workflow
Keep capture quality, uncertainty, review, and action visible.
A production vision system includes the capture boundary, dataset record, model and threshold, evidence attached to each result, review path, workflow integration, and monitoring.
The release decision depends on the action and its error cost. Defect detection, event recognition, inspection, document capture, and reconciliation require different classes, latency, confidence, and review policies.
Evaluation contract
Test the complete response path by class, site, device, operating condition, threshold, latency, review load, rare case, and false-positive or false-negative cost.
Review and action contract
Publish a versioned result with evidence and exception state, route uncertainty to a named reviewer, and record the reviewed action and corrected outcome.
When this is the right starting point
- A model performs well in a curated test but fails on site
- Capture quality, device health, and rejected inputs are invisible
- Uncertain or high-risk results have no owned review path
- Model output is disconnected from the application, inspection, alert, or reconciliation action
Good fit
One operating workflow has a named owner, a measurable baseline, and users who can judge whether the result improves.
Poor fit
The request is capacity-only staffing, an unowned demonstration, or a broad transformation without a first decision and finish condition.
Evidence produced during delivery
- Baseline and decision definition
- Data and system-boundary map
- Evaluation or reconciliation result
- Runbook and ownership transfer
System detail
Open the part you need. Each section expands into the full delivery scope for that step.
01Define the operating decision
Start with the event or condition the system must identify, the actor who uses the result, the required response time, and the consequence of a false positive, false negative, delayed result, or unsupported input.
- Accepted image or video sources
- Object, event, defect, or state to identify
- Required classes and unsupported cases
- Response-time target and approved action
- Cost of each error type
- Review owner, escalation path, retention, and access requirements
02Control the capture boundary
The input contract records device, site, orientation, resolution, frame rate, lighting, motion, obstruction, distance, connectivity, event time, and required metadata. A capture-quality gate checks whether the input is usable before inference. Rejected or incomplete inputs receive a reason code and a route for recapture, review, or safe failure.
03Build a traceable dataset and label record
The dataset records where each image came from, which operating condition it represents, who or what produced the label, how disagreements were resolved, and which dataset version entered training or evaluation.
- Label definitions, examples, and disagreement handling
- Class balance and rare-event coverage
- Site, device, time, and environmental representation
- Train, validation, and test separation
- Duplicate and near-duplicate checks
- Restricted-image handling and dataset-version history
04Evaluate the complete response path
Evaluation covers the capture gate, preprocessing, model, threshold, serving path, review queue, and business action together.
- Precision, recall, and error cost by class
- Performance by device, site, lighting, angle, obstruction, motion, and distance
- Rare, ambiguous, missing, and unsupported cases
- Capture rejection and confidence-threshold behavior
- Automatic-action and human-review rates
- End-to-end response time, queue age, and reviewer turnaround
- Behavior when the model or a dependent service is unavailable
- Comparison with the current manual or rules-based process
05Publish a bounded result and review uncertainty
Each inference result contains the input and event identifiers, model version, predicted class or condition, confidence or score, threshold outcome, processing time, evidence reference, and exception state.
High-confidence results can enter an approved automatic action. Low-confidence, conflicting, unsupported, or high-risk results enter a review queue with the captured evidence. Reviewers can confirm, correct, reject, or escalate the result, while the system records the reviewer, evidence, decision, reason, and time.
06Integrate and monitor the workflow
The reviewed result reaches the application, reconciliation process, inspection workflow, alert, or system of record that owns the action. Monitoring separates capture, data, model, service, review, and integration failures.
Measures can include device health, input completeness, capture rejection, class and confidence distribution, drift, latency, throughput, review rate, correction rate, queue age, workflow completion, and downstream operating effect. Corrected outcomes return to the label and evaluation record. See this path in production in the FASTag computer vision case study.
FAQWhat does a production computer vision system include?
The system includes an accepted capture boundary, quality checks, traceable labels and dataset versions, preprocessing, a versioned model and threshold, end-to-end evaluation, a bounded result contract, human review for uncertain or high-risk inputs, workflow integration, and monitoring.
FAQHow should a computer vision system be evaluated?
Evaluate precision, recall, error cost, capture rejection, confidence behavior, response time, review load, and workflow completion by class, device, site, lighting, angle, obstruction, motion, distance, and rare or ambiguous condition. Include model, service, review, and integration failures.
FAQHow can a computer vision engagement start?
Start with one event class, capture environment, reviewer group, and business action. The first deployment needs representative evidence, an agreed error-cost model, a visible exception path, an end-to-end response target, and an owner for the reviewed outcome.
Start with one operating workflow.
We will review the owner, the baseline, the data path, the system boundary, and the route to go-live.
Discuss one workflow