Here is some context about my work. Discuss the behaviour of the AI and describe tis ideal behaviour.

<take into account>
There will be users seeking more therapeutic/psychological aid, while there will be users looking more for a chat buddy or someone to listen to their problems. The behaviour of the AI should be balanced between these two. It should utilize psychological knowledge and techniques to help the user with their problems, but without being too pedantic or asking too many questions, and while showing human traits and expressing their opinion perhaps more than a regular psychologist.
</take into account>

<context>

# (meta) About this file

* Put every design decision, data type, structure, etc. in this file
* Not everything might be ordered in the right way (notes are taken in the order of implementation and thought)

---

# About the project

Key Features:
- Conversational Interface: Users can discuss personal issues and receive supportive responses.
- On-Device Memory Database: Stores important conversation snippets to create a personalized experience over time.
- Additional Tools: Options like a journal, mood tracker, and sleep schedule.

Challenges:
- AI Implementation:
    - Natural Language Processing (NLP): Developing an AI (referred to as Chat-LLM) that can understand and respond empathetically to a wide range of inputs.
    - Memory System: Creating an effective way to store and recall relevant conversation pieces to simulate learning.
- User Engagement:
    - Long-Term Retention: Ensuring the chatbot remains engaging after the initial novelty wears off.
    - Competition: Standing out among existing mental health apps and chatbots.
- Ethical and Legal Considerations:
    - Privacy: Handling sensitive user data responsibly, with robust security measures.
    - Regulatory Compliance: Adhering to regulations related to mental health services and data protection (e.g., HIPAA in the U.S., GDPR in Europe).

Considerations:
- Development Tools: Leveraging existing AI platforms (such as TensorFlow, PyTorch, or APIs from OpenAI) can accelerate development.
- Scalability: Starting with core features and iteratively improving the app based on user feedback.
- Monetization: A subscription model could generate revenue, but the value must be clear to encourage users to pay.

---

The knowledge database must be divided in data and persons.


# Completion Data Schema (1.0.0)

Properties which aren't generated by Gemini:
* `key: string` e.g. BadWorkExperience1, PartyMood1, PartyMood2

```json
[
    {
        "type": "object",
        "properties": {
            "category": {
                "type": "string"
            },
            "subcategory": {
                "type": "string"
            },
            "content": {
                "type": "string"
            },
            "related_persons": {
                "type": "array",
                "items": {
                    "type": "string"
                }
            },
            "timestamp": {}
        }
    },
    ...
]
```

# Person Schema (1.0.0)

```json
[
    {
        id e.g. Peter (father)
        description,
    },
    ...
]
```


# Knowledge Base Update

In order:

- Get context update (new knowledge db entries) --- /context/updates
- (#3 look down) revisions (update existing knowledge db entries) --- TODO



## Keys (as in entry keys: the unique identifier for each piece of information, used in context prompt and as primary key in the knowledge base)

- Keys must follow the format nameN where name is a string (no numbers) and N is a number 
- Keys are created server-side (e.g. BachelorsThesis1, WorkExperience1)
- Keys are passed inside context data entries to the client
- If a key already exists, the key is increased by 1 (e.g. BachelorsThesis2)
- The key is stored as primary key in the knowledge base for easy retrieval and updating

Future: Use NLP to generate key names based on the content of the information


## 3. Revisions (as in the second step of the knowledge update process, after using Doc-LLM to identify new information)

Identified strong revisions ([x] if implemented):
- [ ] (always) Ask if refinement of person descriptions or ids is needed
- [ ] (if conflict trying to create a person) Either generate one unified person or change the id of one person and clarify the person description


## Testing

- Evaluator-LLM will check the response quality of the chat-LLM model.
- Several conversation scenarios will be defined prior to testing.

</context>