Robot-Fleet Learning Safety-Case Architect — Public-Space Services

The mandate

Robots operating in stations, hospitals and commercial concourses encounter edge cases that become training candidates for later fleet policies. Current tools track software deployment and incident tickets, but cannot consistently show which field episode was selected, how labels and simulations changed it, why a learned policy passed, or which site constraints made deployment acceptable. Fleet scale magnifies weak learning governance.

The required deliverable is a Robot Fleet-Learning Safety Case Architecture spanning episode capture, privacy filtering, annotation, scenario abstraction, training set, policy build, simulation, safety argument, site approval, canary release, monitoring and rollback. Three representative behaviour changes will demonstrate the model without converting statistical performance into an unsupported claim of site or product safety.

Milestone one at week four provides deployment observation, learning-lineage fractures and consequence-ranked scenarios. Week ten concludes milestone two with evidence contracts and decision boundaries. By week eighteen, milestone three delivers reference safety threads and controlled fleet trials. The accepted architecture, supplier schedules, release playbook and internal qualification suite close milestone four at week twenty-six.

Acceptance requires internal safety owners to reconstruct fifteen unseen behaviour changes from field episode to current fleet exposure; a poisoned label and a site-specific near miss must trigger bounded withdrawal; and privacy specialists must verify pedestrian-data treatment. The group safety director signs after client teams conduct a novel-crowd and disconnected-robot exercise without external direction.

The client will provide sanitised field recordings, incident and intervention histories, model and dataset registers, simulation assets, release logs, site rules, privacy assessments and controlled robot access. Client engineers build reference integrations and select algorithms. Product Safety and site operators retain safety and deployment decisions; production development, robot certification, surveillance design and hardware change are excluded.

Why this is external work

Autonomy teams optimise learning, field teams manage local hazards and release tooling records binaries, but no neutral owner joins all three into a reviewable safety argument. Suppliers have incentives to privilege their simulator or data stack. External architecture provides portable evidence and adversarial exercises without declaring the learned robot safe or directing public operations.

What you will own

• Trace field episode, intervention, privacy treatment, annotation, scenario, dataset, policy build, simulation, approval, release and rollback evidence.
• Define when site-specific context may support fleet learning and when it must constrain or prohibit broader policy deployment.
• Design change arguments that connect safety requirements to test coverage, uncertainty, residual risk and accountable human acceptance.
• Exercise corrupted label, rare pedestrian behaviour, sensor degradation, venue change, connectivity loss and canary-monitoring blindness.
• Specify fleet segmentation, rollout ceilings, kill paths and rollback evidence for learned behaviour under live operating constraints.
• Compare simulation and learning platforms through scenario portability, provenance, privacy, determinism, supplier exit and field usability.
• Transfer scenario curation, safety-thread review and release qualification to permanent autonomy, safety and operations owners.

Candidate qualifications

• Led safety assurance or learning-platform architecture for deployed mobile robots, autonomous vehicles or comparable embodied-AI fleets.
• Connected field interventions, curated episodes, datasets, learned policies, simulations and staged releases in a reproducible evidence chain.
• Governed policy withdrawal after a site-specific near miss, label defect, distribution shift or monitoring failure under operating pressure.
• Worked with safety engineers, human-factors specialists and public-site operators without treating aggregate model metrics as deployment approval.
• Designed canary, fleet segmentation and rollback mechanisms for heterogeneous robot hardware, software and environmental constraints.
• Delivered supplier-neutral assurance architecture that internal teams used to qualify novel scenarios after engagement closure.

Non-negotiables

• The named architect must lead Tokyo field observation and the novel-crowd acceptance exercise at an operating deployment.
• No financial relationship may exist with robot, simulation, annotation or fleet-learning suppliers evaluated.
• Product Safety and site operators retain hazard acceptance, public deployment, intervention and certification decisions.
• Production autonomy development, surveillance expansion, robot certification and unrelated hardware redesign remain outside scope.

1. 49 words maximum. Describe a field episode that improved one robot policy while creating unsafe transfer risk elsewhere.
2. 49 words maximum. How did you expose a learned behaviour’s residual risk beyond its aggregate simulation score?
3. 49 words maximum. Which client evidence is essential before testing a poisoned-label fleet rollback?