TOoSmOotH · Sep 8, 2026 · Aug 20, 2026 · Aug 24, 2026 · Aug 25, 2026 · Sep 3, 2026
diff --git a/docs/elasticsearch.md b/docs/elasticsearch.md
@@ -65,7 +65,7 @@ You can configure Elasticsearch by going to [Administration](administration.md)
 
 ## Parsing
 
-Elasticsearch receives unparsed logs from [Logstash](logstash.md) or [Elastic Agent](elastic-agent.md). Elasticsearch then parses and stores those logs. Parsers are stored in `/opt/so/conf/elasticsearch/ingest/`. Custom ingest parsers can be placed in `/opt/so/saltstack/local/salt/elasticsearch/files/ingest/`. Files placed here are not detected by [Auto State Apply](salt.md#auto-state-apply), so to make these changes take effect, apply the Elasticsearch state to all nodes running Elasticsearch:
+Elasticsearch receives unparsed logs from [Logstash](logstash.md) or [Elastic Agent](elastic-agent.md). Elasticsearch then parses and stores those logs. Parsers are stored in `/opt/so/conf/elasticsearch/ingest/`. Custom ingest parsers can be placed in `/opt/so/saltstack/local/salt/elasticsearch/files/ingest/`. [Auto State Apply](salt.md#auto-state-apply) picks these up within a few minutes. If you don't want to wait, apply the Elasticsearch state to all nodes running Elasticsearch:
 
 
 ```

diff --git a/docs/images/01_grub.png b/docs/images/01_grub.png
diff --git a/docs/images/02_initial_install.png b/docs/images/02_initial_install.png
diff --git a/docs/images/04_setup_init.png b/docs/images/04_setup_init.png
diff --git a/docs/images/05_setup_option.png b/docs/images/05_setup_option.png
diff --git a/docs/images/06_setup_airgap.png b/docs/images/06_setup_airgap.png
diff --git a/docs/images/06_setup_type.png b/docs/images/06_setup_type.png
diff --git a/docs/images/07_setup_license.png b/docs/images/07_setup_license.png
diff --git a/docs/images/08_setup_hostname.png b/docs/images/08_setup_hostname.png
diff --git a/docs/images/09_setup_hostname_conflict.png b/docs/images/09_setup_hostname_conflict.png
diff --git a/docs/images/10_setup_mn_nic.png b/docs/images/10_setup_mn_nic.png
diff --git a/docs/images/11_setup_mn_int.png b/docs/images/11_setup_mn_int.png
diff --git a/docs/images/12_setup_cidr.png b/docs/images/12_setup_cidr.png
diff --git a/docs/images/13_setup_gateway.png b/docs/images/13_setup_gateway.png
diff --git a/docs/images/14_setup_dns_servers.png b/docs/images/14_setup_dns_servers.png
diff --git a/docs/images/15_setup_dns_domain.png b/docs/images/15_setup_dns_domain.png
diff --git a/docs/images/16_setup_docker_range.png b/docs/images/16_setup_docker_range.png
diff --git a/docs/images/18_setup_direct_proxy.png b/docs/images/18_setup_direct_proxy.png
diff --git a/docs/images/20_setup_webuser.png b/docs/images/20_setup_webuser.png
diff --git a/docs/images/21_setup_webpass1.png b/docs/images/21_setup_webpass1.png
diff --git a/docs/images/22_setup_webpass2.png b/docs/images/22_setup_webpass2.png
diff --git a/docs/images/23_setup_access_type.png b/docs/images/23_setup_access_type.png
diff --git a/docs/images/26_setup_so_allow.png b/docs/images/26_setup_so_allow.png
diff --git a/docs/images/27_setup_so_allow_input.png b/docs/images/27_setup_so_allow_input.png
diff --git a/docs/images/27_telemetry.png b/docs/images/27_telemetry.png
diff --git a/docs/images/28_setup_summary.png b/docs/images/28_setup_summary.png
diff --git a/docs/images/29_setup_finished.png b/docs/images/29_setup_finished.png
diff --git a/docs/images/38_overview.png b/docs/images/38_overview.png
diff --git a/docs/images/39_grid.png b/docs/images/39_grid.png
diff --git a/docs/images/40_upload.png b/docs/images/40_upload.png
diff --git a/docs/images/45_import.png b/docs/images/45_import.png
diff --git a/docs/images/50_alerts.png b/docs/images/50_alerts.png
diff --git a/docs/images/51_alerts_play.png b/docs/images/51_alerts_play.png
diff --git a/docs/images/52_alerts_options.png b/docs/images/52_alerts_options.png
diff --git a/docs/images/53_dashboards.png b/docs/images/53_dashboards.png
diff --git a/docs/images/54_dashboards_options.png b/docs/images/54_dashboards_options.png
diff --git a/docs/images/56_hunt.png b/docs/images/56_hunt.png
diff --git a/docs/images/57_0_cases.png b/docs/images/57_0_cases.png
diff --git a/docs/images/57_1_cases_options.png b/docs/images/57_1_cases_options.png
diff --git a/docs/images/57_2_cases_create.png b/docs/images/57_2_cases_create.png
diff --git a/docs/images/57_detections.png b/docs/images/57_detections.png
diff --git a/docs/images/58_detections_options.png b/docs/images/58_detections_options.png
diff --git a/docs/images/59_detection_create.png b/docs/images/59_detection_create.png
diff --git a/docs/images/60_detection_nids.png b/docs/images/60_detection_nids.png
diff --git a/docs/images/60_detection_nids_0_comments.png b/docs/images/60_detection_nids_0_comments.png
diff --git a/docs/images/60_detection_nids_1_signature.png b/docs/images/60_detection_nids_1_signature.png
diff --git a/docs/images/60_detection_nids_2_tuning_1.png b/docs/images/60_detection_nids_2_tuning_1.png
diff --git a/docs/images/60_detection_nids_2_tuning_2_add.png b/docs/images/60_detection_nids_2_tuning_2_add.png
diff --git a/docs/images/60_detection_nids_3_playbook.png b/docs/images/60_detection_nids_3_playbook.png
diff --git a/docs/images/60_detection_nids_4_history.png b/docs/images/60_detection_nids_4_history.png
diff --git a/docs/images/60_detection_sigma.png b/docs/images/60_detection_sigma.png
diff --git a/docs/images/60_detection_sigma_2_tuning_1.png b/docs/images/60_detection_sigma_2_tuning_1.png
diff --git a/docs/images/60_detection_sigma_2_tuning_2_add.png b/docs/images/60_detection_sigma_2_tuning_2_add.png
diff --git a/docs/images/60_detection_yara.png b/docs/images/60_detection_yara.png
diff --git a/docs/images/61_actions.png b/docs/images/61_actions.png
diff --git a/docs/images/62_pcap.png b/docs/images/62_pcap.png
diff --git a/docs/images/65_pcap_details.png b/docs/images/65_pcap_details.png
diff --git a/docs/images/72_jobs.png b/docs/images/72_jobs.png
diff --git a/docs/images/73_jobs_add.png b/docs/images/73_jobs_add.png
diff --git a/docs/images/75_grid.png b/docs/images/75_grid.png
diff --git a/docs/images/76_grid_options.png b/docs/images/76_grid_options.png
diff --git a/docs/images/78_downloads.png b/docs/images/78_downloads.png
diff --git a/docs/images/81_users.png b/docs/images/81_users.png
diff --git a/docs/images/82_users_detail.png b/docs/images/82_users_detail.png
diff --git a/docs/images/83_users_add.png b/docs/images/83_users_add.png
diff --git a/docs/images/84_gridmembers.png b/docs/images/84_gridmembers.png
diff --git a/docs/images/87_config.png b/docs/images/87_config.png
diff --git a/docs/images/88_config_options.png b/docs/images/88_config_options.png
diff --git a/docs/images/91_licensekey.png b/docs/images/91_licensekey.png
diff --git a/docs/images/94_usermenu.png b/docs/images/94_usermenu.png
diff --git a/docs/images/config-item-backup.png b/docs/images/config-item-backup.png
diff --git a/docs/images/config-item-bpf.png b/docs/images/config-item-bpf.png
diff --git a/docs/images/config-item-elastalert-alerter.png b/docs/images/config-item-elastalert-alerter.png
diff --git a/docs/images/config-item-elastalert.png b/docs/images/config-item-elastalert.png
diff --git a/docs/images/config-item-elasticfleet.png b/docs/images/config-item-elasticfleet.png
diff --git a/docs/images/config-item-elasticsearch.png b/docs/images/config-item-elasticsearch.png
diff --git a/docs/images/config-item-firewall.png b/docs/images/config-item-firewall.png
diff --git a/docs/images/config-item-global-url.png b/docs/images/config-item-global-url.png
diff --git a/docs/images/config-item-global.png b/docs/images/config-item-global.png
diff --git a/docs/images/config-item-host.png b/docs/images/config-item-host.png
diff --git a/docs/images/config-item-idh.png b/docs/images/config-item-idh.png
diff --git a/docs/images/config-item-influxdb.png b/docs/images/config-item-influxdb.png
diff --git a/docs/images/config-item-kafka.png b/docs/images/config-item-kafka.png
diff --git a/docs/images/config-item-kibana.png b/docs/images/config-item-kibana.png
diff --git a/docs/images/config-item-kratos.png b/docs/images/config-item-kratos.png
diff --git a/docs/images/config-item-logstash.png b/docs/images/config-item-logstash.png
diff --git a/docs/images/config-item-manager.png b/docs/images/config-item-manager.png
diff --git a/docs/images/config-item-nginx.png b/docs/images/config-item-nginx.png
diff --git a/docs/images/config-item-ntp.png b/docs/images/config-item-ntp.png
diff --git a/docs/images/config-item-patch.png b/docs/images/config-item-patch.png
diff --git a/docs/images/config-item-redis.png b/docs/images/config-item-redis.png
diff --git a/docs/images/config-item-sensor.png b/docs/images/config-item-sensor.png
diff --git a/docs/images/config-item-sensoroni.png b/docs/images/config-item-sensoroni.png
diff --git a/docs/images/config-item-soc-additionalAlerters.png b/docs/images/config-item-soc-additionalAlerters.png
diff --git a/docs/images/config-item-soc-subgrids.png b/docs/images/config-item-soc-subgrids.png
diff --git a/docs/images/config-item-soc.png b/docs/images/config-item-soc.png
diff --git a/docs/images/config-item-strelka.png b/docs/images/config-item-strelka.png
diff --git a/docs/images/config-item-suricata.png b/docs/images/config-item-suricata.png
diff --git a/docs/images/config-item-telegraf.png b/docs/images/config-item-telegraf.png
diff --git a/docs/images/config-item-versionlock.png b/docs/images/config-item-versionlock.png
diff --git a/docs/images/config-item-zeek.png b/docs/images/config-item-zeek.png
diff --git a/docs/kernels.md b/docs/kernels.md
@@ -0,0 +1,39 @@
+# Kernels
+
+Security Onion standardizes on the Oracle Unbreakable Enterprise Kernel (UEK). Nodes run the UEK8 (6.x) kernel series, and the standard EL9 RedHat compatible kernel (RHCK, 5.14) is removed once a node is actually running UEK8.
+
+This is all automatic and you should not need to do anything. Nodes pick up the UEK8 kernel as part of their normal OS updates, and the stock EL9 kernel is removed for you on the next highstate after the node reboots onto UEK8.
+
+The removal is deliberately deferred until after the reboot. `dnf` refuses to erase the running kernel, and waiting also means the node has proven it boots on UEK8 before its fallback is deleted. Fresh installs reboot at the end of setup and are cleaned up on the first highstate after that; existing nodes are cleaned up whenever you reboot them.
+
+These are the packages removed:
+
+```
+kernel kernel-core kernel-modules kernel-modules-core kernel-tools kernel-tools-libs
+```
+
+!!! NOTE
+
+    Older UEK7 `kernel-uek` 5.x packages are not removed. They age out on their own as newer kernels are installed.
+
+## Doing It Manually
+
+If a node did not end up on UEK8 on its own, you can run the following command on that node:
+
+```
+sudo so-kernel-upgrade
+```
+
+This installs the UEK8 kernel and makes it the boot default. It does not reboot the node, so you can schedule the reboot yourself. The new kernel does not take effect until you reboot.
+
+!!! NOTE
+
+    The manager mirrors the UEK8 packages and serves them to the rest of the grid. If the manager has not synced them yet, `so-kernel-upgrade` on the manager will sync them for you; on any other node it will tell you to sync the manager first.
+
+Similarly, if the stock EL9 kernel is still installed on a node that is already running UEK8, you can run the cleanup directly instead of waiting for the next highstate:
+
+```
+sudo so-kernel-upgrade --cleanup
+```
+
+This does nothing unless the node is already running UEK8.
diff --git a/docs/local-llm.md b/docs/local-llm.md
diff --git a/docs/logstash.md b/docs/logstash.md
@@ -71,7 +71,7 @@ In [SOC](security-onion-console.md), navigate to [Administration](administration
 custom/myfile.conf
 ```
 
-The configuration will be applied at the next scheduled highstate (see [Highstate Interval](salt.md#highstate-interval)) or you can apply it immediately by clicking the `SYNCHRONIZE GRID` button under the `Options` menu.
+[Auto State Apply](salt.md#auto-state-apply) will apply the configuration within a few minutes. If you don't want to wait, click the `SYNCHRONIZE GRID` button under the `Options` menu.
 
 You can monitor events flowing through the output by running the following command on the manager:
 
@@ -82,7 +82,7 @@ curl -s localhost:9600/_node/stats | jq .pipelines.manager
 
 ## Modified Event Forwarding
 
-To forward events to an external destination AFTER they have traversed the Logstash pipelines (NOT ingest node pipelines), perform the same steps as above but instead of adding the reference for your Logstash output to the `manager` pipeline add it to `search` pipeline instead. The configuration will be applied at the next scheduled highstate (see [Highstate Interval](salt.md#highstate-interval)) or immediately by clicking the `SYNCHRONIZE GRID` button under the `Options` menu.
+To forward events to an external destination AFTER they have traversed the Logstash pipelines (NOT ingest node pipelines), perform the same steps as above but instead of adding the reference for your Logstash output to the `manager` pipeline add it to `search` pipeline instead. [Auto State Apply](salt.md#auto-state-apply) will apply the configuration within a few minutes. If you don't want to wait, click the `SYNCHRONIZE GRID` button under the `Options` menu.
 
 You can monitor events flowing through the output by running the following command on the search nodes:
 

diff --git a/docs/manager-of-managers.md b/docs/manager-of-managers.md
@@ -55,7 +55,7 @@ While on the API Client screen, click the ⤓ icon to download the Certificate A
 
 !!! NOTE
 
-    Please be aware that any users in the MoM Grid will be able to connect to the subgrid using the permissions defined for the API client. For example, suppose that you create an API client ID in the subgrid called `supermom` and you grant it all permissions. Once the MoM is configured to connect to the subgrid as shown in the next section, then any users in the MoM Grid will connect to the subgrid as `supermom` and have all permissions to the subgrid regardless of whether the user has equivalent permissions in the MoM.
+    Starting in release 3.3.0, all MoM users that are not already superusers must be granted either the `subgrid-auditor` or `subgrid-superuser` role in order to interact with subgrids. The `subgrid-auditor` role will permit read operations (HTTP GET API requests), and `subgrid-superuser` will permit read and write operations (HTTP GET, POST, PUT, PATCH, and DELETE API requests) against the subgrids. These requests to the subgrid will all utilize the same subgrid API client credentials. As an example, a user with `subgrid-auditor` can see cases on the subgrid, but cannot modify them. Whereas a user with `subgrid-superuser` can modify cases on the subgrid, as well as manage subgrid users and their roles.
 
 ### Subgrid Config
 

diff --git a/docs/onion-ai.md b/docs/onion-ai.md
@@ -103,7 +103,7 @@ Security Onion now supports local models through any OpenAI-compatible endpoint.
 
 ## Hosting Local Models
 
-Hosting your own models requires powerful and expensive hardware. For beginners we recommend using a tool such as LM Studio. **You need at least 96GB of VRAM** to host your own models locally. The speed and accuracy of OnionAI when hosted locally is based on the hardware that you are using. For the most accurate results we recommend using credits with OnionAI.
+Hosting your own models requires powerful and expensive hardware. For beginners we recommend using a tool such as LM Studio. The models listed above are large, and **you need at least 96GB of VRAM** to host them locally. Smaller mixture-of-experts models can run in considerably less memory while still offering a context window large enough for the assistant; see [Local LLM Hosting](local-llm.md) for a tested walkthrough on a single machine. The speed and accuracy of OnionAI when hosted locally is based on the hardware that you are using. For the most accurate results we recommend using credits with OnionAI.
 
 ## Available Tools
 
@@ -155,3 +155,63 @@ Your system prompt addendum will be added after Security Onion's default system
 Superusers can review token usage and conversation history for all users by going to Administration --> AI Metrics. This page provides usage statistics for a given date range. The page starts with a table of usage by user. Clicking a user's binoculars icon on the right hand side will show any sessions the user interacted with during the selected date range, even deleted sessions. Clicking on a session's binoculars icon will show the full conversation. Administrators can adjust who has permissions via RBAC roles.
 
 To provide an accurate history, deleted sessions are retained on the metrics page even after being deleted by the user.
+
+## Memory
+
+OnionAI can utilize its memory system to retain and reference facts disclosed by users when chatting with the assistant. Memory works by scanning sessions in the background looking for new facts and storing them in a database. The memory is then used to provide contextual information to the assistant when it responds to a user's message.
+
+### How Memory Works
+
+The memory system scans sessions in the background extracting, embedding, reconciling, and saving memories to later be referenced when chatting with Onion AI.
+
+First, extraction. The selected sessions have their transcripts given to a Memory agent that parses out useful facts. The agent also identifies the scope of the fact: is it specific to the user who owns the session we just scanned or is it applicable to the entire organization.
+
+These facts are then embedded using an Embed agent. This enables SOC to compare memories and is the heart of how memory works.
+
+!!! NOTE
+
+    The embedding process is model specific. Memories embedded by one model cannot be accurately compared to memories embedded by any other model. Changing the model used for embedding will render all your previous memories unusable. They will not be deleted and will be accessible if the model is reverted back.
+
+Once embedded, the facts are compared against existing memories on the same topics in a step called Reconcilation. A Reconcile agent will decide how the facts should be added, merged, replaced or removed. The reconcile agent's recommendations are validated before being executed to ensure that user defined memories aren't modified and that the session owner's permissions are respected.
+
+If any facts were rewritten during reconcilation, they are re-embedded before being stored in postgres.
+
+Finally the session is updated indicating that it has been scanned. If new messages are sent in a previously scanned session, memory scans will find and scan only the new messages.
+
+When a user sends a message to the assistant, the memory system will embed the message about to be sent and check for any similar memories. Memories are added to the conversation by being added to the end of the prompt.
+
+### Configuring Memory
+
+| Name | Default Value | Description |
+|---|---|---|
+| `useMemory` | `true` | Enable memory use when sending a message. |
+| `useMemoryScanner` | `false` | Enables the scanning of historical sessions. |
+| `dontScanBefore` | `""` | A date in RFC3339 format (2026-08-31T22:05:48Z) to use as a cutoff point for memory scans. |
+| `memoryScanIntervalSeconds` | `300` | How long between scans the memory scanner waits before scanning again. |
+| `memoryProximityThreshold`  | `0.8` | A similarity threshold that determines how similar a fact must be to a previous memory for it to be considered "similar." |
+| `messageProximityThreshold`  | `0.5` | A similarity threshold that determines how similar a message from a user must be to a stored memory for it to be considered "similar." |
+| `maxUserMemoriesToReconcile` | `20` | The maximum number of user-specific memories to reconcile at once. |
+| `maxGlobalMemoriesToReconcile` | `20` | The maximum number of global memories to reconcile at once. |
+| `maxUserMemoriesToInclude` | `5` | The maximum number of user-specific memories to include when sending a message. |
+| `maxGlobalMemoriesToInclude` | `5` | The maximum number of global memories to include when sending a message. |
+| `memoryModel` | `gemma@SOAI` | The model used to extract facts from sessions. |
+| `memoryPersona` | `""` | Special instructions for the memory agent included in the prompt. |
+| `embedModel` | `amazon.titan-embed-text-v2@SOAI` | The model used to embed facts. |
+| `reconcileModel` | `gemma@SOAI` | The model used to reconcile facts from sessions with existing memories.  |
+| `reconcilePersona` | `""` | Special instructions for the reconcile agent included in the prompt. |
+| `toolUseTurnAttempts` | `12` | When the assistant requests a read-only tool, SOC can approve it automatically. Because the approval can fire before the original request has finished being written to Elasticsearch, SOC will retry the approval up to this many times before giving up. |
+| `toolUseTurnDelayMs` | `175` | The time to wait between auto-approval attempts. Together with the attempts setting, this defines the total grace period SOC allows for the tool request to become available. |
+| `maxMemoryRetries` | `2` | The maximum number of times SOC will attempt to extract memories from sessions before marking the session to be ignored. Increasing this value may retry sessions that haven't been attempted in a long time. |
+
+Memory and the Memory Scanner may be enabled independently. Disabling memory will stop applying memories to prompts on outgoing messages. Disabling the memory scanner will prevent the scanner from extracting memories from previous assistant sessions. The memory scanner marks sessions as it extracts facts from them so that they are not re-scanned in future scans. If a memory scan takes longer than the interval between scans, then at most 1 scan will queue up for processing and it'll begin again immediately after the previous scan finishes.
+
+### How to Write a Good Memory
+
+When entering memories in manually in the Agent Studio, it's important to understand that how the memory is written affects how it'll be used by the memory system.
+
+1. **One fact per memory.** If a memory has multiple facts then matching is harder to accomplish resulting in the memory being accessed less.
+1. **Make each memory self-contained.** It will be read out of context, alone, possibly months later in a conversation about something else. Every memory should make sense to someone who has only that sentence.
+1. **Declarative facts, not instructions.** If you want to give an instruction, then use a prompt instead.
+1. **Present tense, absolute references, durable phrasing.** A memory is read long after it's written and is never automatically updated, so describe how things are rather than how they changed. Prefer "PCAP retention is 90 days (set August 2026)" over "We recently changed retention to 90 days."
+
+To help track your most successful memories, the Agent Studio presents how many times a memory has been accessed and when was the last time it was referenced.
-Original file line number
+Diff line change
@@ Expand Up @@
     ## Parsing
-    Elasticsearch receives unparsed logs from [Logstash](logstash.md) or [Elastic Agent](elastic-agent.md). Elasticsearch then parses and stores those logs. Parsers are stored in `/opt/so/conf/elasticsearch/ingest/`. Custom ingest parsers can be placed in `/opt/so/saltstack/local/salt/elasticsearch/files/ingest/`. Files placed here are not detected by [Auto State Apply](salt.md#auto-state-apply), so to make these changes take effect, apply the Elasticsearch state to all nodes running Elasticsearch:
+    Elasticsearch receives unparsed logs from [Logstash](logstash.md) or [Elastic Agent](elastic-agent.md). Elasticsearch then parses and stores those logs. Parsers are stored in `/opt/so/conf/elasticsearch/ingest/`. Custom ingest parsers can be placed in `/opt/so/saltstack/local/salt/elasticsearch/files/ingest/`. [Auto State Apply](salt.md#auto-state-apply) picks these up within a few minutes. If you don't want to wait, apply the Elasticsearch state to all nodes running Elasticsearch:
     ```
@@ Expand Down @@