diff --git a/schema/tables/dns_cache.yml b/schema/tables/dns_cache.yml
new file mode 100644
index 0000000000..9fd3d326dc
--- /dev/null
+++ b/schema/tables/dns_cache.yml
@@ -0,0 +1,16 @@
+name: dns_cache
+examples: >-
+  An integral part of incident response is understanding all systems that may have been compromised. To help with this, a query like the following will return positive for a system that has resolved a domain that contains `baddomain`. It's important to note that a system will only cache the DNS mapping for a limited time - see Notes below for further information. 
+  
+  ```
+     
+   SELECT name, type FROM dns_cache WHERE name LIKE '%baddomain%';
+
+  ```
+
+    
+notes: >-
+
+  This table pulls from the local system's DNS cache. By default, the local DNS cache entry for a domain will be removed once the TTL for the domain has expired. For instance, osquery.io has a TTL of 60 seconds. When this domain has been resolved on a local Windows system, the DNS mapping will expire in 60 seconds from the resolution time - so `SELECT * FROM dns_cache WHERE name = 'osquery.io'` will only return results during that 60 second window.
+
+  Windows has a maximum time that it allows a cache entry to exist- by default, it is 1 day. If the domain has a TTL of greater than 1 day, Windows will still remove the DNS entry from its cache after 1 day.
diff --git a/schema/tables/ntdomains.yml b/schema/tables/ntdomains.yml
new file mode 100644
index 0000000000..dade6050e0
--- /dev/null
+++ b/schema/tables/ntdomains.yml
@@ -0,0 +1,13 @@
+name: ntdomains
+examples: >-
+  If the system is joined to a domain, this query will return the domain name as well as all known domain controllers and their IP addresses.
+  
+  ```
+     
+   SELECT domain_name, domain_controller_name, domain_controller_address, status FROM ntdomains WHERE domain_name != "";
+
+  ```
+    
+notes: >-
+
+This table returns a row even if the local system is not joined to a domain - in this case, the `status` column will be `Unknown` and the `name` column will contain `Domain: $Hostname of local system`.
diff --git a/schema/tables/shimcache.yml b/schema/tables/shimcache.yml
new file mode 100644
index 0000000000..fed2c24e20
--- /dev/null
+++ b/schema/tables/shimcache.yml
@@ -0,0 +1,21 @@
+name: shimcache
+examples: >-
+  As a byproduct of its functionality, the Application Compatibility Cache (also known as the shimcache) logs some details around process execution. These logs can be useful, especially during incident response. The following query looks for a potential IoC (indicator of compromise) - evidence of process execution of a Windows binary named certutil. (Certutil is a legitimate Windows application, but is also known to be a lolbin - living off the land binary. See more details here: https://lolbas-project.github.io/lolbas/Binaries/Certutil/ ) This query joins the local system's uptime to its results because shimcache logs are kept in memory until the system is rebooted, at which point they are written to disk - so we would also want to know the last time this system was rebooted.
+
+  ```
+
+   SELECT entry AS execution_order, path, DATETIME(modified_time, 'unixepoch') AS file_last_modified,  uptime.days || ' days, ' || uptime.hours || ' hours' AS host_uptime FROM shimcache CROSS JOIN uptime WHERE path LIKE '%certutil%';
+
+  ```
+
+notes: >-
+
+  Some key caveats to know about this data source:
+
+  * Process execution logs are only written during a reboot, otherwise they are stored in memory. This means you may not be seeing the data you would expect if the system hasn't been rebooted recently.
+
+  * The entry column shows the order of execution - Starting from 1, which is the most-recent process execution, and then on from there.
+
+  * The modified_time column displays the last modified time for the file.
+
+  Source: https://bromiley.medium.com/windows-wednesday-shim-cache-1997ba8b13e7
diff --git a/schema/tables/userassist.yml b/schema/tables/userassist.yml
new file mode 100644
index 0000000000..ed382207e2
--- /dev/null
+++ b/schema/tables/userassist.yml
@@ -0,0 +1,10 @@
+name: userassist
+examples: >-
+  The User Assist featureset allows Windows to keep track of most recently used applications. Because of that, it is a useful datasource to pull from during investigations and incident response. The following example queries the userassist table and converts the last_execution_time into a human readable format (using UTC) and then sorts the results by this column, descending. It also joins the users table to change the user SID into a human readable username.  The output from this query displays most recently used applications, sorted by most recent timestamp as well as the username of who ran it.
+  
+  ```
+     
+    SELECT userassist.path, datetime(userassist.last_execution_time, 'unixepoch') AS timestamp_of_last_exec, userassist.count as execution_count, users.username FROM userassist join users ON users.uuid = userassist.sid  ORDER BY timestamp_of_last_exec DESC;
+
+  ```
+