@fraczak/k 6.10.6 → 7.0.1

package/DOCS/DICTIONARY.md

@@ -14,75 +14,79 @@ target execution.
 - Use semantic names for all externally visible concepts.
 - Distinguish a concept from its serialized representation.
 - Distinguish source syntax from the semantic object represented by that syntax.
-- Distinguish a mathematical function from the compiler artifacts used to
+- Distinguish a mathematical relation from the compiler artifacts used to
   compile or execute it.
-- Treat "pattern" as a type-context concept, not as ordinary value-pattern
-  matching over raw trees.
+- Use `schema` for data shapes (algebraic tree automata), `contract` for
+  relational signatures, `filter` for partial identity guards and inductive
+  witnesses, and `(schema, payload)` for framed runtime values.
 
 ## Source-Level Concepts
 
 ### k Source
 
-`k source` is the textual language read by the parser. It can define types,
-partial functions, and an entry expression.
+`k source` is the textual language read by the parser. It defines relations
+(including schemas defined as partial identities/filters) and an optional
+entry expression.
 
 Use this term for source text before compiler passes have resolved names,
-canonicalized types, or derived pattern information.
+canonicalized schemas, or derived relational contracts.
 
 ### Expression
 
 An `expression` is a source-level program fragment that denotes a partial
-function over enveloped values.
+relation over framed values.
 
 Expressions include identity, composition, projection, variant introduction,
-product construction, ordered union, type checks, pattern guards, and references
-to named partial functions or intrinsics.
+product construction, ordered union, filters, and references to named
+relations or intrinsics.
 
-### Partial Function
+### Partial Relation
 
-A partial function maps an input enveloped value to an output enveloped value
+A `partial relation` maps an input framed payload to an output framed payload
 when it is defined. If it is not defined for the input, execution fails normally.
 This failure is part of the language semantics, not a system exception.
 
-Mathematically, a k program denotes a deterministic partial function.
+Mathematically, a k program denotes a deterministic partial relation
+(partial function).
 
-### Type
+### Schema
 
-A `type` describes a set of value trees accepted by an algebraic shape. Types are
-built from products and tagged unions.
+A `schema` describes a set of labeled tree payloads accepted by a finite tree
+automaton. Schemas are built from products and tagged unions. A schema can be
+*closed* (all constructors determined) or *open* (containing schema parameters
+$X, Y$).
 
-Use "type" for the semantic concept. Avoid using "code" by itself in public docs
-when the meaning is type.
+Use "schema" for the semantic concept. Avoid using "code" or "type pattern" by
+itself in public docs when the meaning is a schema.
 
-### Type Code
+### Canonical Schema
 
-A `type code` is the canonical, hashable representation of a type.
+A `canonical schema` is the deterministic, hashable normal form of a schema
+automaton. Its canonical textual syntax is its primary universal identity in the
+schema registry; its `@hash` is a fixed-width indexing digest.
 
-Use "type" for the semantic concept and "type code" for its canonical
-representation.
+### Filter
 
-### Pattern Guard
+A `filter` is an expression `?schema` that constrains the input payload to a
+schema and otherwise behaves like identity.
 
-A `pattern guard` is an expression that constrains the input envelope to a type
-pattern and otherwise behaves like identity.
-
-Source syntax may present this operation as a filter expression. The semantic
-operation is a pattern guard.
+In recursive relations, filters also serve as **inductive termination witnesses**,
+ensuring contract derivation converges.
 
 ### Canonical Content-Addressed Hash (`@hash`)
 
 A `canonical content-addressed hash` is the immutable, unique identifier
 derived from the normalized AST of a relation or the minimal deterministic
-tree automaton of a type.
+tree automaton of a schema.
 
 In `k`, there is no global symbol namespace. Every compiled relation and
-type code is identified globally and uniquely by its `@hash`.
+schema is identified globally and uniquely by its `@hash`.
 
 ### Local Alias
 
 A `local alias` is a human-readable identifier (such as `plus`, `int`,
 or `5`) mapped to a canonical hash in object metadata (`relAlias`,
-`typeAliases`).
+`schemaAliases`).
 
 Aliases are local to their compilation scope. When loading libraries
 with `--lib`, canonical definitions are available by their `@hash`, but
@@ -93,120 +97,109 @@ unless explicitly mapped with `--export`.
 
 In `k`, there are no primitive numerical types or built-in integer
 literals. Numerical identifiers such as `5` or `10` are nullary
-relations (constants) mapping the unit `${}` to bit trees of type
-`${} -> $bits`. Operations on signed integers (`$int`) require
+relations (constants) mapping the unit `{}` to bit trees of contract
+`{} -> bits`. Operations on signed integers (`int`) require
 converting bit trees via the `int` constructor (`5 int`).
 
-## Values, Types, And Patterns
-
-### Value Tree
+## Values, Schemas, And Contracts
 
-A `value tree` is the product/variant tree part of a value during execution.
+### Payload Tree (or Payload)
 
-By itself, a value tree is not enough to recover the semantic value at a binary
-or polymorphic boundary. The same tree can be meaningful under different type
-contexts.
+A `payload tree` (or `payload`) is the product/variant tree part of a value during
+execution.
 
-### Type Pattern
+By itself, a raw payload tree is not self-describing at a binary or polymorphic
+boundary. The same tree is meaningful only when framed by a schema.
 
-A `type pattern` describes a set of possible types. It is the semantic object
-represented by source filter syntax and by the pattern graphs carried through
-compilation and execution.
+### Schema
 
-The short name `pattern` is acceptable once the context is clear. Use "type
-pattern" when introducing the concept or when there is risk of confusion with
-ordinary value matching.
+A `schema` describes a set of possible payload trees accepted by an algebraic
+automaton. It is the semantic object represented by source filter syntax and by the
+schema graphs carried through compilation and execution.
 
-Examples of type pattern kinds include:
+Examples of schema kinds include:
 
-- any type;
+- unconstrained schema parameter (`X`, `?X`);
 - open product;
 - closed product;
 - open union;
 - closed union;
-- singleton type pattern derived from a concrete type code.
-
-### Pattern Graph
-
-A `pattern graph` is the graph representation of a type pattern. Nodes describe
-pattern kind and openness. Edges describe required product fields or union tags.
-
-Pattern graph node identity matters: if two positions point to the same pattern
-node, they must share the same type context.
+- closed schema derived from concrete definitions.
 
-Use "pattern graph" for the representation, and "type pattern" for the semantic
-constraint it represents.
+### Schema Graph
 
-### Envelope
+A `schema graph` is the graph representation of a schema. Nodes describe
+schema kind and openness. Edges describe required product fields or union tags.
 
-An `envelope` is the type pattern carried with a value at an execution or wire
-boundary.
+Schema graph node identity matters: if two positions point to the same schema
+node, they share the exact same schema structure.
 
-The envelope describes the type context in which the value tree should be
-decoded, checked, projected, transformed, or encoded. The spelling should always
-be `envelope`.
+Use "schema graph" for the representation, and "schema" for the semantic
+language it defines.
 
-### Enveloped Value
+### Framed Value `(schema, payload)`
 
-An `enveloped value` is a pair:
+A `framed value` (formerly called an enveloped value) is a pair:
 
 ```text
-(value tree, envelope)
+(schema, payload)
 ```
 
-Structural operations propagate or refine the envelope:
+Structural operations propagate or refine the framing schema:
 
-- projection selects a subpattern;
-- product construction builds a closed product envelope from field envelopes;
-- variant introduction builds an open union envelope for the introduced tag;
-- pattern guards intersect the active envelope with a static type pattern.
+- projection selects a subschema;
+- product construction builds a closed product schema from field schemas;
+- variant introduction builds an open union schema for the introduced tag;
+- filters intersect the active schema with a static schema constraint.
 
-The envelope is part of the semantic value at compilation and execution
-boundaries. A value tree without an envelope is incomplete at those boundaries.
+The schema is part of the semantic value at compilation and execution
+boundaries. A payload tree without a framing schema is incomplete at those boundaries.
 
-### Pattern Signature
+### Contract
 
-A `pattern signature` is the input/output type-pattern pair attached to an
-expression or partial function:
+A `contract` is the derived $(input, output)$ linked schema graph attached to an
+expression or relation:
 
 ```text
-input pattern -> output pattern
+input schema -> output schema
 ```
 
-Pattern signatures are compiler facts. They constrain valid inputs and describe
-the envelope shape produced when evaluation succeeds.
+Contracts are compiler facts. Unlike independent types, a contract is a single
+connected schema graph where shared vertices ($=X$) prove structure preservation:
+input substructures flow through to the output without destruction or rebuilding.
+Contracts guide diagnostics, REPL output, binary serialization, and optimizations.
 
 ### Domain
 
 Use "domain" carefully.
 
-The input pattern of a partial function is a static type-context constraint, not
-necessarily the exact mathematical domain of the function. A function may still
-be undefined for some enveloped values that fit its input pattern.
+The input schema of a relation is a static constraint, not
+necessarily the exact mathematical domain of the relation. A relation may still
+be undefined for some payload trees that fit its input schema.
 
 Prefer:
 
-- "input pattern";
-- "accepted envelope";
+- "input schema";
+- "accepted schema";
 - "static input constraint".
 
 Use "domain" only when referring to the actual set of inputs for which the
-partial function is defined.
+partial relation is defined.
 
 ## Serialization And Boundaries
 
 ### Wire Stream
 
-A `wire stream` is the binary transport representation of an enveloped value.
+A `wire stream` is the binary transport representation of a framed value `(schema, payload)`.
 
 The active format is:
 
 ```text
-encoded envelope, followed by value bits encoded under that envelope
+encoded schema, followed by payload bits encoded under that schema
 ```
 
-Use "wire stream" or "pattern+value wire stream" for external transport
-boundaries. Use "enveloped value" for the semantic object used during
+Use "wire stream" or "schema+payload wire stream" for external transport
+boundaries. Use "framed value" for the semantic object used during
 execution.
 
 ### Codec
@@ -214,26 +207,26 @@ execution.
 A `codec` converts between an external representation and a k wire stream.
 
 Examples include the unit, JSON, integer, IEEE, UTF-8, and UTF-16 codecs. A
-codec must preserve the envelope/value relationship: it either supplies an
-envelope for parsing, decodes the envelope from the stream for printing, or
-works with a universal representation that can infer a suitable envelope.
+codec must preserve the schema/payload relationship: it either supplies a
+schema for parsing, decodes the schema from the stream for printing, or
+works with a universal representation that can infer a suitable schema.
 
-### Input Envelope
+### Input Schema
 
-An `input envelope` is the pattern carried by the input value at a program or
+An `input schema` is the schema framing the input payload at a program or
 execution boundary.
 
-Execution targets use the input envelope to specialize or validate execution.
-The input envelope can be provided explicitly, derived from a type expression, or
+Execution targets use the input schema to specialize or validate execution.
+The input schema can be provided explicitly, derived from a filter expression, or
 decoded from a wire stream.
 
-### Output Envelope
+### Output Schema
 
-An `output envelope` is the pattern attached to the output value after execution.
+An `output schema` is the schema attached to the output payload after execution.
 
-A correct runner must emit both the output envelope and the output value bits.
-Rendered values can hide envelope differences, so conformance checks must compare
-envelopes whenever envelope identity matters.
+A correct runner must emit both the output schema and the output payload bits.
+Rendered values can hide schema differences, so conformance checks must compare
+schemas whenever schema identity matters.
 
 ## Compiler Stages
 
@@ -242,43 +235,43 @@ envelopes whenever envelope identity matters.
 The `parsed AST` is the direct parser output. It keeps source-shaped expression
 nodes, source names, source ranges, and filter syntax.
 
-Use this term only for the representation before type-code registration,
-partial-function canonicalization, and pattern derivation.
+Use this term only for the representation before schema registration,
+relation canonicalization, and contract derivation.
 
-### Pattern-Annotated Core
+### Contract-Annotated Core
 
-`Pattern-annotated core` is the first semantic compiler artifact after parsing.
+`Contract-annotated core` is the first semantic compiler artifact after parsing.
 
 It keeps the expression structure close to k source, but it has:
 
-- registered canonical type codes;
-- resolved type references to canonical type-code names;
-- partial-function dependency information;
-- canonical aliases for partial functions;
-- a type-pattern graph for each partial function;
-- a pattern signature on each expression;
-- type-derivation convergence status.
+- registered canonical schemas;
+- resolved schema references to canonical schema names;
+- relation dependency information;
+- canonical aliases for relations;
+- a schema graph for each relation;
+- a contract on each expression;
+- contract-derivation convergence status.
 
 The key product is still a k-shaped core expression graph, now annotated by
-type-pattern facts. This stage is a semantic artifact; it does not imply a
+schema contract facts. This stage is a semantic artifact; it does not imply a
 particular serialized format.
 
-### Ahead-Of-Time (AOT) Type Checking
+### Ahead-Of-Time (AOT) Contract Checking
 
-`Ahead-of-time (AOT) type checking` refers to the compilation phase
-where parsing, relation expansion, structural type derivation, and
+`Ahead-of-time (AOT) contract checking` refers to the compilation phase
+where parsing, relation expansion, structural contract derivation, and
 fixed-point constraint convergence are solved in advance.
 
 The resulting compiled artifacts (`.ko`, `.klib`, `.kvm`) store fully
-derived principal type graphs and interned type codes, allowing downstream
-execution or linking to skip cold-start type derivation entirely.
+derived principal schema contracts and interned schemas, allowing downstream
+execution or linking to skip cold-start derivation entirely.
 
 ### k Object
 
 A `k object` is a compiled semantic object.
 
-It stores canonical type codes, partial functions, aliases, metadata,
-type-pattern graphs, and type-derivation status.
+It stores canonical schemas, relations, aliases, metadata,
+schema graphs, and contract-derivation status.
 
 An executable object (`.ko`) has an execution entrypoint (`main:
 "__main__"`). A library object (`.klib`) contains reusable definitions
@@ -289,66 +282,66 @@ but no selected main relation (`main: null`).
 The `k` toolchain defines four primary file formats (for comprehensive
 details and workflows, see [`DOCS/FILE_FORMATS.md`](FILE_FORMATS.md)):
 
-- **Source File (`.k`):** Plain UTF-8 source text defining algebraic data
-  shapes, partial functions, and expressions.
-- **Executable Object (`.ko`):** AOT type-checked executable artifact
-  with binary header `KOBJ\n` and JSON payload containing `codes`, `rels`,
+- **Source File (`.k`):** Plain UTF-8 source text defining algebraic
+  schemas, relations, and expressions.
+- **Executable Object (`.ko`):** AOT contract-checked executable artifact
+  with binary header `KOBJ\n` and JSON payload containing schemas, relations,
   and entrypoint `main: "__main__"`. Executable directly via `k.mjs`,
   WebAssembly, or LLVM.
-- **Library Object (`.klib`):** AOT type-checked library container stored
+- **Library Object (`.klib`):** AOT contract-checked library container stored
   as plain UTF-8 JSON without an entrypoint (`main: null`). Provides
-  reusable pre-converged relations and type graphs for downstream linking.
+  reusable pre-converged relations and schema graphs for downstream linking.
 - **Polymorphic kVM Template (`.kvm`):** Register-IR bytecode template
-  (`format: "k-vm"`, `layer: "KVM-P"`) carrying principal pattern graphs.
+  (`format: "k-vm"`, `layer: "KVM-P"`) carrying principal contracts.
   Specialized on-the-fly at runtime (`specializeKVM`) against concrete
-  input envelopes $(v, P_v)$ without re-running type inference.
+  input schemas $(v, S_v)$ without re-running type inference.
 
 ### Stream Transformer vs. Closed Constant Relation
 
-- A **stream transformer** is a relation with an open domain (e.g. `{() x,
+- A **stream transformer** is a relation with an open input schema (e.g. `{() x,
   5 int y} plus`) that consumes external data arriving from a binary
   stream or standard input.
 - A **closed constant relation** is a relation with no free inputs (such
-  as `{10 int x, 5 int y} plus`). Its domain is the unit type `${}`,
+  as `{10 int x, 5 int y} plus`). Its input schema is the unit `{}`,
   requiring an empty unit `{}` when executed as a standalone script.
 
 ### KIR-P
 
 `KIR-P` is the portable, polymorphic K Intermediate Representation.
 
-It is a stable artifact contract over k objects. It preserves pattern-carrying
-semantics while normalizing names, expression opcodes, and pattern graph node IDs
+It is a stable artifact contract over k objects. It preserves schema-carrying
+semantics while normalizing names, expression opcodes, and schema graph node IDs
 so consumers do not depend on parser-shaped fields or object encoding details.
 
 Use KIR-P as the shared semantic contract between k objects and lower-level
 execution artifacts.
 
-### Envelope-Specialized KIR-P
+### Schema-Specialized KIR-P
 
-`Envelope-specialized KIR-P` is KIR-P rebuilt for a concrete input envelope.
+`Schema-specialized KIR-P` is KIR-P rebuilt for a concrete input schema.
 
-Envelope-specialization:
+Schema-specialization:
 
 - takes a KIR-P object or k object;
-- takes an input envelope;
-- re-runs pattern derivation as if the entry expression were guarded by that
-  envelope;
-- derives the corresponding output envelope;
-- emits ordinary KIR-P for the specialized entry partial function.
+- takes an input schema;
+- re-runs contract derivation as if the entry expression were filtered by that
+  schema;
+- derives the corresponding output schema;
+- emits ordinary KIR-P for the specialized entry relation.
 
 ### KIR-M
 
-`KIR-M` is a materialized execution layer after envelope-specialized KIR-P.
+`KIR-M` is a materialized execution layer after schema-specialized KIR-P.
 
 It should contain layout and ABI decisions such as field offsets, tag dispatch,
-call-site specialization, and envelope-free execution assumptions.
+call-site specialization, and schema-free execution assumptions.
 
 ### Lowered Execution Model
 
 A `lowered execution model` is an executable middle layer.
 
-It lowers KIR-P partial-function bodies into a small instruction model with
-explicit partial failure, pattern guards, projections, construction, calls, and
+It lowers KIR-P relation bodies into a small instruction model with
+explicit partial failure, filters, projections, construction, calls, and
 returns.
 It is an execution contract that a lower-level compiler or executor can
 consume. It is not defined by a particular byte encoding.
@@ -357,69 +350,69 @@ consume. It is not defined by a particular byte encoding.
 
 ### Lowered Execution Artifact
 
-A `lowered execution artifact` is a post-envelope-specialization execution
+A `lowered execution artifact` is a post-schema-specialization execution
 artifact.
 
 It is produced by taking a source or object program, specializing it against a
-concrete input envelope, lowering the resulting KIR-P to a lowered execution
-model, and wrapping the entry metadata and functions. It is not the same thing
+concrete input schema, lowering the resulting KIR-P to a lowered execution
+model, and wrapping the entry metadata and relations. It is not the same thing
 as a general k object.
 
 ## Execution Concepts
 
-### Envelope-Aware Execution
+### Schema-Aware Execution
 
-`Envelope-aware execution` carries envelopes through inner operations.
+`Schema-aware execution` carries framing schemas through inner operations.
 
 This mode matches the reference execution and codec model. It is the safest
-semantic baseline because values keep their envelope throughout execution.
+semantic baseline because values keep their schema framing throughout execution.
 
-### Envelope-Free Execution
+### Schema-Free Execution
 
-`Envelope-free execution` uses static layout and pattern information inside the
-compiled function and attaches the derived output envelope only at the boundary.
+`Schema-free execution` uses static layout and schema information inside the
+compiled relation and attaches the derived output schema only at the boundary.
 
-This is valid only when envelope-specialization and type derivation prove the
-needed pattern contexts.
+This is valid only when schema-specialization and contract derivation prove the
+needed schema contexts.
 
 ### Partial Failure
 
-`Partial failure` is the normal result when a partial function is undefined for
-its input.
+`Partial failure` is the normal result when a partial relation is undefined for
+its input payload.
 
 In high-level execution this is represented as absence of an output value. In
 lower-level execution contracts it may be represented explicitly as a failed
-result. It is distinct from a `type error`, malformed artifacts, system
+result. It is distinct from a `contract violation`, malformed artifacts, system
 failures, and host exceptions.
 
-### Type Error
+### Contract Violation (Type Error)
 
-A `type error` is a semantic contradiction indicating that the type pattern of a
-value or expression does not conform to the expected input pattern of the
-partial function to which it is applied.
+A `contract violation` (or `type error`) is a semantic contradiction indicating
+that the schema of a payload or expression does not conform to the expected
+input schema of the relation to which it is applied.
 
-A type error is fundamentally distinct from `partial failure`:
+A contract violation is fundamentally distinct from `partial failure`:
 
 - `Partial failure` is a normal, valid semantic outcome representing mathematical
   undefinedness for an input value that nonetheless conforms to the expected
-  input pattern (for example, failing a condition in an inner branch, which in
+  input schema (for example, failing a condition in an inner branch, which in
   an ordered union allows subsequent branches to be evaluated).
-- A `type error` represents a type-system contradiction or boundary contract
+- A `contract violation` represents a contract contradiction or boundary contract
   violation. It is not an ordinary execution result and cannot be recovered by
   branching constructs like ordered union.
 
-A type error can occur at two distinct stages:
-
-1. **Compilation time (Type Derivation)**: Triggered during
-   `pattern-signature-derivation` when an expression's type pattern cannot be
-   unified with, or does not satisfy, the required input pattern of a function
-   it is passed to (such as disjoint types or unsatisfiable pattern guards).
-   This causes compilation or type derivation to fail with a diagnostic.
-2. **Runtime (Evaluation Boundary)**: Triggered when an `enveloped value` carries
-   an `input envelope` that does not match or conform to the expected input
-   pattern of the function being executed (for example, passing an incompatible
-   envelope to an entry partial function or target executable). At runtime, a
-   type error halts execution with a fatal diagnostic or error code (such as exit
+A contract violation can occur at two distinct stages:
+
+1. **Compilation time (Contract Derivation)**: Triggered during
+   `contract-derivation` when an expression's schema cannot be
+   unified with, or does not satisfy, the required input schema of a relation
+   it is passed to (such as disjoint schemas or unsatisfiable filters).
+   This causes compilation or contract derivation to fail with a diagnostic.
+2. **Runtime (Evaluation Boundary)**: Triggered when a `framed value` carries
+   an `input schema` that does not match or conform to the expected input
+   schema of the relation being executed (for example, passing an incompatible
+   schema to an entry relation or target executable). At runtime, a
+   contract violation halts execution with a fatal diagnostic or error code (such as exit
    status 5 in compiled targets) rather than producing partial failure.
 
 ### Intrinsic
@@ -427,8 +420,8 @@ A type error can occur at two distinct stages:
 An `intrinsic` is a predefined operation supplied by the execution environment and
 known to the compiler.
 
-Intrinsics need explicit type and lowering rules. Pure identity-like intrinsics
-can participate in ordinary partial-function semantics. Effectful or host-only
+Intrinsics need explicit schema and lowering rules. Pure identity-like intrinsics
+can participate in ordinary relation semantics. Effectful or host-only
 intrinsics require explicit ordering constraints or must be excluded from pure
 lowering targets.
 
@@ -449,8 +442,8 @@ The diagrams use a Petri-net-like convention:
 
 ### Whole-System Artifact Graph
 
-This graph starts with a partial function definition in k syntax and an input
-enveloped value. It ends with an output enveloped value. Lowering paths branch
+This graph starts with a relation definition in k syntax and an input
+framed value `(schema, payload)`. It ends with an output framed value. Lowering paths branch
 after the k object.
 
 ```mermaid
@@ -467,8 +460,8 @@ flowchart TB
     Src["k source<br/>program"]:::artifact
     Parse["source<br/>parsing"]:::transform
     AST["parsed<br/>AST"]:::artifact
-    Annotate["pattern-signature<br/>derivation"]:::transform
-    Core["pattern-annotated<br/>core"]:::artifact
+    Annotate["contract<br/>derivation"]:::transform
+    Core["contract-annotated<br/>core"]:::artifact
     Package["object<br/>packaging"]:::transform
     Object["k<br/>object"]:::artifact
     Src --> Parse --> AST --> Annotate --> Core --> Package --> Object
@@ -476,18 +469,18 @@ flowchart TB
 
   subgraph Input["prepare the input value"]
     direction LR
-    InputValue["input<br/>enveloped value"]:::value
-    ExtractEnvelope["input-envelope<br/>extraction"]:::transform
-    InputEnvelope["input<br/>envelope"]:::artifact
+    InputValue["input framed value<br/>(schema, payload)"]:::value
+    ExtractEnvelope["input-schema<br/>extraction"]:::transform
+    InputEnvelope["input<br/>schema"]:::artifact
     InputValue --> ExtractEnvelope --> InputEnvelope
   end
 
-  subgraph Reference["reference envelope-aware execution"]
+  subgraph Reference["reference schema-aware execution"]
     direction LR
     Select["entry<br/>selection"]:::transform
-    EntryFunction["entry partial<br/>function"]:::artifact
+    EntryFunction["entry<br/>relation"]:::artifact
     ReferenceRun["reference<br/>evaluation"]:::transform
-    OutputValue["output<br/>enveloped value"]:::result
+    OutputValue["output framed value<br/>(schema, payload)"]:::result
     Select --> EntryFunction --> ReferenceRun --> OutputValue
   end
 
@@ -495,9 +488,9 @@ flowchart TB
     direction LR
     ExportKIR["KIR-P<br/>export"]:::transform
     KIRP["KIR-P"]:::artifact
-    Specialize["envelope<br/>specialization"]:::transform
-    SpecializedKIRP["envelope-specialized<br/>KIR-P"]:::artifact
-    OutputEnvelope["output<br/>envelope"]:::artifact
+    Specialize["schema<br/>specialization"]:::transform
+    SpecializedKIRP["schema-specialized<br/>KIR-P"]:::artifact
+    OutputEnvelope["output<br/>schema"]:::artifact
     ExportKIR --> KIRP --> Specialize --> SpecializedKIRP
     Specialize --> OutputEnvelope
   end
@@ -533,8 +526,8 @@ flowchart TB
 ### Reference Execution Graph
 
 The reference path is the semantic baseline. It can run directly from source or
-from a loaded k object. It stays envelope-aware: the value keeps its envelope
-through projections, constructors, pattern guards, and partial-function calls.
+from a loaded k object. It stays schema-aware: the value keeps its schema framing
+through projections, constructors, filters, and relation calls.
 
 ```mermaid
 %%{init: {"flowchart": {"htmlLabels": true, "nodeSpacing": 42, "rankSpacing": 50}, "themeVariables": {"fontSize": "18px"}} }%%
@@ -544,16 +537,16 @@ flowchart LR
   classDef value fill:#e8f7ee,stroke:#16a34a,stroke-width:1.5px,color:#052e16;
   classDef result fill:#fff1f2,stroke:#e11d48,stroke-width:1.5px,color:#4c0519;
 
-  Source["partial function<br/>definition in k syntax"]:::artifact
-  Input["input<br/>enveloped value"]:::value
+  Source["relation<br/>definition in k syntax"]:::artifact
+  Input["input framed value<br/>(schema, payload)"]:::value
   Parse["source<br/>parsing"]:::transform
   AST["parsed<br/>AST"]:::artifact
-  Annotate["pattern-signature<br/>derivation"]:::transform
-  Core["pattern-annotated<br/>core"]:::artifact
+  Annotate["contract<br/>derivation"]:::transform
+  Core["contract-annotated<br/>core"]:::artifact
   Select["entry<br/>selection"]:::transform
-  Transform["partial function with<br/>pattern signature"]:::artifact
+  Transform["relation with<br/>contract"]:::artifact
   Run["reference<br/>evaluation"]:::transform
-  Output["output<br/>enveloped value"]:::result
+  Output["output framed value<br/>(schema, payload)"]:::result
 
   Source --> Parse --> AST --> Annotate --> Core --> Select --> Transform
   Transform --> Run
@@ -563,8 +556,8 @@ flowchart LR
 
 ### Lowering Preparation Graph
 
-The lowering preparation path starts from a k object and an input envelope. It
-specializes the program for that envelope, derives the output envelope, lowers
+The lowering preparation path starts from a k object and an input schema. It
+specializes the program for that schema, derives the output schema, lowers
 to a lowered execution artifact, and may then lower to a concrete execution
 target.
 
@@ -576,12 +569,12 @@ flowchart LR
   classDef lowered fill:#f3e8ff,stroke:#7e22ce,stroke-width:1.5px,color:#2e1065;
 
   Object["k<br/>object"]:::artifact
-  InputEnvelope["input<br/>envelope"]:::artifact
+  InputEnvelope["input<br/>schema"]:::artifact
   Export["KIR-P<br/>export"]:::transform
   KIRP["KIR-P"]:::artifact
-  Specialize["envelope<br/>specialization"]:::transform
-  Specialized["envelope-specialized<br/>KIR-P"]:::artifact
-  OutputEnvelope["output<br/>envelope"]:::artifact
+  Specialize["schema<br/>specialization"]:::transform
+  Specialized["schema-specialized<br/>KIR-P"]:::artifact
+  OutputEnvelope["output<br/>schema"]:::artifact
   LowerModel["execution-model<br/>lowering"]:::transform
   Lowered["lowered execution<br/>artifact"]:::lowered
   TargetLowering["target<br/>lowering"]:::transform
@@ -599,7 +592,7 @@ flowchart LR
 ### Wire Boundary Graph
 
 The wire boundary is separate from program compilation. It converts between a
-binary pattern+value stream and the in-memory enveloped value that execution
+binary schema+payload stream and the in-memory framed value that execution
 uses.
 
 ```mermaid
@@ -611,9 +604,9 @@ flowchart LR
 
   InputWire["input wire<br/>stream"]:::value
   Decode["wire<br/>decoding"]:::transform
-  InputValue["input<br/>enveloped value"]:::value
+  InputValue["input framed value<br/>(schema, payload)"]:::value
   Execute["reference/target<br/>execution"]:::transform
-  OutputValue["output<br/>enveloped value"]:::result
+  OutputValue["output framed value<br/>(schema, payload)"]:::result
   Encode["wire<br/>encoding"]:::transform
   OutputWire["output wire<br/>stream"]:::result
 
@@ -629,7 +622,7 @@ Use noun phrases ending in the operation kind:
 - `Parsing` for syntax to AST.
 - `Registration` for assigning canonical identities.
 - `Construction` for building semantic tables from parsed material.
-- `Derivation` for computing type-pattern information.
+- `Derivation` for computing schema contracts.
 - `Canonicalization` for stable names and hashes.
 - `Packaging` for serializable artifacts.
 - `Loading` for reconstructing semantic objects from artifacts.
@@ -637,7 +630,7 @@ Use noun phrases ending in the operation kind:
 - `Evaluation` for executing a semantic or lowered execution artifact.
 - `Extraction` for reading a component from an artifact without changing it.
 - `Export` for a stable inspection or interchange view.
-- `Specialization` for rewriting an artifact for a concrete envelope.
+- `Specialization` for rewriting an artifact for a concrete input schema.
 - `Lowering` for moving to a lower-level execution contract.
 - `Encoding` and `Decoding` for wire boundaries.
 - `Rendering` for human or external presentation.
@@ -651,24 +644,24 @@ names.
 | Identifier | Preferred name | Inputs | Outputs |
 | --- | --- | --- | --- |
 | `source-parsing` | Source Parsing | k source program | parsed AST |
-| `type-code-registration` | Type-Code Registration | parsed AST | canonical type-code table |
-| `partial-function-table-construction` | Partial-Function Table Construction | parsed AST, canonical type-code table | source partial-function table |
-| `pattern-signature-derivation` | Pattern-Signature Derivation | source partial-function table, canonical type-code table | pattern-annotated core |
-| `partial-function-canonicalization` | Partial-Function Canonicalization | pattern-annotated core | canonical partial-function aliases |
-| `object-packaging` | Object Packaging | pattern-annotated core, canonical partial-function aliases | k object |
+| `schema-registration` | Schema Registration | parsed AST | canonical schema table |
+| `relation-table-construction` | Relation Table Construction | parsed AST, canonical schema table | source relation table |
+| `contract-derivation` | Contract Derivation | source relation table, canonical schema table | contract-annotated core |
+| `relation-canonicalization` | Relation Canonicalization | contract-annotated core | canonical relation aliases |
+| `object-packaging` | Object Packaging | contract-annotated core, canonical relation aliases | k object |
 | `object-loading` | Object Loading | k object | loaded k object |
-| `entry-selection` | Entry Selection | pattern-annotated core or loaded k object | entry partial function |
-| `reference-evaluation` | Reference Evaluation | entry partial function, input enveloped value | output enveloped value or partial failure |
-| `input-envelope-extraction` | Input-Envelope Extraction | input enveloped value | input envelope |
+| `entry-selection` | Entry Selection | contract-annotated core or loaded k object | entry relation |
+| `reference-evaluation` | Reference Evaluation | entry relation, input framed value | output framed value or partial failure |
+| `input-schema-extraction` | Input-Schema Extraction | input framed value | input schema |
 | `kir-p-export` | KIR-P Export | k object | KIR-P |
-| `envelope-specialization` | Envelope Specialization | KIR-P or k object, input envelope | envelope-specialized KIR-P, output envelope |
-| `execution-model-lowering` | Execution-Model Lowering | envelope-specialized KIR-P | lowered execution artifact |
-| `lowered-evaluation` | Lowered Evaluation | lowered execution artifact, input enveloped value | output enveloped value or partial failure |
+| `schema-specialization` | Schema Specialization | KIR-P or k object, input schema | schema-specialized KIR-P, output schema |
+| `execution-model-lowering` | Execution-Model Lowering | schema-specialized KIR-P | lowered execution artifact |
+| `lowered-evaluation` | Lowered Evaluation | lowered execution artifact, input framed value | output framed value or partial failure |
 | `target-lowering` | Target Lowering | lowered execution artifact | target artifact |
-| `target-execution` | Target Execution | target artifact, input enveloped value or input wire stream | output enveloped value or output wire stream |
-| `wire-decoding` | Wire Decoding | input wire stream | input enveloped value |
-| `wire-encoding` | Wire Encoding | output enveloped value | output wire stream |
-| `external-rendering` | External Rendering | output wire stream or output enveloped value | external text, JSON, or host value |
+| `target-execution` | Target Execution | target artifact, input framed value or input wire stream | output framed value or output wire stream |
+| `wire-decoding` | Wire Decoding | input wire stream | input framed value |
+| `wire-encoding` | Wire Encoding | output framed value | output wire stream |
+| `external-rendering` | External Rendering | output wire stream or output framed value | external text, JSON, or host value |
 
 ### Abstract Transformation Contracts
 
@@ -1189,13 +1182,13 @@ Independent tests:
 ### Transformation Notes
 
 - Compilation transformations do not need an input value until
-  envelope-specialization or execution.
-- Reference execution can use the pattern-annotated core directly; target
+  schema-specialization or execution.
+- Reference execution can use the contract-annotated core directly; target
   execution goes through KIR-P and a lowered execution artifact.
-- Envelope-specialization is not a new source language feature. It is a compiler
-  transformation driven by the input envelope.
-- The output envelope is an artifact of execution or specialization. It must be
-  preserved at binary boundaries even when printed value trees look identical.
+- Schema-specialization is not a new source language feature. It is a compiler
+  transformation driven by the input schema.
+- The output schema is an artifact of execution or specialization. It must be
+  preserved at binary boundaries even when printed payload trees look identical.
 - Partial failure is an ordinary result of execution transformations. It should
   not be modeled as a malformed artifact.
 
@@ -1206,10 +1199,10 @@ Use this pipeline in high-level docs:
 ```text
 k source
   -> parsed AST
-  -> pattern-annotated core
+  -> contract-annotated core
   -> k object
   -> KIR-P
-  -> envelope-specialized KIR-P
+  -> schema-specialized KIR-P
   -> lowered execution artifact
   -> target artifact
 ```
@@ -1217,23 +1210,23 @@ k source
 For the execution and codec boundary:
 
 ```text
-wire stream <-> enveloped value <-> partial function <-> enveloped value <-> wire stream
+wire stream <-> framed value (schema, payload) <-> partial relation <-> framed value (schema, payload) <-> wire stream
 ```
 
 ## Terminology Rules
 
 These rules are normative for this specification:
 
-- Use "partial function" as the dominant public term. Avoid "partial
-  transform"; it can read as unfinished rather than undefined for some inputs.
-- Keep "pattern-annotated core" as the name for the normalized,
-  anonymized, pattern-annotated AST stage.
-- Use "envelope-specialized KIR-P" for KIR-P rebuilt under a concrete input
-  envelope.
-- Use "type code" for the canonical representation of a type, and "type" for
-  the semantic concept.
-- Use "envelope" for the type pattern carried with a value at an execution or
-  wire boundary.
-- Use "pattern guard" for the semantic operation that constrains an envelope;
-  reserve "filter expression" for source syntax when the syntax itself is being
-  discussed.
+- Use "relation" or "partial relation" as the dominant public term.
+- Keep "contract-annotated core" as the name for the normalized,
+  contract-annotated AST stage.
+- Use "schema-specialized KIR-P" for KIR-P rebuilt under a concrete input
+  schema.
+- Use "canonical schema" for the deterministic representation of a schema,
+  and "schema" for the semantic language of payload trees.
+- Use "contract" for the connected $(input, output)$ schema graph derived
+  for relations, capturing structural preservation ($=X$).
+- Use "framed value `(schema, payload)`" for the self-describing value
+  at execution and wire boundaries.
+- Use "filter" for the syntactic expression `?schema` that constrains
+  payloads and acts as inductive termination witness.