diff --git a/Consumer-API.md b/Consumer-API.md
index c32a7d0..098bb4b 100644
--- a/Consumer-API.md
+++ b/Consumer-API.md
@@ -8,8 +8,8 @@ This is a **draft** for discussion purposes.
 * Checking that your application schema is congruent (that is: if you assert datoms based on that schema, everything still makes sense) with the database schema set should be relatively cheap. This will be done on each startup.
 * Concurrent consumers within the same process — *e.g.*, browser add-ons — should be aware of each other's schema changes.
 * Extending a database with new attributes should be easy, routine, and cheap.
-* Upgrading schema fragments in certain directions (e.g., enabling or disabling indexing) should be possible.
-* Upgrading schema fragments in other directions (e.g., changing cardinality) should be possible with some effort — *e.g.*, by providing a transformer function that takes the current schema and transaction log and fills a new transaction log, allowing Datomish to rebuild the database to match. This is expected to be expensive and requires coordination with other consumers, and is thus not recommended.
+* Upgrading schema fragments in certain directions (*e.g.*, enabling or disabling indexing) should be possible.
+* Upgrading schema fragments in other directions (*e.g.*, changing cardinality) should be possible with some effort — *e.g.*, by providing a transformer function that takes the current schema and transaction log and fills a new transaction log, allowing Datomish to rebuild the database to match. This is expected to be expensive and requires coordination with other consumers, and is thus not recommended.
 
 ## Example in modern JS