diff --git a/__plans__/beam-implementation.md b/__plans__/beam-implementation.md
index 6606f9e..9ee9bfe 100644
--- a/__plans__/beam-implementation.md
+++ b/__plans__/beam-implementation.md
@@ -90,7 +90,7 @@ graph TD
   - Design storage layer (Mnesia/ETS)
 
 - **View System**
-  - Implement Lossy/Hyperview views
+  - Implement Lossy/Hyperviews
   - Create resolver framework
   - Add caching layer
 
diff --git a/__plans__/housekeeping.md b/__plans__/housekeeping.md
index cee65b2..74652d6 100644
--- a/__plans__/housekeeping.md
+++ b/__plans__/housekeeping.md
@@ -2,8 +2,8 @@
 
 - [x] Organize tests?
 - [x] More documentation in docs/
-- [x] Rename/consolidate, hyperview view() and compose() --> composeView()
-- [x] Rename Hyperview to HyperView
+- [x] Rename/consolidate, hyperview view() and compose() 
+- [x] Rename Lossless to HyperView
 - [x] Rename Lossy to View
 - [x] Consider whether we should use collapsed deltas
 - [ ] Improve ergonomics of declaring multiple entity properties in one delta
diff --git a/__tests__/integration/schema.test.ts b/__tests__/integration/schema.test.ts
index 4c99114..e333f37 100644
--- a/__tests__/integration/schema.test.ts
+++ b/__tests__/integration/schema.test.ts
@@ -359,7 +359,7 @@ describe('Schema System', () => {
 
       debug(`Manually ingested invalid delta: ${JSON.stringify(invalidDelta)}`)
 
-      debug(`Hyperview view: ${JSON.stringify(node.hyperview.compose(), null, 2)}`)
+      debug(`Hyperview: ${JSON.stringify(node.hyperview.compose(), null, 2)}`)
 
       const validIds = collection.getValidEntities();
       expect(validIds).toContain('user1');
diff --git a/markdown/001-meeting.md b/markdown/001-meeting.md
index 9a0bdd2..238df4e 100644
--- a/markdown/001-meeting.md
+++ b/markdown/001-meeting.md
@@ -136,7 +136,7 @@ smalltalk type messaging structure on top of the database
 note dimensions of attack surface
 
 layers:
-primitives - what's a delta, schema, materialized view, view view
+primitives - what's a delta, schema, materialized view, view
 delta store - allows you to persiste deltas and query over the delta stream
 materialized view store - view snapshot(s)
 view bindings - e.g. graphql, define what a user looks like, that gets application bindings
diff --git a/markdown/004-library.md b/markdown/004-library.md
index a7f3b29..5f7b3ff 100644
--- a/markdown/004-library.md
+++ b/markdown/004-library.md
@@ -34,7 +34,7 @@ Pre-built technologies? LevelDB
 Can use LevelDB to store deltas
 Structure can correspond to our desired ontology
 Layers for 
-- primitives - what's a delta, schema, materialized view, view view
+- primitives - what's a delta, schema, materialized view, view
 - delta store - allows you to persiste deltas and query over the delta stream
 - materialized view store - view snapshot(s)
 - view bindings - e.g. graphql, define what a user looks like, that gets application bindings
diff --git a/spec.md b/spec.md
index 40e6a5a..36691c1 100644
--- a/spec.md
+++ b/spec.md
@@ -13,6 +13,6 @@
 	* This could lead to circular references and arbitrarily deep nesting, which runs into the problem of "returning the entire graph". So our schema should specify, for instance, that the "friends" field apply the "Summary" schema to referenced users rather than the "User" schema, where the "Summary" schema simply resolves to username and photo.
 * A `hyperview` is a representation of an `object` that includes a full inventory of all of the deltas that compose that object. So for instance, a hyperview of the object representing the user "Alice" might include `alice.name`, which contains an array of all deltas with a pointer whose `target` is the ID of Alice and whose context is `name`. Such deltas would likely include a second pointer with the name `name` and the target a primitive string "Alice", for instance.
 	* A `hyperview` may also include nested delta/object layering. Consider `alice.friends`, which would include all deltas asserting friendship between Alice and some other person. Each such delta would reference a different friend object. In a hyperview, these references would be expanded to contain hyperviews of those friends. Schemas, as defined above, would be applied to constrain tree depth and avoid infinite regress.
-* A `view view` is a compression of a `hyperview` that removes delta information and flattens the structure into a standard domain object, typically in JSON. So instead of `alice.name` resolving to a list of deltas that assert the object's name it might simply resolve to `"alice"`.
+* A `view` is a compression of a `hyperview` that removes delta information and flattens the structure into a standard domain object, typically in JSON. So instead of `alice.name` resolving to a list of deltas that assert the object's name it might simply resolve to `"alice"`.
 	* Note that in a hyperview any property of an object necessarily resolves to a set of deltas, even if it's an empty set, because we cannot anticipate how many deltas exist that assert values on that context.
-* In collapsing a hyperview into a view view we may specify `resolution strategies` on each field of the schema. A resolution strategy takes as input the set of all deltas targeting that context and returns as output the value in the view view. So if we have 15 deltas asserting the value for an object's name, our resolution strategy may simply say "return the target of the `name` pointer associated with the most recent delta", or it may say "return an array of names". If the value is numeric it may say "take the max" or "take the min" or "take the average".
\ No newline at end of file
+* In collapsing a hyperview into a view we may specify `resolution strategies` on each field of the schema. A resolution strategy takes as input the set of all deltas targeting that context and returns as output the value in the view. So if we have 15 deltas asserting the value for an object's name, our resolution strategy may simply say "return the target of the `name` pointer associated with the most recent delta", or it may say "return an array of names". If the value is numeric it may say "take the max" or "take the min" or "take the average".
\ No newline at end of file
diff --git a/src/collections/collection-basic.ts b/src/collections/collection-basic.ts
index 1912d60..1c65a60 100644
--- a/src/collections/collection-basic.ts
+++ b/src/collections/collection-basic.ts
@@ -18,7 +18,7 @@ export class BasicCollection extends Collection<TimestampResolver> {
     id: string
   ) {
     if (!this.rhizomeNode) throw new Error('collection not connected to rhizome');
-    if (!this.view) throw new Error('view view not initialized');
+    if (!this.view) throw new Error('view not initialized');
 
     const res = this.view.resolve([id]) || {};
 
diff --git a/src/collections/collection-relational.ts b/src/collections/collection-relational.ts
index 6562f6d..7ecd1f2 100644
--- a/src/collections/collection-relational.ts
+++ b/src/collections/collection-relational.ts
@@ -17,7 +17,7 @@ export class RelationalCollection extends Collection<RelationalView> {
     id: string
   ): ResolvedViewOne | undefined {
     if (!this.rhizomeNode) throw new Error('collection not connected to rhizome');
-    if (!this.view) throw new Error('view view not initialized');
+    if (!this.view) throw new Error('view not initialized');
 
     const res = this.view.resolve([id]) || {};
 
diff --git a/src/collections/collection-typed.ts b/src/collections/collection-typed.ts
index 24a0e6f..d065f12 100644
--- a/src/collections/collection-typed.ts
+++ b/src/collections/collection-typed.ts
@@ -63,7 +63,7 @@ export class TypedCollectionImpl<T extends Record<string, unknown>>
 
   resolve(id: string): ResolvedViewOne | undefined {
     if (!this.rhizomeNode) throw new Error('collection not connected to rhizome');
-    if (!this.view) throw new Error('view view not initialized');
+    if (!this.view) throw new Error('view not initialized');
 
     const res = this.view.resolve([id]) || {};
     return res[id];
diff --git a/src/views/view.ts b/src/views/view.ts
index eb750af..59f2fa6 100644
--- a/src/views/view.ts
+++ b/src/views/view.ts
@@ -50,7 +50,7 @@ export abstract class Lossy<Accumulator, Result = Accumulator> {
 
     if (!hyperviewPartial) {
       // This should not happen; this should only be called after the hyperview has been updated
-      console.error(`Hyperview view for entity ${entityId} not found`);
+      console.error(`Hyperview for entity ${entityId} not found`);
       return;
     }
 
diff --git a/todo.md b/todo.md
index b272ccb..7bb2c72 100644
--- a/todo.md
+++ b/todo.md
@@ -186,7 +186,7 @@ This document tracks work needed to achieve full specification compliance, organ
 
 1. **Phase 1** ✅ - These are foundational requirements
 2. **Phase 2.1 (Negation)** ✅ - Core spec feature that affects all views
-3. **Phase 2.2 (Resolvers)** ✅ - Needed for proper view views
+3. **Phase 2.2 (Resolvers)** ✅ - Needed for proper views
 4. **Phase 2.3 (Nesting)** ✅ - Depends on schemas and queries
 5. **Phase 3 (Query)** ✅ - Unlocks powerful data access
 6. **Phase 4 (Relational)** - Builds on query system