diff --git a/.work_note2.swp b/.work_note2.swp
deleted file mode 100644
index 3997cb3..0000000
Binary files a/.work_note2.swp and /dev/null differ
diff --git a/CLAUDE.md b/CLAUDE.md
index 9bedb2a..c4116b9 100644
--- a/CLAUDE.md
+++ b/CLAUDE.md
@@ -1148,6 +1148,7 @@ dynamicReflectivity = std::max(0.0f, std::min(1.0f, dynamicReflectivity));
 
 // Pass 'dynamicReflectivity' to your GLSL shader uniform array
 glUniform1f(glGetUniformLocation(shaderProgram, "targetReflectivity[i]"), dynamicReflectivity);
+but is not written to the database. It is to be passed to the shaders as a uniform.
 
 
 The segment handling asynchronous target ingestion is called traffic_cop.
@@ -1172,13 +1173,13 @@ Data synchronization between threads must be managed explicitly using std::mutex
    and the marine traffic control radars. It will already have the longitude and latitude of the
    police boat radar as it will be processing the location of the police boat radar from the
    simulator.
-8. Instructions regarding chain home. If the current active radar is chain home, we
+7. Instructions regarding chain home. If the current active radar is chain home, we
    need to drop all boat target and any target that is not within 300 miles from the
    latitude and longitude of the chain home radar station. Furthermore all traffic from the
    raspberry PI's need to be discarded for chain home. All chain home target traffic will be
    beyond range for all of the other radars; therefore all such targets shall be discarded if
    the active radar is not chain home.
-7. Critical Section: Assert a std::mutex to gain safe writing access to the 
+8. Critical Section: Assert a std::mutex to gain safe writing access to the 
    double-buffered array driving the SSBO, copy the structural contents, and 
    clear the mutex immediately. May I suggest that this activity be performed 
    about once every screen update. However, the processing speed may not be
@@ -1188,6 +1189,29 @@ Data synchronization between threads must be managed explicitly using std::mutex
    will be 200. Oldest targets shall not be sent to the SSBO if the limit is reached.
    Lets include the maximum in memory copy of the database and SSBO should be
    a value in the settings.h file.
+9. The traffic cop does need to check the variable that had which radar is active.
+   This can be accomplished by seting an additionall mutex strictly for reading the
+   active radar variable from thread 1.
+10. If the timestamp in the database is over 1 hour from the current time, then
+    the target shall be skipped.
+11. If police_boat == 1, then use uniforms to pass heading and location. Do not pass target data as the
+    police boat does not see itself. If police_boat == 0, then treat the police boat as any other target.
+
+Here is the database workflow.
+
+1. Receive target from simulator or raspberry pis
+2. Is target in the memmory copy of the database
+3. Yes - then update the timestamp
+4. If not in memory, the try to pull from the database
+4a. If memory is already full, then delete record with oldest timestamp.
+4b. The do the pull from the database.
+5. If pulled from database, then update the timestamp.
+6. If it cannot be pulled from the database, then enter
+   net target into the database and memory copy. Then do
+   the calculations for RadarMaterialProfile, then pull
+   in other non vilitile target data (size, beam, etc)
+
+
 
 
 ===============================================================