Appendix S — Glossary and Terminology Cross-Reference

“The package moves the value into an async thread, so the borrow is valid for the task’s lifetime.”

Every noun in that review sentence sounds familiar. Almost every relationship in it is unclear.

A Cargo package does not execute. A package contains targets; each target is compiled as a crate. A move changes which place may subsequently be used as an owner, not necessarily where bytes reside. An async task is not necessarily an operating-system thread. A borrow creates a reference or otherwise borrowed access under constraints; “valid for the task’s lifetime” might mean a Rust lifetime relationship, the wall-clock duration of one poll, or the operational lifecycle from spawn through join. Those are different claims with different evidence.

A reviewable rewrite is narrower:

The relay-service binary target spawns a runtime task that owns an Arc<Batch>. The task may be polled on different operating-system threads because its spawned future satisfies the selected runtime’s Send bound. No reference into request-local storage crosses the spawn boundary. The service retains the join handle and joins the task before dropping the batch store.

The rewrite is longer because it names four boundaries: build unit, ownership, scheduling, and service lifecycle. It is also testable. Cargo metadata can identify the target and crate. The type checker can reject a non-Send spawned future for a runtime API that requires Send. Source inspection can establish that the future owns the Arc. Deterministic shutdown tests can observe joining. None of those observations proves all the others.

Use this glossary to recover that precision. A compact definition identifies the governing distinction and points to the fuller argument; it does not replace the Reference, library documentation, a runtime’s pinned contract, or a safety case.

Use the glossary at the boundary that is failing

Do not read this appendix as a second syntax tour. Start with the boundary in dispute:

• Build and distribution: workspace, package, Cargo target, crate, module, item, path, feature, and artifact.
• Memory and responsibility: place, value, binding, ownership, move, copy, clone, borrow, reference, raw pointer, lifetime, scope, and drop.
• Unsafe proof: validity, initialization, invariant, undefined behavior, safety, soundness, provenance, and aliasing.
• Execution and failure: thread, future, task, executor, reactor, runtime, concurrency, parallelism, blocking, cancellation, backpressure, panic, and error.
• Compatibility and evidence: edition, toolchain, MSRV, API, ABI, SemVer, guarantee, current implementation, convention, recommendation, third-party behavior, and evidence.

Use the definition to separate the claims, follow its chapter routes for the full model, then use Appendix T to identify the controlling authority and version. If the dispute crosses two rows, write two claims; a single overloaded sentence is usually the defect.

Read the system from package to item

The same repository name is often used loosely for a project, package, library, crate, and service. Keep the layers distinct:

workspace
└── package: one Cargo manifest-defined unit
    ├── target: a buildable library, binary, example, test, or benchmark
    │   └── crate: one Rust compilation unit
    │       └── module tree: namespace and privacy structure
    │           └── item: function, type, trait, impl, const, static, module, ...
    └── artifact: output produced from a selected target and configuration

Workspace. A Cargo coordination scope containing one or more packages with shared resolution and a shared output directory. A virtual workspace need not itself be a package. Workspace policy can centralize metadata, dependencies, profiles, lints, and release operations, but it does not fuse member crates into one Rust visibility boundary. See Chapters 39–44 and Appendix I.

Package. A Cargo distribution and build unit described by a Cargo.toml. A package may define several targets and therefore produce several crates. Package version, features, dependencies, and rust-version are Cargo concerns. “One package” does not mean “one binary” or “one crate.” The Cargo glossary is the controlling vocabulary source. See Chapters 39–41 and Appendix I.

Target. A Cargo-selected build subject such as a library, binary, example, integration test, or benchmark. Each target compiles as a crate. “Target” is overloaded: a Cargo target is this build subject, while a compiler target or target triple identifies a platform such as x86_64-unknown-linux-gnu. State which meaning applies. See Chapters 40–43, 82, 94, and 95.

Crate. One Rust compilation unit: either a library crate or binary crate. The crate has one outermost module and is the boundary for compilation, crate paths, coherence reasoning in many common cases, and pub(crate) visibility. A dependency edge connects crates, not arbitrary modules. “Crate” is sometimes used loosely for a registry archive; use published package archive when the distribution object matters. See Chapters 1, 39–44, and Appendix I.

Module. A named or outermost container in a crate’s module tree. Modules organize paths, scopes, and privacy; they are not independently compiled libraries. A source file can supply a module body, but file layout and module structure are related conventions rather than synonyms. The Reference defines a module as a container for items. See Chapters 1 and 39 and Appendix A.

Item. A compile-time component of a crate, including functions, type definitions, traits, implementations, constants, statics, modules, and the other forms listed by the Reference’s item grammar. Items differ from local bindings and runtime values. An associated function is an item; a value returned by calling it is not. See Chapters 4, 13–25, and Appendix A.

Path. Syntax that resolves to an item, type, variant, local binding, or other named entity according to its context and namespace. A filesystem path locates a file; a Rust path such as crate::store::Batch names through the module system. A Cargo path dependency locates a package. Qualify “path” when more than one is plausible. See Chapters 1, 4, 39–41, and Appendix A.

Feature. Most often, a named Cargo conditional-compilation capability. The same word also names unstable Cargo/rustc/rustdoc flags and CPU target features. A Cargo feature is additive configuration input, not a separate package edition or a permission system. See Chapter 41 and Appendices I, J, P, and Q.

Artifact. A file or set of files produced by a build: executable, library, object, generated documentation, firmware image, or another declared output. An artifact record is incomplete without the package/target, toolchain, target triple, profile, features, dependency resolution, and relevant build inputs. See Chapters 42–44, 82, 93–99, and Appendices P and Q.

Separate places, values, and ownership operations

Rust’s ownership vocabulary becomes clearer when the memory location and the value held there are not collapsed:

place expression ──evaluated in value context──> value
      │                                      ├── Copy type: copy value
      │                                      └── non-Copy movable value: move out
      ├── &place  ──> shared reference carrying borrowed access
      └── &mut place ──> mutable reference carrying exclusive borrowed access

The type, context, initialization state, and active borrows constrain each edge.
No edge promises a physical byte copy, allocation, or address change unless its API does.

Place. An expression representing a memory location, such as a local, static, dereference, field, or indexed element in the cases defined by the Reference. A place can be read, moved from when permitted, borrowed, assigned when mutable, or become deinitialized. It is not simply “a variable.” See Chapter 4 and Appendix A; the authoritative distinction is place expressions and value expressions.

Value. The result represented or produced by evaluating an expression. A value has a type and may be stored in a place, passed, returned, copied, moved, borrowed through a place, or dropped. “The value’s address” is meaningful only after naming a representation and place; values are not defined by permanent addresses. See Chapters 4–6 and Appendix A.

Binding. A name introduced by a pattern and associated with a value or place access according to the pattern context. let mut x makes the binding mutable; it does not mean every value reachable from x has unrestricted interior mutation. Shadowing creates a new binding. See Chapters 1, 4, 6, and Appendix A.

Ownership. The program relationship that determines which binding, field, container, or task is responsible for a value and its eventual destruction or transfer. Ownership is a semantic design model supported by Rust’s move and drop rules; it is not a runtime registry. Shared ownership through Rc or Arc is still ownership, with destruction triggered when the strong-owner condition is met. See Chapters 2 and 6–12 and Appendix B.

Move. A by-value transfer after which the moved-from place may not be read until it is reinitialized, subject to the precise move rules. A move is not guaranteed to copy bytes, allocate, clear the source, or change an address. Optimized machine code may implement no data motion at all. Partial moves can leave other fields usable when the type and drop rules permit. See Chapter 6 and Appendix B.

Copy. The implicit duplication used when a value’s type implements Copy in a context that would otherwise move. Both values can then be used independently according to their types. Copy is a language trait contract, not a guarantee that a particular instruction or number of bytes appears after optimization. Types with destructors cannot implement it. See Chapter 6 and Appendices B and D.

Clone. An explicit operation through Clone whose cost and semantics are type-defined. It may copy bytes, allocate, increment a reference count, duplicate an operating-system resource through a platform operation, or perform other documented work. clone() does not mean “deep copy,” “cheap,” or “new identity.” See Chapters 6, 12, 29, and 85 and Appendices B and F.

Borrow. Temporary access that does not transfer ownership, governed by aliasing, mutation, and lifetime constraints. Borrowing often produces a reference, but the language also uses implicit borrowing and reborrowing in method calls, patterns, and operators. “The borrow ends” means its constraints cease to be needed; it does not necessarily name a lexical closing brace or runtime event. See Chapters 7–10 and Appendices B and C.

Reference. A &T or &mut T value that refers to a valid place under Rust’s reference rules. Shared references permit shared access and restrict mutation except through UnsafeCell-based mechanisms; mutable references express exclusive access for their active use. References are never null and carry validity and aliasing obligations that raw pointers do not automatically provide. See Chapters 7–10, 28, 67–69, and Appendices B, C, and K.

Raw pointer. A *const T or *mut T value. Creating or carrying one is often safe; dereferencing and many operations require the caller to establish operation-specific validity, alignment, initialization, provenance, and aliasing facts. *const versus *mut does not by itself enforce the reference aliasing rules. See Chapters 66–70 and Appendices K and L.

Lifetime. A compile-time relationship constraining how long references or other lifetime-parameterized values may be used relative to one another. A lifetime annotation does not extend storage, schedule destruction, keep a task running, or represent elapsed time. 'static means the relevant reference may be valid for the program’s duration or that an owned type contains no non-'static borrows, depending on context; it does not mean “lives forever” or “global allocation.” See Chapters 8–9 and Appendix C.

Scope. A region of source text in which a name may be referred to, or one of several language-defined regions used for drops and temporary lifetime extension. Scope and lifetime frequently interact but are not interchangeable: a borrow can end before the enclosing name’s scope, and a value’s operational lifecycle can span multiple scopes through ownership transfer. See Chapters 4, 8, and 11 and Appendix C.

Drop. Running destruction for a value when its drop scope or owning container requires it, including user-defined Drop where present, followed by field destruction rules. drop(x) is an ordinary by-value call that causes x to be destroyed at that point; it does not call a destructor method directly. Leaking and process termination show why “every value is always dropped” is false. See Chapter 11 and Appendices H and K.

Keep validity, safety, and soundness at different proof levels

These words all constrain unsafe reasoning, but they answer different questions:

Validity. The requirements a value of a type must satisfy at the relevant operation and program point. Validity includes more than allocation: references have alignment, non-null, dereferenceability, initialization, and aliasing-related requirements; enums require valid discriminants; bool and char have restricted values; a slice requires a coherent pointer/length relationship. The exact requirement depends on the type and operation. See Chapters 26–28 and 66–70 and Appendices K and L.

Initialization. The state in which storage contains a value sufficiently formed for the operation that will observe it. Allocated bytes are not automatically initialized as T; zeroed bytes are not valid for every T; writing fields piecemeal does not permit creating a reference to the whole T early. See Chapters 26–27 and 67 and Appendix K.

Invariant. A property that must hold at declared boundaries or throughout declared transitions. A type invariant might hold whenever safe public methods return; a data-structure invariant may be temporarily broken inside a private operation if panic and unsafe paths cannot expose the broken state; a service invariant may span durable storage and acknowledgements. Name the boundary and preservation obligations. See Chapters 2, 12–17, 33, 46–51, and Appendix R.

Undefined behavior (UB). Program behavior outside Rust’s permitted execution because a language or library safety rule has been violated. UB is not a specified panic, error return, nondeterministic but permitted result, deadlock, race at the application level, or merely undesirable outcome. Once UB occurs, ordinary reasoning about later observations is unavailable. The Reference’s current UB list is intentionally not claimed as a complete final model. See Chapters 66–74 and Appendix K.

Safety. Context-dependent. Memory safety concerns defects such as invalid access and data races in the language sense. An unsafe fn publishes caller obligations; an unsafe block asserts that the enclosed operations’ preconditions are established. Product safety, security, panic freedom, deadlock freedom, correctness, and operational reliability are separate properties. “Written in safe Rust” is meaningful evidence about access to unsafe capabilities, not a proof of business correctness. See Chapters 2, 66–74, 91–93, and Appendices K, P, and R.

Soundness. The property that a safe interface cannot be used by safe callers to cause UB. Soundness is non-local across the private state and safe methods that establish or preserve assumptions used by unsafe code. An abstraction can be sound yet wrong for its product contract; it can return incorrect results, leak resources, deadlock, panic, or violate an SLO without causing UB. The Rustonomicon’s safe/unsafe boundary and working-with-unsafe discussion provide project guidance. See Chapters 66–74 and Appendix K.

Provenance. The abstract permission and origin information associated with a pointer in addition to its numerical address. Provenance constrains which memory a pointer may access and how derived pointers relate to allocations. The standard library’s std::ptr documentation provides stable Strict Provenance APIs while stating that Rust’s full provenance and aliasing model is not finalized. Do not promote Stacked Borrows, Tree Borrows, Miri behavior, or an integer round-trip that happens to work into a language guarantee. See Chapters 68–70 and 74 and Appendix K.

Aliasing. Multiple access paths that can designate overlapping storage. Whether aliasing is permitted depends on the pointer/reference kinds, mutation, operation, and active guarantees. “Two pointers have the same address” is not a complete aliasing or provenance argument. See Chapters 7, 10, 27–30, and 68–70 and Appendices B, F, and K.

Distinguish execution carriers from deferred computations

The word running hides several layers:

future: deferred computation polled through Future::poll
   │ owned and scheduled as part of
task: runtime/executor scheduling unit and lifecycle
   │ polled on zero, one, or several times over
OS thread: operating-system execution context
   │ selected by
executor/scheduler within a runtime
   └── often paired with reactor, timers, I/O drivers, channels, and blocking pool

Thread. In this handbook, an operating-system thread represented in Rust by facilities such as std::thread. It has its own stack and is scheduled by the operating system. A thread can execute many functions and may poll many async tasks over time. A Rust thread is not a Cargo target, async task, or CPU core. See Chapters 52–57 and Appendices M and N.

Future. A value implementing Future, representing an asynchronous computation that may yield Pending or complete once with Ready(Output) when pinned and polled under its contract. Futures are lazy in the standard execution model: creating one does not by itself guarantee polling. A future may contain a tree of child futures and may be polled directly inside another task without being separately spawned. See Chapters 58–64 and Future::poll.

Task / async task. A logical concurrent sequence managed by an executor or runtime, usually owning a top-level future plus scheduling state. Rust’s standard library exposes task primitives such as Waker, but the language does not define one universal spawn, join, cancellation, fairness, or task-local-storage contract. Those behaviors belong to the selected runtime and version. See Chapters 57–64, Appendix M, and the Async Book’s futures, tasks, and runtime terminology.

Executor. The mechanism that drives futures by polling them when they may make progress. Its scheduling policy, queueing, thread use, fairness, and shutdown are implementation or runtime contracts. An executor can be single-threaded; async does not imply parallel execution. See Chapters 58–60 and the Async Book’s executor walkthrough.

Reactor. A component that observes external readiness—commonly I/O, timers, or platform events—and arranges wakeups. Not every executor has a separately named reactor, and not every future is I/O-driven. See Chapter 59.

Runtime. A crate or subsystem combining an executor with some collection of reactors, timers, I/O drivers, synchronization tools, task APIs, blocking facilities, and operational behavior. Rust does not ship one mandatory async runtime. “The runtime cancels it” is incomplete until the named runtime API, pinned version, ownership boundary, and cancellation event are stated. See Chapters 59–64 and Appendix M.

Concurrency. Multiple computations whose executions overlap or can make progress in interleaved periods. Concurrency does not require simultaneous execution. Threads, tasks, processes, signals, callbacks, and state machines can introduce concurrency. See Chapters 52–64.

Parallelism. Simultaneous execution on multiple processing resources. A concurrent single-threaded executor need not be parallel; a data-parallel computation may use multiple threads without async. See Chapters 52, 57, and 65.

Blocking. Preventing an execution carrier from making other intended progress until an operation completes. Blocking an OS thread is different from a future returning Pending; holding a mutex while waiting creates another form of progress obstruction. State what is blocked and which bounded resource it consumes. See Chapters 54–55, 59, 62, and 89–90.

Cancellation. A contract for what happens when interest or authority to continue is withdrawn. Dropping a future stops future polling of that future but does not universally revoke already-started external effects or detached child tasks. A timeout may only stop waiting. Define commit points, cleanup, idempotency, result discovery, and child ownership. See Chapters 60–64, 89–90, and Appendices M and R.

Backpressure. A bounded mechanism by which downstream capacity changes upstream admission, waiting, rejection, shedding, or degradation. A queue is not backpressure merely because it exists; an unbounded queue postpones refusal into memory growth and latency. See Chapters 56, 62, and 90 and Appendix M.

Panic. Rust’s language/library failure mechanism for conditions that are not returned as ordinary values. Depending on the panic strategy and boundary, panic may unwind or abort. A panic is not UB by itself and is not interchangeable with a recoverable Result::Err. See Chapters 33 and 36–38 and Appendices H and R.

Error. A value or report describing a failure callers or operators may handle. Error contracts should preserve distinctions needed for correction, retry, rollback, escalation, or termination. Not every failure should be an error value: absence may be Option, violated internal assumptions may panic or terminate by policy, and UB is outside the error model. See Chapters 33–38, 49, and Appendices H and R.

Name compatibility and evidence precisely

Edition. A language-compatibility mode selected per package target, such as Rust 2024. Editions let projects adopt coordinated language changes while crates of different editions interoperate. Edition is not compiler release, package version, or MSRV. See Chapter 3 and Appendices I and Q.

Compiler release / toolchain. A versioned rustc and, for a toolchain record, associated Cargo, rustfmt, Clippy, standard library, target components, and channel. rustc 1.97.0 and “stable” are different identifiers: stable advances. See Chapters 3, 42, 82, and 99 and Appendix Q.

MSRV. The minimum supported Rust version under a project’s declared policy and support scope. An MSRV is a consumer promise only when the product states which targets, features, commands, and components it covers and tests that matrix. The rust-version manifest field communicates a floor to Cargo but does not prove the whole policy. See Chapters 3, 40–44, 82, and 99 and Appendices I and Q.

API. A program-facing contract: callable items, types, traits, features, errors, panics, safety requirements, cancellation, blocking, behavior, and other documented consumer-relevant properties. pub visibility contributes to a Rust API but does not enumerate the full contract. See Chapters 45–51 and Appendices J, Q, and R.

ABI. The binary-level calling, layout, symbol, and platform convention through which compiled components interact. Rust’s ordinary ABI is not a stable cross-version interface. An extern "C" function selects a calling convention but does not alone settle ownership, layout for all types, unwinding, allocation, callbacks, or symbol/version policy. See Chapters 70 and 72–73 and Appendix L.

SemVer. A package-versioning convention and policy vocabulary for communicating compatibility. Cargo’s Rust-specific SemVer guidance catalogs source hazards, but version numbers do not prove compatibility, runtime safety, data migration, rollback, target support, or downstream behavior. See Chapters 44 and 51 and Appendices J and Q.

Guarantee. Behavior promised by the controlling language, standard library, tool, platform, crate, or product contract for a named version and scope. A guarantee should cite its authority and boundary. See Chapters 2–5 and Appendix T.

Current implementation. Reproduced behavior of a named compiler, library, optimizer, runtime, operating system, or tool configuration that is not promised as stable. Retain the reproducer, complete environment, observation, and recheck trigger. See Chapters 3, 5, 18, 26, 28, 58, 68, 74, 78, and 85–87 and Appendix T.

Convention. A common ecosystem practice not enforced by the language or controlling tool. Conventions can be useful defaults, but review must allow products to choose differently and must not call violation UB or compiler error without evidence. See Chapters 2–3, 39–44, and Appendix T.

Recommendation. The handbook’s reasoned design or operational judgment. A recommendation names trade-offs and product assumptions; it is not smuggled in as a guarantee. See Chapter 2 and Appendix T.

Third-party behavior. A contract or observation owned by a named crate, runtime, tool, platform, or standard outside the core Rust language and official tools. Pin the dependency or specification version, feature set, target, and relevant API. See Chapters 40–44, 59–64, 73–74, 81, 87–92, and 94–96 and Appendix T.

Evidence. An artifact or argument that discriminates a claim: compiler result, test, model, trace, benchmark distribution, safety case, source citation, target build, incident record, or downstream witness. Evidence has a scope and residual risk. Green CI is evidence that selected commands passed in one matrix, not proof of every contract. See Chapters 5, 74, 79–87, 93, 98–99, and Appendices O, P, R, and T.

Exercise: repair a review note without adding false certainty

Rewrite this note for a public library that offers an optional Tokio adapter:

The crate’s async runtime safely shares the buffer across threads. Its static lifetime means cancellation cannot invalidate it, and SemVer guarantees old users still compile.

Your repair must:

1. distinguish package, library target, crate, optional feature, and produced artifact;
2. say whether the public operation returns a future, spawns a runtime task, or both;
3. identify the actual owned value or reference and explain the relevant Send, Sync, and lifetime relationships;
4. state what drop or cancellation does before and after the external commit point;
5. separate language/standard-library guarantees from the pinned Tokio adapter contract;
6. identify at least one downstream witness for source compatibility and one behavior test;
7. replace “SemVer guarantees” with the project’s declared compatibility policy and evidence;
8. list the unresolved claim rather than filling it with a confident adjective.

A strong answer might choose an owned Bytes-like value retained by a runtime task, but it must pin and source that third-party type. Another strong answer may keep all borrowing within the caller-owned future and spawn nothing. The designs need different cancellation, Send, retention, and runtime-coupling contracts. Precision does not force one architecture; it makes the chosen architecture reviewable.

Terminology desk card

Before accepting a dense technical sentence, ask:

• Is the named thing a workspace, package, Cargo target, crate, module, item, runtime value, or artifact?
• Is the expression a place or value, and is the operation a move, implicit copy, explicit clone, borrow, reborrow, or drop?
• Does “lifetime” mean a Rust relationship, lexical scope, storage duration, task lifecycle, support window, or wall-clock time?
• Is the claim about validity, an unsafe precondition, soundness, product correctness, security, or operational reliability?
• Does a pointer argument preserve provenance, or only compare numerical addresses?
• Is work carried by an OS thread, future, executor task, process, callback, or external system?
• Does “cancel” stop polling, signal owned work, revoke an effect, wait for cleanup, or merely stop waiting?
• Is the statement a guarantee, current implementation observation, convention, recommendation, experimental behavior, or pinned third-party contract?
• What source and evidence control the claim, and what observation would falsify it?

If two reviewers use the same word for different layers, stop the review and name both layers. Terminology is not polish applied after the proof; it is part of the proof boundary.

Once the layer and relationship are named precisely, the remaining question is evidentiary: which source controls the claim, what version and scope it covers, and what observation would force a recheck?

Sources and version notes

• The Cargo glossary, Reference crate model, modules, and items control the package/crate/module/item distinctions.
• The Reference’s expression categories and move rules, borrow expressions, and destructors support the place/value/move/borrow/drop vocabulary.
• The Reference’s undefined-behavior chapter, standard library std::ptr module, and Rustonomicon safe/unsafe model have different authority and completeness. The full aliasing and provenance model is not presented here as finalized.
• Standard-library Future, std::task, and std::thread define core interfaces. The Async Book provides official project guidance; spawn, task, runtime, cancellation, fairness, and I/O behavior remain tied to a selected runtime and version.

This appendix uses the handbook’s Rust 1.97.0 snapshot dated 2026-07-09 for source selection. Its recorded local verification environment was Rust 1.93.1, so no new compiler-behavior claim here is represented as locally reproduced on 1.97.0. Recheck definitions and links against the active toolchain, and resolve disagreements through Appendix T’s authority order.