brimdata · philrz · Aug 22, 2026 · Aug 22, 2026
diff --git a/book/src/command/db.md b/book/src/command/db.md
@@ -617,7 +617,7 @@ super db merge -use logs@updates <branch>
 * [Global](options.md#global)
 * [Database](options.md#database)
 * [Output](options.md#output)
-* [Commmit](options.md#commit)
+* [Commit](options.md#commit)
 
 Data is merged from one branch into another with the `merge` command, e.g.,
 ```

diff --git a/book/src/command/output.md b/book/src/command/output.md
@@ -159,7 +159,7 @@ to conform to a single type.
 Also, data fusion can sometimes involve sum types that are not
 representable in a format like Parquet.  While a bit cumbersome,
 you could write a query that adjusts the output by renaming columns
-so that heterogenous data column types are avoided.   This modified
+so that heterogeneous data column types are avoided.  This modified
 data could then be fused without sum types and output to Parquet.
 
 ## Splitting Schemas

diff --git a/book/src/database/format.md b/book/src/database/format.md
@@ -11,7 +11,7 @@ To support the client-facing SuperDB access
 implemented by the [`super db` command](../command/db.md), we are developing
 an open specification for the database format described in this document.
 
-This format is somewhat analagous the emerging
+This format is somewhat analogous to the emerging
 cloud table formats like [Iceberg](https://iceberg.apache.org/spec/),
 but differs but differs in a fundamental way: there are no tables in SuperDB.
 
@@ -26,7 +26,7 @@ to provide a universal data representation for all of these different approaches
 > aren't present in the database**
 
 Also, while we are not currently focused on building a SQL engine for the SuperDB database,
-it is most certainly possible to do so, as a Super record type is analagous to
+it is most certainly possible to do so, as a Super record type is analogous to
 a SQL table definition.  SQL tables can essentially be dynamically projected
 via a table virtualization layer built on top of the SuperDB model.
 

diff --git a/book/src/database/intro.md b/book/src/database/intro.md
@@ -71,7 +71,7 @@ we have plans to support CRUD updates at the primary-key level
 in the near future.
 
 TODO: make pools independent entities then tie them together with a separate
-layer of adminstrative glue (i.e., there should be no depedencies in a pool
+layer of administrative glue (i.e., there should be no dependencies in a pool
 that are required to interpret and query it outside of the pool entity)
 
 TODO: back off on github metaphor?

diff --git a/book/src/dev/integrations/fluentd.md b/book/src/dev/integrations/fluentd.md
@@ -47,7 +47,7 @@ Two edits were then performed to the configuration:
 removed to uncomment `@load packages`, which allows the JSON Streaming Logs
 package to be activated when Zeek starts.
 
-2. The file `/opt/zeek/etc/node.cfg` was edited to to change the `interface`
+2. The file `/opt/zeek/etc/node.cfg` was edited to change the `interface`
 setting to reflect the network source from which Zeek should sniff live
 traffic, which in our instance was `enX0`.
 

diff --git a/book/src/dev/integrations/zeek/shaping.md b/book/src/dev/integrations/zeek/shaping.md
@@ -301,7 +301,7 @@ values nest_dotted(this)
                       case true => values _shaped
                       case false => values {_original, _shaped, _cropped}
                       | switch _error_if_cropped (
-                          case true => values error({msg: "shaper error: one ore more fields were cropped", _original, _shaped, _cropped})
+                          case true => values error({msg: "shaper error: one or more fields were cropped", _original, _shaped, _cropped})
                           case false => values _cropped
                         )
                   )

diff --git a/book/src/formats/bsup.md b/book/src/formats/bsup.md
@@ -109,7 +109,7 @@ frame length is compressed and has the form:
 <format><size><compressed payload>
 ```
 where
-* `<format>` is a single byte indicating the compression format of the the compressed payload,
+* `<format>` is a single byte indicating the compression format of the compressed payload,
 * `<size>` is a `uvarint` encoding the size of the uncompressed payload, and
 * `<compressed payload>` is a bytes sequence whose length equals
 the outer frame length less 1 byte for the compression format and the encoded length

diff --git a/book/src/intro.md b/book/src/intro.md
@@ -440,7 +440,7 @@ and improved ergonomics can reside in the pipe operators, e.g.,
 are case sensitive in pipe operators,
 * complex scoping rules for table aliases and column references are required in
 relational SQL while binding from names to data in pipe operators is managed
-in a uniform and simple way as derefenced paths on [this](super-sql/intro.md#pipe-scoping),
+in a uniform and simple way as dereferenced paths on [this](super-sql/intro.md#pipe-scoping),
 * the syntactic structure of SQL clauses means all data must conform to a table
 whereas pipe operators can emit any data type desired in a varying fashion, and
 * [sum types](super-sql/types/union.md) are integral to piped data allowing mix-typed data processing

diff --git a/book/src/super-sql/aggregates/fuse.md b/book/src/super-sql/aggregates/fuse.md
@@ -13,7 +13,7 @@ fuse(any) -> type
 The _fuse_ aggregate function applies [type fusion](../type-fusion.md)
 to its input and returns the fused type.  A fused type differs
 from a [blended type](blend.md) as it includes fusion types in the nested type hierarchy
-whereever type changes were made to combine types in the type fusion process.
+wherever type changes were made to combine types in the type fusion process.
 
 ## Examples
 

diff --git a/book/src/super-sql/aggregates/union.md b/book/src/super-sql/aggregates/union.md
@@ -12,7 +12,7 @@ union(any) -> set[any]
 
 The _union_ aggregate function computes a set union of its input values.
 If the values are of uniform type, then the output is a set of that type.
-If the values are of mixed type, the the output is a set of union of the
+If the values are of mixed type, the output is a set of union of the
 types encountered.
 
 ## Examples

diff --git a/book/src/super-sql/expressions/containment.md b/book/src/super-sql/expressions/containment.md
@@ -1,6 +1,6 @@
 # Containment
 
-A containment expression expression tests for the existence of
+A containment expression tests for the existence of
 a value in another value and has the form
 ```
 <item> in <target>

diff --git a/book/src/super-sql/functions/parsing/grok.md b/book/src/super-sql/functions/parsing/grok.md
@@ -80,7 +80,7 @@ the use of the `grok` function, review the tips below.
    [Logstash docs](https://www.elastic.co/guide/en/logstash/current/plugins-filters-grok.html#_custom_patterns)
    ([super/4899](https://github.com/brimdata/super/issues/4899)).
 
-   Instead use the the approach shown later in that section of the Logstash
+   Instead use the approach shown later in that section of the Logstash
    docs by including a custom pattern in the `definitions` argument, e.g.,
 
    ```mdtest-spq {data-layout="stacked"}

diff --git a/book/src/super-sql/sql/intro.md b/book/src/super-sql/sql/intro.md
@@ -191,7 +191,7 @@ part of the input scope for the `SELECT` operation in which it appears.
 While identifiers in SQL expressions typically resolve to columns in table,
 they may also refer to lexically-scoped
 [declarations](../declarations/intro.md) for constants, named queries,
-and so forth.  These bindings have a precedence higher than than relational
+and so forth.  These bindings have a precedence higher than relational
 bindings so an identifier is first resolved via
 [lexical binding](../expressions/intro.md#identifier-resolution).
 

diff --git a/book/src/super-sql/sql/select.md b/book/src/super-sql/sql/select.md
@@ -112,7 +112,7 @@ A grouped projection occurs when either or both occur:
 
 In a grouped projection, the `HAVING` clause, `ORDER BY` clause, and
 the projection may refer only to inputs that are aggregate functions
-(where the function arguments are bound to the input scope and colum
+(where the function arguments are bound to the input scope and column
 aliases) or to expressions or combination of expressions that appear
 in the `GROUP BY` clause.
 

diff --git a/book/src/super-sql/sql/set-ops.md b/book/src/super-sql/sql/set-ops.md
@@ -49,7 +49,7 @@ When processing mixed-type tables or non-table inputs, the effect
 of union can be achieved by simply combining pipe queries using
 [fork](../operators/fork.md).
 
-When it is desirable to have a homogenous output for such data,
+When it is desirable to have a homogeneous output for such data,
 data can be fused into one type with the [fuse](../operators/fuse.md) or
 [blend](../operators/blend.md) operators,
 which resembles the _union-by-name_ variation available in some SQL dialects.