# On-device redaction for field-service photos: 120ms vs service level, redact or skip

Chase Pierce · October 25, 2026

> No public benchmark publishes a per-device redaction latency figure; measure your own fleet's three most common capture types against a 120 ms budget.

A practical check: separate workflow documentation from timing evidence. A product page can show that a photo attaches to a work order, but it cannot show that the redaction pass fits a 120 ms capture-time budget. Only a fleet benchmark can.

Therefore, the sourcing gap is the operative finding: no public benchmark in the sources reviewed here publishes a per-device redaction latency figure. Every number in your latency budget must be measured on your own fleet, using your three most common capture devices and your actual redaction pass.

![field technician high vis jacket photographs industrial HVAC unit](https://static.mm-ais.com/article-images-ai/on-device-redaction-for-field-service-ph-ai-48dfe1d1.jpg)
field technician high vis jacket photographs industrial HVAC unit

## Redact On-Device vs Skip vs Server-Side

The decision among on-device redaction, skipping redaction, and server-side redaction should be made from the capture-time latency budget, not from a feature checklist. If the redaction pass fits inside that budget on the devices technicians actually use, redact at capture; if it does not, keep capture fast and redact after upload; reserve skipping redaction for jobs whose photos contain no third-party subjects. The winner is therefore conditional, not universal: it changes with the measured latency on your fleet.

Option A, on-device redaction at capture, makes the technician wait for the model pass. Its benefit is that privacy is protected both in transit and at rest, and its cost is per-photo wait time multiplied by photos per job. When the measured median latency is within the budget, this option is the winner because it removes sensitive content before the photo leaves the device.

Option B, skipping redaction, gives zero latency and the fastest capture. The tradeoff is that raw faces, plates, and documents land in the work order system and in any downstream share. It is acceptable only where photos contain no third-party subjects; it is an exception, not a redaction strategy.

Option C, server-side redaction after upload, also gives zero technician wait. Privacy is protected at rest but not in transit. When on-device median latency exceeds the budget, this option wins because it preserves capture speed while restoring privacy before storage and sharing.

| Option | Technician wait | Privacy result | Choose when |
| --- | --- | --- | --- |
| A: on-device at capture | Model pass at capture | Protected in transit and at rest | Measured median latency is within the capture-time budget |
| B: skip redaction | None | Raw content remains in system and shares | Photos contain no third-party subjects |
| C: server-side after upload | None | Protected at rest, not in transit | Measured median latency exceeds the capture-time budget |

Apply the rule with measurements from your three most common capture devices: if the median redaction latency is within your budget, for example 120 ms, choose Option A; otherwise choose Option C. Option B remains limited to no-third-party-subject photos.

![Redact On-Device vs Skip vs Server-Side — On-device redaction for field-service photos](https://static.mm-ais.com/article-images-ai/on-device-redaction-for-field-service-ph-ai-4b9692a7.jpg)

## Costs and Numbers That Matter

The cost model this section owns is technician wait time: median redaction latency in seconds multiplied by average photos per work order multiplied by work orders per technician per day. That product is seconds of technician time per day. To price it, convert seconds to hours by dividing by 3,600, then multiply by your loaded hourly labor rate; annualize by technician count and working days. No external rate is supplied in the available sources, so use your own payroll or burdened-rate figure.

At a median latency of 500 ms, 8 photos per work order, and 6 work orders per technician per day, the arithmetic is 0.5 × 8 × 6 = 24 seconds per technician per day. That number is small in isolation, but it is incurred at capture time, on the critical path of every photo, so it can compound into capture friction rather than disappearing into background processing.

The larger exposure is behavioral: if redaction feels slow, technicians may skip photos. The available sources sources "How Real-Time Triage Reduces Callbacks" and "How Remote Diagnostics Reduce Unnecessary Truck Rolls" tie slower diagnosis to callbacks and unnecessary truck rolls, and "Why Manual Field Service Diagnostics Slow Down Every Service" frames manual diagnostics as inefficient. Skipped evidence can therefore convert a small wait into a larger downstream cost; price that exposure from your own callback and repeat-roll history.

Use the model as a gate, not a forecast: measure median latency on your three most common capture devices, compute the daily seconds, and compare the resulting labor cost with your callback and repeat-roll baseline and your capture-time budget (for example, 120 ms). If the wait cost is below tolerance but skipped-photo risk is high, treat the latency number as a warning signal rather than a green light.

For pricing, keep the rate internal: take the daily seconds, divide by 3,600, multiply by the loaded hourly rate you already use for field labor, and annualize by technician count and working days. Re-run the calculation whenever device mix, photo policy, or work-order volume changes; the formula is stable, but every input is local.

![Costs and Numbers That Matter — On-device redaction for field-service photos](https://static.mm-ais.com/article-images-pixabay/on-device-redaction-for-field-service-ph-a0301cd5.jpg)

## What the Evidence Does Not Establish

The evidence does not establish a device-independent redaction time. No published benchmark in the reviewed sources shows that on-device redaction completes in about 120 ms on mid-range field devices; modern phones differ by chip, camera resolution, and model size. Treat 120 ms as a budget to verify on your own fleet, not as a published specification.

That uncertainty matters because the latency rule is conditional. It applies when capture-time inference is the binding constraint and the device class is representative. If your three most common capture devices have different median latencies, the rule can flip by device class rather than by site or technician.

| Condition | Does the latency-budget rule still decide? | What to check instead |
| --- | --- | --- |
| Representative mid-range device, normal connectivity, no retention constraint | Yes | Benchmark the pass; if median latency exceeds the budget, skip capture-time redaction |
| Poor upload bandwidth at the site | No | Prefer on-device redaction even if slower; the network, not the model, is the bottleneck |
| Policy requires retained, auditable, or recoverable redacted images | Not automatically | Confirm whether on-device-only output satisfies retention and audit requirements before choosing it |

Low-connectivity sites are the first break in the rule. When upload bandwidth is poor, server-side redaction (Option C) can fail or delay, so on-device redaction can win even if its pass exceeds the capture-time budget. In that case the network, not the model, is the bottleneck, and the latency budget should not be the deciding factor.

Regulatory retention is the second break. If policy requires redacted images to be retained, auditable, or recoverable, confirm whether an on-device-only output satisfies that requirement before treating latency as decisive. The evidence reviewed here does not establish retention behavior for any specific platform or policy.

Use the table as a decision check, not as a substitute for measurement. Benchmark the redaction pass on your three most common capture devices, record median latency by device class, and only then decide whether capture-time redaction, skip-at-capture, or server-side processing fits the job.

![What the Evidence Does Not Establish — On-device redaction for field-service photos](https://static.mm-ais.com/article-images-pixabay/on-device-redaction-for-field-service-ph-05d3af84.jpg)

## And Rollout Checklist

Run this checklist before enabling redaction for any technician group. The rollout decision should follow measured latency on your own fleet, not a vendor claim or a single-device test.

Checkpoint 1 — measure. On each of your three most common capture devices, capture 20 test photos that include faces and license plates, then record median and p95 redaction latency per device. Keep the photo set, lighting, and capture distance identical across devices so the comparison reflects hardware rather than scene difficulty. Example inputs: Device A median 90 ms, Device B median 140 ms, Device C median 310 ms.

| Device | Median latency | p95 latency | Budget result | Action |
| --- | --- | --- | --- | --- |
| Device A | 90 ms | your measured p95 | Pass at 120 ms | Enable on-device redaction |
| Device B | 140 ms | your measured p95 | Marginal at 120 ms | Test p95 before deciding |
| Device C | 310 ms | your measured p95 | Fail at 120 ms | Route to server-side redaction |

Checkpoint 2 — apply the budget. Compare each median to the capture-time budget you verified for your workflow, here 120 ms. Device A at 90 ms passes. Device B at 140 ms is marginal: compare its p95 before deciding, because a median under the budget can still hide tail latency that blocks capture. Device C at 310 ms fails and should not use capture-time on-device redaction. Do not average devices; a mixed fleet needs a per-device rule.

Checkpoint 3 — cost the wrong call both ways. Forcing on-device redaction onto a device above the budget spends technician capture time on every photo and can turn redaction into a retry or a skipped step; skipping redaction on a device inside the budget leaves faces or plates unredacted in photos that leave the device. Include help-desk, rework, and privacy-review time in that cost, not just model runtime.

Copy the worksheet into the rollout ticket and require a named owner for each row. Enable on-device redaction only where both median and p95 clear the budget; otherwise configure the app to skip capture-time redaction for that device class and use the server-side path. Re-run the 20-photo benchmark after any OS, model, or camera change, and keep the benchmark file with the release notes.

![And Rollout Checklist — On-device redaction for field-service photos](https://static.mm-ais.com/article-images-pixabay/on-device-redaction-for-field-service-ph-80c9b162.jpg)

## Decision Rules: Redact or Skip

Start with a measured gate, not a policy preference: benchmark the redaction pass on your three most common capture devices and compare each class's median latency to your capture-time budget, such as 120 ms. Use the median rather than the average, because one slow model can hide inside an average. The decision is made per device class, because a phone that clears the budget and a phone that does not should not share one redaction setting.

If the measured on-device median latency is at or below the budget for a device class, enable on-device redaction for that class. If it is above the budget, configure that class for server-side redaction instead. Apply the rule separately to each class; avoid blending results across classes, because a median is only meaningful for the devices that produced it.

Before spending any latency, triage by photo type. If a type provably contains no sensitive subjects—for example, equipment close-ups with no people or plates—skip redaction for that type and keep the full capture-time budget for photos that actually need masking. Document the subject inventory that supports the skip so the exception is auditable rather than assumed.

Use a connectivity exception when the site has poor upload bandwidth: prefer on-device redaction even when the pass exceeds the normal budget, because a slow mask beats an unredacted upload. In that case, accept the capture-time cost as the price of not transmitting sensitive pixels over a weak link, and revisit the choice when connectivity improves.

Keep the rules explicit and reversible. Record the enable, skip, or server-side choice for each device class and photo type, then re-benchmark after any app, model, or OS update. When a class crosses the threshold, change its configuration rather than arguing from a single fleet-wide default.

## Frequently Asked Questions

**What kind of evidence can show that a redaction pass fits the capture-time budget?**

Only a fleet benchmark can show that, because a product page can show that a photo attaches to a work order but cannot show that the redaction pass fits the capture-time budget.

**What is the operative sourcing finding about public benchmarks?**

No public benchmark in the sources reviewed publishes a per-device redaction latency figure.

**How must every number in the latency budget be measured?**

Every number in the latency budget must be measured on your own fleet, using your three most common capture devices and your actual redaction pass.

**What should decide among on-device redaction, skipping redaction, and server-side redaction?**

The decision should be made from the capture-time latency budget, not from a feature checklist.

**When should skipping redaction be reserved?**

Skipping redaction should be reserved for jobs whose photos contain no third-party subjects.

**What privacy benefit does on-device redaction at capture provide?**

Privacy is protected both in transit and at rest.

## Quick answers

| What evidence is needed to know if a redaction pass fits the 120 ms capture-time budget? | Only a fleet benchmark can show that the redaction pass fits the 120 ms capture-time budget. |
| --- | --- |
| Are there any public figures for per-device redaction latency? | No public benchmark in the sources reviewed here publishes a per-device redaction latency figure. |
| What should guide the decision between on-device redaction, skipping redaction, and server-side redaction? | The decision should be made from the capture-time latency budget, not from a feature checklist. |
| When is it appropriate to skip redaction? | Skipping redaction should be reserved for jobs whose photos contain no third-party subjects. |
| How can reliable latency numbers be obtained for this decision? | Every number in your latency budget must be measured on your own fleet, using your three most common capture devices and your actual redaction pass. |

Also worth reading: **Work order closeout with voice: 18 to 3-4.2 minutes, dispatch or skip**: [Work order closeout with voice:](https://technician.dev/blog/work-order-closeout-with-voice-18-to-3-42-minutes-dispatch-or-skip.php) · **AI Field Technician Dispatch: Cutting Response Times and Boosting Satisfaction in 2026**: [AI Field Technician Dispatch: Cutting](https://technician.dev/blog/ai_field_technician_dispatch_cutting_response_times_and_boosting_satisfaction_in_2026.php) · **UPS ORION, Freeze Horizons, and the 10% Disruption Line**: [UPS ORION, Freeze Horizons, and](https://technician.dev/blog/ups-orion-freeze-horizons-and-the-10-disruption-line.php)

### Related reading

- [Field Service Routing: 14% Cost-to-Serve vs Union Seniority/Hours-of-Service Split](https://technician.dev/blog/field-service-routing-14-cost-to-serve-vs-union-seniorityhours-of-service-split.php)
- [Field service parts inventory staleness: AI dispatch first-time fix vs idle time 5 minutes](https://technician.dev/blog/field-service-parts-inventory-staleness-ai-dispatch-first-time-fix-vs-idle-time-5-minutes.php)
- [Field Service Dispatcher Overrides: 15-Minute Gate vs Full Automation](https://technician.dev/blog/field-service-dispatcher-overrides-15-minute-gate-vs-full-automation.php)
- [From Moving Averages to Stochastic Demand Forecasting in Field Service](https://technician.dev/blog/from-moving-averages-to-stochastic-demand-forecasting-in-field-service.php)
- [How AI is Optimizing Shift Scheduling for Field Service Teams](https://technician.dev/blog/how_ai_is_optimizing_shift_scheduling_for_field_service_teams.php)
- [Same Day Service Calls: 2026 5-Minute Re-Solve Cuts 18% Driving vs Manual](https://technician.dev/blog/same-day-service-calls-2026-5-minute-re-solve-cuts-18-driving-vs-manual.php)

### Latest

- [Field Service Routing: 14% Cost-to-Serve vs Union Seniority/Hours-of-Service...](https://technician.dev/blog/field-service-routing-14-cost-to-serve-vs-union-seniorityhours-of-service-split.php)
- [Artificial Intelligence Field Dispatch 2026: 30% Reassign or Manual Split?](https://technician.dev/blog/artificial-intelligence-field-dispatch-2026-30-reassign-or-manual-split.php)
- [Field service parts inventory staleness: AI dispatch first-time fix vs idle...](https://technician.dev/blog/field-service-parts-inventory-staleness-ai-dispatch-first-time-fix-vs-idle-time-5-minutes.php)

Canonical: https://technician.dev/blog/on-device-redaction-for-field-service-photos-120ms-vs-service-level-redact-or-skip.php
Markdown: https://technician.dev/blog/on-device-redaction-for-field-service-photos-120ms-vs-service-level-redact-or-skip.php/index.md