AI Prototype Architecture for an Amanah Companion System

Amanah Companions should not begin with a humanoid body.

They should begin with an architecture.

Before we ask whether an AI companion can stand in the room, we need to ask whether the system behind it can be trusted with care knowledge.

Can it protect privacy?
Can it preserve dignity?
Can it keep human authority visible?
Can it distinguish care memory from surveillance?
Can it support communication without speaking over the person?
Can it escalate safety concerns without becoming the decision-maker?

That means the first prototype should not be a robot.

The first prototype should be a governed care continuity system.

A body may come later.

The spine comes first.

Prototype Goal

The first Amanah Companion prototype should answer one question:

Can a human-led AI system help preserve, organize, and responsibly use care knowledge for a vulnerable person without turning that person into a dataset?

This is not a medical device claim.

It is not a replacement caregiver.

It is not a diagnostic tool.

It is a care continuity prototype: a system for Care Profiles, Communication Maps, Sensory Maps, Guardian Gates, Care Memory Ledgers, source trace, audit logs, and human-reviewed AI support.

Why Start With Software, Not a Body?

Assistive technology already includes both physical and digital tools. WHO describes assistive products as tools that maintain or improve functioning related to cognition, communication, hearing, mobility, self-care, and vision, supporting health, well-being, inclusion, and participation. WHO also notes that many people need more than one assistive product, making integrated services important. (World Health Organization)

That supports the Amanah Companion path.

The first useful layer may be:

care dashboard
parent/guardian app
caregiver handoff system
AAC-adjacent communication map
sensory map
review queue
AI summary assistant
safety alert workflow
exportable care profile

No humanoid body required.

The body is the last-mile interface, not the foundation.

Core Architecture

A v0.1 Amanah Companion system could have eight core layers:

1. Human Interface Layer
2. Care Profile Layer
3. Guardian Gate / Permissions Layer
4. Care Memory Ledger
5. AI Assistance Layer
6. Integration Layer
7. Audit / Source Trace Layer
8. Safety and Privacy Layer

Each layer has a different job.

The system becomes dangerous if these layers collapse into one vague “memory.”

1. Human Interface Layer

This is what people actually use.

Different users need different interfaces:

Parent / guardian dashboard
Caregiver view
Teacher / therapist contribution form
Emergency summary view
AI-assisted review queue
Care profile editor
Communication Map editor
Sensory Map editor
Care Memory Ledger
Export panel
Permission panel

The interface should not look like a chatbot first.

It should look like a care system.

The chatbot can exist, but it should not be the authority surface.

A caregiver should be able to see:

what is approved
what is only a draft
what needs review
what is sensitive
what has expired
who added it
what the AI suggested
what a human confirmed

Ethics must be visible in the interface.

2. Care Profile Layer

The Care Profile is the central care object.

It stores the governed map of the person’s support needs:

identity and dignity notes
guardian authority
communication map
sensory map
routine and transition map
regulation plan
safety map
care circle
setting differences
review status

This layer must be structured.

Not one giant note.

Not a pile of chat logs.

Not “memory” in the vague companion-app sense.

A care profile needs fields, sources, review status, sensitivity levels, and expiry/review dates.

3. Guardian Gate / Permissions Layer

The Guardian Gate decides who can do what.

It should define:

who can view
who can edit
who can approve
who can export
who can invite others
who can connect AI tools
who can see sensitive records
who can approve a care-rule change
who can delete or archive entries

This is where the system preserves human authority.

UNICEF’s child-centred AI guidance emphasizes safety, privacy, accountability, transparency, inclusion, child well-being, and child-centred governance for AI systems affecting children. It also flags AI companions used by children and accessibility for children with disabilities as emerging issues.

So the Guardian Gate should not be optional.

It is core infrastructure.

4. Care Memory Ledger

The Care Memory Ledger stores care-relevant memory.

It does not store everything.

Memory entries should be typed:

raw event
caregiver note
school note
therapist note
clinician note
AI-generated draft
candidate pattern
approved care rule
sensitive incident
handoff summary

Each entry should include:

care purpose
source
date
setting
review status
privacy level
retention status
permissions
whether AI access is allowed
whether training use is forbidden by default

The default should be:

no model training from private care data.

Care memory serves the person.

It does not feed the system.

5. AI Assistance Layer

This is where the model enters.

But the model should not sit directly on raw private data with unlimited freedom.

The AI Assistance Layer should be narrow, gated, and task-specific.

Allowed v0.1 AI tasks:

summarize caregiver notes
draft handoff summaries
detect possible repeated patterns
suggest review questions
flag missing source trace
suggest possible sensory trigger categories
organize notes into Care Profile sections
compare current event with approved care rules
prepare export summaries
generate plain-language caregiver instructions from approved rules

Not allowed v0.1 AI tasks:

diagnose
prescribe
change care plans automatically
interpret consent alone
speak as the child without confirmation
share records without approval
train on care data by default
make emergency decisions independently
override guardians or clinicians
promote its own guesses into truth

NIST’s AI Risk Management Framework is intended to help developers, users, and evaluators manage risks to individuals, organizations, and society from AI systems, and it centers trustworthiness considerations such as safety, accountability, transparency, explainability, privacy, and fairness. (NIST)

For Amanah Companions, this means the AI layer should be designed as a controlled assistant.

Not a free-roaming agent.

6. Integration Layer

The prototype may eventually connect to other systems.

Possible integrations:

AAC apps or exports
calendar routines
visual schedule tools
school/therapy note uploads
smart-home alerts
wearables, if appropriate
emergency contacts
cloud storage export
healthcare records, only with strict boundaries
FHIR-compatible health data, if clinical integration is ever pursued

FHIR is a healthcare data exchange standard published by HL7, designed to support electronic exchange of healthcare information using modular “Resources.” It is widely used as an interoperability framework, but an Amanah Companion should only touch clinical data with proper consent, clear scope, and expert implementation. (HL7)

For v0.1, I would not begin with deep clinical integration.

Start with manual import/export and source trace.

Clinical interoperability can come later.

7. Audit / Source Trace Layer

Every meaningful action should leave a trail.

The system should log:

who viewed a record
who edited a record
who approved a care rule
who rejected an AI suggestion
who exported data
which AI tool accessed which records
what was retrieved
what was generated
what was promoted
what was archived
what was deleted
what permissions changed

Source trace should attach to every care entry:

parent observation
guardian-approved rule
teacher note
therapist note
clinician note
AI-generated draft
device log
manual caregiver entry
unknown / needs review

No care system should allow invisible memory mutation.

If the system changes what it “knows” about a vulnerable person, the care circle should be able to see how and why.

8. Safety and Privacy Layer

This layer sets hard boundaries.

It should include:

encryption at rest and in transit
role-based access
sensitive-record restrictions
local-first or private-hosting options where possible
export controls
deletion / archive rules
guardian approval for sharing
no third-party training by default
age-appropriate protections
consent logs
emergency contact rules
restricted handling of media
redaction tools
data minimization

The UN Convention on the Rights of Persons with Disabilities states that persons with disabilities have the right to protection from arbitrary or unlawful interference with privacy, family, home, correspondence, or communications, and that personal, health, and rehabilitation information must be protected. (World Health Organization)

That means privacy is not a feature.

It is a right.

Suggested v0.1 System Diagram

Amanah Companion v0.1

[Parent / Guardian Dashboard]
        |
        v
[Guardian Gate + Permissions]
        |
        v
[Care Profile]
   |       |       |
   v       v       v
[Communication Map] [Sensory Map] [Routine / Safety Maps]
        |
        v
[Care Memory Ledger]
        |
        v
[Review Queue]
        |
        v
[AI Assistance Layer]
   |       |       |
   v       v       v
Summaries  Candidate Patterns  Handoff Drafts
        |
        v
[Human Review Required]
        |
        v
[Approved Care Rules / Archived Notes]

Parallel layers:
- Source Trace
- Audit Log
- Privacy Controls
- Export / Backup
- Emergency Summary

The key is that the AI does not bypass the review queue.

It may assist.

It may not quietly govern.

Database Objects

A simple v0.1 schema might include:

users
- id
- name
- role
- contact
- authentication_status

care_subjects
- id
- name
- date_of_birth
- preferred_address
- dignity_notes
- guardian_id

care_profiles
- id
- care_subject_id
- status
- version
- created_at
- updated_at

profile_sections
- id
- care_profile_id
- section_type
- content
- sensitivity_level
- review_status
- source_id

care_memory_entries
- id
- care_subject_id
- entry_type
- care_purpose
- content
- source_id
- setting
- privacy_level
- review_status
- retention_status
- created_at

guardian_permissions
- id
- user_id
- care_subject_id
- permission_type
- granted_by
- expires_at

ai_suggestions
- id
- care_subject_id
- source_entries
- suggestion_type
- content
- confidence_label
- status
- reviewed_by
- reviewed_at

audit_logs
- id
- actor_id
- action_type
- target_type
- target_id
- timestamp
- details

sources
- id
- source_type
- source_person
- role
- date_observed
- setting
- confidence

This is not final.

But it shows the philosophy:

memory is typed
authority is explicit
AI suggestions are separate
review status matters
source trace is structural
audit logs are mandatory

AI Workflow Example

A caregiver enters:

“Bath was hard today. He cried when tablet was taken.”

The system stores it as a raw caregiver note.

The AI may generate:

“Possible transition issue: tablet removal before bath. Check whether warning was given, visual timer used, water temperature, soap smell, and fatigue.”

The system marks this as:

AI-generated draft
unreviewed
candidate pattern
not active care rule

If similar notes appear several times, the AI may suggest:

“Bath transition may be difficult when tablet use ends abruptly. Guardian review recommended.”

The guardian reviews and approves:

“Use five-minute visual timer before bath. Do not remove tablet suddenly. Offer first/then script.”

Only then does it become an approved care rule.

That is the Guardian Gate working.

Human Roles

The prototype should define human roles clearly.

Parent / Legal Guardian

Can approve rules, manage permissions, export records, review AI suggestions, and control sensitive data.

Approved Caregiver

Can add notes, view approved care instructions, receive handoff summaries, and flag concerns.

Therapist / Clinician

Can contribute professional notes within scope, review relevant patterns, and suggest care plan updates.

Teacher / School Support

Can add setting-specific notes, view approved school-relevant instructions, and contribute observations.

AI Assistant

Can summarize, organize, suggest, flag, and draft.

Cannot approve, diagnose, prescribe, override, or silently promote memory.

Model Design

The AI layer should not rely on one huge prompt.

It should use task-specific functions.

Examples:

SummarizeHandoff
DetectCandidatePattern
ClassifyCareMemory
CheckSourceTrace
DraftGuardianReviewQuestion
CompareWithApprovedRoutine
SuggestSensoryCategory
RedactSensitiveExport
GenerateEmergencySummary

Each function should have:

input scope
allowed sources
forbidden outputs
required uncertainty labels
review requirements
audit logging

This is where the Ahd Nucleus idea of Stem Cells becomes practical.

Stem Cells are not magic.

They are small governed behaviors.

For Amanah Companions, each Stem Cell should do one narrow care-support task and know its boundary.

Safety Rules for AI Output

Every AI output should be labeled.

Possible labels:

Draft
Unreviewed
Possible pattern
Needs guardian review
Clinician review recommended
Approved care rule
Superseded
Sensitive
Emergency only

The AI should use careful language:

“May indicate…”
“Possible pattern…”
“Check with guardian…”
“Do not assume…”
“Needs human review…”
“Outside AI authority…”

It should avoid overconfident language:

“He always…”
“He is manipulating…”
“He definitely wants…”
“This proves…”
“Change the plan…”

In care, phrasing is safety.

Embodied Layer Later

Only after the software architecture is stable should embodiment be tested.

A future embodied Amanah Companion might be allowed to:

display visual schedule
play approved calming audio
bring AAC device closer
alert caregiver
move away during overload
support transition cue
carry safe object
adjust lights through approved smart-home controls

But it should not be allowed to:

restrain
discipline
block movement except under carefully governed emergency designs
remove communication tools
physically force transitions
record private spaces by default
interpret consent alone
act as sole supervisor

The embodied layer should inherit the Guardian Gate.

Not bypass it.

Minimum Viable Prototype

A realistic MVP would not include robotics.

It would include:

Care Profile editor
Guardian Gate permissions
Communication Map
Sensory Map
Routine Map
Safety Map
Care Memory Ledger
Review Queue
AI summary drafts
AI candidate-pattern detection
Source Trace
Audit Log
Export function
Privacy settings
No training by default

That is enough to test the core question:

Can continuity governance improve care documentation and handoff without becoming surveillance?

Pilot Study Shape

A careful pilot could involve:

small number of families
opt-in participation
no private model training
local or private deployment
manual entry first
guardian-controlled data
therapist/clinician advisory input
measured caregiver burden
measured handoff clarity
measured usefulness of AI summaries
tracking false or harmful suggestions
reviewing privacy comfort
testing exportability
testing whether the system reduces or increases stress

Success should not be measured by engagement.

It should be measured by care usefulness and trust.

Possible pilot questions:

Did caregivers find handoffs clearer?
Did the system reduce repeated explanation burden?
Were AI suggestions useful or noisy?
Did the review queue feel manageable?
Did families feel in control of data?
Were privacy boundaries understandable?
Did the system avoid overclaiming?
Did it help preserve meaningful care patterns?

What Not to Build First

Do not build the humanoid first.

Do not build a child-facing AI friend first.

Do not build emotional attachment loops first.

Do not build always-on home recording first.

Do not build automatic behavioral scoring first.

Do not build “AI knows what your child wants” first.

Do not build training-data pipelines first.

Build the care spine first.

Everything else must answer to it.

Where Ahd Nucleus Fits

Ahd Nucleus gives the parent architecture.

It already asks:

What is the source of truth?
Who has authority?
What is draft?
What is canon?
What is sensitive?
What should be retrieved?
What should be reviewed?
What should be logged?
What should never be flattened?

Amanah Companions applies that same continuity governance to care.

The difference is the stakes.

In creative work, bad memory can damage a project.

In care, bad memory can misread a person.

That is why the architecture must be stricter.

Closing

The Amanah Companion prototype should not begin with a face.

It should begin with a governed care system.

A Care Profile.
A Guardian Gate.
A Communication Map.
A Sensory Map.
A Care Memory Ledger.
Source trace.
Audit logs.
Human review.
Privacy by design.
AI suggestions that know they are only suggestions.

If that foundation cannot hold, the system should not be embodied.

A body without governance is not care.

It is theatre with sensors.

But a governed continuity system — one that helps families, caregivers, therapists, and teachers preserve what matters without surrendering dignity or privacy — could become something genuinely useful.

Not because it imitates a person.

Because it helps people care better.

That is the prototype worth building.