COI Orb is designed around individual choice, authorized support, and transparent information sharing. You decide who can participate in your circle and, where supported, what information each person can access. When another person is authorized to assist you, their access should correspond to the permissions granted to them — never more.

COI Orb does not treat all members of your circle as having the same access. Depending on your settings, different people may see different parts of your workspace:

You — You can access your own workspace according to your account and configuration. You are always the owner of your data.

Family — A family member may be allowed to see family messages, photos, memories, appointments, and selected activities — but not private notes, health data, or other restricted information. Family membership alone does not automatically grant access to sensitive information.

Caregiver — A caregiver may receive access to check-ins, tasks, selected activities, and care coordination information, depending on their authorization. The platform avoids giving a caregiver unrestricted access simply because they are designated as a caregiver.

Care Team — An authorized care professional may receive access to information intentionally shared with the care team — such as approved observations, appointment information, and care preferences.

Authorized Representative — An authorized representative may manage selected parts of the individual's workspace when that authority has been granted. The platform always preserves the distinction between helping and taking ownership.

COI Orb follows a need-to-know access model rather than an "everyone-sees-everything" model. Access is granted intentionally and is scoped to the specific information each person needs to fulfill their role.

For example:

Individual ├── Family Member A — Memories ✓, Messages ✓, Health Data — ├── Caregiver — Activities ✓, Tasks ✓, Private Journal — └── Care Team — Shared Health Information ✓, Appointments ✓, Private Memories —

This is enforced by the application — not merely described in the interface. The backend authorization layer checks every request against the viewer's identity, relationship, role, the specific resource, the action requested, the scope, and any time-based expiration. A malicious user cannot bypass this by calling the API directly; the backend is the authority.

The Privacy Center is where you (or an appropriately authorized person) can review information-sharing permissions.

Location: User → Settings → Privacy Center → Care Circle

The Privacy Center answers three simple questions:

1. Who can access my information? — Shows the people you have authorized.

2. What can they access? — Shows individual per-scope permissions for each person (Memories, Appointments, Health, Messages, etc.).

3. What has been shared? — Shows relevant sharing history and status, including when access was granted or revoked.

The Privacy Center is designed to be understandable, not hidden behind technical language. You see real names, real relationships, and real permissions — not abstract policy configurations.

Permissions in COI Orb are granular. Instead of a single "Family Access: ON" toggle, each person in your circle has a per-scope permission matrix:

Sarah (Daughter) ✓ Memories ✓ Appointments ✓ Activities — Health — Notes ✓ Messages ✓ Photos ✓ Voice ✓ Video — Records

This allows you to build a Care Circle that actually reflects your wishes. A daughter may be allowed to see memories and appointments but not health information. A caregiver may see activities but not private journals. A physician may see approved care information but not personal family conversations.

Permissions are set through the Circle of Care invite wizard (at invite time) and can be adjusted at any time through the Privacy Center. Changes take effect immediately and are recorded in the audit trail.

Family access is configurable. Possible permissions include:

• View memories • View photos • Send messages • Send voice messages • Send video greetings • Join Family Room • View appointments • View selected activities • Participate in shared tasks • Receive selected notifications

Family membership alone does not automatically grant access to sensitive information. A sibling who joins your circle starts with the FAMILY role defaults (typically VIEW on most scopes), and you can further restrict or expand their access per scope. This is the difference between a relationship ("this person is my sister") and a permission ("my sister can see my health data").

A caregiver's access depends on their role and authorization. Possible capabilities include:

• View check-ins • View selected activities • Record observations • Complete tasks • Add notes • Receive authorized notifications • Participate in Family Room • Assist with appointments

The platform avoids giving a caregiver unrestricted access simply because they are designated as a caregiver. A professional home-care aide may receive WRITE access to daily check-ins and tasks, but NONE on private journal entries and family messages. A family caregiver may receive VIEW on health data but not WRITE. Each grant is intentional and scoped.

Care-team access is limited to information that has been made available through the platform's authorization and organizational access model. Possible information includes:

• Shared care information • Approved observations • Appointment information • Care preferences • Approved summaries • Relevant activity information • Authorized communications

Private personal content remains private unless intentionally shared or otherwise legitimately accessible under the applicable authorization model. A clinic that joins your circle does not automatically see your private journal — they see only what you (or an authorized representative) have explicitly approved for care-team viewing.

An Authorized Representative is a person who has been given authority to assist with your COI Orb workspace. This may be important when you:

• Want another person to help manage your workspace • Have difficulty using technology • Want a family member to assist with organization • Are unable to manage some or all functions independently

The platform distinguishes between helping and taking ownership. An authorized representative may operate parts of your dashboard — adjusting permissions, accepting invitations, managing modules — but the underlying identity and data ownership remain yours. The dashboard records who operated it and on whose behalf, so the audit trail always reflects the true actor.

This is a foundational part of the product:

If you can manage your workspace: Individual → User Dashboard

If you authorize assistance: Individual → Authorized Person → Assistance with selected functions

If an authorized representative is managing the workspace: Individual → Authorized Representative → Delegated dashboard access

The application always preserves the distinction between the person the dashboard belongs to and the person currently operating it. This means permissions, audit logs, and AI context all continue to resolve against the individual — not the representative — even when the representative is the one clicking.

Open: Privacy Center → Sharing Controls

From there, you can review individual permissions per circle member. Example:

Daughter — Sarah Can see: ✓ Appointments, ✓ Family messages, ✓ Photos, ✓ Selected activities Cannot see: — Private journal, — Health records, — Private notes

You can adjust each scope independently. Revoking a scope takes effect immediately — the next time the affected person loads their dashboard, that section will be hidden or empty, and any active session is revalidated.

COI Orb supports temporary access where appropriate, instead of permanently granting broad access when temporary access is sufficient.

Example: "Share appointment preparation with Dr. Smith."

• Purpose: Appointment preparation • Recipient: Dr. Smith • Start: August 20 • End: August 21 • Information: Appointment Preparation Package

Once the end time passes, access is automatically revoked. This is preferable to permanently granting broad access for a one-time need.

Compassion AI (COI) does not automatically make every piece of AI-generated information part of the shared record. AI-generated content has a lifecycle:

User Input → AI Processing → AI Draft → Human Review → Approve / Edit / Discard → Shared or Saved Information

This supports the Human-in-the-Loop principle: AI can prepare, humans decide.

Why human approval is required: AI can misunderstand speech, context, names, emotions, medical terminology, personal preferences, and family relationships. Therefore, important AI-generated information is reviewed before becoming an authoritative shared record.

An AI Draft is information generated or organized by COI that has not yet been approved as a final record. Example:

Compassion AI Draft "I organized your recent voice journal into a summary." [ Review ] [ Edit ] [ Discard ] [ Approve & Sign ]

The user remains in control throughout. AI-generated information does not automatically become visible to the Family Circle or Care Team simply because it was generated. Instead: AI → Draft → Human Approval → Permission Check → Share.

The platform's Signature Prompt acts as the final confirmation layer for important AI-generated records:

┌────────────────────────────────────────────┐ │ COMPASSION AI DRAFT │ │ "I organized your spoken memory into │ │ a journal entry." │ │ [ Review ] [ Discard ] [ Approve & Sign ] │ └────────────────────────────────────────────┘

After approval, the record captures: • approved_by — USER_ID • approved_at — TIMESTAMP • approval_method — SIGNATURE

What "signature" means: the application distinguishes user confirmation from any legally required formal electronic signature. The exact legal requirements depend on the specific workflow and applicable law. For ordinary platform workflows, the system records who approved, what they approved, when they approved, what version they approved, and what changed afterward.

Every AI-created object has a clear status:

• AI_DRAFT — newly generated, awaiting review • PENDING_REVIEW — queued for a human reviewer • EDITED — modified by a human, awaiting final approval • APPROVED — signed off, becomes part of the shared record • REJECTED — discarded, not shared • ARCHIVED — superseded but retained for audit • SUPERSEDED — replaced by a newer version

Example:

Story Scribe Entry Created: Aug 19, 2026 Created by: Compassion AI Status: PENDING REVIEW [ Review ]

This status travels with the record — anyone viewing it knows whether they are looking at a draft, an approved entry, or a superseded version.

You can request or download information associated with your account, subject to applicable legal, organizational, and technical requirements.

Possible export categories: • Profile information • Care preferences • Activities • Journal entries • Memories • Photos • Messages • Appointments • Reports • Approved AI-generated records

The interface clearly shows what will be included before the export begins. Structured data is available in JSON or CSV; human-readable documents are available in PDF. The exact formats depend on the type of information.

Export security: exports can contain sensitive information. Therefore the platform requires appropriate authentication, confirms the export request, logs the request, protects generated files, provides an expiration period for download links, and never exposes exports through public URLs. An exported file is now outside the platform's normal permission controls — you should treat it accordingly.

Recommended route: Settings → Account → Delete Account

Before deletion, the platform clearly explains: • What will be deleted • What may be retained where required • What happens to shared information • What happens to family access • What happens to uploaded memories • What happens to pending invitations • What happens to AI drafts • Whether deletion can be reversed

Deletion is not an immediate "one click." Because the system contains interconnected information, the flow has safeguards:

Request Deletion → Explain Consequences → Confirm Identity → Confirm Again → Optional Export → Schedule / Process Deletion → Revoke Access → Delete / Retain According to Policy → Audit Completion

When an individual's account or permissions change, connected people do not retain access simply because they previously had a valid session. The platform re-evaluates authorization: Permission Revoked → Access Token / Session → Revalidated → Access Removed.

COI Orb maintains an appropriate audit trail for important security and permission events:

• Permission granted • Permission revoked • Representative added • Representative removed • Data shared • Data exported • AI draft approved • AI draft rejected • Record modified • Account deletion requested • Account deletion completed

The audit record answers: Who? What? When? Why / context? What changed?

The Privacy Center surfaces a simple Recent Privacy Activity feed:

Today — 10:32 AM — Sarah was granted access to Appointments. Yesterday — 4:18 PM — Health information access was removed from Michael. August 15 — 9:02 AM — Appointment Preparation Package shared with care team.

This creates transparency without overwhelming the user.

These are related but different:

Privacy — Who is allowed to see or use information? Security — How does the system protect information from unauthorized access?

Both are required. Privacy controls define the policy; security controls enforce it. COI Orb uses industry-standard AES-256 encryption for data at rest and TLS 1.3 for data in transit, with per-care-circle logical separation and regular security audits. But encryption alone does not decide who is allowed to see what — that is the permission layer's job.

Some modules require device capabilities. COI Orb requests only the permissions needed for the feature being used.

Camera — may be needed for Vitals Core, video calls, photos, and gesture features.

Microphone — may be needed for Compassion AI voice interaction, Story Scribe, voice messages, and video calls.

Notifications — may be needed for messages, appointments, shared tasks, and authorized safety notifications.

Why did my browser ask for camera access? A browser may request camera permission when you use a feature that requires the camera (Family Room, Video Call). You can deny permission, but the camera-dependent feature may not work.

Why did my browser ask for microphone access? The microphone may be required for Compassion AI voice interaction, Story Scribe, voice messages, and video calls. Only grant microphone access when you are comfortable using the feature.

COI Orb follows data minimization: collect what the feature needs — not everything the platform could possibly collect. If a feature only needs preferred_language, it does not require a full demographic profile.

This is especially important for the modular architecture. Turning on a module does not automatically expose unrelated information. Example:

User activates: Sensory Lane → Module data created → Module-specific sharing policy applies → User authorization determines who sees it → Authorized recipient only

The permission system eventually supports:

resource + action + subject + recipient + scope + expiration

Conceptually: Sarah CAN_VIEW John's Sensory Lane UNTIL 2026-09-01

This is much stronger than simple role-based access alone.

The Orb itself obeys the same authorization architecture. COI cannot retrieve your Private Journal simply because someone asks: "Tell my daughter everything you know about me."

The system determines: 1. Who is asking? 2. Who is the subject? 3. What information is requested? 4. Is that information available? 5. Is it shareable? 6. Is the recipient authorized? 7. Is human approval required?

Only then is information disclosed.

The AI architecture has a clear data boundary:

Authorized Data → AI Context Layer → Compassion AI → Draft / Answer → Safety + Permission → Human Approval

COI does not have unrestricted database access. It sees only what the permission layer allows it to see for the current interaction, and its outputs pass through safety + permission checks before reaching the user or any shared surface.

1. The individual comes first. 2. Access should be intentional. 3. Family does not automatically mean full access. 4. Caregivers receive only the access they need and are authorized to have. 5. AI drafts are not automatically authoritative records. 6. Humans remain responsible for important approvals. 7. Modules do not automatically share information. 8. Permissions should be transparent. 9. Important access changes should be auditable. 10. Privacy should be understandable, not hidden behind technical language.

The core rule for the platform: No role automatically owns the individual's data. A role is not permission. A relationship is not permission. A module is not permission. An AI capability is not permission. Instead:

IDENTITY + RELATIONSHIP + ROLE + AUTHORIZATION + RESOURCE + ACTION + SCOPE + TIME = ACCESS DECISION