diff --git a/docs/designers-developers/key-concepts.md b/docs/designers-developers/key-concepts.md
index 3252337ba2b33..e42f5aa044ba1 100644
--- a/docs/designers-developers/key-concepts.md
+++ b/docs/designers-developers/key-concepts.md
@@ -143,4 +143,6 @@ A purely dynamic block that is to be server rendered before display could look l
 
 ## The Gutenberg Lifecycle
 
-In summary, the workflow for editing a Gutenberg post starts with taking the persisted version of the document and generating the in-memory tree, aided by the presence of token delimiters. It ends with the reverse: serialization of blocks into `post_content`. During editing, all manipulations happen within the block tree. In summary, a Gutenberg post is built upon an in-memory data structure which gets persisted somehow in an fully-isomorphic way. Right now that persistence is via a serialization/parser pair but could just as easily be replaced through a plugin to store the data structure as a JSON blob somewhere else.
+In summary, the Gutenberg workflow parses the saved document to an in-memory tree of blocks, using token delimiters to help. During editing, all manipulations happen within the block tree. The process ends by serializing the blocks back to the `post_content`.
+
+The workflow process relies on a serialization/parser pair to persist posts. Hypothetically, the post data structure could be stored using a plugin or retrieved from a remote JSON file to be converted to the block tree.