Industries

Firmware rollouts for inspection and mining robots.

Units that work underground, inside pressure vessels and along corridors with no coverage for kilometres. Temper treats the depot as a real delivery path and keeps an evidence trail that survives the incident review.

What breaks in inspection work, specifically

Connectivity assumptions break hardest in this segment, and the compliance burden is heavier than anywhere else on this site.

Some sites have no RF at all

Underground, inside a vessel, down a substation corridor. There is no marginal link to be clever about, there is no link. The update path is the depot, a technician's laptop, or nothing.

Change control is a document someone signs

Permit to work, safety case, incident review. Months later somebody has to prove which build was on that unit on that shift, and who authorised it. A commit hash in a chat thread is not an answer.

Long service intervals hide bad builds

A unit inspected quarterly can carry a regression for months before anyone notices. You cannot lean on frequent check-ins, because thirty days of silence is normal here, not a signal.

What a health gate looks like on an inspection unit

Signals worth gating an inspection payload release on
SignalWhy it gates here
calibration_drift_pctA payload that reads half a percent off still returns data, and that data goes into a report someone acts on. Silent measurement error is the worst failure mode in this segment.
scan_coverage_pctA run that misses eight percent of the surface looks like a completed inspection until the next one contradicts it.
localisation_time_on_entryIf a unit takes too long to place itself on entry to a known drift, the shift is lost and the operator walks it out.
selftest: gas-sensor, estopSafety-relevant peripherals get an explicit post-update self-test, because a regression here is not a data quality problem.
attest: recovery_slotOn a unit nobody can reach for a month, the recovery image being intact is itself a gate condition, not an assumption.

The same rollout, written for a site with no coverage

rollout.yamlmining and inspection
# Some of this fleet will never see the control plane.
release: inspection-payload@2.4.1
rollback_to: 2.3.0

transport:
  - name: uplink
    match: { site: surface }
  - name: depot                  # underground units are updated at the portal
    match: { site: underground }
    bundle: signed, offline
    applied_by: technician

verify:                          # runs ON the unit, no network assumed
  trial_boot: 3 attempts
  confirm_within: 1 shift
  checks:
    - service: payload-core healthy
    - metric: calibration_drift_pct < 0.5
    - metric: scan_coverage_pct > 98
    - selftest: gas-sensor, estop
    - attest: recovery_slot intact
  on_failure: revert_and_report

rings:
  - name: canary
    match: { fleet: internal }
    soak: 2 shifts
  - name: surface
    match: { site: surface }
    soak: 5 shifts
  - name: underground
    match: { site: underground }
    requires_approval: true
    approver_role: responsible_engineer

ring_gate:
  min_confirmed: 8 units
  max_self_reverts: 0
  stale_after: 30d               # quarterly service intervals are normal here
  on_timeout: escalate

evidence:
  retain: 7y                     # outlives the unit, and usually the contract
  export: signed_manifest

on_gate_failure: halt_and_rollback

The transport block is what makes this segment different. A depot ring is not a fallback for when the network fails, it is the normal delivery path for part of the fleet, with a signed offline bundle and a named person who applied it. The unit still verifies itself exactly the same way afterwards, because the risk is unchanged by how the bytes arrived.

stale_after at thirty days reflects real service intervals. evidence.retain at seven years reflects the fact that the question gets asked long after the release is forgotten, and usually by someone outside your company.

How Temper handles it

01Depot as a first-class ring

Offline bundles are signed, versioned and recorded the same way an over-the-air release is, so the audit trail does not have a hole where the underground fleet should be. See offline updates.

02Verification that assumes nothing

Trial boot, on-unit checks, automatic revert. A unit two kilometres in has to save itself, because nobody is going to reach it. See automatic rollback.

03Approval with a name on it

Rings that touch the underground fleet require an approver in a named role, and the approval is part of the record rather than a message someone screenshots. See audit and compliance.

04An answer for the review

What ran on which unit, when, applied by whom, verified against what. One query, exportable as a signed manifest. See audit and compliance.

Early access

Running units where there is no signal?

If your update process currently ends with a technician, a laptop and a USB stick at the portal, that is a supported path here rather than a workaround.

Founding customers get direct engineering time and a permanent founding rate.