Documentation & Classification

Purpose

Robot labor is difficult to study when similar systems are described with incompatible labels, when machine work is hidden inside broad terms such as “automation,” or when records focus only on technical specifications and omit the labor function, operating context, and responsibility structure.

This framework provides a stable way to describe recognizable forms of robot labor. It combines multidimensional classification with a shared Core Record so that cases can be compared without pretending that every system or sector is identical.

Reference taxonomy

The taxonomy classifies a case across separate dimensions rather than placing unlike categories on one list. A system can therefore be described by its form, labor function, relationship to human work, oversight pattern, and operating context without treating those dimensions as interchangeable.

1. System form

• Embodied system — a robotic or machine system that acts in a physical environment.
• Digital agent — an AI agent or structured software system carrying out recurring, identifiable operational work inside an organized workflow.

2. Labor function

• Physical execution — handling, movement, inspection, assembly, transport, or other physical task performance.
• Service interaction — intake, guidance, assistance, communication, or other direct interaction with users or customers.
• Coordination and allocation — routing, scheduling, dispatching, matching, prioritizing, or allocating work or resources.
• Decision support — recommendations, triage, scoring, eligibility support, or other outputs that materially shape human or institutional decisions.
• Administrative and workflow processing — recurring document, data, transaction, or process steps inside an organized workflow.
• Monitoring and inspection — observation, detection, checking, or alerting that forms part of ongoing work.

3. Human–machine relation

• Substitute — the system performs work previously or otherwise performed by a person.
• Assist — the system supports a person who retains the primary work role.
• Coordinate — the system organizes the sequence, distribution, or timing of human or machine work.
• Monitor — the system observes work, conditions, or outcomes and produces signals for action.
• Shape decisions — the system materially influences prioritization, recommendations, or choices while final authority remains elsewhere.

4. Autonomy and oversight

• Directly controlled — operation depends on active human command or close step-by-step control.
• Supervised operation — the system performs bounded work while a human role remains routinely available to review or intervene.
• Exception-based oversight — routine operation proceeds without continuous attention, with human review triggered by defined exceptions or escalation points.
• Human final authority — the system may recommend, triage, or coordinate, but a designated person or institution retains the final consequential decision.

5. Sector and operating context

Sector, deployment environment, affected population, operating period, and site conditions should be recorded as contextual descriptors. They are not substitutes for the four classification dimensions above.

Core Record and classification extensions

Frameworks 02 and 03 use the same Core Record so that operational review and public classification begin from a common factual base. Documentation & Classification then adds fields needed for comparison, evidence handling, and public explanation.

Shared Core Record

• System name or descriptive identifier, version where relevant, and responsible technical unit or vendor where known
• Purpose of use and recurring labor function
• Sector, deployment site or operating environment, and operating period or observation date
• Primary workers, teams, users, or other people affected
• Permitted task scope, important boundaries, and exception conditions
• Deploying organization or responsible unit
• Human oversight and escalation arrangement
• Maintenance, configuration, or update responsibility where known
• Evidence basis for the record
• Last reviewed date and record version

Classification extensions

• System form
• Labor function class or classes
• Human–machine relation
• Autonomy and oversight pattern
• Sector and contextual descriptors
• Short classification rationale where the best-fit label is not obvious
• Known uncertainties, missing information, or conflicting evidence
• Public-facing summary where proportionate disclosure is warranted

Operational logs, overrides, incidents, corrective actions, and other management records belong to the operational extensions in Responsibility & Operations rather than being duplicated here.

Example entries

These examples illustrate the level of description intended by the framework. They are illustrative records, not entries in an operating public database.

Public service routing robot

A public-facing physical system deployed in a high-traffic service environment to guide visitors, answer common questions, and route requests.

• System form: Embodied system
• Labor function: Service interaction / Coordination and allocation
• Human–machine relation: Assist / Coordinate
• Oversight pattern: Supervised operation
• Sector and context: Public service / high-traffic visitor environment
• Key boundary: Complex or exceptional requests are transferred to staff

Administrative triage agent

A digital system that sorts incoming requests, assigns priority categories, and triggers defined follow-up steps inside a recurring administrative process.

• System form: Digital agent
• Labor function: Administrative and workflow processing / Coordination and allocation
• Human–machine relation: Coordinate / Shape decisions
• Oversight pattern: Exception-based oversight / Human final authority
• Sector and context: Administration / recurring request-handling workflow
• Key boundary: Final exceptional decisions remain with designated staff

Disclosure layer

Internal records support operational review; public-facing disclosure supports legibility. The two should be connected but do not need to expose the same level of detail.

Where robot labor materially affects workers, customers, residents, patients, students, or other public users, an institution should be able to explain in proportionate terms:

• That a robotic or machine-mediated system is performing a meaningful labor function
• What role the system performs and what it does not do
• Where human oversight or escalation remains available
• Which organization remains responsible for the deployment
• How questions, complaints, or material errors can be raised

Disclosure should improve understanding rather than dramatize the technology. Clear description of function, limits, and responsibility is generally more useful than promotional language about autonomy or intelligence.

Documentation workflow

1. Classify across dimensions. Record system form, labor function, human–machine relation, and autonomy or oversight pattern separately.
2. Describe the labor function. State what recurring task, service, coordination role, or decision-support function is being performed.
3. Complete the Core Record. Note purpose, sector, environment, affected people, task boundaries, responsibility, oversight, operating period, evidence basis, and review date.
4. Add classification extensions. Record classification rationale, contextual labels, uncertainty, and missing information where relevant.
5. Connect operational records when needed. Use Responsibility & Operations for logs, overrides, incidents, corrective action, and other operational extensions.
6. Review material change. Update the record when the system's task, environment, scope, reliance level, or oversight materially changes.
7. Disclose proportionately. Translate the internal record into public-facing language when external explanation is warranted.

The structure is intended to support comparable documentation across sectors while leaving room for sector-specific fields where they materially improve understanding.

Publication status and use boundary

The current publication is a reference structure for classification, records, and disclosure. Future case material, if published, will identify its evidence basis and verification status rather than being treated as an approved-system registry.

The examples illustrate the record structure; they do not verify or endorse any real deployment. Apply the framework alongside the recordkeeping and operating requirements of the actual setting. See the Frameworks use boundary.