Smart-AID

An emotional-support system where the safety rules were written before the conversation.
_{Two complementary companions. A risk gate that runs before the model speaks. A five-field capsule instead of your history.}
_{by Jonatan Estiven Sánchez Vargas · Systems and Informatics Engineering, Universidad Nacional de Colombia}

Why this exists

Smart-AID emerged during a personally difficult period of my life, in which mindfulness and the company of my dog Alan became important sources of calm, structure and emotional support.

That experience inspired a question I later began to explore through my Systems Engineering degree: how can technology responsibly support human well-being, and how can the effects of practices such as meditation be studied with scientific rigour?

The idea first took shape in an engineering project centred on stress, wearable sensing and non-clinical well-being. It later evolved through research into meditation, psychophysiological signals, software quality and responsible artificial intelligence.

Alan & Aura represents two forms of support that shaped that process. Alan — named after my dog, and the emblem of the application — stands for companionship, encouragement, and the possibility of moving forward one small, manageable step at a time. Aura stands for calm, reflection and self-compassion.

This personal origin is also why safety, privacy and clearly defined non-clinical limits were designed before the conversational experience itself.

[!IMPORTANT] Read this before anything else. Smart-AID is designed and documented, not implemented. There is no product source code, no deployed application, no executed product tests (the only tested code is internal tooling), and no clinical validation. No performance figure here is a measured result of my own system — anything that reads as performance is a design target, a projection, or a citation from published literature, and is labelled as such where it appears. The remaining numbers are artefact counts — how many requirements, risks or scenarios a document contains — verifiable directly for the public artefacts, and on request for the private corpus.

That state is deliberate and gate-enforced: the methodology I wrote forbids building the conversational product before the safety work closes. What does exist is the rarer half: a governed, traceable, safety-first design corpus — the status matrix shows exactly how much.

Why this exists
In two minutes
What it looks like
The problem
How the four lines fit together
What actually exists — status matrix
Design decisions that define the system
Alan and Aura
Sensing and wearable engineering
Skills and technologies
A prototyping direction for Hack the North
Evidence and artefacts
My contribution
Scope and limits
Roadmap
Acknowledgements
Licence and notices
References
Documentation →

Short on time? Read Why this exists and the status matrix — five minutes, and you will know what this is and exactly how finished it is. The documentation goes one level deeper.

In two minutes

A language model that improvises inside an emotional-support conversation is not a feature. It is a hazard. Most companion apps solve the interface first and bolt safety on afterwards. Smart-AID inverts that order: the constraints came first, and the conversation was designed to fit inside them.

The product is a pair of companions — Alan, who works on activation through small, manageable steps, and Aura, who works on regulation and reflection. They differ in tone, pacing and the kind of question they ask. Neither of them can relax a single safety clause. Personality modulates how something is said; it never has authority over whether it may be said.

Around that sits an ecosystem: a research programme that studies what actually changes in a person over time, a wearable sensing architecture for occupational stress, and a quality and risk apparatus — traceable requirements, ISO-anchored quality targets, quantified risk — that keeps ambition tied to evidence.

The aim is narrow and deliberate: to accompany someone through an ordinary difficult moment without pretending to be a clinician, without competing for their attention, and without ever being usable against them. Everything else in this repository follows from that — see why this exists.

What it looks like

[!NOTE] High-fidelity design mockups from the public academic package — not a running product. Self-contained HTML, warm neutrals, AA-checked contrast, light and dark themes. An MVP construction phase is underway as a university deliverable; when it ships, this section will show the running build.

Chat mockup: Aura greets the user warmly; the user says they feel overwhelmed; Aura validates the feeling and offers to sort things out together, one thing at a time. The same screen exists in a warm-neutral dark theme with AA contrast.

_{The conversation with Aura — and this image follows your colour scheme: viewers in dark mode are seeing the dark mockup right now.}


_{Landing — what it is, and what it is not}	_{Choosing your companion}	_{Granular consent — nothing pre-ticked}

Sixteen screens exist in the public package — including the safety-degradation states and the containment screen, which are documented there rather than showcased here. Browse all sixteen live → — every mockup is a self-contained page you can open and click through.

The problem

Occupational stress and psychosocial risk are among the least well-served problems in applied technology, and the gap is widest where support is least available.

The World Health Organization estimates that 15 % of working-age adults were living with a mental disorder (2019 estimate), and that 12 billion working days are lost every year to depression and anxiety (WHO, Mental health at work, 2022).
In Colombia, 2024 press coverage of consultancy findings — echoed by the Ministry of Labour — put close to 80 % of workers describing elevated stress, concentrated in health, manufacturing, transport and outsourced services (El Tiempo, 2024). The figure originates in sector reports rather than an official measurement, and is treated here as a signal, not a statistic.
Conventional responses — workshops, leaflets, self-care campaigns — show limited durable effect, mainly because they offer no personalisation, no continuity, and no capacity to intervene at the moment it matters.

At the same time, conversational AI has moved into this space faster than the safety engineering has. Systems improvise in situations where improvisation is exactly the wrong behaviour, and they are frequently optimised for engagement in a domain where engagement is not the goal.

The design premise of Smart-AID is that emotional safety outranks engagement, and that this has to be enforced architecturally rather than promised in a prompt.

How the four lines fit together

Four bodies of work, each answering a different question, each with a different maturity.

flowchart TD
    NQ["<b>NeuroQuantIA</b><br/>Scientific research programme<br/><i>What actually changes in a person over time?</i>"]
    SA["<b>Smart-AID</b><br/>Applied ecosystem &amp; governance<br/><i>How do we build this without doing harm?</i>"]
    AA["<b>Alan &amp; Aura</b><br/>Conversational companion<br/><i>How should it speak, and when must it not?</i>"]
    WE["<b>Smart-AID Anti-Stress</b><br/>Wearable sensing &amp; business case<br/><i>Is it viable to build and sustain?</i>"]

    NQ -->|"grounds and constrains"| SA
    SA -->|"bounded, buildable slice"| AA
    SA -->|"sensing &amp; feasibility line"| WE
    WE -.->|"physiological context, later"| AA
    NQ -.->|"measurement architecture"| WE

    classDef prog fill:#E7F1EF,stroke:#1F6357,stroke-width:2px,color:#123F39
    classDef eco  fill:#EBF1F4,stroke:#3F6E8C,stroke-width:2px,color:#22333F
    classDef prod fill:#FBEFDD,stroke:#8A5216,stroke-width:2px,color:#5C360E
    class NQ prog
    class SA eco
    class AA,WE prod

Line	What it is	Question it answers	State
NeuroQuantIA	Research programme on meditation, stress and psychophysiological regulation	What changes, and how would we know?	Longitudinal design in planning
Smart-AID	Applied ecosystem, domain canon, normative base, audit pipeline	How is this governed so it cannot drift?	Documented
Alan & Aura	The conversational companion — the buildable slice	How should it speak, and when must it refuse?	Designed through analysis and interface
Smart-AID Anti-Stress	Wearable for occupational stress + full engineering pre-feasibility study	Is it viable to build, certify and sustain?	Study executed, device not manufactured

The dotted arrows matter as much as the solid ones. Physiological context is a later input to the conversation, never a prerequisite: the conversational MVP is specified to work with no wearable at all.

What actually exists — status matrix

Five progression stages per component. The furthest column a row reaches is the claim — everything to its right is explicitly not claimed.

Component	Designed	Documented	Implemented	Tested	Deployed
Ecosystem domain canon — with the conversational module decomposed into 25 internal submodules, 14 external modules and 17 cross-cutting domains	✅	✅	—	—	—
Alan & Aura character system — 7-phase intervention cycle, 14 typified situations	✅	✅	—	—	—
Conversational contract — 10 hard clauses, 8 personality traits	✅	✅	—	—	—
Safety protocol — binary gate, deterministic fallback, unified S0–S5 triage scale	✅	✅	—	—	—
LLM architecture v2.0 — four planes, two-speed loop, parallel guardian	✅	✅	—	—	—
Requirements — 26 functional (26/26 traced, zero orphans), plus 10 non-functional and 10 quality requirements	✅	✅	—	—	—
Domain model & use cases — 12 classes, 10 use cases, 10 textual specifications	✅	✅	—	—	—
Interface design — 16 screens delivered as 19 self-contained HTML files, AA contrast checked at design level	✅	✅	—	—	—
Risk apparatus — 42 risks with RPN, 20 000-run ordinal Monte Carlo, 23 adversarial scenarios	✅	✅	—	—	—
Test cases — 15 in Given/When/Then, each tied to a risk and a gate	✅	✅	—	❌ not executed	—
Knowledge-graph infrastructure — deterministic merge, verified byte-for-byte rollback	✅	✅	✅ ~36 scripts	✅	—
Wearable sensing architecture	✅	✅	—	—	—
Product application code	—	—	❌ none	❌	❌

The only thing I have implemented is the knowledge-graph tooling that makes this corpus navigable — roughly 36 Python scripts. The conversational product has no code, on purpose.

Design decisions that define the system

[!NOTE] Personality never outranks safety. As stated above, the contract makes this a hard rule: traits modulate voice, no trait relaxes a clause, and both companions carry identical limits.

[!NOTE] The risk gate runs before the model generates. On a turn that trips the gate, the language model never produces the reply at all. A deterministic, locally computed fallback answers instead — and it keeps working when the model provider is down. The policy is fail-closed on high-risk surfaces, with the crisis path explicitly required to survive without any LLM. That requirement is non-negotiable in the architecture, and the fallback is specified as the first component to be built, before any feature.

[!NOTE] The model receives a capsule, not your history. Instead of a conversation transcript, the model receives a small structured profile capsule carrying only what it needs, each attribute stamped with confidence, recency and source. The specification lists explicitly what is forbidden from ever reaching it: raw history, item-by-item questionnaire answers, the full journal, raw biomarkers, organisational data, clinical labels, and any inference without a confidence value. One rule governs updates: recent high-confidence evidence outranks the historical prior.

[!NOTE] Structured decision, not vector RAG. Intervention techniques live in versioned Technique Cards — objective, theoretical basis, indications, contraindications, prerequisites, activation signals, flow, what not to say, metrics, and interruption criteria. Selection is a deterministic engine over that registry, not similarity search over free text. The reason is specific: it makes selection auditable, it makes contraindications guaranteed rather than probable, and it makes hallucinated protocols structurally impossible. Retrieval is reserved for curated psychoeducation, with provenance checks.

[!NOTE] Three contradictory triage scales, reconciled into one. Auditing my own corpus, I found the same construct measured on three incompatible scales across different documents. Reconciling them into a single S0–S5 scale, and demonstrating that every prior level maps onto the new one, took longer than any diagram in the project. Unnoticed, it would have produced a system whose safety thresholds disagreed with themselves.

The two-speed loop

Latency and longitudinal learning pull in opposite directions. The architecture separates them.

flowchart LR
    U([User message]) --> G1["<b>Ingress guard</b><br/>PII · injection · crisis screen"]
    G1 --> CAP["Context capsule<br/><i>bounded, sealed</i>"]
    CAP --> REAS["Affective + CBT formulation<br/>phase · strategy · gate"]
    REAS --> TECH["Technique selection<br/><i>deterministic</i>"]
    TECH --> GEN["Controlled generation<br/>Alan / Aura voice"]
    GEN --> G2["<b>Egress guard</b><br/>clinical · ethical · privacy"]
    G2 --> R([Reply])

    G1 -.->|"gate tripped"| FB["<b>Deterministic fallback</b><br/>no LLM involved"]
    FB --> R

    R -.-> SLOW["<b>Slow path, asynchronous</b><br/>post-turn evaluation · selective memory<br/>profile update · analytics · red-team sampling"]
    SLOW -.-> CAP

    classDef guard fill:#F3E4DD,stroke:#9E5744,stroke-width:2px,color:#6E3A2C
    classDef fast  fill:#E7F1EF,stroke:#1F6357,stroke-width:1.5px,color:#123F39
    classDef slow   fill:#EFEBE3,stroke:#6B6862,stroke-width:1.5px,color:#2B2A27
    class G1,G2,FB guard
    class CAP,REAS,TECH,GEN fast
    class SLOW slow

The fast path is synchronous and runs on a latency budget. The slow path — evaluation, memory writes, profile updates, analytics — runs after the turn, where it costs the user nothing. The guardian operates in parallel at four enforcement points: pre-prompt, pre-inference, post-inference and post-action.

Alan and Aura

Two companions, one job each, and a rule that binds them.

	Alan	Aura
Form	Border Collie, chocolate merle — the emblem of the application	Ragdoll cat
Function	Positive activation	Deep regulation
Works on	Movement, small steps, habits, focus, practical coping	Calm, validation, breathing, introspection, emotional regulation
Intervenes when	The user needs to move, and calm has become stillness	The user needs to come down before anything else can happen

Alan activates so that calm does not become immobility. Aura regulates so that action can be safe.

Alan is named after my own dog — the story is in Why this exists. The design consequence: a character with a real temperament to be faithful to, instead of a generic cheerful-assistant persona.

Alan — a chocolate merle Border Collie with heterochromatic eyes and a red bandana, smiling up at the camera. The real dog behind the character, and the emblem of the application.

Around them: a seven-phase intervention cycle — detection, initial containment, companion selection, support-type selection, accompanied execution, feedback, personalised learning — plus 14 typified situations from acute anxiety and panic to procrastination, perfectionism, insomnia and the sense of failure. Each carries what each companion says, and what neither of them may say. The character system is specified through 25 functional requirements and 30 business rules in the ecosystem corpus — a distinct scope from the MVP's 26 requirements in the status matrix above.

Neither of them diagnoses, treats, or handles an emergency autonomously. In a crisis the personality is subordinated to the protocol — which is the entire point.

Sensing and wearable engineering

[!WARNING] Deliberately redacted. Industrial-property protection for this device is reserved. This section publishes the engineering reasoning — modalities, physiological rationale, architecture pattern and standards — at full depth. It withholds component-level specifications, the exact sampling-parameter set, and the electronic integration design; the standard protocols named below are industry building blocks, not the withheld combination. Nothing here has been manufactured; no hardware exists, no data has been acquired, no signal pipeline runs.

Smart-AID Anti-Stress is a head-worn band for occupational stress in high-demand sectors, developed as a complete engineering pre-feasibility study. Its analytical engine is named SpectroStress — the name is public; its design is not. The device is positioned as a commercial well-being device, explicitly not a medical device — no diagnosis, no treatment, no regulatory clearance claimed or obtained.

The sensing minimum, and why each part is there

Modality	What it contributes	Why it is in the minimum
EEG (dry frontal)	Cortical activity across theta, alpha and beta bands	The only window onto cognitive fatigue and attentional micro-disconnection; peripheral signals cannot substitute for it
EDA	Tonic level and phasic responses	The most sensitive index of sympathetic arousal, and it responds on the timescale an intervention needs
PPG → HRV	Pulse-derived heart-rate variability	Autonomic regulation and recovery. Chosen because it is low-power and wearable-realistic
Accelerometer / IMU	Motion, posture, stillness	Not an emotional sensor — a correction term. Motion artefact is the dominant failure mode of wearable PPG, and without motion context an HRV drop from walking is indistinguishable from an HRV drop from stress

Everything beyond those four — skin temperature, SpO₂ as a safety guardrail during guided breathing, an electrochemical cortisol channel for slow-axis context, indoor positioning — is an extension above the minimum, not part of it.

Two design commitments are worth stating because they are easy to get wrong:

Confounders are engineered in, not apologised for later. The IMU is present to suppress false stress positives from movement; skin temperature is present to separate thermal and physical load from emotional load. Neither is a "bonus sensor".
Safety instrumentation is not well-being instrumentation. SpO₂ appears as a guardrail during breathing exercises, not as a wellness metric. The same principle that governs the chatbot — safety outranks engagement — applied to the physical layer.

Architecture

Edge-first, six layers, standards throughout.

Layer	Approach
Device / edge	Real-time operating system; notch and low-pass filtering and feature extraction on-device; TinyML inference within a declared latency budget, so classification does not depend on connectivity; local haptic and LED alerting that survives network loss
Security on-device	Secure boot with a chain of trust, hardware-isolated secure domain for keys and biometric handling, encrypted local storage, signed over-the-air update
Gateway	Single-board aggregator for environments without direct Wi-Fi: local buffering, secure forwarding, fallback logic
Transport	BLE 5.2 with link-layer encryption; Zigbee (IEEE 802.15.4) mesh fallback for sites without stable networks; MQTT v5 over TLS 1.3 for critical telemetry
Cloud	Containerised microservices under orchestration; time-series store for physiological signals alongside a relational store for context; federated learning with differential privacy so model training does not require centralising raw biometrics
Interoperability	HL7 FHIR for clinical systems, OData and SOAP connectors for enterprise platforms, WebSockets for live dashboards

Materials and physical design are specified against ISO 10993 biocompatibility, IP68 ingress protection and IEC 60601-1 electrical safety, at a target mass of ≤120 g, with mounting variants for helmets, surgical caps and headsets — because a device that is uncomfortable at hour six produces no data at all.

Privacy is architectural rather than declared: pseudonymisation, encryption in transit and at rest, granular and revocable consent, aggregated and anonymised dashboards, and an explicit prohibition on punitive use. Voice analysis, where present, processes transient paralinguistic metadata only — no audio is stored or transmitted.

Skills and technologies

Each grouping is anchored to an artefact that exists — a specification, a design system, a study, or working tooling. Where a skill is exercised at design level rather than in running code, the heading says so.

Requirements & systems engineering — requirements engineering with a Wiegers business-rule taxonomy · UML and ICONIX (domain model, use-case diagram, 23-section textual specifications) · end-to-end traceability with orphan verification · MoSCoW, definition of ready and definition of done.

Software quality, normed — ISO/IEC 25010:2023 including the safety characteristic family · SQuaRE (25022, 25023, 25024, 25030, 25040) · ISO/IEC/IEEE 15939 measurement · 12207 and 16326 lifecycle · GQM with explicit thresholds and gates · a project-to-standard bridge matrix where each row declares its own verification level.

AI & LLM systems — safety-first conversational architecture · prompt-injection defence by data delimitation · data minimisation via a bounded context capsule · deterministic technique selection over versioned cards · evaluation harness design with golden datasets, calibrated LLM-as-judge and release gates · per-locale parity rules for bilingual deployment.

Embedded, edge & IoT (architecture level — designed, not yet built) — TinyML and on-device inference under a latency budget · real-time operating system, digital filtering and feature extraction at the edge · BLE 5.2, Zigbee, MQTT v5 over TLS 1.3 · secure boot, hardware-isolated key storage, signed OTA · six-layer IoT architecture with explicit throughput, failover and recovery objectives.

Biosignals & sensing (design and analysis level) — EEG, EDA, PPG/HRV, IMU, ECG/RSA, cortisol · derived indices (RMSSD, SDNN, frontal alpha asymmetry, theta/beta ratio, tonic and phasic EDA features) · signal-quality control and motion-artefact reasoning · the discipline of signal → quality-controlled feature → first-order inference → triangulated interpretation, and the refusal to skip a step.

Research & evidence synthesis — literature review with declared method and enumerated deviations · AACODS appraisal for grey literature · evidence matrices · risk-of-bias awareness · a three-layer research protocol (immutable primary record → versioned report → living integrator) across roughly 250 references.

Risk, simulation & decision engineering — risk registers with RPN · ordinal Monte Carlo simulation · adversarial scenario injection · quantitative investment appraisal (WACC, IRR, NPV) · demand modelling with ARIMA and diffusion curves · market sizing with Porter and TAM/SAM/SOM.

Data & knowledge engineering — Python, networkx · deterministic graph merging · reproducible pipelines with verified byte-for-byte rollback · fourteen empirically verified failure modes of an external tool, documented so no one rediscovers them.

Governance & responsible technology — architecture decision records with alternatives, negative consequences and reversal conditions · privacy by design under Colombian data protection law and GDPR · accessibility to WCAG 2.2 AA as a design constraint · traceability discipline with declared verification levels.

A prototyping direction for Hack the North

[!NOTE] Hack the North has not yet published its 2026 hardware list. This is written to be robust to whatever is available, and it is a proposal, not a commitment.

Thirty-six hours is not enough to build Smart-AID. It is exactly enough to build the one component the architecture says must be built first.

The slice: a motion-aware stress signal with a safety gate that survives the network.

Acquire PPG and accelerometer from whatever is on the hardware table — a wrist sensor, a dev board with an optical sensor, or a phone camera plus IMU if no dedicated hardware exists.
Derive HRV features, then use the accelerometer to reject or flag windows contaminated by motion. This is the part most demos skip, and it is the part that decides whether the signal means anything.
Infer at the edge with a small model under a declared latency budget — proving the architecture's claim that classification does not require connectivity.
Gate the response deterministically. Demonstrate live that when the network or the model provider is cut, the safety path still answers. That is the single most important behaviour in the whole system, and it is demonstrable in a two-minute video.
Voice it through Alan or Aura, showing that the two companions differ in tone while carrying identical limits.

Why this slice. It is honest about scope, it exercises the genuinely hard part rather than the visible part, and it produces something a judge can break on purpose — pull the cable, shake the sensor — and watch behave correctly.

Fallbacks by availability: with no biosensors at all, the same architecture is demonstrable with simulated signal injection and a real gate; with a microcontroller but no ML accelerator, with a quantised classical model; with neither, as a phone-only build. The safety gate and the artefact-rejection logic are the deliverable — the sensor is an input.

Scope note. This is a judged, closed demo — not user exposure. The decision record that mandates an evaluation harness before any user sees the product governs releases; what this slice builds is precisely the component that record says must exist first.

What I want to learn there. Rigorous evaluation of LLM systems from people who ship them; embedded ML beyond the datasheet; and how teams with completely different stacks cut scope under pressure. I bring the safety-and-evidence discipline; I want the shipping reflexes.

Evidence and artefacts

Artefact	Where
Alan & Aura Académico — ICONIX analysis package through use-case specifications (robustness and sequence analysis pending): 12-class domain model, 10 use cases with textual specifications, 26 traced requirements with zero orphans, 16 screens of high-fidelity mockups, evidence-based design system, 27 recorded decisions. Authored in Spanish (es-CO)	`github.com/jonatan8254/alan-aura-academico` — public · mockups navigable live
Domain model (own diagram; labels in Spanish)	`assets/diagrams/domain-model.svg`
Use-case diagram (own diagram; labels in Spanish)	`assets/diagrams/use-cases.svg`
Macro-project corpus, audit pipeline, architecture decision records, external research series	Private repository — available on request
Wearable pre-feasibility study, financial model, supply-chain analysis	Private — commercially sensitive
NeuroQuantIA longitudinal protocol	Private — pre-publication

Everything in the private set is described here at the level of approach and method. Detail is withheld for the reasons stated in NOTICE.md.

My contribution

Individually authored and continuously led: the idea and business concept, the vision, the business rules, the ecosystem across macro- and micro-project, the verbal models and domain canon, functional and non-functional requirements, planning, architecture, methodological tailoring, the Alan and Aura characters and their interaction and personality design; within the implementation plan, the management and lifecycle processes — including the strategic processes, the most extensive part of that document — the whole of the quality requirements documentation, and the Monte Carlo risk simulation and its analysis; plus the entire audit pipeline, the architecture decision records, the external research series and the knowledge-graph infrastructure.

Collective work, credited as such: three of these lines are course deliverables produced with teams. Teammates contributed named artefacts — test cases, user-story extraction and estimation, the development contract, supporting diagrams — and are credited by line in NOTICE.md. Individual names are withheld where I do not have authorisation to publish them.

I state the boundary because a portfolio that blurs it is worth less than one that does not.

Scope and limits

Smart-AID does not diagnose, treat or prevent any condition. It is non-clinical technology for emotional well-being.

No clinical validation has been performed, and none is claimed.
No participant data has been collected. No study has been executed.
No regulatory registration has been obtained or applied for.
The conversational system does not handle emergencies autonomously; the crisis path is a deterministic protocol that routes to human help.
The minimum age for the conversational MVP is 18+, decided and documented, with a hard block rather than a soft warning — and a referral to resources rather than a closed door.
Data minimisation is architectural: the model receives a bounded capsule, never raw history, journals, questionnaire items or raw biomarkers.
Use is never punitive. Aggregated views are anti-re-identification by design, and no critical safety path may be blocked by payment status.
The system is specified to work without any wearable.

No performance figure anywhere in my work is a measured result of my own system — anything that reads as performance is a design target, a projection, or a citation from published literature, labelled as such where it appears. Figures that describe the corpus itself are artefact counts — verifiable directly for the public artefacts, and on request for the private corpus.

Roadmap

Near term — the public documentation is complete as it stands: docs/ covers the ecosystem, governance and the companions at overview level, and deliberately stops there. Deeper layers — quality and risk, the construction roadmap, the research protocol, the sensing specification — remain internal by design, available on request. The immediate milestone is the MVP build, underway as a university deliverable.

Then — build the reconstruction artefacts the audit prescribes, in the order the queue defines: the safety protocol first, then the conversational contract, then the verbal-model standard. Bilingual from birth rather than translated late, behind explicit internationalisation gates.

After that — the evaluation harness: golden datasets per locale, a crisis lexicon per locale, calibrated judge rubrics, and the release gates that must go green before any user sees anything. Only then the vertical slice: consent, onboarding, companion selection, a live conversation, non-persistent chat, an administrative kill switch, and the deterministic safety fallback.

Long horizon — the longitudinal study, and the sensing layer as a separate line with its own ethics and validation path.

Acknowledgements

This project exists because of people who supported it long before it was anything.

Gladis Vargas Pérez and María Valentina Sánchez Vargas — my mother and my sister — for unconditional support throughout this process.

Professor Eliana Arango, whose course gave me the tools I needed at the moment I most needed them.

Professor Angela Maldonado, who guided me through Engineering Project Structuring and Evaluation, where the idea first took the shape of a project.

Professor Albeiro Espinosa, who has accompanied this work through Software Quality and through Software Product Design and Construction, where it became a system.

Professor Francisco Albeiro Gómez Jaramillo at Universidad Nacional de Colombia and Professor Geneviève C. Major at Université Laval, for opening the door to studying this scientifically.

And my teammates across three university courses, who built alongside me.

Licence and notices

This repository is published to be read and evaluated, not reused. You are welcome to read it, evaluate it, link to it, and quote brief excerpts with attribution. Copying, modification, redistribution, commercial use, use as the basis of another product, publication or deliverable, and use for training or evaluating machine-learning models require prior written permission — which is genuinely available on request.

No patent or trademark rights are granted. Industrial property over the wearable device and its analytical method is expressly reserved. Standards and literature are cited, never redistributed. See NOTICE.md for trademarks, third-party material, collective-work attribution, and the absence of institutional endorsement.

References

Standards and frameworks referenced across this work — cited by identifier, never reproduced:

Quality & lifecycle — ISO/IEC 25010:2023 · ISO/IEC 25022:2016 · ISO/IEC 25023:2016 · ISO/IEC 25024:2015 · ISO/IEC 25030:2019 · ISO/IEC 25040:2011 · ISO/IEC/IEEE 15939:2017 · ISO/IEC/IEEE 12207:2017 · ISO/IEC/IEEE 16326:2019 · ISO 9001:2015 · ISO/IEC 90003:2018 · PMBOK Guide, 7th ed.

Safety, health & devices — ISO 45001 · ISO 45003 · ISO 10993 · IEC 60601-1

Security, privacy & accessibility — ISO/IEC 27001 · ISO/IEC 27701 · WCAG 2.2 · GDPR · Ley 1581 de 2012 (Colombia) · Decreto 1377 de 2013 · Ley 1480 de 2011 · Resolución 0312 de 2019 · Circular Externa 002 de 2024 (SIC)

Interoperability — HL7 FHIR · MQTT v5 · Bluetooth Low Energy 5.2 · IEEE 802.15.4

Method — Wiegers, Software Requirements · Rosenberg, Use Case Driven Object Modeling with UML · Basili, Goal-Question-Metric · PRISMA 2020 · AACODS

_{Jonatan Estiven Sánchez Vargas

Systems and Informatics Engineering · Universidad Nacional de Colombia — Facultad de Minas, Medellín

GitHub · LinkedIn · Devpost

Affiliation is context, not endorsement.

Last updated: 2026-07-28}

Built With

documented

smart-aid