chore: README and CHANGELOG updates

CHANGELOG.md

@@ -11,11 +11,14 @@ and this project adheres to [Semantic Versioning](http://semver.org/).
 
 - JWT based API authentication
 - Configurable logging
+- Consolidated LLM Inference via `ModelClient` class
+- Dynamic logging configurable via environment variables
 
 ### Changed
 
 - Deriver & Dialectic API to use Hybrid Memory Architecture
 - Metamessages are not strictly tied to a message
+- Database provisioning is a separate script instead of happening on startup
 
 ## [0.0.16]
 

README.md

@@ -75,10 +75,10 @@ Below is a mapping of the different primitives.
 Apps
 └── Users
     ├── Sessions
-    │   ├── Messages
-    │   └── Metamessages
-    └── Collections
-        └── Documents
+    │   └── Messages
+    ├── Collections
+    │   └── Documents
+    └── Metamessages
 ```
 
 Users familiar with APIs such as the OpenAI Assistants API will be familiar with
@@ -105,18 +105,6 @@ The `Session` object represents a set of interactions a `User` has with an
 The `Message` represents an atomic interaction of a `User` in a `Session`.
 `Message`s are labed as either a `User` or AI message.
 
-#### Metamessages
-
-A `Metamessage` is similar to a `Message` with different use case. They are
-meant to be used to store intermediate inference from AI assistants or other
-derived information that is separate from the main `User` `App` interaction
-loop. For complicated prompting architectures like [metacognitive prompting](https://arxiv.org/abs/2310.06983)
-metamessages can store thought and reflection steps along with having developer
-information such as logs.
-
-Each `Metamessage` is associated with a `Message`. The convention we recommend
-is to attach a `Metamessage` to the `Message` it was derived from or based on.
-
 #### Collections
 
 At a high level a `Collection` is a named group of `Documents`. Developers
@@ -132,6 +120,18 @@ PDF files, and more.
 
 As stated before a `Document` is vector embedded data stored in a `Collection`.
 
+#### Metamessages
+
+A `Metamessage` is similar to a `Message` with different use case. They are
+meant to be used to store intermediate inference from AI assistants or other
+derived information that is separate from the main `User` `App` interaction
+loop. For complicated prompting architectures like [metacognitive prompting](https://arxiv.org/abs/2310.06983)
+metamessages can store thought and reflection steps along with having developer
+information such as logs.
+
+Each `Metamessage` is associated with a `User` with the ability to optionally
+tie to a `Session` and a `Message`.
+
 ### Insights
 
 The Insight functionality of Honcho is built on top of the Storage service. As

docs/getting-started/architecture.mdx

@@ -56,7 +56,7 @@ This is pretty straightforward.
 
 Plenty of applications have intermediate steps between `User` input and the
 response that gets sent. The `Metamessage` object allows you to store those
-intermediate steps and link them to the messages they were derived from.
+intermediate steps and link them to the users, sessions, or messages they were derived from.
 
 ### Collections
 
@@ -80,4 +80,4 @@ developers implement their own solutions that without a doubt increase overhead
 and maintenance. Our goal with Honcho is to provide a simple and flexible
 storage framework accompanied by a smooth developer experience to ease pains
 building the cumbersome parts of LLM applications. We hope this will allow
-developers more freedom to explore exciting, yet-to-be-discovered areas!
+developers more freedom to explore exciting, yet-to-be-discovered areas!