A diagnosis tells us something about a person.

It does not tell us what an artificial system should be allowed to do.

A professional credential tells us something about a practitioner.

It does not automatically justify access to an entire life record.

A parent’s consent may authorise one function.

It does not authorise every future function.

A care centre may be capable of supervising a shared device.

That does not mean the same device is safe in an unsupervised home.

The central permission question for Amanah Companions is therefore not:

Does this person have the right label?

It is:

What capability is being unlocked, what could happen if it fails, and what level of evidence, oversight, training, consent, and accountability is proportionate to that risk?

Permission should follow risk.

That principle allows Amanah to avoid two opposite failures.

The first is careless openness: giving high-risk clinical, surveillance, or physical capabilities to anyone who can install an application.

The second is unnecessary exclusion: withholding low-risk communication, planning, and person-owned continuity tools from people who cannot obtain formal diagnosis or specialist approval.

Amanah needs neither one universal lock nor one universal key.

It needs a risk-tiered capability architecture.

Access to the system is not access to every function

Software products often treat access as binary.

You are inside or outside.

Free or premium.

Verified or unverified.

Administrator or ordinary user.

Amanah cannot work this way.

A person may safely use one function without being eligible for another.

They may use a visual schedule without any diagnosis.

They may maintain a private sensory journal without a clinician.

They may create an emergency communication card with help from a caregiver.

But a system that interprets medical signals, recommends treatment, administers medication, physically transfers a person, or independently responds to an emergency belongs to a different risk class.

The correct model is:

One continuity system, many capabilities, each separately classified and gated.

This means Amanah should know, for every function:

• what it does;
• who it is for;
• whether it only stores, displays, suggests, recommends, decides, or acts;
• what information it requires;
• whether the effect is reversible;
• whether a mistake is inconvenient, distressing, discriminatory, medically harmful, or physically dangerous;
• whether a human can review the output before anything happens;
• whether the person can stop it;
• whether the system is operating in private, in public, in a centre, or in a home;
• and which law, standard, professional process, or institutional safeguard may apply.

The gate is attached to the capability.

Not merely to the user account.

Risk is more than physical injury

When people hear “risk,” they often imagine collision, falls, burns, or medical error.

Amanah must consider those.

But care systems can cause serious harm without touching the body.

Possible harms include:

Communication harm

The system misattributes a gesture, AAC selection, or silence.

It speaks as the person without confirmation.

It suppresses or delays access to communication.

It treats uncertainty as consent.

Sensory harm

A voice, movement, light, vibration, appearance, distance, or repeated prompt causes overload.

The technology continues because its physical force is technically safe.

Informational harm

Private records are exposed.

One person’s data leaks into another person’s session.

A school receives medical or relational history it did not need.

A temporary provider retains access after leaving.

Authority harm

An AI suggestion becomes an approved rule without genuine human review.

A guardian’s childhood permission persists into adulthood.

A professional acts outside scope.

A system uses the phrase “the AI decided” to hide human responsibility.

Identity harm

Old difficulties become permanent identity.

Diagnosis becomes a universal mode.

A person is treated as a risk profile rather than someone who can change.

Relational harm

The system is designed to maximise dependence or engagement.

It imitates a deceased person.

It withholds relational memory behind a subscription.

It makes replacement or refusal emotionally punitive.

Opportunity harm

Records of difficulty reduce access to education, work, travel, community life, relationships, or new experiences.

A support profile becomes a deficit dossier.

Clinical harm

A system makes or implies diagnostic, treatment, medication, or health-monitoring claims beyond its evidence and regulatory status.

Physical harm

An embodied system collides, traps, lifts, transfers, blocks, startles, restrains, touches, or moves an object in a way that causes injury or distress.

Risk classification must include the whole person.

Not only the machine’s mechanics.

The first principle: the least powerful useful function

When a need is identified, Amanah should not immediately ask:

How can AI solve this?

It should ask:

What is the least powerful, least intrusive function that can meet the need safely?

If a visual card solves the problem, do not require an always-listening model.

If a timer works, do not deploy behavioural prediction.

If a manual communication passport works, do not begin with biometric inference.

If a fixed environmental switch works, do not require a humanoid hand.

If a caregiver can review a summary later, do not allow automatic care-plan changes.

If a person can initiate the support, do not make the system continuously monitor them.

This principle protects privacy, agency, cost, maintainability, and safety.

It also keeps Amanah from turning every human difficulty into a reason for more machine authority.

A proposed five-tier capability model

The final Amanah risk model will require legal, clinical, disability, cybersecurity, robotics, and lived-experience review.

But the research programme can begin with five provisional tiers.

Tier 0 — Person-owned continuity and ordinary accessibility

These are the lowest-risk functions.

They organise information or provide ordinary support without making clinical claims, inferring consent, monitoring continuously, or acting physically.

Possible examples:

• personal notes;
• a communication passport;
• visual schedules;
• preferred routines;
• transition planning;
• private sensory journalling;
• person-owned preferences;
• appointment preparation;
• reminders;
• accessible checklists;
• an exportable “what helps me” summary;
• a list of trusted people;
• and a personal record of accommodations.

Access may be open or self-directed.

A formal diagnosis should not normally be required.

The person may use these tools alone or with a supporter.

Required safeguards

Even low-risk functions still require:

• understandable privacy controls;
• export and deletion;
• clear AI labelling if AI is used;
• no hidden diagnosis inference;
• no operational-data training by default;
• accessibility;
• source trace where information will later be shared;
• and protection against manipulative engagement design.

Low risk does not mean no governance.

It means the consequences of error are bounded and the person retains control.

Tier 1 — Bounded AI assistance

These functions use AI to organise, translate, summarise, or identify possible patterns, but the output remains a draft or suggestion.

Possible examples:

• summarising caregiver notes;
• drafting a handoff;
• identifying missing source information;
• organising records into a Care Profile;
• preparing a plain-language summary from approved material;
• comparing a current event with an approved routine;
• suggesting questions for a clinician;
• flagging a possible repeated pattern;
• translating a support summary;
• or generating an accessible version of an existing plan.

These functions may be available without diagnosis, depending on the data and context.

But they require stronger safeguards because the model may sound authoritative.

Required safeguards

• AI output is visibly labelled.
• The source material is shown.
• Uncertainty remains explicit.
• The model cannot promote its own output into an approved rule.
• Sensitive data access is purpose-limited.
• Human review occurs before consequential use.
• The person can dispute or remove the output.
• The system logs what was retrieved and generated.
• The function is tested for predictable failure modes.
• No emergency, diagnostic, medication, or consent conclusion is allowed.

The AI assists with cognition.

It does not acquire authority.

Tier 2 — Professionally supported configuration and monitored integration

These capabilities may shape ongoing support, connect to specialist tools, or interpret data in ways that require trained human involvement.

Possible examples:

• AAC configuration;
• clinician- or therapist-reviewed Communication and Sensory Maps;
• integration with a school or centre plan;
• structured functional assessment;
• smart-home support configured around safety;
• wearable data used for non-diagnostic pattern review;
• a shared centre continuity system;
• or person-specific support protocols used across several carers.

Formal diagnosis may or may not be required.

The legitimate gateway may instead be:

• a functional assessment;
• a professional recommendation;
• an AAC assessment;
• a centre enrolment;
• a school accommodation plan;
• or another recognised pathway.

Required safeguards

• verified professional role where professional authority is used;
• person-specific assessment;
• direct or supported person participation;
• bounded context;
• clear distinction between recommendation and active rule;
• review dates;
• training for users and carers;
• service maintenance;
• incident reporting;
• revocation when a professional or institution leaves;
• and no transfer of the whole record merely because one integration is enabled.

WHO’s assistive-technology work repeatedly treats provision as more than product delivery. Assessment, fitting, user training, follow-up, maintenance, and repairs are part of a people-centred service.¹

That lesson matters here.

Amanah should not unlock a complex support layer and then leave the person or family to manage it alone.

Tier 3 — Clinical, safety-significant, or high-consequence decision support

These capabilities influence healthcare, safety, or other consequential decisions.

Possible examples:

• analysing person-specific health signals;
• clinical decision support;
• medication-related reminders tied to verified clinical records;
• health-risk alerts;
• recommendations that could influence treatment;
• emergency summaries used in clinical care;
• or predictive systems whose failure could delay necessary help or trigger unnecessary intervention.

This tier requires jurisdiction-specific regulatory analysis.

In the United States, FDA policy is function-specific. Some clinical decision-support functions may be excluded from the medical-device definition, while others remain device software subject to regulatory oversight—including functions used by patients or caregivers.² FDA also states that its oversight focuses on device software whose malfunction could pose risk to patient safety.³

Amanah cannot declare itself “not a medical device” merely because it is called a companion.

Intended use, claims, users, outputs, and risk determine the regulatory question.

Required safeguards

Depending on jurisdiction and function:

• qualified clinical leadership;
• medical-device or health-software assessment;
• validation against the intended population and context;
• human review before action;
• explanation of the basis for recommendations;
• cybersecurity;
• quality-management processes;
• post-market monitoring;
• incident and adverse-event pathways;
• version control;
• change management;
• clear contraindications;
• and a safe fallback when the model, data, or network is unavailable.

A care companion should never smuggle a medical product through the emotional language of companionship.

Tier 4 — Embodied, intimate, mobility-related, or safety-critical action

This is the highest-risk Amanah tier.

It includes systems that can alter the physical environment or act directly around the person.

Possible task classes include:

• carrying and placing objects;
• positioning an AAC device;
• operating doors, lights, or household controls;
• guiding a mapped route;
• providing physical assistance;
• supporting transfers;
• person carrying;
• intimate-care assistance;
• mobility-adjacent action;
• emergency physical response;
• or any action capable of blocking, touching, lifting, restraining, or moving the person.

Not all physical actions carry equal risk.

Playing approved calming audio is not the same as transferring a person from bed.

Bringing a safe object is not the same as handling medication.

Moving away on a stop signal is not the same as deciding to restrain.

Tier 4 may therefore require sub-classification by task.

Required safeguards

• formal task-specific risk assessment;
• evidence that the embodiment is acceptable to the person;
• sensory testing;
• defined force, speed, distance, and contact limits;
• hardware safety;
• safe-state behaviour;
• immediate stop and withdrawal;
• current assent checks where applicable;
• no reuse of old consent;
• human supervision requirements;
• maintenance and inspection;
• environmental constraints;
• training;
• insurance and liability clarity;
• incident investigation;
• and prohibition of tasks that cannot be made acceptably safe or legitimate.

ISO 13482:2014 covers safety requirements for mobile servant robots, physical assistant robots, and person carrier robots, including human–robot physical contact. It explicitly excludes robots regulated as medical devices, as well as military and public-force applications.⁴ Related ISO technical reports emphasise that tests and parameters should follow the risk assessment of the particular robot design and use.⁵

Mechanical safety is necessary.

It is not sufficient.

A robot may remain within safe force limits and still act without valid permission.

Amanah’s body must inherit both a safety case and an authority case.

Some functions should remain prohibited

Risk tiering should not become a polite way of saying that every capability is acceptable with enough paperwork.

Amanah should establish hard prohibitions.

The current doctrine already refuses:

• AI diagnosis or prescribing;
• AI speaking as the person without confirmation;
• autonomous consent interpretation;
• training on operational care records;
• autonomous emergency authority;
• reduction of necessary human care merely because software exists;
• and unauthorised physical action.

For embodiment, additional prohibitions should include:

• discipline;
• punishment;
• forced transitions;
• removal of communication tools;
• default recording of private spaces;
• obedience scoring;
• physical restraint as an ordinary care function;
• sexualised or coercive adaptation of the care system;
• weaponisation;
• military or public-force conversion;
• and any claim that physical capability gives the machine moral authority.

Some edge cases—especially emergency safety systems—will require careful research.

But the burden should remain clear:

Amanah is not required to make every technically possible action available.

Risk follows context, not only function

The same capability may move between risk tiers depending on context.

A reminder can be low risk.

A medication reminder may be higher risk.

A visual schedule can be ordinary support.

A schedule that determines whether a person receives food, movement, or access to communication becomes consequential.

A location function may help someone navigate a route.

Continuous location tracking may become surveillance.

A camera may support device positioning during a supervised centre trial.

The same camera in a bedroom may be unacceptable.

A model may summarise a private journal for the person.

The same model may create risk if the summary is automatically sent to a guardian.

A robot may bring an AAC device from a table.

The same action becomes dangerous if it removes the device from the person or decides when communication is permitted.

Risk classification must therefore include:

• intended use;
• actual use;
• environment;
• user population;
• data sensitivity;
• reversibility;
• frequency;
• supervision;
• and the consequences of misuse.

Amanah should classify the use case, not merely the feature name.

Risk follows the person as well as the task

The system must also adapt to person-specific risk.

A moving robot that is acceptable to one person may cause severe distress to another.

A voice prompt may help one person and overload another.

A wearable may feel supportive to one user and intolerable to someone with tactile sensitivity.

A route-guidance function may be safe for a familiar environment and unsafe during a crowded event.

A physical support may be appropriate when directly requested and unacceptable when initiated automatically.

The risk assessment must include:

• sensory profile;
• communication access;
• motor access;
• ability to stop the system;
• current health;
• environment;
• trauma history where relevant and voluntarily disclosed;
• and the person’s own acceptance or refusal.

“Safe for autistic users” is not a meaningful final claim.

The system must be safe and acceptable for this person, in this context, for this task.

Permission follows reversibility

One useful Amanah question is:

Can the effect be easily undone?

A reminder can be dismissed.

A draft can be deleted.

A visual schedule can be changed.

A shared record can be revoked—though exposure cannot always be reversed once copied.

A robot moving closer can move away, but not before causing distress.

A door being locked may not be meaningfully reversible to the person inside.

A medication dose cannot be taken back.

A fall cannot be undone.

The lower the reversibility, the stronger the permission and safety requirements should become.

This suggests another gradient:

• informational;
• advisory;
• reversible environmental;
• physical contact;
• bodily or clinical;
• and irreversible or emergency consequence.

Amanah should never treat all “actions” as one class.

Permission follows time sensitivity

A system may have enough time for review.

Or it may need to act quickly.

Time pressure changes governance.

Non-urgent

A care-profile update can wait for review.

A machine hypothesis can remain pending.

A professional recommendation can be discussed.

Time-sensitive but reversible

A transition support can be offered under a pre-authorised protocol.

The person can refuse.

The system can stop.

Urgent and high consequence

A health or physical emergency may require immediate human response.

Amanah should alert, communicate, retrieve emergency information, or enter a safe state according to a tested protocol.

It should not pretend that an AI can assume general emergency authority.

The more urgent the function, the more important it is to define in advance:

• what counts as an emergency;
• what the system may do;
• who is alerted;
• what happens if nobody responds;
• which physical actions are prohibited;
• and how the event is audited.

Emergency vagueness is not safety.

Permission follows who bears the consequence

A centre may decide that a new device improves efficiency.

The person bears the sensory and privacy consequences.

A company may decide that more data improves the model.

The family bears the exposure.

A clinician may approve an integration.

Carers and the person live with its daily behaviour.

A government may procure one platform.

Disabled people bear the cost of incompatibility or vendor failure.

Amanah’s risk process must therefore include the people who experience the harm, not only the institutions that approve the technology.

Disabled people, AAC users, nonspeaking people, families, and direct-support workers should participate in classification and testing.

Not as ceremonial reviewers.

As people whose refusal, experience, and evidence can stop or redesign a capability.

Low risk should not mean low quality

There is a danger in tiered regulation.

Developers may call a product “low risk” to avoid serious design work.

But a low-risk Amanah function can still be inaccessible, manipulative, unreliable, or careless with privacy.

FDA’s January 2026 guidance on general-wellness products addresses a particular U.S. category of low-risk products promoting a healthy lifestyle.⁶ Amanah should not copy that category as its own architecture, and many Amanah functions would not fit within it.

The useful lesson is narrower:

Claims and intended use matter.

A planning tool should not imply treatment.

A sensory journal should not imply diagnosis.

A reflective companion should not imply clinical monitoring.

A low-risk product remains low risk partly by refusing higher-risk claims and functions.

Amanah must not market one thing and quietly do another.

Professional involvement should be useful, not ceremonial

Requiring professional approval can look responsible while adding little safety.

A clinician may sign a form without understanding the system.

A centre may rubber-stamp a device.

A review queue may become automatic approval.

A professional credential may be used mainly to legitimise the company.

This is Gate theatre.

Professional involvement is useful only when the professional:

• has relevant expertise;
• understands the function;
• has enough information;
• acts within scope;
• can review the evidence;
• can disagree;
• remains accountable;
• and can stop or modify deployment.

A paediatrician should not be asked to approve a robotics safety case they are unqualified to assess.

A roboticist should not decide communication meaning.

An AI developer should not determine legal capacity.

A therapist should not become a cybersecurity auditor.

High-risk Amanah needs multidisciplinary review.

No single profession owns the whole problem.

Centre-first deployment can reduce some risks

For advanced embodiment, an early centre-based model may be more defensible than direct household sale.

A qualified centre can provide:

• controlled environments;
• trained staff;
• scheduled sessions;
• device cleaning;
• maintenance;
• incident reporting;
• multidisciplinary observation;
• shared costs;
• and clearer stop authority.

A centre can also compare how the technology behaves around different people without pretending that one successful interaction proves universal suitability.

But centre deployment creates its own risks:

• institutional convenience may outrank person preference;
• shared devices may leak data;
• staff may use the system as a substitute for care;
• people may feel unable to refuse;
• the centre may control access to their continuity;
• and a successful centre protocol may fail at home.

“Centre first” is not automatically ethical.

It is a deployment hypothesis requiring governance.

Home deployment requires a different safety case

A home is not a laboratory.

It includes:

• private rooms;
• family conflict;
• variable connectivity;
• children;
• pets;
• visitors;
• clutter;
• religious and cultural practices;
• intimate care;
• unscheduled routines;
• and moments with no trained staff present.

A household system may need:

• stronger privacy defaults;
• local operation;
• simple physical stop controls;
• restricted sensor modes;
• safe behaviour during outages;
• clear maintenance responsibilities;
• remote support that does not become remote surveillance;
• and household-specific consent and access rules.

A device proven in a centre is not automatically proven for home use.

Risk follows setting.

Every capability needs an evidence threshold

Amanah should establish a claim register for every major capability.

The register might include:

• intended benefit;
• target population;
• context;
• evidence strength;
• known limitations;
• required permissions;
• potential harm;
• reversibility;
• human review;
• technical standard;
• regulatory status;
• training requirements;
• falsifier;
• and stop condition.

For example:

Capability

AI drafts a caregiver handoff.

Evidence threshold

Synthetic testing, human review, source fidelity, privacy assessment, and user evaluation.

Capability

AI identifies possible sensory patterns.

Evidence threshold

Pattern accuracy testing, visible uncertainty, no automatic care-rule promotion, review by the person and care circle.

Capability

Wearable flags possible health deterioration.

Evidence threshold

Clinical validation, medical-device analysis, false-positive and false-negative testing, cybersecurity, and qualified clinical oversight.

Capability

Robot carries an AAC device.

Evidence threshold

Task-specific robotics risk assessment, route safety, object handling, person stop signal, sensory acceptability, supervision, maintenance, and incident testing.

The evidence grows with the risk.

The Gate should permit useful assistance

Risk governance can fail by becoming so restrictive that Amanah cannot help.

If every reminder needs a clinician, the system is absurd.

If every calming support requires a committee, the moment is gone.

If every person-owned note requires guardian approval, the architecture has betrayed its centre.

If every machine output is prohibited, there is no reason to use AI.

Amanah needs appropriately pre-authorised support.

For example:

• display the person’s chosen visual schedule;
• lower lights through an approved control;
• offer a preferred communication board;
• remind the person of an appointment;
• retrieve an approved routine;
• move away when the person signals stop;
• draft a summary for review;
• or alert a named human under a configured condition.

Useful governance does not create maximum friction.

It creates the correct friction.

Low-risk support proceeds.

Uncertain output waits.

Sensitive disclosure narrows.

High-risk action requires stronger authority.

Prohibited action stops.

The Gate should become stricter when capability accumulates

A single low-risk function may become high risk when combined with others.

Consider a system that can:

• monitor location;
• infer distress;
• identify the person;
• control doors;
• contact caregivers;
• and act physically.

Each function may have an individual justification.

Together, they create a powerful supervisory system.

Amanah must therefore assess compositional risk.

The total system may be more dangerous than the sum of its parts.

A reminder plus a calendar is ordinary.

A reminder plus continuous monitoring, behavioural scoring, automatic reporting, and physical enforcement becomes control.

Capability accumulation should trigger reclassification.

The system must not unlock high-risk authority through a chain of individually innocent settings.

A proposed permission sentence

Every Amanah capability should be expressible in one sentence:

This actor may perform this bounded function for this person, in this context, using these approved sources, under these conditions, until this expiry, with this review and stop path.

For example:

The home tablet may display the person’s approved transition schedule after the person opens the routine, without sharing data externally, until the schedule is revised.

Or:

The centre robot may bring the person’s AAC device from the charging station to the marked table after a valid request, while supervised, using the approved route and configured stop signal, during this session only.

Or:

The AI may draft a possible sensory-pattern summary from three months of authorised notes, clearly label it as unconfirmed, and send it to the review queue; it may not activate a support rule.

If a permission cannot be expressed clearly, it is probably too broad.

The governing rule

Amanah should not be divided into “safe users” and “unsafe users.”

It should be divided into capabilities whose risks are understood, bounded, reviewed, and matched to appropriate evidence and authority.

A diagnosed person does not automatically qualify for every function.

An undiagnosed person should not automatically be excluded from every function.

A professional credential does not create unlimited access.

A household purchase does not create permission for physical autonomy.

A centre deployment does not erase the person’s right to refuse.

A robot body does not confer moral authority.

The gate must ask:

What could this system do?

What could go wrong?

Who experiences the harm?

What is the least intrusive useful form?

What evidence is enough?

Which human remains accountable?

Can the person stop it?

Can the effect be reversed?

Does the function still belong in Amanah at all?

Permission should follow risk.

And when the risk becomes too great, too opaque, too coercive, or too difficult to govern—

permission should end.

---

Research status

This essay extends the fourteen foundational Amanah Companions articles, particularly:

• The Guardian Gate: Human Authority in AI-Assisted Care
• Human-Led Care in an AI-Assisted Future
• Embodiment Is the Last Mile, Not the Beginning
• The Sensory Map: Why Regulation Comes Before Compliance
• Care Memory vs Surveillance Archive
• AI Prototype Architecture for an Amanah Companion System

It develops the later authorial proposition that Amanah access should be tiered by functional risk rather than diagnosis alone.

The five-tier model is a provisional research architecture. It is not a regulatory classification system and should not be represented as one. Actual legal and regulatory status depends on the function, intended use, claims, users, jurisdiction, deployment setting, and applicable medical-device, AI, robotics, disability, safeguarding, privacy, and professional rules.

Sources

1. World Health Organization, Improving access to assistive technology. WHO describes a user-centred provision pathway including assessment and prescription, fitting, user training, follow-up, maintenance, and repair. https://www.who.int/activities/improving-access-to-assistive-technology ↩
2. U.S. Food and Drug Administration, Clinical Decision Support Software: Guidance for Industry and Food and Drug Administration Staff, final guidance issued January 2026. The guidance distinguishes certain non-device clinical decision-support functions from software functions that remain medical devices and clarifies that device policies may apply to functions intended for patients or caregivers. https://www.fda.gov/regulatory-information/search-fda-guidance-documents/clinical-decision-support-software ↩
3. U.S. Food and Drug Administration, Policy for Device Software Functions and Mobile Medical Applications. FDA states that oversight focuses on device software functions whose failure could pose a risk to patient safety. https://www.fda.gov/regulatory-information/search-fda-guidance-documents/policy-device-software-functions-and-mobile-medical-applications ↩
4. International Organization for Standardization, ISO 13482:2014 — Robots and robotic devices — Safety requirements for personal care robots. The standard addresses mobile servant, physical assistant, and person carrier robots and human–robot physical contact; it excludes robots regulated as medical devices and military or public-force applications. https://www.iso.org/standard/53820.html ↩
5. International Organization for Standardization, ISO/TR 23482-1:2020 — Robotics — Application of ISO 13482 — Part 1: Safety-related test methods. The technical report states that testing parameters should be selected through a risk assessment of the robot’s design and use. https://www.iso.org/standard/71564.html ↩
6. U.S. Food and Drug Administration, General Wellness: Policy for Low Risk Devices, final guidance reissued January 2026. This is a U.S.-specific regulatory policy concerning low-risk products that promote a healthy lifestyle; it is cited as an example of how intended use and claims shape regulatory posture, not as the Amanah tier model. https://www.fda.gov/regulatory-information/search-fda-guidance-documents/general-wellness-policy-low-risk-devices ↩