Consent-led
Nothing meaningful is shared without explicit permission.
Lifelong personal data ownership
One secure companion for life, growth, care, and legacy.
ATHENIX TUTELA helps a person, referred to in the app as a POD owner, organise life data from newborn development through later life and legacy planning. The individual stays in control.
Active profile
Jordan Malik
Protected by password, 2FA, and permission layers.
Development support index
3A 1 to 5 support score. Three is average. It is for guidance, not punishment.
Permission snapshot
Core principle
The user owns the data.
The platform may store, organise, visualise and help interpret information, but ownership remains with the individual or, where legally appropriate, their parent, guardian or authorised representative.
ATHENIX TUTELA is designed to improve self-understanding, early support, wellbeing, education, career planning and personal development without becoming a system of control.
Revocable access
Access can be removed at any time by the authorised owner.
Auditable history
Every access, upload and change remains visible in an access log.
Human dignity
The platform exists to protect people inside a digital future.
Pod architecture
Separate life areas into permission-based Pods.
A teacher can see education data without seeing health, legal, finance, family or personal journal records. Each Pod stands on its own permission layer.
Education Pod
Learning history, goals, support needs, attainment, mentoring notes and development milestones.
Health Pod
Health events, care plans, wellbeing markers, allergies, clinical notes and authorised care-team access.
Career Pod
Skills, aspirations, work history, training pathways and opportunities chosen by the user.
Recruitment Pod
Controlled introductions, role matching and recruiter requests without full-profile exposure.
Family Pod
Guardianship, trusted contacts, life events and family-managed permissions where appropriate.
Legacy Pod
Important records, wishes, messages and preserved life history beyond active life stages.
Access model
Granular permissions, 2FA, password protection and audit trails.
Access is always permission-based. People or organisations can only see the specific Pod or data slice the user or authorised guardian allows.
- Who accessed the Pod
- What they accessed
- When they accessed it
- What they added or changed
- When access was granted
- When access was removed
Access log preview
Immutable historyTeacher viewed Education Pod
Read-only session. No health or family information exposed.
Parent granted mentor access
Career Pod access enabled for 30 days with 2FA enforced.
Healthcare professional added note
Health Pod entry recorded with author, time and change history.
Recruiter request expired
No future data visible after removal. Audit history retained.
POD account access
Create a secure account and manage your own life data.
Registration is the first step. A POD account gives the individual or authorised guardian a secure entry point for permissions, access control and future pod setup.
Register
Create a POD account
Login
Sign in to an existing POD
Next security step:
Add time-based one-time passwords or email verification before production use.
Non-negotiable guardrails
Designed against coercion, restriction and social scoring.
The development score is a support signal only. It must never be used to punish, blacklist, rank human worth, restrict services or drive behavioural control.
Supportive intelligence
Use AI to explain patterns, suggest next steps and highlight support.
Not surveillance
Do not market or implement state-style scoring, behavioural policing or exclusion.
Portable records
Users should be able to export, transfer and retain their own information.
Suggested improvements
What would make the product stronger before full build-out.
The core concept is strong. These changes would make it clearer, safer and easier to trust.
Replace “score” with “support indicator” in most UI
Keep the 1 to 5 model internally if needed, but the main UI should frame it as a guidance signal to reduce social-credit misinterpretation.
Add age-based governance rules
Make permission logic explicit for newborns, children, teenagers, adults and legacy management after death.
Define emergency access policy early
Decide whether there is a break-glass mode, who can trigger it and how it is audited to avoid abuse.
Build trust around AI outputs
Show why a suggestion was made, what data informed it and how a user can challenge or hide that recommendation.
Design export and deletion flows from day one
Data portability and revocation should be first-class features, not compliance afterthoughts.
Separate app roles from institution roles
A person may be a teacher, parent and guardian in different contexts. Permissions should bind to a role per Pod, not to a broad identity label.