diff --git a/README.md b/README.md
index 5268290..24e9282 100644
--- a/README.md
+++ b/README.md
@@ -53,4 +53,326 @@ Make sure that **ffmpeg** is installed on your system, as it may be required for
---
-**Installation complete!** You're now ready to use Video2Document.
\ No newline at end of file
+**Installation complete!** You're now ready to use Video2Document.
+
+###General Despription
+## Project Overview
+
+V2D (Video to Document Framework) is a student project developed to convert video and audio content into structured, readable documents using AI-based text processing. The tool is designed to help users automatically generate documents such as meeting reports, summaries or structured texts from recorded videos or audio files.
+
+The main problem V2D addresses is the time-consuming manual effort required to listen to recordings and write documents afterwards. By automating transcription, structuring and document generation, the tool improves efficiency and usability for students, teams and small organizations.
+
+The project was created as part of a university software engineering course and is developed using agile methods (Scrum). It focuses on modular design, usability and extensibility, allowing new document types and features to be added easily.
+
+### Used Packages and Dependencies
+
+This project uses several Node.js packages to handle video processing, AI-based document generation, backend communication, and the desktop user interface. Below is an overview of the most important dependencies and their purpose.
+
+##Core Dependencies:
+
+Electron:
+Used to build the desktop application. It allows the project to run as a cross-platform GUI application using web technologies.
+
+Express:
+Acts as a lightweight backend server that handles internal API requests and communication between different parts of the application.
+
+Axios:
+Used for making HTTP requests, for example when communicating with external APIs such as AI services.
+
+dotenv:
+Used to securely load API keys and other sensitive configuration values from environment variables instead of hardcoding them in the source code.
+
+@google/genai:
+Provides access to Google’s Generative AI models. This package is used to generate structured documents from transcribed text based on configurable prompts.
+
+ffmpeg-static:
+Provides a static FFmpeg binary so that video and audio processing works without requiring FFmpeg to be installed separately on the system.
+
+fluent-ffmpeg:
+Used together with FFmpeg to process video and audio files, for example extracting audio tracks from uploaded videos.
+
+puppeteer:
+Used to render and process HTML content programmatically. This is helpful for document previews and automated content generation.
+
+html-to-docx:
+Converts generated HTML documents into downloadable DOCX files, which are provided to the user as the final output.
+
+mocha:
+A testing framework used to run unit tests and ensure that core functionalities work as expected.
+
+##Development Dependencies:
+
+TypeScript:
+Used to add static typing to the project, improving code quality, readability, and maintainability.
+
+ts-node:
+Allows running TypeScript files directly without manually compiling them first.
+
+@types/node:
+Provides TypeScript type definitions for Node.js APIs.
+
+@types/fluent-ffmpeg:
+Type definitions for fluent-ffmpeg to improve development experience and error checking.
+
+@types/cli-progress:
+Provides type support for progress bar functionality used during processing tasks.
+
+###Why These Packages Are Needed
+
+Together, these packages enable:
+
+*Processing video and audio files
+
+*Communicating with AI models for document generation
+
+*Secure handling of API keys
+
+*Generating structured documents (DOCX)
+
+*Providing a user-friendly desktop interface
+
+*Ensuring code quality through testing
+
+###API Keys and Configuration
+
+The V2D – Video to Document tool uses external AI and media processing services to convert video and audio content into structured documents.
+To access these services, several API keys are required. For security reasons, API keys are not stored in the repository and must be provided via environment variables.
+
+ ##Supported API Keys
+
+The project currently supports the following API keys. Depending on the configuration and selected provider, one or more of these keys may be used.
+
+Google Gemini API
+
+Environment variable: GOOGLE_API_KEY
+
+Usage:
+Used for AI-based document generation. The Large Language Model processes transcripts and creates structured documents such as meeting reports.
+
+OpenAI (ChatGPT)
+
+Environment variable: OPENAI_API_KEY
+
+Usage:
+Alternative AI provider for text processing and document generation.
+
+AssemblyAI
+
+Environment variable: ASSEMBLYAI_API_KEY
+
+Usage:
+Speech-to-text processing for audio and video files.
+
+Saya
+
+Environment variable: SAYA_API_KEY
+
+Usage:
+Additional or experimental AI provider that can be integrated into the document generation pipeline.
+
+##How to Set API Keys
+
+API keys must be configured as environment variables before starting the application.
+
+Linux / macOS
+export GOOGLE_API_KEY="your_api_key_here"
+export OPENAI_API_KEY="your_api_key_here"
+export ASSEMBLYAI_API_KEY="your_api_key_here"
+export SAYA_API_KEY="your_api_key_here"
+
+Windows (PowerShell)
+setx GOOGLE_API_KEY "your_api_key_here"
+setx OPENAI_API_KEY "your_api_key_here"
+setx ASSEMBLYAI_API_KEY "your_api_key_here"
+setx SAYA_API_KEY "your_api_key_here"
+
+
+Alternatively, for local development, a .env file can be used:
+
+GOOGLE_API_KEY=your_api_key_here
+OPENAI_API_KEY=your_api_key_here
+ASSEMBLYAI_API_KEY=your_api_key_here
+SAYA_API_KEY=your_api_key_here
+
+
+⚠️ Important:
+The .env file must not be committed to the repository and should be listed in .gitignore.
+
+Security Notes:
+
+*API keys are injected at runtime
+
+*No secrets are stored in the source code
+
+*Prevents accidental exposure of sensitive data
+
+*Supports secure collaboration in GitLab and CI/CD environments
+
+*Follows best practices for secret management
+
+
+
+###End-to-End User Guide (Video → Final Document)
+
+This section describes how a user can create a structured document from a video using the V2D – Video to Document tool.
+
+Start the Application:
+
+Ensure all required API keys are configured as environment variables.
+
+
+Install dependencies:
+
+npm install
+
+
+Start the application:
+
+npm start
+
+
+The Electron-based GUI will open.
+
+#Upload a Video File:
+
+In the application interface, select Upload Video.
+
+Choose a supported video file (e.g. .mp4, .mov).
+
+The video is loaded into the system for processing.
+
+
+
+#Audio Extraction:
+
+The application automatically extracts audio from the uploaded video.
+
+This is handled internally using FFmpeg.
+
+No user interaction is required for this step.
+
+
+#Speech-to-Text Transcription:
+
+The extracted audio is sent to the speech-to-text service.
+
+The transcription process converts spoken content into text.
+
+The generated transcript is stored internally and used for further processing.
+
+
+#Select Document Type:
+
+The user selects a document type (e.g. Meeting Report).
+
+Each document type is based on a predefined prompt template.
+
+The selected template defines the structure and style of the final document.
+
+
+#Document Generation:
+
+The transcript and selected prompt are sent to the AI service.
+
+The AI model processes the input and generates a structured document.
+
+The output is formatted in Markdown.
+
+
+#Document Preview:
+
+The generated document is displayed in the application preview.
+
+Users can review the content before exporting.
+
+No manual editing is required, but validation is possible.
+
+
+#Export the Final Document:
+
+The user exports the document in the desired format.
+
+
+#Supported formats include:
+
+Markdown (.md)
+
+Word (.docx)
+
+The document is saved locally.
+
+
+#Completion:
+
+The final document is now ready for use.
+
+The user can repeat the process with another video if needed.
+
+
+###Resources
+
+This section lists the main technologies, libraries, and external resources used in the V2D (Video to Document) project. These resources are required to understand, run, and further develop the application.
+
+##Project Dependencies
+
+The following packages and tools are used in this project (as defined in package.json):
+
+Application & Backend
+
+Node.js – JavaScript runtime environment used for backend processing
+
+Electron – Framework for building the desktop application
+
+Express – Backend web framework for handling requests and internal APIs
+
+AI & API Communication
+
+@google/genai – Used for AI-based document generation
+
+Axios – HTTP client for communicating with external APIs (LLMs)
+
+Video & Audio Processing
+
+ffmpeg-static – Extracts audio from uploaded video files
+
+fluent-ffmpeg – Controls FFmpeg operations programmatically
+
+Document Generation & Preview
+
+html-to-docx – Converts structured content into Word documents
+
+Puppeteer – Renders HTML content for document preview and processing
+
+Configuration & Security
+
+dotenv – Loads API keys securely from environment variables
+
+Testing & Development
+
+Mocha – Unit testing framework
+
+TypeScript – Improves code quality and type safety
+
+These dependencies enable the complete end-to-end workflow from video input to structured document output.
+
+
+##Relevant Repositories
+
+V2D Main Repository:
+https://gitlab.rlp.net/proj-wise2526-video2document/video2document
+
+This repository contains the full source code, configuration files, and documentation for the V2D project.
+
+Downloads & External Resources
+
+The following tools and documentation may be required to run or understand the project:
+
+Node.js: https://nodejs.org
+
+Electron Documentation: https://www.electronjs.org/docs
+
+FFmpeg: https://ffmpeg.org
+
+Google Generative AI: https://ai.google.dev
+
+Puppeteer: https://pptr.dev
\ No newline at end of file
diff --git a/documentation.md b/documentation.md
new file mode 100644
index 0000000..eaf64b5
--- /dev/null
+++ b/documentation.md
@@ -0,0 +1,116 @@
+# Documenation of our Program
+
+## Table of Contents
+1. [How to run the Software](#how-to-run-the-software)
+2. [How it works](#how-it-works)
+3. [Modules](#modules)
+3. [IPC](#ipc)
+
+## How to run the Software
+If you read the readme file, you will see the basic setup command in order to run the program.
+You will need nodejs, the newer the better.
+The software is tested with `nodejs-19`, `nodejs-20`, `nodejs-22` and `nodejs-24`.
+These versions are confirmed to work with our software, but prior versions may work aswell.
+To get nodejs, simply go to their [website](https://nodejs.org/en/download) and download whatever version you want and install it.
+Afterward go into the directory of our program, and run the command `npm i`, this will install all the necessary libraries.
+Next up you need to set up the .env file.
+The file must contain your keys for the modules you want to use.
+The .env file looks like this:
+```
+ASSEMBLYAI_API_KEY=wefhjhjakeghjkahejkghjkaegh
+GOOGLE_API_KEY=wefhjhjakeghjkahejkghjkaegh
+SAIA_API_KEY=wefhjhjakeghjkahejkghjkaegh
+```
+Note that if you write your module in the same format we did, then you will only need to supply the api keys to the individual services you will actually use.
+If you dont want to use Assembly AI, you can for example just leave this row out of your .env, and the program will just work fine.
+Only issue will be that it will throw an error if you do run the Assembly AI module anyways.
+Once that is done, you can run the command `npm start` to actually start the program.
+Alternatively you can double click the start.bat if you are on Windows for example.
+
+## How it works
+Our software is fully modular, this means, every part can easily be edited, replaced, removed or added without needing to make many adjustments in the code.
+The modules can be found under `./services/modules`
+The Structure is as follows:
+Inside of `modules` are folders named after the general thing the module does.
+For example, `transcription-remote`, this folder contains all the modules that do transcription on a remote service, such as assembly-ai for example.
+Inside of these folders we put our modules.
+The name of the folder and the module dont matter, as long as the structure is kept, and the module filename ends with .js, it will work.
+The program iterates through all of the folders within `./services/modules`, and then iterates over each `.js` file within each of these folders, and then loads them into a specific map called `mapFunctions`.
+This map is available ANYWHERE in the backend code, even within a module, which means, you can call a module, from within a module, from within a module, from within yet another module.
+
+## Modules
+Building a new module is super easy, any idiot can get it done.
+All you need to do is follow the previously mentioned structure.
+When you have created your module file, the `.js` file, you simply copy paste this code snippet into it.
+```js
+module.exports = {
+ name:"example", // Unique name for our function that will later be used to get the function from the map via "mapFunctions.get("example").function()"
+ type:"example-type", // value used to differentiate each module to order them in the UI
+ displayname:"Example", // The displayname used within the UI
+ async function(randomParameter){
+ // Here we put a simple console.log to show how the system works
+ // This function will be called from the @startup.js function in the utility folder
+ console.log(`\n------------\nThis is the example function called by the ${randomParameter} function\n------------\n`);
+ }
+}
+```
+If by this point, you cared enough to actually look at the code and the modules and so on, you might have spotted a file in `./services/modules/utility` called `example.js`.
+This is a template file that you can just copy paste and use as a base for your new module.
+It has the same exact code as mentioned right above.
+Now as for how the code works.
+Each module is essentially just a JSON object that is being exported, so that the main process can load it into the `mapFunctions` map.
+the required fields are as follows
+- name: This field contains the internal name through which it will be called. It HAS TO BE unique.
+- type: This field contains the type of the module. Is it an LLM module, transcription module, or whatever.
+- displayname: This field contains the Displayname used in the UI.
+
+And lastly the function call.
+This function call is what is being called by other functions, it is generally the main entrypoint for a module.
+Sure, you can always set custom function names, but this is a general solution that works without having to manage function names.
+You can always define custom functions inside your module that you call from the entrypoint function, but it is highly advised just to call the entrypoint function from outside of the module as it prevents headaches by just working as intended.
+
+Note, there are also other module fields for specific module types, such as:
+- description: Used by any module that needs to be shown on the UI, such as Transcription and LLM modules.
+- audioformat: Used by transcription modules to tell the audio extraction module what audio format to use.
+
+## IPC
+Our software is split up into 2 pieces, the main process (Backend) and the frontend.
+The frontend is written in Electron, so it is essentially just a website.
+This makes it relatively easy to edit the frontend.
+But it comes with one downside, which is, the frontend and backend cant just directly communicate, you first need to set up an IPC channel between them.
+As for the base functionality, all of this is already done.
+The frontend gets a list of all the available LLM and Transcription modules sent by the backend on startup.
+The JSON object for this information looks like this:
+```json
+{
+ "ai_modules":[
+ {"name": "Example", "displayname": "Example"}
+ ],
+ "transcription_modules":[
+ {"name": "Example", "displayname": "Example"}
+ ]
+}
+```
+The backend needs a specific set of informations from the frontend in order to start the pipeline.
+The JSON for that looks like this:
+```json
+{
+ "video": {
+ "module": "extraction-video-to-audio",
+ "inputVideoPath": "A:\\programing\\@projects\\video2document\\test\\unit\\testvideo.mp4"
+ },
+ "transcription": {
+ "module": "assembly"
+ },
+ "document": {
+ "module": "llm-saia_openai_gpt",
+ "type": "followup-report",
+ "outputType": "pdf"
+ }
+}
+```
+As you can see in this JSON object, each part specifies which module is being used for each step.
+The module names are each the name field specified in the module itself.
+As for the rest of the fields, they are pretty self explanatory except `document.type`, that is a predefined report type.
+This is the minimum required setup for the currently implemented pipeline to work.
+You can always add fields to it, but dont remove the ones from above.
diff --git a/electron/main/custom_document.html b/electron/main/custom_document.html
index a12b429..e6e79a8 100644
--- a/electron/main/custom_document.html
+++ b/electron/main/custom_document.html
@@ -1,210 +1,17 @@
+
Custom Document
+
-