kamrulhasan12345/sentinel

1. System boundary

Sentinel is a self-contained, offline-first mobile app. The runtime architecture is almost entirely on-device: user input, model inference, triage decisioning, medical guidance lookup, and history storage all happen locally. There is no backend service or network API shown in this repository.

2. App shell and navigation

The UI is built with Expo Router in src/app. The root layout and drawer layout define the navigation shell, with at least two primary surfaces: the main triage screen (index.tsx) and a library screen. Supporting routes include a modal, a not-found page, and a web HTML entry. This makes the navigation structure file-based and easy to map as a top-level app shell plus feature screens.

3. Primary interaction layer

src/screens/ChatScreen.tsx appears to be the core triage interface. It is the main place where symptoms are entered and results are displayed. The screen is supported by shared UI components in src/components, such as themed text, external links, and client-only helpers.

4. Voice and text input path

User input can arrive as typed text or through voice capture. The useVoiceToText hook is the dedicated input bridge from microphone speech to text, which is important because the product targets emergency/high-stress usage. That means the app’s first data flow is: microphone or keyboard input → normalized text → triage engine.

5. Orchestration layer

src/services/HybridEngine.ts is the central decision-maker. It coordinates the two model paths: the primary CNN classifier and the transformer-based semantic fallback. The readme describes a confidence-based switch, so the architecture should show the hybrid engine choosing the inference path and merging the final intent/severity/confidence result.

6. Primary ML inference path

CNNEngine.ts and CNNVocab.ts implement the fast, first-pass classification model. The packaged TFLite artifact lives in src/assets/models/sentinel-cnn-v1/med_intent.tflite, with a vocabulary file and labels. This is the app’s low-latency intent classifier for common symptom phrases.

7. Fallback semantic inference path

STEngine.ts and STVocab.ts back the secondary semantic model. The packaged all-MiniLM-L6-v2 assets include the TFLite transformer and anchors.json, which suggests local embedding generation plus similarity matching against precomputed intent anchors. This path resolves unfamiliar phrasing when the CNN confidence is low.

8. Medical knowledge and response generation

KnowledgeBase.ts plus src/data/emergency_data.json provide the protocol content shown after classification. This is where an inferred intent is turned into first-aid steps, warnings, and escalation guidance. In other words, the models classify the problem, and the knowledge base supplies the human-readable medical response.

9. Severity, UI mapping, and emergency actions

App-wide constants such as SeverityMap.ts, Colors.ts, Config.ts, and StopWords.ts shape the final experience. Severity is translated into user-facing UI states and likely determines emergency escalation behavior, including the documented one-tap call to local emergency services for critical cases. The model confidence also feeds visual cues in the UI.

10. Local persistence and privacy boundary

HistoryService.ts stores assessment history on-device, which is part of the app’s privacy-first design. This is an important architectural boundary: saved triage sessions stay local instead of being synchronized to a remote account or cloud backend.

11. ML training pipeline vs runtime app

ml_pipeline/ is a separate build-time environment, not part of the mobile runtime. It contains the training dataset (data/intents.json), preprocessing logic, and the notebook used to train the text classifier. The pipeline produces the model artifacts that are later copied into src/assets/models, creating a clear separation between offline model development and device inference.

12. Platform/tooling implications

The app is built with React Native, TypeScript, Expo, and TensorFlow Lite. Because native ML is bundled into the client, the project relies on a development build rather than plain Expo Go. The repository also includes standard Expo/EAS configuration and Metro setup, which support packaging the local model assets and native runtime dependencies.