diff --git a/kuksa_databroker/doc/behavior.md b/kuksa_databroker/doc/behavior.md
new file mode 100644
index 00000000..bee5441f
--- /dev/null
+++ b/kuksa_databroker/doc/behavior.md
@@ -0,0 +1,4 @@
+# Runtime behavior and potential attacks
+The implementation of KUKSA databroker shall represent the latest value of a ```Datapoint```. Therefore the databroker always sets a ```timestamp``` for a ```Datapoint```. This means if a new value comes in it overwrites the older value. We opted for this behavior because a actuator/provider/application can have no access to a system time. For some use cases it could be interesting to provide a timestamp set by the actuator/provider/application. For this we added a so called source timestamp (short ```source_ts```) to the ```Datapoint``` class. This source timestamp is optional and per default set to None.
+
+If an attacker gets an authorized connection to the databroker he can set the source_timestamp and overwrite the value with a new one. But for this he/she needs read and write access through JWT tokens. If a provider decides to work with ```source_ts``` of a ```Datapoint``` than it should be clear that they can be false/outdated.
diff --git a/kuksa_databroker/doc/timestamp.md b/kuksa_databroker/doc/timestamp.md
deleted file mode 100644
index a8eed404..00000000
--- a/kuksa_databroker/doc/timestamp.md
+++ /dev/null
@@ -1,5 +0,0 @@
-# Databroker Timestamps
-The implementation of KUKSA databroker shall represent the latest value of a ```Datapoint```. Therefore it adds a ```timestamp``` to a ```Datapoint```. If an actuator/provider/application has no system time the databroker sets the ```timestamp``` to the current system time. For some use cases it can be interesting to provide a timestamp set by the actuator/provider/application. For this we added a so called source timestamp (short ```source_ts```) to a ```Datapoint```. This source timestamp is optional and per default set to None.
-
-# Potential attacks
-If an attacker gets an authorized connection to the databroker he can set the source_timestamp and overwrite the value with a new one. But for this he/she needs read and write access through JWT tokens. If a provider decides to work with ```source_ts``` of a ```Datapoint``` than it should be clear that they can be false/outdated.