Section navigation
AAExample Conforming DeploymentABExample Conformance StatementACExample Record Surface MapADExample Configuration MatrixAEExample Multi-Vendor WorkflowAFExample Discovery AssessmentAGExample Feedback Routing TableAHExample Legal Hold ProcedureAIInternational Legal Sector GuidanceAJEmergent Autonomous Execution in a Web Research DeploymentAKMCP Integration with Regulated Financial InfrastructureALAcquisition Modality Landscape for Retained Interaction RecordsAMMobile Agent WorkflowANHealthcare Revenue Cycle Agent WorkflowAOEnterprise Governance Interceptor Workflow

Annex AM: Mobile Agent Workflow

Purpose

This annex illustrates ARCS application to a mobile-agent deployment in which on-device processing, operating-system AI services, cloud fallback, local storage, analytics, and platform backup together create a fragmented custody surface.

Scenario

A user installs a mobile application that provides AI-assisted health coaching. The application uses an on-device operating-system model for routine queries and a cloud API fallback for more complex requests. The user grants the application access to health data, location, and activity sensors. The application stores conversation history and personalized coaching artifacts in local app storage. The device is backed up to a platform cloud service under default settings.

Record Identification

Relevant records may include:

  • user health queries and instructions
  • model outputs and coaching recommendations
  • conversation history
  • health, location, and activity data used as inputs
  • personalized coaching artifacts or preference records
  • cloud fallback API logs
  • local application storage artifacts
  • platform backup copies
  • analytics or telemetry events
  • session receipts or other attestation records, if used

Some of these records contain deliberative content. Others are operational, sensor-derived, or mixed.

Lifecycle Boundaries

This scenario involves several distinct runtime and storage components:

  • the mobile application process
  • the operating-system AI service layer
  • the cloud fallback API
  • local persistent app storage
  • the platform backup service
  • analytics or telemetry SDKs

Artifacts may cross lifecycle boundaries when:

  • the app invokes the operating-system AI layer
  • the operating system routes a request to cloud services
  • the app writes from volatile processing into persistent local storage
  • the platform backup service replicates local storage to cloud
  • analytics or telemetry providers receive events from the device

Where the device or operating system determines the on-device versus cloud path at runtime, the operator may not always know which path a given interaction traversed.

Custody Surface Fragmentation

The custody surface may therefore include:

  • operator-controlled local application storage
  • platform-controlled AI service layers
  • model-provider-controlled cloud fallback systems
  • platform-controlled backup services
  • analytics-provider surfaces

The user may experience the workflow as intimate and local, while the technical reality is distributed across several independent surfaces with different retention and deletion behavior.

Acquisition and Deletion Implications

Deletion of the application does not necessarily delete all copies of interaction-related artifacts. Backup services, platform-controlled AI layers, analytics providers, and cloud fallback vendors may retain records outside the operator's immediate deletion authority.

Claims such as "on-device," "local," or "zero retention" therefore require careful qualification. They may describe only one part of the workflow and not the full set of surfaces created by the deployment.

Non-Creation and Backup Claims

This scenario is especially useful for evaluating non-creation or strong minimization claims. On-device processing can reduce some external exposure, but it does not by itself eliminate:

  • local persistence
  • backup replication
  • cloud fallback records
  • analytics-derived records
  • platform-side artifacts outside the application's direct control

Any public-facing claim about non-retention should therefore be assessed against the full workflow, including abnormal termination, fallback behavior, and backup replication.

Observations

This scenario exemplifies the automated record custody gap in a mobile setting. The social meaning of the phone may be local and personal, but the record consequences are often distributed and path-dependent.

ARCS is useful here because it helps distinguish:

  • where records are created
  • which components hold them
  • which transitions create new surfaces
  • which copies remain outside the operator's deletion authority

The key governance issue is not simply whether processing begins on-device. It is what records are created across the full workflow and how those records persist, replicate, and become reachable over time.