@fraczak/k 6.10.6 → 7.0.0

package/DOCS/book/03-types-as-finite-automata.md

@@ -1,14 +1,14 @@
-# Chapter 3 — Types as Finite Automata
+# Chapter 3 — Schemas as Finite Automata
 
 ## **3.1 Motivation**
 
-A type in `k` describes a set of finite labeled trees, which can be recognized by a finite tree automaton (FTA). Equivalently, a type definition can be seen as a context-free grammar (CFG), where the values of the type are the derivation trees of the grammar.
+A schema in `k` describes a set of finite labeled trees, which can be recognized by a finite tree automaton (FTA). Equivalently, a schema definition can be seen as a context-free grammar (CFG), where the payloads of the schema are the derivation trees of the grammar.
 
-For example, the recursive type definition of a `list`:
+For example, the recursive schema of a `list`:
 
 ```k-lang
-$ bool = < {} true, {} false >;
-$ list = < {} nil, { bool head, list tail } cons >;
+bool = ?< {} true, {} false >;
+list = ?< {} nil, { < {} true, {} false > head, L tail } cons > = L;
 ```
 
 corresponds to the following 4-rule grammar:
@@ -20,7 +20,7 @@ corresponds to the following 4-rule grammar:
 4: <list> ::= { <bool> head, <list> tail } |cons
 ```
 
-A value of type `list` is a derivation tree of this grammar. For instance, a list containing a single boolean value `true` can be represented by the following derivation:
+A payload of schema `list` is a derivation tree of this grammar. For instance, a list containing a single boolean value `true` can be represented by the following derivation:
 
 ```
 <list>
@@ -31,25 +31,25 @@ A value of type `list` is a derivation tree of this grammar. For instance, a lis
                      -- (rule 1) --> {} |true
 ```
 
-This derivation tree corresponds to the value generated by the constant function `{ {} |true head, {} |nil tail } |cons`.
+This derivation tree corresponds to the payload generated by the constant relation `{ {} |true head, {} |nil tail } |cons`.
 
-Representing types as automata (or CFGs) provides each type with a well-defined structure, independent of the names used in the source code. This allows for canonical normal forms and for comparing types for equality by structure alone.
+Representing schemas as automata (or CFGs) provides each schema with a well-defined structure, independent of the names used in the source code. This allows for canonical normal forms and for comparing schemas for equality by structure alone.
 
 ---
 
 ## **3.2 States and Transitions**
 
-Each type definition introduces one or more *states* in the automaton. A union or a product definition corresponds to a state, and the variants or fields correspond to transitions to other states.
+Each schema structure introduces one or more *states* in the automaton. A union or a product schema corresponds to a state, and the variants or fields correspond to transitions to other states.
 
-For example, consider the `$bool` type:
+For example, consider the `bool` schema:
 
 ```k-lang
-$ bool = < {} true, {} false >;
+bool = ?< {} true, {} false >;
 ```
 
-This definition translates to an automaton with two states:
+This schema translates to an automaton with two states:
 
-- A root state, let's call it `C0`, representing the `$bool` type itself (a union).
+- A root state, let's call it `C0`, representing the `bool` schema itself (a union).
 - A state `C1` representing the empty product `{}`.
 
 From the root state `C0`, there are two transitions:
@@ -57,46 +57,45 @@ From the root state `C0`, there are two transitions:
 - A transition labeled `true` to state `C1`.
 - A transition labeled `false` to state `C1`.
 
-`C0` is the root state of the type, and `C1` is a leaf state, representing an empty value.
+`C0` is the root state of the schema, and `C1` is a leaf state, representing an empty unit value.
 
 ---
 
 ## **3.3 Canonical Form**
 
-Different type expressions can describe the same automaton. For example:
+Different schema expressions can describe the same automaton. For example:
 
 ```k-lang
-$ bool = < {} false, {} true >;
-$ pair = { bool x, bool y };
-$ pair2 = { < {} true, {} false > x, bool y };
+pair = ?{ < {} false, {} true > x, < {} false, {} true > y };
+pair2 = ?{ < {} true, {} false > x, < {} true, {} false > y };
 ```
 
-The types `pair` and `pair2` are structurally equivalent because `$bool` is defined as `< {} true, {} false >`, making the definition of `x` in `pair2` identical to the standalone `$bool` type used in `pair`. Canonicalization is the process of removing these superficial differences by erasing local names and renumbering states to produce a single stable representation for each unique type structure.
+The schemas `pair` and `pair2` are structurally equivalent because the choice order in a union does not alter the underlying accepted set of trees. Canonicalization is the process of removing these superficial differences by erasing local names and renumbering states to produce a single stable representation for each unique schema structure.
 
-The canonical form is generated by traversing the type's graph structure starting from its root state. The process ensures a unique representation by following a consistent ordering:
+The canonical form is generated by traversing the schema's graph structure starting from its root state. The process ensures a unique representation by following a consistent ordering:
 
-1. **Start at the Root**: Assign the number `C0` to the root state of the type.
+1. **Start at the Root**: Assign the number `C0` to the root state of the schema.
 2. **Explore Neighbors**: Visit all states reachable from `C0`. Sort the transitions alphabetically by their labels (field or variant names) and assign consecutive numbers (`C1`, `C2`, ...) to the destination states in that order.
 3. **Iterate**: Move to the next state in the numbered sequence (`C1`, then `C2`, etc.) and repeat the process for any of its neighbors that have not yet been numbered.
 4. **Complete**: Continue until all reachable states have been assigned a unique number.
 
-This traversal produces a unique and deterministic numbering for any finite directed graph, ensuring that any two structurally identical types will have the exact same canonical representation.
+This traversal produces a unique and deterministic numbering for any finite directed graph, ensuring that any two structurally identical schemas will have the exact same canonical representation.
 
 ---
 
 ## **3.4 Examples**
 
-For a type representing binary natural numbers:
+For a schema representing binary natural numbers:
 
 ```k-lang
-$ bnat = < bnat 0, bnat 1, {} _ >;
+bnat = ?< Bnat 0, Bnat 1, {} _ > = Bnat;
 ```
 
-the canonical form is:
+the canonical automaton form is:
 
-```k-lang
-$C0 = < C0 "0", C0 "1", C1 "_" >;
-$C1 = {};
+```text
+C0 = < C0 "0", C0 "1", C1 "_" >;
+C1 = {};
 ```
 
 The automaton has two states. `C0` is a recursive state that recognizes sequences of "0"s and "1"s, while `C1` is the terminal state, marked by the "_" transition.
@@ -105,52 +104,52 @@ The automaton has two states. `C0` is a recursive state that recognizes sequence
 
 ## **3.5 Normalization Process**
 
-When compiling a program, the following steps are taken to normalize types:
+When compiling a program, the following steps are taken to normalize schemas:
 
-1. **Collect**: Gather all type definitions from the program.
-2. **Expand**: Recursively replace all named types with their underlying definitions until only products and unions remain.
-3. **Deduplicate**: Eliminate duplicate type structures by comparing them structurally.
-4. **Canonicalize**: Assign stable state numbers to the unique types to produce their canonical text representation.
+1. **Collect**: Gather all schema structures and filters from the program.
+2. **Expand**: Recursively replace named relation references with their underlying schema structures until only products and unions remain.
+3. **Deduplicate**: Eliminate duplicate schema structures by comparing them structurally.
+4. **Canonicalize**: Assign stable state numbers to the unique schemas to produce their canonical text representation.
 
-This process is deterministic, ensuring that the same type structure always produces the exact same canonical form.
+This process is deterministic, ensuring that the same schema structure always produces the exact same canonical form.
 
 ---
 
 ## **3.6 Hash-Based Naming**
 
-To create a globally unique and stable identifier for each type, the compiler computes a hash of its canonical representation. This hash becomes the official, unambiguous name of the type.
+To create a globally unique and stable index for each schema, the compiler computes a digest of its canonical automaton representation. This hash becomes a fixed-width content address for the schema in the registry.
 
 For example:
 
 ```text
-Canonical Form: $C0=<C0"0",C0"1",C1"_">;$C1={}
+Canonical Automaton: C0=<C0"0",C0"1",C1"_">;C1={}
       ↓
      Hash
       ↓
 Identifier: @VtPHxGf5GNMzzyVFxtv7gegFfJRYapBGtCeyV56bs5Zb
 ```
 
-Program objects can then refer to types by their hash-based identifiers (prefixed with `@`) without ambiguity.
+Program objects and contracts can refer to schemas by their hash-based identifiers (prefixed with `@`) without ambiguity.
 
 ---
 
 ## **3.7 Interpretation**
 
-The canonical representation of a type can be interpreted as:
+The canonical representation of a schema can be interpreted as:
 
 - A finite set of states, `C0…Cn`.
 - Each state is either a product (a record with named fields) or a union (a set of variants).
 - Transitions between states are labeled with strings (field or variant names).
 
-Every value of a given type is a finite tree that is accepted by this automaton.
+Every payload tree of a given schema is a finite tree that is accepted by this automaton.
 
 ---
 
 ## **3.8 Summary**
 
-- Types in `k` denote sets of finite, labeled trees.
-- Every type can be expressed as a finite tree automaton or a context-free grammar.
-- The canonical form eliminates naming differences, providing a single representation for structurally identical types.
-- Hash-based naming gives each unique type a stable and globally unique identifier.
+- Schemas in `k` denote sets of finite, labeled trees.
+- Every schema can be expressed as a finite tree automaton or a context-free grammar.
+- The canonical form eliminates naming differences, providing a single representation for structurally identical schemas.
+- Hash-based naming gives each unique schema a stable and globally unique content-addressable identifier.
 
 ---

package/DOCS/book/04-partial-functions-and-composition.md

@@ -82,9 +82,8 @@ Since `k` lacks a direct syntax for literal values, constants are created using
 For example, we can define functions that return `true` and `false`:
 
 ```k-lang
-$ bool = < {} true, {} false >;
-true_bool  =  {} |true $bool ;
-false_bool =  {} |false $bool ;
+true_bool  =  {} |true;
+false_bool =  {} |false;
 ```
 
 Here, `true_bool` and `false_bool` are constant functions. They are also **total functions**, meaning they are defined for all inputs. Each function ignores its input and produces a fixed boolean value.

package/DOCS/book/05-typing-filters-and-normalization.md

@@ -1,54 +1,51 @@
-# Chapter 5 — Typing, Filters, and Normalization
+# Chapter 5 — Schemas, Filters, and Contracts
 
-## **5.1 Types as functions**
+## **5.1 Filters as partial identity relations**
 
-A type expression in `k` can appear wherever a function is expected.
-When used this way, it is prefixed by `$`.
-It then behaves as a partial **identity** function that is defined only for values of that type.
-For example, `$ bool` is a partial identity: it returns its argument unchanged when the argument is of type `bool`, and it is undefined otherwise.
+Filters in `k` are introduced by `?` and appear wherever an expression is expected.
+A filter behaves as a partial **identity** relation: it returns its payload unchanged when the payload matches the schema described by the filter, and it is undefined otherwise.
+For example, `? < {} true, {} false >` is a partial identity: it returns its payload unchanged when the payload is a boolean variant, and it is undefined otherwise.
 
-This convention eliminates any special syntax for annotating sub-expressions with types.
-An expression may be *restricted* to a type simply by composing it with the corresponding type expression.
+Beyond serving as runtime guards, filters serve as **inductive termination witnesses** that allow contract derivation for recursive relations to converge into finite-state automata.
 
 ---
 
-## **5.2 Filters**
+## **5.2 Filters and Schemas**
 
-A **filter** is a syntactic form that denotes a *class of types* — a set of types that share a common structure.
+A **filter** is a syntactic form that denotes a *schema graph* — a structural specification of payloads that share a common shape.
 
 Filter expressions are introduced by `?` and can be:
 
-- **Type expressions** — `? $bool`, `? $< {} x, bool y >`
 - **Product filters** — `? { Filter1 field1, Filter2 field2 }`  
 - **Union filters** — `? < Filter1 tag1, Filter2 tag2 >`
-- **Any-type filter** — `? ( ... )`
-- **Filter variables** — `? X` (metavariables representing unknown types)
-- **Filter bindings** — `? < X f, (...) = Y g, ... > = X`
+- **Any-schema filter** — `? ( ... )`
+- **Schema variables** — `? X` (local metavariables representing schema graph nodes)
+- **Schema bindings** — `? < X f, (...) = Y g, ... > = X`
 
 Filters may contain `...` to indicate that additional fields or tags are allowed:
 `? { Filter1 field1, ... }` matches any product with at least `field1`.
 
-The filter `? (...)` matches any type.
-The filter `? {...}` matches any product type.
-The filter `? <...>` matches any union type.
+The filter `? (...)` matches any schema.
+The filter `? {...}` matches any product schema.
+The filter `? <...>` matches any union schema.
 There is no closed unknown filter: use `?{}` for the empty product or `?<>` for the empty union.
 
 ---
 
 ## **5.3 Examples of filters**
 
-- `?(...)` — represents any type.
-- `?< (...) f, (...) g >` — represents all union types having exactly two variants `f` and `g`.
-- `?{ X f, X g }` — represents all product types with two fields `f` and `g`, both of the same type.
+- `?(...)` — represents any schema.
+- `?< (...) f, (...) g >` — represents all union schemas having exactly two variants `f` and `g`.
+- `?{ X f, X g }` — represents all product schemas with two fields `f` and `g`, both of the same schema.
 
-A filter constrains where a partial function is defined; it does not affect the operational behavior of the function once defined.
+A filter constrains where a relation is defined; it does not alter the output payload once defined.
 
 ---
 
-## **5.4 Recursive filters**
+## **5.4 Recursive schemas and filters**
 
 Filters may be recursive.
-They can describe families of recursive types by defining a metavariable in terms of a filter that references it.
+They can describe families of recursive schemas by defining a metavariable in terms of a filter that references it.
 
 Example (list definition):
 
@@ -56,19 +53,19 @@ Example (list definition):
 ?< {} nil, {X car, Y cdr} cons > = Y
 ```
 
-This filter states that `Y` is a union type with two variants: `nil` and `cons`.
+This filter states that `Y` is a union schema with two variants: `nil` and `cons`.
 
 - The `nil` variant holds an empty product `{}`.
-- The `cons` variant is a product with two fields: `car` of some type `X`, and `cdr` of type `Y` itself.
+- The `cons` variant is a product with two fields: `car` of some schema `X`, and `cdr` of schema `Y` itself.
 
-This recursive structure defines a linked list where each element has a `car` (the value) and a `cdr` (the rest of the list).
-It thus denotes lists of elements of type `X`.
+This recursive structure defines a linked list where each element has a `car` (the payload) and a `cdr` (the rest of the list).
+It thus denotes lists of elements of schema `X`.
 
 ---
 
-## **5.5 Type variables and scope**
+## **5.5 Schema variables and scope**
 
-A type variable (an identifier, typically starting with an uppercase letter) introduced in a filter is visible within the enclosing function definition.
+A schema variable (an identifier, typically starting with an uppercase letter) introduced in a filter is visible within the enclosing relation definition.
 For example:
 
 ```k-lang
@@ -77,35 +74,36 @@ car = ?< {} nil, {X car, Y cdr} cons > = Y /cons .car ?X;
 
 Here:
 
-- `X` and `Y` are type variables.
-- The filter `?<{}nil,{X car,Y cdr}cons>=Y` constrains the function `car` to be defined only on types that match the recursive list structure.
-- The expression `/cons` selects the `cons` variant of the union.
+- `X` and `Y` are schema variables.
+- The filter `?<{}nil,{X car,Y cdr}cons>=Y` constrains the relation `car` to be defined only on inputs that match the recursive list structure.
+- The expression `/cons` asserts the `cons` variant of the union.
 - The expression `.car` accesses the `car` field of a `cons` variant.
-- The final filter `?X` asserts that the result of the field access is of type `X`, the type of the list's elements.
+- The final filter `?X` asserts that the result of the field access is of schema `X`, the schema of the list's elements.
 
 ---
 
-## **5.6 Type inference and normalization**
+## **5.6 Contract derivation and normalization**
 
-Every `k` program can be analyzed to assign an input and an output filter to every sub-expression. This process is called type inference and normalization.
+Every `k` relation is analyzed by the compiler to derive its **contract**: a connected $(input, output)$ schema graph with shared vertices ($=X$) proving that input substructures are preserved through to the output.
 
-Type inference and normalization proceed as follows:
+Contract derivation and normalization proceed as follows:
 
-1. Build a graph of all type references appearing explicitly and implicitly in the program.
-2. Annotate each expression node with a pair of (input filter, output filter).
-3. Replace filters that match a single, concrete type with that type expression, adding any newly discovered types to the graph.
-4. Repeat until a fixed point is reached and no more changes occur.
-5. Compute canonical forms for all newly introduced types.
+1. Build a schema graph from explicit filters and primitive operations (projections, constructors, products).
+2. Propagate schemas forward and backward through compositions, products, and choices.
+3. Validate inductive convergence for recursive relations using filter witnesses.
+4. Replace filters that match a single, concrete schema with that closed schema, adding any newly discovered schemas to the registry.
+5. Repeat until a fixed point is reached.
+6. Compute canonical forms and content-addressed hashes for all discovered schemas.
 
 ---
 
 ## **5.7 Summary**
 
-- Type expressions act as identity functions defined on values of that type.
-- Filters describe sets of types and can constrain where a function is defined.
-- Filters may be products, unions, or the unconstrained any-type form, and can be recursive.
+- Filter expressions act as partial identity relations defined on payloads conforming to a schema.
+- Filters describe schema constraints and inductive termination witnesses for recursive relations.
+- Filters may be products, unions, or the unconstrained any-schema form, and can be recursive.
 - Variables in filters have definition-level scope.
-- Normalization computes explicit input/output filters for every expression.
-- Filters are used in the normalization and type checking process. They are ignored at runtime.
+- Contract derivation computes an interconnected $(input, output)$ schema graph for every relation.
+- The canonical form of a schema provides a universal content-addressable identity in the schema registry.
 
 ---

package/DOCS/book/06-values-in-memory.md

@@ -11,7 +11,7 @@ Every `k` value exists in one of three forms during execution:
 This unified approach enables programs to operate on serialized inputs without unnecessary deserialization, optimizing performance for identity operations and partial data access patterns.
 
 In the current pattern-framed model, every form also has a pattern context. For
-serialized values this is the decoded leading `$pattern` value; for materialized
+serialized values this is the decoded leading `pattern` value; for materialized
 values it is carried on the runtime `Value`. The product/union tree is the
 payload, while the pattern records the polymorphic type information needed to
 interpret and re-encode that payload.
@@ -111,11 +111,11 @@ Each node in the value tree is encoded based on its automaton state:
 
 #### **Example: Natural numbers**
 
-For type `bnat`, intuitively binary natural numbers defined by `$bnat = < bnat 0, bnat 1, {} _ >`, we get
+For type `bnat`, intuitively binary natural numbers defined by `bnat = ?< Bnat 0, Bnat 1, {} _ > = Bnat;`, we get
 
 ```text
-> :C bnat
-$ bnat = < @... 0, @... 1, {} _ >;  -- @...
+> :rel bnat
+bnat = ?< Bnat 0, Bnat 1, {} _ > = Bnat;  -- @...
 ```
 
 The corresponding Context-Free grammar is:
@@ -191,7 +191,7 @@ Subtrees that happen to produce the same local payload bits under different type
 Consider a binary tree with repeated leaf patterns:
 
 ```k-lang
-$tree = < { tree left, tree right } branch, int leaf >;
+tree = ?< { T left, T right } branch, int leaf > = T;
 ```
 
 Value: A tree corresponding to the structure:
@@ -293,8 +293,8 @@ These are encoder-side construction choices for reaching the same canonical resu
 Consider a list of similar records:
 
 ```k-lang
-$record = { string name, int age, string department };
-$company = < { record head, company tail } cons, {} nil >;
+record = ?{ string name, int age, string department };
+company = ?< { record head, C tail } cons, {} nil > = C;
 ```
 
 Value representing 1000 employees where 80% work in "Engineering":
@@ -712,9 +712,9 @@ const Arena = struct {
 Consider processing a large JSON-like structure where we only need one field:
 
 ```k-lang
-$record = { string name, list data, metadata meta };
-$list = < {nat value, list next} cons, {} nil >;
-$metadata = { timestamp created, string author };
+metadata = ?{ timestamp created, string author };
+list = ?< { nat value, L next } cons, {} nil > = L;
+record = ?{ string name, list data, metadata meta };
 ```
 
 For the input program `\x.x.name` (extract name field):

package/DOCS/book/08-operational-semantics-and-execution.md

@@ -54,16 +54,16 @@ If `v` carries a pattern, the result carries the subpattern reached by `label`.
 For a union projection `/label`, the same rule applies to the selected tag's
 payload.
 
-### **Type expression**
+### **Filter expression**
 
-For a type `T`,
+For a pattern filter `?F`,
 
 ```text
-⟨ $T , v ⟩ ⇓ v     if v ∈ T
+⟨ ?F , v ⟩ ⇓ v     if v ∈ L(F)
 ```
 
 and undefined otherwise.
-Type expressions thus act as identity functions restricted to their type.
+Filter expressions thus act as partial identity functions restricted to their pattern language.
 
 ---
 
@@ -121,22 +121,19 @@ If no subfunction is defined, the union composition is undefined.
 
 ## **8.7  Rules for filters**
 
-If a filter `F` matches a single type `T`
+A filter `?F` validates that the input value conforms to the pattern:
 
 ```text
-⟨ ?F , v ⟩ ⇓ ⟨ $T , v ⟩ 
+⟨ ?F , v ⟩ ⇓ v     if v matches pattern F
 ```
 
-otherwise it is an identity
+otherwise undefined.
 
-```text
-⟨ ?F , v ⟩ ⇓ v
-```
-
-Filters therefore act as compile-time annotations for type checking only.
-As operations they are identities at run time, unless they lead to fully typed
-expressions (i.e., can be replaced by a type). Their pattern information may
-still be present on the runtime value because values can carry codec patterns.
+Filters act as partial identity relations. At compile time, they guide type
+derivation and provide inductive termination witnesses for recursive relations.
+At runtime, filters succeed and preserve the input value when it conforms to
+the pattern, or fail if the value does not match. Their pattern information is
+carried by the runtime value's pattern envelope.
 
 ---
 
@@ -156,19 +153,17 @@ for any given input, at most one result tree can be produced.
 Given:
 
 ```k-lang
-$bool = < {} true, {} false >;
-neg = $bool < .true {{ } false}, .false {{ } true} > $bool;
+bool = ?< {} true, {} false >;
+neg = ?< {} true, {} false > < /true | false, /false | true >;
 ```
 
-and input value `{ {} true }` of type `bool`,
-evaluation steps are:
+and input value `{} |true`, evaluation steps are:
 
-1. `⟨ $bool , { {} true } ⟩ ⇓ { {} true }`
-2. `⟨ < .true {{ } false}, .false {{ } true} > , { {} true } ⟩ ⇓ {{ } false}`
-3. `⟨ $bool , {{ } false} ⟩ ⇓ {{ } false}`
+1. `⟨ ?< {} true, {} false > , {} |true ⟩ ⇓ {} |true`
+2. `⟨ < /true | false, /false | true > , {} |true ⟩ ⇓ {} |false`
 
-Final result: `{{ } false}`.
-If the input were of another type, step 1 would be undefined.
+Final result: `{} |false`.
+If the input were of another shape, step 1 would be undefined.
 
 ---
 
@@ -181,7 +176,7 @@ The evaluation rules map directly onto the runtime ABI:
 | Projection          | `k_project`                           |
 | Product composition | multiple subcalls + `k_make_product`  |
 | Union composition   | sequential subcalls with early return |
-| Type                | runtime check of `state`              |
+| Filter              | runtime check or identity             |
 | Composition         | function call chain                   |
 
 In compiled form, the `ok` flag of `KOpt` represents whether a rule applies;
@@ -194,7 +189,7 @@ the node pointer represents the result value.
 * Execution follows deterministic, left-to-right rules.
 * All expressions denote partial functions on runtime values.
 * Runtime values may carry patterns, and structural operations propagate them.
-* Type expressions act as restricted identities.
+* Filter expressions act as restricted identities.
 * Composition is associative; undefined propagates automatically.
 * Runtime semantics match the formal evaluation relation exactly.
 

package/DOCS/book/09-compiler-architecture.md

@@ -73,15 +73,15 @@ These tables ensure that generated code can find fields and variants by number r
 Consider a simple k program:
 
 ```k-lang
-$bool = < {} true, {} false >;
-neg = $bool < /true | false, /false | true > $bool;
+bool = ?< {} true, {} false >;
+neg = bool < /true | false, /false | true > bool;
 ```
 
 1. **Parsing:**
-   The compiler recognizes a type definition `$bool` and a function `neg`.
+   The compiler recognizes the relation definitions `bool` and `neg`.
 
 2. **Type analysis:**
-   Both the input and output of `neg` are of type `bool`.
+   The compiler derives that both the input and output of `neg` conform to boolean variants.
 
 3. **Internal representation:**
    The compiler constructs an internal tree describing that
@@ -105,13 +105,13 @@ Before producing final code, many compilers use an *intermediate representation*
 It is a language designed to be easy to generate and easy to translate further into real machine code.
 For `k`, the IR mirrors the structure of partial functions:
 
-| Concept in k          | IR operation                     |
-| --------------------- | -------------------------------- |
-| Projection `.x` `/x`  | `PROJECT label_id`               |
-| Composition `(f g)`   | `CALL f; CALL g`                 |
-| Union `<f,g>`         | `TRY f; IF undefined THEN TRY g` |
-| Product `{.x f, .y g}` | `PRODUCT_CALL (f, g); COMBINE`   |
-| Type restriction `$T` | `CHECK_TYPE state_id`            |
+| Concept in k            | IR operation                     |
+| ----------------------- | -------------------------------- |
+| Projection `.x` `/x`    | `PROJECT label_id`               |
+| Composition `(f g)`     | `CALL f; CALL g`                 |
+| Union `<f,g>`           | `TRY f; IF undefined THEN TRY g` |
+| Product `{.x f, .y g}`  | `PRODUCT_CALL (f, g); COMBINE`   |
+| Filter restriction `?F` | `CHECK_FILTER pattern_id`        |
 
 The compiler converts each AST node into one or more IR instructions.
 The `PRODUCT_CALL(f, g)` instruction is a higher-level concept that implies applying both `f` and `g` to the same input value.

package/DOCS/book/10-from-ast-to-intermediate-representation.md

@@ -42,24 +42,23 @@ Each function in the program becomes a small list or tree of such IR instruction
 Source program:
 
 ```k-lang
-$bool = < {} true, {} false >;
-neg = $bool < .true {{ } false}, .false {{ } true} > $bool;
+bool = ?< {} true, {} false >;
+neg = ?< {} true, {} false > < /true | false, /false | true >;
 ```
 
 The IR for `neg` can be written informally as:
 
 ```text
 neg:
-  TYPECHECK bool
+  CHECK_FILTER bool
   UNION [
     SEQ [ PROJECT true, CONST false ],
     SEQ [ PROJECT false, CONST true ]
   ]
-  TYPECHECK bool
 ```
 
 This IR expresses the same logic as the source:
-check the type, then try the first projection `.true`, otherwise the second, and finally ensure the result is again of type `$bool`.
+check that the value matches the pattern, then try the first projection `/true`, otherwise the second.
 
 ---
 
@@ -89,8 +88,8 @@ The process of converting the AST to IR follows a recursive pattern:
 2. **Compositions** `(f g h)` become a `SEQ` list of their components.
 3. **Unions** `<f,g>` become a `UNION` list.
 4. **Products** `{f l₁, g l₂}` become a `PRODUCT` list with labeled entries.
-5. **Type expressions** `$T` become `TYPECHECK` instructions.
-6. **Filters** disappear; their meaning is already captured by typechecks.
+5. **Filter expressions** `?F` become `CHECK_FILTER` or `TYPECHECK` instructions.
+6. Inductive filters that match derived shapes can be elided or turned into no-op identity during execution.
 
 Each transformation step produces IR nodes with fixed behavior and explicit order.
 

package/DOCS/book/14-canonical-serialization.md

@@ -67,8 +67,8 @@ This rule allows the decoder to know, from the type alone, how many bits to read
 
 For the type
 
-```
-$bnat = < bnat 0, bnat 1, {} _ >;
+```k-lang
+bnat = ?< Bnat 0, Bnat 1, {} _ > = Bnat;
 ```
 
 the canonical form has three transitions from state C0.