diff --git a/AUDIT-CONCURRENCY.md b/AUDIT-CONCURRENCY.md
new file mode 100644
index 0000000..a00146f
--- /dev/null
+++ b/AUDIT-CONCURRENCY.md
@@ -0,0 +1,57 @@
+# Concurrency and Race Condition Audit
+
+## 1. Executive Summary
+
+The Poindexter library has a well-defined concurrency model. The core `KDTree` data structure is **not safe for concurrent modification**, and this is clearly documented. Developers using `KDTree` in a concurrent environment must provide their own external synchronization (e.g., `sync.RWMutex`).
+
+All other components, including `TreeAnalytics`, `PeerAnalytics`, and the DNS tools, are internally synchronized and safe for concurrent use. The WebAssembly (WASM) interface is effectively single-threaded and does not introduce concurrency issues.
+
+The project's test suite includes a `make race` target, which passed successfully, indicating that the existing tested code paths are free of race conditions.
+
+## 2. Race Detector Analysis
+
+The command `make race` was executed to run the full test suite with the Go race detector enabled.
+
+**Result:**
+```
+ok      github.com/Snider/Poindexter    1.047s
+ok      github.com/Snider/Poindexter/examples/dht_helpers       1.022s
+ok      github.com/Snider/Poindexter/examples/dht_ping_1d       1.022s
+ok      github.com/Snider/Poindexter/examples/kdtree_2d_ping_hop        1.021s
+ok      github.com/Snider/Poindexter/examples/kdtree_3d_ping_hop_geo    1.022s
+ok      github.com/Snider/Poindexter/examples/kdtree_4d_ping_hop_geo_score      1.024s
+```
+**Conclusion:** All tests passed successfully, and the race detector found no race conditions in the code covered by the tests.
+
+## 3. Focus Area Analysis
+
+### 3.1. Goroutine safety in math operations
+
+- **`KDTree`:** The documentation explicitly states: `Concurrency: KDTree is not safe for concurrent mutation. Guard with a mutex or share immutable snapshots for read-mostly workloads.` This is a critical and accurate statement. Any attempt to call `Insert` or `DeleteByID` concurrently with other read or write operations will result in a race condition.
+- **`TreeAnalytics`:** This component is **goroutine-safe**. It correctly uses types from the `sync/atomic` package (`atomic.Int64`, `atomic.Uint64`) to safely increment counters and update statistics from multiple goroutines without locks.
+- **`PeerAnalytics`:** This component is **goroutine-safe**. It uses a `sync.RWMutex` to protect access to its internal maps (`hitCounts`, `distanceSums`, `lastSelected`). The `RecordSelection` method uses a double-checked locking pattern, which is implemented correctly to minimize lock contention while safely initializing stats for new peers. Read operations like `GetPeerStats` use a read lock (`RLock`), allowing for concurrent reads.
+- **`dns_tools.go`:** The functions in this file are **goroutine-safe**. They are stateless and rely on the standard library's `net.Resolver`, which is safe for concurrent use.
+
+### 3.2. Channel usage patterns
+
+The codebase does not use channels for its core logic. Therefore, there are no channel-related concurrency patterns to audit.
+
+### 3.3. Mutex/RWMutex usage
+
+The only mutex in the audited code is the `sync.RWMutex` within `PeerAnalytics`.
+
+- **`PeerAnalytics`:** The usage is correct. A read lock is used for read-only operations (`GetAllPeerStats`, `GetPeerStats`), and a full lock is used only for the short duration of initializing a new peer's metrics. This is an effective and safe use of `RWMutex`.
+
+### 3.4. Context cancellation handling
+
+- **`dns_tools.go`:** The `DNSLookupWithTimeout` and `DNSLookupAllWithTimeout` functions correctly use `context.WithTimeout` to create a context that is passed to the network calls (`resolver.Lookup...`). This ensures that DNS queries do not block indefinitely and can be safely cancelled if they exceed the specified timeout. This is a proper and robust implementation of context handling.
+
+### 3.5. WebAssembly (WASM) Interface
+
+- **`wasm/main.go`:** The WASM module exposes functions to a JavaScript environment. The JavaScript event loop is single-threaded, meaning that calls into the WASM module from JS will be serial. The Go code in `wasm/main.go` does not spawn any new goroutines. The `treeRegistry` is a global map, but because all access to it is driven by the single-threaded JS environment, there is no risk of concurrent map access. The WASM boundary, in this case, does not introduce concurrency risks.
+
+## 4. Recommendations
+
+1.  **`KDTree` Synchronization:** End-users of the library must be reminded that `KDTree` instances are not thread-safe. When sharing a `KDTree` between goroutines, any methods that modify the tree (`Insert`, `DeleteByID`) must be protected by a mutex. For read-heavy workloads, it is safe to share an immutable `KDTree` across multiple goroutines without a lock.
+2.  **Documentation:** The existing documentation comment on `KDTree` is excellent. This warning should be maintained and highlighted in user-facing documentation.
+3.  **No Changes Required:** The existing concurrency controls in `TreeAnalytics` and `PeerAnalytics` are robust and do not require changes. The use of context in the DNS tools is also correct. No vulnerabilities were found.