diff --git a/flight-proposal.org b/flight-proposal.org
index 9800570..f43e749 100644
--- a/flight-proposal.org
+++ b/flight-proposal.org
@@ -133,3 +133,67 @@ is a high level function that encapsulates
 #+END_SRC
 Free the entire session created.
 
+* Render machine
+_Note: We do not talk about how the game_
+_itself is deployed here and we assume that
+the game is avaliable to execute._
+
+This node is incharge of computing the game
+in it's CPU and GPU. This layer does not
+distinguish if the game is running bare-metal
+or on a virtualised environment but rather
+focuses on game itself is rendered and
+is pass through the /user machine/. Xplane
+is called using the binary.
+locally on the machine and the instructions
+relating to which window it's running is
+_yet to be decided (This is considered a todo_).
+This section is split into 3 parts:
+- Streaming part
+- Keyboard and mouse passthrough
+- API layer
+    
+** Streaming part
+The flight sim session is streamed using
+WebRTC. We will initially hook a chromuim
+browser to detect the screen and over time
+reduce this to a simple screencapture
+native program to stream the video feed.
+
+_TODO: Specifics to be documented._
+
+** Keyboard and mouse passthrough
+We plan to maintain a open source fork
+of InputLeap. Input Leap is software that
+mimics the functionality of a KVM switch,
+which historically would allow you to use
+a single keyboard and mouse to control
+multiple computers by physically turning
+a dial on the box to switch the machine
+you're controlling at any given moment.
+Input Leap does this in software,
+allowing you to tell it which machine to
+control by moving your mouse to the edge
+of the screen, or by using a keypress to
+switch focus to a different system.
+
+_TODO: Diagramtic explaination of setup._
+
+** API layer
+We use the Xplane API REST server and UDP calls
+to transmit data back to the
+/Instructor machine/ for further analyses
+and controlling the flight scenarious.
+We will implement our own wrapper on
+top of the Xplane API to create standarised
+controls no matter the version of the flight
+sim and we can more fine system control
+such as new scenery files to pull.
+
+_TODO: Internal Xplane APIs to use, Extact routes_
+_and relation to transmitted to the instructor server._
+
+
+
+* Network of Scenery files
+Not documented until mid 2026.
diff --git a/flight-proposal.pdf b/flight-proposal.pdf
index 1c758a9..df02da2 100644
Binary files a/flight-proposal.pdf and b/flight-proposal.pdf differ
diff --git a/flight-proposal.tex b/flight-proposal.tex
index 21b8f93..cc516e7 100644
--- a/flight-proposal.tex
+++ b/flight-proposal.tex
@@ -1,4 +1,4 @@
-% Created 2025-10-08 Wed 11:52
+% Created 2025-10-08 Wed 16:48
 % Intended LaTeX compiler: pdflatex
 \documentclass[11pt]{article}
 \usepackage[utf8]{inputenc}
@@ -25,7 +25,7 @@
 \begin{document}
 
 \section{Xplane WebRTC}
-\label{sec:org0e3cbea}
+\label{sec:org21772c5}
 \begin{center}
 \includegraphics[width=.9\linewidth]{./xprc.drawio.png}
 \end{center}
@@ -76,7 +76,7 @@ approach and this open lot of areas of future research and hopefully better
 performant flight simulators with better purposed algorithm to offload tasks to
 devices such as FPGAs or potato machines in abstraction layer similar to speaking nodes in an network.
 \section{Architecture}
-\label{sec:orgb730ec5}
+\label{sec:org7fd7def}
 This chapter dives into the high architecture design of the
 project and each module is communicated in detail on the following
 section below.
@@ -86,7 +86,7 @@ section below.
 \caption{High level architecture of the entire project}
 \end{figure}
 \subsection{Game allocator}
-\label{sec:orgd67a679}
+\label{sec:orge51828f}
 The game allocator stores information about the game sessions. This consists of attributes
 such as:
 \begin{verbatim}
@@ -110,7 +110,7 @@ information. A session consists of multiple pilots training with a single
 instructor. Each pilot is assigned a node to render the game remotely
 and the instructor can set the scenarios to be trained on.
 \subsubsection{Interfaces}
-\label{sec:org380680a}
+\label{sec:org2d55851}
 We will now motivate the higher level interfaces to construct a \uline{game allocator}
 this term is inspired from the use of terms like \emph{malloc} and \emph{free} in userspace
 for allocating memory in a kernel. 
@@ -161,4 +161,69 @@ is a high level function that encapsulates
 FreeSession(Session)
 \end{verbatim}
 Free the entire session created.
+\section{Render machine}
+\label{sec:orgf386a0c}
+\uline{Note: We do not talk about how the game}
+\uline{itself is deployed here and we assume that
+the game is avaliable to execute.}
+
+This node is incharge of computing the game
+in it's CPU and GPU. This layer does not
+distinguish if the game is running bare-metal
+or on a virtualised environment but rather
+focuses on game itself is rendered and
+is pass through the \emph{user machine}. Xplane
+is called using the binary.
+locally on the machine and the instructions
+relating to which window it's running is
+\uline{yet to be decided (This is considered a todo}).
+This section is split into 3 parts:
+\begin{itemize}
+\item Streaming part
+\item Keyboard and mouse passthrough
+\item API layer
+\end{itemize}
+\subsection{Streaming part}
+\label{sec:org3e0d1c7}
+The flight sim session is streamed using
+WebRTC. We will initially hook a chromuim
+browser to detect the screen and over time
+reduce this to a simple screencapture
+native program to stream the video feed.
+
+\uline{TODO: Specifics to be documented.}
+\subsection{Keyboard and mouse passthrough}
+\label{sec:orgd4c9ff9}
+We plan to maintain a open source fork
+of InputLeap. Input Leap is software that
+mimics the functionality of a KVM switch,
+which historically would allow you to use
+a single keyboard and mouse to control
+multiple computers by physically turning
+a dial on the box to switch the machine
+you're controlling at any given moment.
+Input Leap does this in software,
+allowing you to tell it which machine to
+control by moving your mouse to the edge
+of the screen, or by using a keypress to
+switch focus to a different system.
+
+\uline{TODO: Diagramtic explaination of setup.}
+\subsection{API layer}
+\label{sec:org74f43ae}
+We use the Xplane API REST server and UDP calls
+to transmit data back to the
+\emph{Instructor machine} for further analyses
+and controlling the flight scenarious.
+We will implement our own wrapper on
+top of the Xplane API to create standarised
+controls no matter the version of the flight
+sim and we can more fine system control
+such as new scenery files to pull.
+
+\uline{TODO: Internal Xplane APIs to use, Extact routes}
+\uline{and relation to transmitted to the instructor server.}
+\section{Network of Scenery files}
+\label{sec:org5c40c9a}
+Not documented until mid 2026.
 \end{document}