diff --git a/Thoughts:-filtering-databases.md b/Thoughts:-filtering-databases.md
new file mode 100644
index 0000000..418cccf
--- /dev/null
+++ b/Thoughts:-filtering-databases.md
@@ -0,0 +1,5 @@
+Consumers will typically only be interested in particular subsets of a store: perhaps only the attributes of some set of entities, or only assertions using certain schema fragments. (Those fragments will overlap.)
+
+We can imagine being able to get a handle to a filtered version of a database which appears to only contain assertions that are relevant to the consumer.
+
+This has some amount of value when applied to the current DB: it's equivalent to introducing some complication to queries, and so improves clarity. However, if the filtering logic can be pushed a little lower, it makes instant-in-time ideas much more tractable: a consumer might be able to back a Time Machine-esque interface by a filtered database, one that appears to only contain relevant transactions, and materializing only relevant datoms as needed.
\ No newline at end of file