Vyr is a general-purpose programming language with systems capability, whose design is constrained by auditability of correctness, practical and predictable performance, local reasoning, robust tooling at scale, precisely defined semantics backed by tests, and a small coherent surface area. Vyr prioritizes correctness over cleverness and favors designs that are mechanically checkable, hard to misuse, easy to review, and stable under refactoring. Vyr prioritizes local reasoning so a reader can understand code from nearby context without relying on hidden control flow, hidden allocations, hidden global effects, or other action at a distance. Vyr prioritizes simplicity and coherence by preferring a smaller number of orthogonal features over overlapping feature piles, and when features overlap it prefers the option with clearer semantics, better tooling and refactoring properties, and lower long-term complexity cost. Vyr should remain capable of systems programming use cases that require low-level control over memory and layout, predictable latency and throughput, and tight integration with operating systems and hardware, but these capabilities must not force low-level complexity onto the majority of general-purpose code. Vyr must define a standard runtime distributed with the compiler, and the runtime must support a tracing garbage collector as an available fallback memory management strategy while allowing profiles that reduce runtime overhead when those services are not needed. Vyr should support multiple memory management strategies selected by static analysis, programmer intent, or profile policy, so code can use ownership or region-style management where beneficial and fall back to garbage collection where that is safer or simpler. Vyr must be safe by default, with safe code providing strong guarantees such as preventing memory corruption, type confusion, and undefined behavior attributable to safe constructs, and where concurrency is supported it should aim to prevent data races. Vyr must require an explicit unsafe boundary for operations that can violate core safety guarantees, so that unsafe capabilities are visibly contained and can be minimized and reviewed separately. Vyr must enable auditability of unsafe code by allowing tools to report where unsafe exists, what unsafe capabilities are used, and how unsafe usage propagates through the dependency graph. Vyr must make important operational effects visible in code structure and or types, including effects such as allocation, input output, spawning or concurrency, panic abort or exception-like control flow, sources of non-determinism, and unsafe capabilities. Vyr should avoid action at a distance by making function behavior discoverable from its signature and nearby declarations, especially with respect to allocation, input output, failure or abort behavior, and mutation of shared state. Vyr must support first-class contracts such as preconditions, postconditions, and invariants, so contracts can improve correctness, document intent precisely, and support testing and verification workflows. Vyr must integrate contracts and effects with tooling so failures and contract violations are surfaced clearly and tools can support contract-guided testing and help refactoring preserve contract intent. Vyr must make potentially failing operations explicit and typed in safe code, and must not rely on hidden unchecked exceptions; if panic or abort mechanisms exist they must be explicit, effect-visible, and controllable by build profile. Vyr must enable strong and reasonably predictable performance across common workloads, and it should provide low-level control paths for performance-critical code without requiring low-level techniques for routine programming. Vyr should follow a no hidden costs principle by avoiding features whose costs are routinely invisible at call sites, and when costs exist it should make them discoverable and tool-visible rather than surprising. Vyr should target zero-cost abstractions where practical, meaning high-level abstractions should compile down to efficient code without mandatory runtime penalties when this does not compromise auditability, tooling stability, simplicity, or semantic clarity. Vyr must be designed so high-quality tooling is practical and robust, including fast incremental builds, precise actionable diagnostics, reliable navigation such as definitions and references, stable deterministic formatting, and refactoring tools that preserve meaning. Vyr must include explicit compile-time and incremental-build performance targets and measure them on representative large codebases using reproducible benchmarks. Vyr should support tiered execution in the standard runtime, including just-in-time translation from Vyr source to Vyr IR and from Vyr IR to native code, with clear controls for ahead-of-time-only deployments. Vyr must provide stable, versioned, machine-readable interfaces for core semantic artifacts such as syntax trees, symbols, types, effects, and diagnostics, so third-party tools can integrate without depending on compiler internals. Vyr should favor constructs that are easy for tools to transform safely and should strongly discourage ambiguity, ad-hoc parsing tricks, and context-dependent meaning that undermines refactoring correctness. Vyr should scale to large mono-repositories and multi-package systems with predictable dependency boundaries, stable name resolution rules, deterministic builds, and reproducible outputs. Vyr should require explicit import and name-resolution behavior and should discourage wildcard imports that reduce local reasoning or tooling determinism. Vyr must strive for semantics that can be specified precisely, rejecting folklore semantics for core language behavior. Vyr must define a normative core semantics that is mechanically checkable or executable and backed by a conformance test suite with clear traceability between semantic rules and tests. Vyr should minimize implementation-defined and unspecified behavior, and where such behavior exists it must be explicitly identified and testable. Vyr should be readable by default with clear structure, consistent patterns, minimal syntactic noise, and meaningful defaults that support comprehension and review. Vyr should aim for a small number of canonical patterns for common tasks, and where multiple patterns exist they must be justified by clear tradeoffs rather than accidental complexity. Vyr should support progressive disclosure so everyday programming does not require mastering the full language, while advanced features exist without leaking complexity into routine code. Vyr should adopt sensible defaults that trend toward immutability unless mutation is requested, privacy and encapsulation at module boundaries, explicitness for potentially dangerous operations, and predictable evaluation and conversion rules. Vyr should interoperate well with existing native ecosystems, especially C-family ABIs, by supporting predictable data layout controls where required and providing foreign function interfaces that keep unsafe explicit rather than infecting safe code. Vyr should be portable across major platforms while keeping semantics tight, achieving portability through specification and tooling rather than by leaving behavior undefined. Vyr should avoid language complexity traps that historically harm tooling correctness, refactoring stability, readability, or semantic clarity, such as pervasive ad-hoc implicit conversions, context-sensitive parsing that changes meaning unexpectedly, and features whose semantics cannot be specified precisely. Vyr must not include implementation inheritance as a core abstraction model, and any inheritance-like extension mechanism must be narrowly scoped and must not undermine local reasoning, tooling, or semantic clarity. Vyr should prefer unique function names over overloading, and any overloading that exists must be narrowly constrained so it does not create ambiguous reading, break refactoring tools, or make diagnostics unreliable. Vyr acknowledges that certain constraint choices remain to be settled by future changes to this document, including the exact policy for strategy selection across ownership, region, and garbage-collected memory management in safe code, the core set of effects that must be visible and the minimal strategy to make them visible, detailed error-typing and panic-profile semantics, the concurrency guarantees, the module and package model needed for large-scale tooling stability, and the minimal escape hatches needed for systems work without making unsafe the default. The keywords MUST, SHOULD, and MAY in this document indicate strength of constraint, where MUST is a hard constraint that requires changing this document to violate, SHOULD is a strong preference with rare and well-justified exceptions, and MAY indicates optionality.