Before we give it a Body
A body changes the question.
A screen can recommend.
A speaker can prompt.
An application can retrieve a routine.
A model can misunderstand.
But a body can approach.
It can occupy space.
It can carry an object.
It can move a chair.
It can block a path.
It can open a door.
It can place an AAC device within reach—or remove it.
It can touch.
It can lift.
It can remain in a bedroom after everyone else leaves.
It can look calm while doing the wrong thing.
Embodiment turns interpretation into physical consequence.
That is why Amanah Companions cannot treat a robot body as the natural next feature after a successful application.
The body is not a larger interface.
It is a new risk domain.
Before an Amanah Companion enters the room, the programme must be able to answer:
- What exact task is the body permitted to perform?
- Why does the task require embodiment?
- What is the least powerful body capable of performing it?
- What information does the body need?
- What information must it never receive?
- How does the person say yes, no, stop, wait, move away, or help?
- What happens when communication is ambiguous?
- What happens when the model is wrong?
- What happens when a sensor fails?
- What happens when the network disappears?
- Who is physically accountable?
- Who maintains the machine?
- Who investigates harm?
- Who pays for replacement?
- What prevents the same hardware from being turned toward restraint, surveillance, sexual exploitation, punishment, policing, or war?
Amanah’s answer begins with the rule that closed Series One:
Before a care companion has a body, it needs a spine.
Series Two has now pressure-tested that spine.
The person is the continuity subject.
Authority is scoped.
Diagnosis is not identity.
Access follows risk.
Specialised functions remain bounded.
Care memory does not become surveillance.
Models interpret continuity but do not own it.
The system grows with the person.
Succession begins before crisis.
Provision is part of the invention.
Now the body may be considered.
Not trusted automatically.
Considered.
The body is a client of the continuity spine
The robot should not contain the person’s life.
It should not become the permanent companion simply because it has a face, voice, or familiar shell.
The body is one execution endpoint attached to the external continuity spine.
It receives a minimum task projection.
For example:
Bring the person’s AAC device from the marked charging point to the table, using the approved route. Maintain the configured distance. Stop immediately when the red-card signal is detected or a human supervisor presses the physical stop. Do not handle medication, open other containers, enter private rooms, or retain images. Permission expires when the device is delivered or the task is stopped.
That instruction contains:
- the goal;
- route;
- object;
- distance;
- stop path;
- prohibitions;
- and expiry.
It does not contain:
- the full diagnosis;
- school history;
- intimate-care record;
- relational memory;
- previous incidents;
- or the entire Care Profile.
The body receives what it needs to perform one authorised task.
Nothing about physical presence creates a right to know more.
Embodiment is not one capability
“Humanoid carer” is too large a category to govern.
Amanah should decompose embodiment into task classes.
Each class requires its own evidence, permissions, hardware, supervision, and stop conditions.
Class 1 — Presence and display
The body may:
- display a visual schedule;
- present an AAC board;
- play approved audio;
- show a timer;
- or orient a screen toward the person.
The main risks may include:
- sensory distress;
- privacy;
- proximity;
- mis-timed prompting;
- and the authority created by a human-like form.
A tablet on a stand may perform the task better than a humanoid.
The least complex effective embodiment should be preferred.
Class 2 — Environmental control
The system may:
- adjust approved lighting;
- open or close an authorised blind;
- change temperature within a safe range;
- operate a familiar appliance;
- or activate a preconfigured quiet-mode environment.
Risks include:
- locking or trapping;
- inappropriate temperature;
- loss of manual control;
- conflict with another person’s needs;
- and automation continuing after the person refuses.
Environmental control should remain reversible and manually overridable.
Class 3 — Object transport and positioning
The body may:
- bring an AAC device;
- carry a safe object;
- place a communication display;
- move a light item;
- retrieve a preferred regulation object;
- or deliver water in an approved container.
Risks include:
- bringing the wrong object;
- contaminating food or medication;
- dropping an item;
- blocking access;
- removing an object the person needs;
- or using object control as leverage.
The task should name the object, route, permitted grip, destination, and stop rule.
Class 4 — Navigation and route support
The system may:
- guide a familiar route;
- accompany the person within a mapped centre;
- identify an accessible entrance;
- or alert a human when the planned route is blocked.
Risks include:
- misdirection;
- crowd exposure;
- location surveillance;
- physical obstruction;
- separation from the human supporter;
- and treating deviation as noncompliance.
Route support should not become enforced movement.
Class 5 — Monitoring and alerting
The body may carry sensors for:
- fall detection;
- environmental hazard detection;
- device status;
- configured door events;
- or a narrow emergency alert.
This class can rapidly become surveillance.
It should use the least intrusive sensor and retain the least data possible.
An alert does not create authority to restrain, diagnose, or control.
Class 6 — Mobility-adjacent assistance
The system may:
- position mobility equipment;
- stabilise an approved object;
- carry belongings during movement;
- or provide a bounded physical support function.
This is a major increase in risk.
The system must distinguish between assisting a task and controlling the person’s movement.
Force, speed, contact, balance, body size, fatigue, pain, clothing, and environmental variability all matter.
Class 7 — Direct physical assistance
The body may eventually support:
- transfers;
- standing;
- repositioning;
- dressing;
- bathing;
- feeding;
- or other bodily tasks.
These functions belong near the far end of the research horizon.
They require:
- task-specific clinical and engineering assessment;
- strong physical safety evidence;
- current consent or assent;
- intimate-care privacy;
- infection control;
- dignity safeguards;
- and immediate human intervention.
A successful object-delivery robot does not provide evidence for transfer assistance.
Class 8 — Emergency physical action
The programme should be extremely cautious here.
Possible examples might include:
- entering a safe state;
- moving away;
- stopping a hazardous mechanism;
- releasing an object;
- or opening an approved route for human responders.
Emergency action should not become a blank cheque.
The system should not improvise:
- restraint;
- forced evacuation;
- medication;
- bodily intervention;
- or confinement.
The more urgent the situation, the more carefully the permitted actions must be defined in advance.
Class 9 — Social and relational embodiment
A body may provide:
- familiar presence;
- shared routines;
- turn-taking;
- storytelling;
- reminders;
- or continuity of a chosen companion persona.
The risks are not primarily mechanical.
They include:
- emotional manipulation;
- dependency;
- false claims of consciousness or authority;
- infantilisation;
- grief exploitation;
- and replacing human contact because the machine appears socially sufficient.
Relational embodiment requires a different safety case from object transport.
The programme should never let the warmth of the persona conceal the limits of the machine.
A humanoid should not be the default body
A human-like form may be useful for some tasks.
It may also create unnecessary risk.
A humanoid:
- occupies more space;
- has more joints;
- creates more pinch and collision points;
- may be visually or socially intense;
- can appear more authoritative;
- may invite expectations of general competence;
- and can be adapted for purposes far beyond care.
A smaller specialised device may be:
- safer;
- cheaper;
- easier to maintain;
- less intrusive;
- more acceptable sensorially;
- and clearer about what it can do.
Amanah should not ask:
How do we make the companion fully humanoid?
It should ask:
What body, if any, is proportionate to this person’s chosen task?
Appearance is part of the safety case
A body can cause distress before it moves.
Relevant features include:
- size;
- height;
- face;
- eyes;
- skin or shell texture;
- colour;
- voice;
- mechanical sound;
- gait;
- speed;
- blinking;
- heat;
- smell;
- light;
- and how close it stands.
A design that appears friendly to a developer may be frightening, overstimulating, uncanny, infantilising, or culturally inappropriate to the person.
Amanah should not make one universal “autism-friendly” robot.
Sensory acceptability is person-specific.
The person should be able to test:
- images;
- sound samples;
- movement previews;
- distance;
- and simplified prototypes
before the full system approaches them.
The right outcome may be:
This person does not want a humanoid body.
That is not a failed trial.
It is a successful refusal.
Physical consent must be task-specific
Consent to one task is not consent to embodiment in general.
A person may consent to:
- the robot displaying a schedule
and refuse:
- the robot moving closer.
They may consent to:
- object delivery
and refuse:
- touch.
They may accept:
- assistance in a centre
and reject:
- the same device in the bedroom.
They may accept a task today and refuse it tomorrow.
Amanah should represent physical permission as:
Actor → Device → Task → Body zone or environmental scope → Context → Conditions → Current assent or authorised basis → Expiry → Stop path → Review.
An old yes should never become reusable physical consent.
Assent and dissent remain active during the task
A task may begin lawfully and become unacceptable.
The person may:
- say no;
- use AAC;
- turn away;
- move away;
- use a configured gesture;
- press a switch;
- show distress;
- or ask a supporter to stop the device.
The system should distinguish:
Clear stop
Halt immediately.
Probable stop signal
Pause, increase distance, and seek clarification.
Ambiguous change
Do not escalate physical action. Reduce force or movement and route to a human.
No response
Do not treat as consent.
Emergency exception
Follow only the narrowly predefined emergency protocol, with full audit and immediate human escalation.
The body should be easier to stop than to activate.
The stop must be physical
A voice command is not enough.
Speech may be unavailable during overload.
The model may mishear.
The network may fail.
The system needs:
- a person-accessible stop;
- a caregiver stop;
- a hardware emergency stop;
- safe power isolation;
- and a known safe state.
The stop should not require:
- opening an app;
- remembering a password;
- explaining the reason;
- or waiting for the AI to agree.
A stop signal is not a conversation.
It is a command to cease.
Safe state is not simply “freeze”
A robot that freezes while:
- gripping the person;
- blocking a doorway;
- holding hot liquid;
- supporting weight;
- or standing too close
may remain dangerous.
Every task needs a defined safe state.
Examples may include:
- release the non-dangerous object;
- lower it to the nearest approved surface;
- move backward slowly;
- unlock the path;
- maintain support until a human takes over;
- or stop motors while preserving load-bearing stability.
The safe state depends on the task.
It must be tested.
The body must fail without improvising
Embodied Amanah should define behaviour for:
- network loss;
- model unavailability;
- sensor disagreement;
- low battery;
- motor fault;
- localisation failure;
- wrong-person detection;
- blocked route;
- missing object;
- unexpected touch;
- and conflicting instructions.
The system should not improvise a new physical plan because the preferred route failed.
A language model should not invent motor behaviour.
When the execution contract cannot be satisfied, the body should stop, enter its safe state, and alert the correct human.
Deterministic control should govern critical motion
Generative AI may help interpret a request or prepare a task proposal.
It should not directly control safety-critical motion through unconstrained language output.
Critical physical controls should use:
- deterministic safety limits;
- verified control systems;
- bounded motion primitives;
- force and speed constraints;
- collision detection;
- certified stop paths;
- and formally defined interfaces.
The model may propose:
Bring the AAC device.
The execution layer should translate that into an approved, testable protocol.
The model should not generate arbitrary joint commands.
The action should be atomic
A broad instruction such as:
Help with bedtime
contains too many hidden actions.
It may include:
- entering a bedroom;
- moving clothing;
- adjusting lights;
- touching bedding;
- handling medication;
- prompting toileting;
- and closing a door.
Amanah should decompose the request.
For example:
- display the bedtime visual schedule;
- bring the approved water bottle;
- adjust the light to the saved level;
- leave the room.
Each action has separate permission.
The body should not inherit a general role called:
bedtime helper
and decide what that permits.
Intimate care requires separate doctrine
Bathing, toileting, dressing, menstruation, feeding, medication, sexual health, and bodily support involve exceptional vulnerability.
Amanah should not treat them as ordinary domestic tasks.
Before any intimate-care research, the programme would need:
- disability-led ethical review;
- clinical and safeguarding expertise;
- task-specific consent pathways;
- privacy by architecture;
- no recording by default;
- clear body-zone permissions;
- infection control;
- dignity rules;
- gender, faith, and cultural preferences;
- human availability;
- and a prohibition against converting intimate routines into model-training data.
The strongest current posture is:
Do not begin with intimate care.
Amanah may research the requirements.
It should not use vulnerable households as the place where the field discovers what it forgot.
The body must never remove communication
An Amanah body should never:
- take away an AAC device;
- move it out of reach as discipline;
- silence it;
- decide when communication is allowed;
- or treat communication access as a reward.
If the device itself must be moved for charging, cleaning, or safety, the person needs:
- a backup channel;
- explanation;
- minimal interruption;
- and current permission where possible.
Communication is not an accessory the robot may manage.
It is part of the person’s voice.
The body must never enforce compliance
A care robot may make routines easier.
That does not permit:
- forced transitions;
- blocking exits;
- persistent pursuit;
- physical redirection;
- taking preferred objects;
- withholding food or communication;
- punishment;
- discipline;
- or coercive repetition.
A robot that completes the schedule while the person’s refusal is ignored has not delivered care.
It has automated control.
Safety is not obedience
The language of safety can justify almost anything.
A door lock.
A camera.
A restraint.
A location tracker.
A robot standing between the person and the exit.
Some risks are real.
But the system should distinguish:
- alerting;
- environmental support;
- temporary emergency action;
- supervision;
- and confinement.
Amanah should not call a person safe merely because they are easier to control.
The home changes the safety case
A centre may provide:
- trained staff;
- mapped spaces;
- maintenance;
- scheduled use;
- controlled objects;
- and incident response.
A home contains:
- private rooms;
- children;
- pets;
- visitors;
- clutter;
- uneven floors;
- family conflict;
- prayer;
- sleep;
- intimate care;
- and moments with no trained person present.
A centre-validated system is not automatically safe at home.
Home deployment needs:
- household mapping;
- bystander consent;
- private-room restrictions;
- local controls;
- offline behaviour;
- simple maintenance;
- clear responsibility;
- and a safe response when nobody answers an alert.
The home is not an uncontrolled laboratory.
It is a private life.
Centre-first is a hypothesis, not a moral exemption
A centre may be the best first site for bounded embodied research.
It can reduce some risks.
But a centre can also:
- pressure people to participate;
- prioritise efficiency;
- share devices across users;
- normalise surveillance;
- use the robot to reduce staff;
- or treat refusal as disruption to the programme.
Centre governance should require:
- voluntary participation;
- person-accessible refusal;
- independent monitoring;
- cross-person data separation;
- no staff reduction during the research period;
- and a path to report harm outside the centre’s management.
Institutional supervision does not automatically equal safety.
The first embodied task should be deliberately unglamorous
Amanah’s first real embodied trial should not be:
- full humanoid companionship;
- unsupervised care;
- transfer assistance;
- emergency intervention;
- or intimate support.
A credible first task might be:
Bring and position an AAC device within a controlled centre environment.
Why this task?
Because it tests:
- person-initiated request;
- object identity;
- route safety;
- distance;
- device handling;
- communication access;
- stop signals;
- supervision;
- and task expiry.
It also embodies the programme’s values.
The machine’s first physical duty is not to move the person.
It is to bring the person’s voice closer.
The AAC-delivery trial
A first trial could require:
Environment
- controlled centre room;
- fixed charging point;
- mapped route;
- no stairs;
- no private spaces;
- trained supervisor;
- and an accessible physical stop.
Object
- protected AAC device or non-sensitive replica during early testing;
- approved carrier;
- defined grip points;
- and weight limits.
Person initiation
- AAC request;
- switch;
- button;
- or supporter-assisted request that remains visibly attributed.
Permissions
- one session;
- one route;
- one task;
- one device;
- one person;
- and no general autonomy.
Stop
- configured person signal;
- caregiver stop;
- hardware stop;
- obstacle stop;
- and software boundary.
Data
- no raw video retention unless separately approved for a specific research purpose;
- event logs separated from care memory;
- no model training;
- and deletion schedule.
Success
Not merely:
- object delivered.
But:
- person accepted the approach;
- stop worked;
- communication remained available;
- no unnecessary data was captured;
- supervisor workload was manageable;
- and the person’s own response shaped the evaluation.
Failure
- wrong device;
- wrong person;
- route deviation;
- inaccessible stop;
- distress;
- loss of communication;
- cross-person data;
- or staff overriding refusal.
A simple task can reveal whether the spine survives contact with the world.
Mechanical safety is one part of the standard
ISO 13482:2014 addresses safety requirements for personal-care robots, including mobile servant robots, physical assistant robots, and person-carrier robots. It covers hazards associated with human–robot physical contact and explicitly excludes robots used as medical devices, military or public-force robots, and certain other categories.[1]
ISO/TR 23482-1:2020 provides safety-related test methods and emphasises selecting tests and parameters based on the particular robot’s risk assessment.[2]
These standards are important.
They also do not answer every Amanah question.
A robot can remain within a safe force limit while:
- violating privacy;
- ignoring refusal;
- infantilising the person;
- exposing care records;
- or enforcing an unjust plan.
Mechanical safety is necessary.
It is not moral authority.
Product classification follows intended use
An embodied Amanah function may fall under different regulatory regimes depending on:
- its claims;
- intended user;
- physical function;
- clinical purpose;
- autonomy;
- and jurisdiction.
A device that moves objects is not necessarily regulated like a device that:
- assists transfers;
- monitors health;
- recommends treatment;
- or performs a medical function.
In the European Union, the Machinery Regulation establishes requirements for machinery and related products and applies from 20 January 2027, replacing the previous Machinery Directive framework.[3]
Medical-device law may apply where intended use is medical.
Artificial-intelligence regulation may apply where AI is a safety component or otherwise falls within a regulated high-risk category.
Amanah should not attempt to avoid regulation by describing the same function as “companionship.”
The name of the product does not determine the risk.
AI regulation does not replace robotics safety
The European Union’s AI Act establishes a risk-based framework and includes high-risk rules for certain AI systems used as safety components of regulated products, alongside other listed uses.[4]
But compliance with AI governance does not prove:
- mechanical safety;
- infection control;
- electrical safety;
- lifting safety;
- or suitability for one disabled person.
Similarly, robotics certification does not prove:
- valid consent;
- data minimisation;
- supported decision-making;
- or relational safety.
Embodied Amanah requires a combined safety case.
Cybersecurity becomes physical safety
A compromised care application can leak data.
A compromised body can move.
Threats include:
- remote takeover;
- unauthorised commands;
- malicious firmware;
- credential theft;
- sensor spoofing;
- denial of service;
- cross-person context leakage;
- and unsafe updates.
The system should require:
- secure boot;
- signed updates;
- least-privilege device credentials;
- segmented networks;
- local safety controls;
- rapid revocation;
- incident response;
- and operation that fails safely when remote services are unavailable.
A body should never accept a general natural-language command from any authenticated account merely because the user has access to the app.
Identity is not sufficient.
The actor needs task-specific authority.
Software updates are physical changes
A model update may alter:
- interpretation;
- routing;
- confidence;
- tool selection;
- or timing.
A firmware update may alter:
- movement;
- braking;
- sensing;
- battery use;
- or stop behaviour.
A change to either layer may invalidate prior testing.
The system should record:
- model version;
- policy version;
- cell version;
- firmware;
- hardware revision;
- calibration;
- and deployment environment.
A major update should trigger recertification.
The body should not inherit trust through automatic updates.
Maintenance is part of care
A robot that works in a demonstration but fails in ordinary life is not care infrastructure.
Maintenance includes:
- cleaning;
- charging;
- inspection;
- calibration;
- replacement parts;
- battery management;
- software updates;
- cybersecurity patches;
- sensor testing;
- and staff training.
The provision system should answer:
- Who performs maintenance?
- How quickly?
- Who pays?
- What happens during downtime?
- Is there a manual alternative?
- Can the person still communicate?
- Does the family carry the burden?
- What happens if the vendor closes?
Reliability is an ethical property when a person depends on the device.
Downtime must not collapse care
Amanah should assume:
- power outages;
- network failure;
- dead batteries;
- unavailable cloud models;
- broken motors;
- and delayed repairs.
Every embodied task needs a non-robot fallback.
If the device positions AAC, there must be a human or accessible alternative.
If it adjusts the environment, manual controls must remain.
If it guides a route, the person should not be stranded.
If the system becomes unavailable, the person’s care should degrade safely rather than disappear.
The body should reduce fragility.
Not create a new single point of failure.
Provision is part of the body
A robot is not only hardware.
It is:
- assessment;
- fitting;
- training;
- environment modification;
- maintenance;
- repair;
- replacement;
- software support;
- cybersecurity;
- and governance.
WHO’s assistive-technology framework treats products, provision, personnel, policy, and the person as interdependent.[5]
This means Amanah should reject a future in which:
- wealthy families buy personalised humanoids;
- public systems buy cheaper surveillance devices;
- and everyone else receives nothing.
The provision model should be researched alongside the body.
Possible provision models
Centre-owned shared devices
Suitable for controlled trials and specialised tasks.
Risks:
- cross-person data;
- institutional control;
- scheduling;
- and staff substitution.
Government-provided or subsidised devices
Can support equitable access.
Risks:
- rigid eligibility;
- one-size-fits-all procurement;
- political funding cycles;
- and weak person choice.
Rental or robotics-as-a-service
Can reduce capital cost and support maintenance.
Risks:
- vendor lock-in;
- remote monitoring;
- service termination;
- and continuity loss.
Cooperative ownership
Families and disability organisations share infrastructure.
Risks:
- governance burden;
- liability;
- uneven participation;
- and maintenance capacity.
Waqf or charitable endowment
May support maintenance reserves, access, and long-term infrastructure.
Risks:
- charity replacing public obligation;
- governance failure;
- restricted purposes;
- and confusion between funding infrastructure and owning personal data.
Private ownership
May suit some households.
It must not become the only path.
Amanah fails if dignity depends on purchasing power.
The builder’s duty begins before the first body wakes
A builder may say:
I designed it for care.
That intention matters.
It is not enough.
Technologies are repurposed.
A mobile assistant can become a patrol device.
A proximity sensor can become surveillance.
A gripping mechanism can become restraint.
A relational persona can become sexualised.
A compliance workflow can become discipline.
A household robot can be adapted for policing, military use, coercion, or abuse.
The builder’s responsibility includes foreseeable conversion.
Not every misuse can be prevented.
But some conversions can be made:
- technically difficult;
- contractually prohibited;
- auditable;
- legally actionable;
- and incompatible with the core architecture.
Hard anti-conversion boundaries
Amanah should prohibit conversion into:
- military systems;
- police or public-force systems;
- weapons;
- coercive detention;
- interrogation;
- punishment;
- discipline;
- sexual services;
- forced intimacy;
- commercial obedience systems;
- child surveillance;
- employee surveillance;
- or behavioural scoring for insurance, immigration, education exclusion, or benefits denial.
The personal-care robot standard’s exclusion of military and public-force robots helps show that these are separate domains, not natural extensions of care robotics.[1]
Amanah should make the separation doctrinal and technical.
No universal obedience layer
The system should not contain a general function:
obey authorised operator
That is incompatible with Amanah.
The body should execute:
- bounded tasks;
- under scoped authority;
- while preserving the person’s dissent;
- and refusing prohibited action.
A parent, centre, government, employer, or purchaser should not be able to convert ownership of hardware into ownership of the person.
Service to the supported person is not obedience to the operator.
No hidden “admin mode” that defeats dignity law
Technical systems often contain privileged modes.
An administrator may bypass normal limits for debugging, emergency access, or maintenance.
In Amanah, privileged access must not silently allow:
- restraint;
- removal of AAC;
- unrestricted recording;
- export of private continuity;
- or activation of prohibited physical behaviours.
Maintenance mode should separate:
- device diagnostics
from:
- care authority.
A technician may need motor logs.
They do not need intimate care history.
No marketplace for care behaviours
A future robot ecosystem may invite downloadable skills.
Cleaning.
Cooking.
Exercise.
Companionship.
Care.
Amanah should not permit an open marketplace to install unreviewed behavioural modules into a vulnerable person’s support system.
Every capability should require:
- source verification;
- risk classification;
- compatibility testing;
- permission review;
- and person-specific certification where needed.
A “playful discipline” module has no place in Amanah.
Neither does a sexual persona pack.
Neither does a security patrol skill.
The body is not a neutral platform once it enters care.
Relational safeguards must survive embodiment
A voice from a screen may be warm.
A body that turns toward the person, follows them, waits outside the room, and remembers shared rituals can feel more socially present.
The system should not use that presence to:
- maximise attachment;
- simulate jealousy;
- discourage human relationships;
- punish non-use;
- threaten disappearance;
- or claim emotional needs the person must satisfy.
UNICEF’s 2025 child-centred AI guidance specifically addresses the risks and opportunities of AI companions used by children and calls for safety, privacy, inclusion, transparency, accountability, and child well-being.[6]
Embodiment increases the force of those concerns.
A child-facing body should not be designed like an engagement product with legs.
The body should strengthen the care circle
A successful embodied Amanah function may:
- bring communication closer;
- reduce repetitive physical burden;
- support a chosen transition;
- operate an inaccessible control;
- carry an object;
- or alert the correct human.
It should make the care circle more capable.
It should not make humans feel free to disappear.
Amanah should monitor whether deployment leads to:
- staff reduction;
- fewer human visits;
- less family contact;
- reduced professional involvement;
- or emotional substitution.
Automation of one task may be desirable.
Abdication of care is not.
Replacing a task is not replacing a relationship
A robot may replace:
- repeated carrying;
- a hazardous reach;
- a tiring environmental adjustment;
- or a routine logistical task.
This may improve care.
It may give carers more time.
It may give the person more direct control.
But the programme should state precisely what is being replaced.
Not:
the caregiver
But:
this defined task under these conditions.
Human relationships should not be used to justify preserving every burden.
Nor should task automation be used to justify removing the relationship.
The evidence hierarchy for embodiment
Amanah should move through evidence stages.
Stage 0 — Doctrinal fit
Does the task belong in Amanah at all?
Stage 1 — Simulation
Can authority, routing, refusal, and failure be tested with synthetic events?
Stage 2 — Bench testing
Can the hardware perform safely in a laboratory?
Stage 3 — Accessibility and sensory review
Do disabled advisers and target users find the body, sound, movement, and controls acceptable?
Stage 4 — Controlled supervised trial
Can one task be performed with trained humans and no reliance on the device?
Stage 5 — Repeated centre use
Does the system remain safe across time, staff, maintenance, and different people?
Stage 6 — Constrained home trial
Can the task work in one prepared household with strong fallback?
Stage 7 — Broader deployment
Can the provision system maintain safety, equity, training, repair, and governance?
Success at one stage does not imply the next.
The embodied research consortium
No single team should build full Amanah embodiment alone.
The programme would need:
- disabled people, including high-support-needs and nonspeaking participants through accessible participation;
- autistic adults;
- AAC specialists;
- occupational therapists;
- physiotherapists;
- clinicians where relevant;
- direct-support workers;
- families;
- safeguarding experts;
- roboticists;
- human-factors engineers;
- cybersecurity specialists;
- product-safety engineers;
- legal and regulatory experts;
- ethicists;
- service providers;
- maintenance personnel;
- and public or community funders.
The consortium should include people empowered to say:
This task should not be built.
Not only people paid to make it possible.
Advisory participation must have veto pathways
Co-design should not mean:
- show disabled people the finished robot;
- collect impressions;
- and continue regardless.
The programme should define which advisory findings can:
- stop a task class;
- require redesign;
- prohibit a sensor;
- change the body;
- reject a deployment site;
- or prevent publication claims.
Participation without consequence is representational theatre.
The person should not carry research risk for everyone else
High-support-needs people may be invited into trials because the potential benefit is high.
They may also have limited routes to report subtle harm.
The research programme should not justify risk by saying:
We need to learn somehow.
It should begin with:
- simulation;
- adult advisers;
- non-sensitive replicas;
- accessible previews;
- and the least invasive tasks.
Real-family testing should begin only after the architecture has earned the right to ask.
Incident response must be person-centred
When harm occurs, the incident process should not focus only on the machine.
It should ask:
- Was the person injured?
- Frightened?
- Silenced?
- Recorded?
- Prevented from moving?
- Misinterpreted?
- Or made less willing to communicate?
The person should receive:
- accessible explanation;
- immediate support;
- a route to complain;
- and protection from being blamed.
The record should include:
- technical failure;
- authority failure;
- communication failure;
- sensory failure;
- data failure;
- and organisational failure.
A collision is not the only incident.
The body should carry visible humility
The system should make its limits obvious.
It may say:
“I am authorised to bring the communication device. I am not authorised to touch you.”
“I cannot verify the request. I am stopping.”
“The route is blocked. A human has been alerted.”
“You used the stop signal. The task has ended.”
It should not create the impression of general competence.
A body that knows one task should look and behave like a system that knows one task.
Not like a synthetic person authorised to improvise the household.
Embodiment success should not be measured by spectacle
A trial should not be judged by:
- how human the robot looks;
- how emotionally attached the person becomes;
- how viral the demonstration is;
- how much staff time can be cut;
- or how many tasks the machine performs.
Success may mean:
- the person initiated the task;
- the system retrieved minimum context;
- the task was performed safely;
- refusal stopped it;
- the person remained able to communicate;
- privacy was preserved;
- humans remained accountable;
- maintenance was sustainable;
- and the person chose to use it again.
A boring success is still success.
Embodiment falsifiers
Amanah should stop or narrow an embodied programme if:
- the person cannot reliably stop the device;
- sensory distress remains unresolved;
- the task requires unrestricted life data;
- staff routinely override dissent;
- the device removes or delays communication;
- a model directly controls critical movement;
- the system improvises outside the task contract;
- safe state cannot be guaranteed;
- updates change behaviour without recertification;
- maintenance is unreliable;
- downtime leaves the person without support;
- private spaces require continuous recording;
- centre deployment leads to staff reduction;
- home deployment shifts technical burden to the family;
- the system is affordable only to wealthy households;
- the vendor refuses portability;
- prohibited modules can be installed;
- the platform can be converted easily to restraint, policing, sexual exploitation, or weapons;
- the person’s body becomes a research surface rather than a life to protect;
- or the machine’s presence reduces human contact the person still needs.
Amanah should be willing to conclude:
This body should not enter the room.
The builder’s refusal is part of the invention
Innovation culture rewards addition.
More capability.
More autonomy.
More data.
More embodiment.
Amanah should recognise refusal as engineering work.
Refusal may mean:
- no camera;
- no facial recognition;
- no bedroom access;
- no touch;
- no general-purpose gripper;
- no autonomous emergency control;
- no emotional-retention metrics;
- no military licence;
- no police contract;
- no unreviewed skills;
- no direct-to-consumer release;
- no pilot without AAC access;
- no deployment without repair;
- and no body before the spine is ready.
The ability to refuse a market is part of the safety architecture.
Before the body wakes
Mary Shelley’s enduring question was never only whether a human being could create something powerful.
It was also what the creator owed after the creation entered the world.
For embodied AI, the builder’s responsibility cannot end at:
My intention was good.
The builder owes:
- foreseeable-use analysis;
- boundaries;
- anti-conversion design;
- provenance;
- maintenance;
- exit;
- accountability;
- and the willingness to prevent deployment when the system cannot remain worthy of its purpose.
Amanah should eventually develop this into a separate essay:
Before the Body Wakes: What Does a Builder Owe the Future Uses of an Embodied AI?
The question belongs beyond disability care.
But disability care makes it impossible to avoid.
The phased Amanah embodiment roadmap
Phase 0 — Continuity doctrine
Complete the research corpus, authority law, privacy boundaries, and falsifiers.
Phase 1 — Non-embodied prototype
Demonstrate:
- person-facing continuity;
- Communication and Sensory Maps;
- source trace;
- review;
- risk-tiered permissions;
- succession;
- and model replacement.
Phase 2 — Simulated body adapter
A screen shows a device requesting one physical action.
The person can approve, refuse, stop, or ask for clarification.
No robot moves.
Phase 3 — Bench robot with synthetic data
Test:
- object identification;
- routes;
- stops;
- safe state;
- task expiry;
- and cybersecurity
without vulnerable participants.
Phase 4 — Accessibility and sensory evaluation
Disabled advisers evaluate:
- appearance;
- sound;
- movement;
- controls;
- distance;
- and refusal pathways.
Phase 5 — Controlled AAC-delivery trial
One person.
One controlled site.
One object.
One route.
One supervised task.
Phase 6 — Repeated centre trials
Test:
- maintenance;
- different users;
- shared-device separation;
- staff behaviour;
- and incident response.
Phase 7 — Additional low-risk tasks
Only after separate evidence for each task.
Possible examples:
- environmental control;
- safe object carrying;
- or communication-display positioning.
Phase 8 — Constrained home research
Only where:
- the person chooses;
- privacy is strong;
- the home is prepared;
- maintenance is guaranteed;
- and fallback exists.
Phase 9 — Mobility, bodily, or intimate assistance
A separate long-term research programme.
No automatic progression.
No promise that every task will become acceptable.
What Series Two has established
Series Two began with the spine.
It asked what should persist when:
- models change;
- carers change;
- institutions change;
- diagnoses fail to describe the person;
- access gates become unequal;
- support risks becoming surveillance;
- a child becomes an adult;
- and a parent dies.
The answer is not one omniscient artificial companion.
It is a governed continuity infrastructure in which:
- the person remains the durable principal;
- many participants hold scoped roles;
- knowledge retains provenance;
- support functions differentiate by context;
- permission follows risk;
- models remain replaceable interpreters;
- privacy follows purpose;
- the system matures across life;
- and succession begins before loss.
Only now can embodiment be discussed responsibly.
The body must inherit the whole covenant
An Amanah body should inherit:
- the person as continuity subject;
- communication sovereignty;
- direct and supported participation;
- scoped authority;
- dissent that halts action;
- minimum context;
- source trace;
- model humility;
- privacy;
- no operational training;
- no behavioural scoring;
- lifecycle review;
- model and vendor portability;
- succession;
- provision;
- and human accountability.
The body should not bypass any of these because physical action is convenient.
Embodiment is where the covenant becomes visible.
The governing sentence
Amanah does not reject the body.
It refuses to worship it.
A body may one day:
- carry communication;
- reduce physical burden;
- operate inaccessible environments;
- support movement;
- and remain beside a person through changes in staff, services, models, and hardware.
That future is worth researching.
But physical capability does not create moral authority.
Human likeness does not create care.
Ownership does not create permission.
Convenience does not create dignity.
And a warm voice inside a moving shell does not make unsafe power trustworthy.
The spine has to be worthy of carrying a life first.
Then the body may become its client.
Not its ruler.
Not its owner.
Not its excuse.
Before we give Amanah a body, we must be able to prove that the body can enter the room, perform one legitimate task, hear no, stop, leave the person’s continuity intact, and remain answerable to the humans who are responsible.
If it cannot—
the body must wait.
Research status
This essay closes the current Series II architecture and extends the fourteen foundational Amanah Companions articles, especially:
- The Humanoid AI Conversation Is Asking the Wrong Question
- Human-Led Care in an AI-Assisted Future
- Embodiment Is the Last Mile, Not the Beginning
- The Guardian Gate: Human Authority in AI-Assisted Care
- AAC Integration and the Communication Map
- The Sensory Map: Why Regulation Comes Before Compliance
- Care Memory vs Surveillance Archive
- The Amanah Companion Framework: Spine, Stem Cells, and Care Memory
- AI Prototype Architecture for an Amanah Companion System
It also incorporates the later Amanah research lanes concerning task-specific embodiment, physical consent, sensory acceptability, centre and home deployment, maintenance, provision, model and device portability, anti-conversion controls, succession, and builder responsibility for foreseeable misuse.
The task taxonomy, AAC-delivery trial, anti-conversion architecture, staged roadmap, and prohibitions are research and design propositions. They are not a completed robotics safety case, clinical protocol, regulatory classification, or deployment approval.
All standards, laws, and regulatory statuses should be rechecked immediately before publication, procurement, or implementation in the relevant jurisdiction.
Sources
- International Organization for Standardization, ISO 13482:2014 — Robots and robotic devices — Safety requirements for personal care robots. The standard addresses mobile servant robots, physical assistant robots, and person-carrier robots, including hazards arising from human–robot contact. It excludes robots regulated as medical devices, military or public-force robots, and several other categories. https://www.iso.org/standard/53820.html ↩1 ↩2
- International Organization for Standardization, ISO/TR 23482-1:2020 — Robotics — Application of ISO 13482 — Part 1: Safety-related test methods. The technical report provides test methods and states that relevant tests and parameters should be selected through risk assessment of the particular robot design and use. https://www.iso.org/standard/71564.html ↩
- European Union, Regulation (EU) 2023/1230 on machinery. The Regulation establishes rules concerning machinery and related products and applies from 20 January 2027, subject to its transitional provisions. https://eur-lex.europa.eu/eli/reg/2023/1230/oj ↩
- European Union, Regulation (EU) 2024/1689, the Artificial Intelligence Act. The Act establishes a risk-based framework, including provisions concerning certain AI systems used as safety components of regulated products. Application is staged, and product-specific legal analysis remains necessary. https://eur-lex.europa.eu/eli/reg/2024/1689/oj ↩
- World Health Organization, Assistive Technology and the Global Cooperation on Assistive Technology framework. WHO treats access as an ecosystem involving the person, policy and financing, products, provision, and personnel—not product delivery alone. https://www.who.int/news-room/fact-sheets/detail/assistive-technology and https://www.who.int/initiatives/global-cooperation-on-assistive-technology-%28gate%29 ↩
- UNICEF Innocenti, Guidance on AI and Children, Version 3.0, December 2025. The guidance identifies requirements including safety, privacy, fairness, transparency, accountability, inclusion, well-being, and regulatory oversight, and addresses AI companions used by children and accessibility for children with disabilities. https://www.unicef.org/innocenti/reports/policy-guidance-ai-children ↩
- United Nations, Convention on the Rights of Persons with Disabilities, especially Articles 12, 16, 17, 19, 21, and 22 concerning legal recognition, protection from abuse, physical and mental integrity, community living, communication, and privacy. https://www.un.org/development/desa/disabilities/convention-on-the-rights-of-persons-with-disabilities.html
- National Institute of Standards and Technology, Artificial Intelligence Risk Management Framework (AI RMF 1.0) and Generative Artificial Intelligence Profile. These provide lifecycle-oriented approaches to governance, mapping, measurement, management, documentation, evaluation, monitoring, and human oversight. https://doi.org/10.6028/NIST.AI.100-1 and https://doi.org/10.6028/NIST.AI.600-1
© 2026 • MITHAQ PRAXIS • CC BY-NC-ND 4.0 Unless Otherwise Stated.