Nazm Language Grand Goals and Historical Barrier Constitution

File: NAZM_LANGUAGE_GOALS.md
Document class: Long-term language constitution / goal document
Purpose: Define what Nazm is ultimately trying to solve and why.
Status: Authoritative long-term goals; not an implementation-status document.

Constitution revision — 2026-09-22. This revision preserves the original historical-barrier and AI-era constitution, aligns the long-term memory ambition with the N7 memory constitution, and extends the domain ambition to best-in-class multi-profile compilation, WebAssembly and decentralized/Web3 execution. It does not upgrade any capability status; implementation truth remains owned by capability-matrix.md.

0. Authority and Interpretation

This document defines the long-term engineering ambition of the Nazm programming language.

It exists to prevent Nazm from becoming a collection of fashionable language features.

Nazm must instead understand the historical barriers that caused major programming languages and programming models to emerge, identify the deeper root problems behind those barriers, and attempt to solve as many of those root problems as possible through a small, coherent semantic foundation.

The governing principle is:

Nazm does not aim to contain every feature from every programming language. Nazm aims to understand why those features became necessary and solve the underlying problems with the smallest coherent set of semantic mechanisms possible.

This file expresses GOALS.

Implementation truth belongs elsewhere, particularly in:

• capability/status matrices;
• architecture records;
• specifications;
• test evidence;
• benchmark evidence;
• release provenance;
• research records.

A future implementation must never be marked complete merely because this file says Nazm intends to support it.

1. The Central Thesis

The history of programming languages can be understood partly as a sequence of barriers.

Developers repeatedly encountered a boundary:

machine code is too difficult
        ↓
assembly

assembly is too machine-specific
        ↓
higher-level compiled languages

systems languages are unsafe
        ↓
managed runtimes / ownership systems

shared-state concurrency is too difficult
        ↓
message passing / structured concurrency

dynamic languages are productive but slower
        ↓
JIT / specialization / modern native languages

CPUs are insufficient for massively parallel workloads
        ↓
GPU programming

general languages are difficult to verify
        ↓
restricted high-assurance languages

large codebases become too complex
        ↓
simpler languages + integrated tooling

human-readable source is still opaque to machines and AI
        ↓
semantic compiler interfaces

general-purpose execution assumes one trusted machine
        ↓
deterministic, capability-restricted and metered execution for decentralized systems

one compiler/runtime model rarely fits every domain
        ↓
one semantic language with restriction profiles and multiple backends

Nazm’s ambition is to attack these barriers together without simply stacking all historical solutions on top of each other.

The target is:

human clarity
+
machine control
+
native performance
+
memory safety
+
concurrency safety
+
failure isolation
+
predictable cost
+
high assurance
+
heterogeneous computing
+
AI-readable semantics
+
developer productivity
+
AI-era token efficiency
+
deterministic decentralized execution
+
portable sandboxed execution
+
resource-aware smart contracts

under one coherent language model.

1.1 What “best of the best” means

Nazm does not define “best” as winning one universal ranking. Programming-language goals conflict:

maximum low-level freedom        ↔ strongest static guarantees
maximum clean-build optimization ↔ minimum development latency
fully automatic management       ↔ deterministic resource lifetime
ambient convenience              ↔ capability security
general OS execution             ↔ deterministic smart-contract execution

The goal is therefore Pareto excellence under explicit profiles, not pretending the trade-offs do not exist.

Nazm should aim to be best-in-class, with evidence, across independently measured dimensions:

• semantic correctness;
• memory and concurrency safety;
• native runtime performance;
• predictable latency and resource use;
• compiler and incremental latency;
• binary size and startup;
• portability and cross compilation;
• embedded and systems control;
• server concurrency and fault isolation;
• high-assurance analyzability;
• WebAssembly portability;
• decentralized/Web3 determinism and resource metering;
• diagnostics and repair quality;
• interoperability and ecosystem adoption;
• reproducibility and provenance;
• AI semantic context efficiency;
• human and agent task-completion efficiency.

A claim of superiority in one dimension never silently becomes a claim about another.

1.2 One semantic language, many execution environments

The long-term shape is:

                         Nazm source
                              │
                     one semantic language
                              │
       ┌──────────────────────┼──────────────────────┐
       │                      │                      │
    General                Systems                Critical
       │                      │                      │
     Server                Embedded               Verified
       │                      │                      │
     AI/HPC                  WASM                  Web3
       └──────────────────────┼──────────────────────┘
                              │
                       profile restrictions
                              │
       ┌──────────────────────┼──────────────────────┐
       │                      │                      │
   native LLVM            WebAssembly         contract backends
                                                  │
                                   ┌──────────────┼──────────────┐
                                   │              │              │
                                  EVM           sBPF/SVM     future VMs

A profile may refuse constructs, authorities or nondeterministic operations. It must not reinterpret ordinary Nazm semantics. Web3 must therefore be a restricted execution profile and backend family, not a forked language dialect.

2. Historical Barrier Ledger

The following languages and programming models are not competitors to imitate.

They are engineering evidence.

Each emerged or became important because an earlier approach had a serious limitation.

2.1 Assembly — The Machine-Control Barrier

Barrier

Raw machine instructions were:

• difficult for humans;
• tied closely to specific hardware;
• error-prone;
• difficult to maintain;
• difficult to reuse.

Assembly introduced symbolic names and more manageable machine-level programming while retaining direct hardware control.

Lesson for Nazm

Machine control matters.

Nazm must eventually be capable of expressing:

• exact layouts;
• calling conventions;
• registers/intrinsics where justified;
• atomics;
• volatile operations;
• MMIO;
• SIMD;
• target-specific instructions;
• linker sections;
• interrupt boundaries;
• bare-metal startup.

Barrier left behind

Assembly still exposes enormous accidental complexity and weak portability.

Nazm goal

Retain machine-level capability without making machine-level representation the ordinary programming model.

2.2 FORTRAN — The Numerical Abstraction Barrier

FORTRAN demonstrated that a high-level language could express mathematical computation while compilers generated efficient machine programs.

Lesson

High abstraction and serious performance do not have to be opposites.

Nazm goal

Mathematical and numerical code should remain readable while lowering to efficient scalar, vector and accelerator execution.

A future Nazm programmer should not need to abandon Nazm merely because a numerical kernel becomes performance-critical.

2.3 Lisp — The Symbolic and Metaprogramming Barrier

Lisp demonstrated major ideas including:

• symbolic computation;
• programs as manipulable structure;
• dynamic programming environments;
• garbage-collected memory;
• powerful metaprogramming.

Lesson

A language can expose its own structure and become an environment for building abstractions rather than only executing instructions.

Nazm goal

Nazm should support powerful abstraction and compile-time program generation, but avoid uncontrolled textual macro systems.

Machine manipulation of code should preferably operate on structured syntax or semantic representations rather than arbitrary token substitution.

2.4 C — The Portable Systems Programming Barrier

What C solved

• portable systems implementation;
• efficient native execution;
• relatively small language;
• direct memory representation;
• predictable interoperability;
• simple ABI-friendly data;
• ability to write operating systems and runtimes.

What remained difficult

• unchecked pointer manipulation;
• memory lifetime errors;
• buffer errors;
• undefined behaviour;
• aliasing complexity;
• data races;
• manual resource discipline;
• limited semantic information for tools.

Nazm inheritance goal

Nazm must preserve:

native execution
machine control
small runtime possibility
C interoperability
explicit layout when required
predictable ABI
low-level escape hatch

while eliminating entire classes of accidental memory unsafety from normal code.

Nazm must not require developers to sacrifice safety merely to access the machine.

2.5 C++ — The Abstraction-without-Abandoning-Systems Barrier

What C++ demonstrated

High-level abstractions can coexist with:

• native code;
• deterministic object lifetime;
• generic programming;
• compile-time specialization;
• high performance;
• systems programming.

Barrier that accumulated

Long-lived compatibility plus continuous feature addition can create:

• language complexity;
• surprising implicit behaviour;
• difficult compile errors;
• long compilation;
• multiple overlapping abstraction mechanisms;
• large semantic surface area.

Nazm lesson

Nazm should seek zero-cost abstraction without adopting unlimited feature accumulation.

The number of language concepts must be treated as a performance and correctness budget.

Every major feature must justify why existing semantic primitives cannot express the same need.

2.6 Ada / SPARK — The High-Assurance Barrier

What this solved

For critical systems, ordinary testing is insufficient.

Developers may need evidence concerning:

• information flow;
• initialization;
• range correctness;
• overflow;
• contracts;
• absence of particular runtime errors;
• implementation/specification agreement.

Nazm lesson

Safety-critical capability cannot be created merely by adding a safe keyword.

Nazm must eventually support a restricted Critical Profile where analyzability is more important than unrestricted expressiveness.

Nazm goal

The language should eventually allow different assurance levels without becoming incompatible languages.

Example:

General Nazm
      ↓ restrictions
Systems Nazm
      ↓ restrictions
Embedded Nazm
      ↓ restrictions
Critical Nazm

Critical Nazm may intentionally reject valid General Nazm programs.

That is acceptable.

Analyzability is a feature.

2.7 Erlang — The Concurrency, Distribution and Failure Barrier

What Erlang solved unusually well

• massive lightweight concurrency;
• process isolation;
• asynchronous messaging;
• supervision;
• failure containment;
• distributed semantics;
• fail-fast components;
• long-running systems.

Fundamental lesson

A program does not become reliable merely because individual functions are correct.

Large systems fail.

The language/runtime architecture must decide:

What fails?
Who observes the failure?
Who owns recovery?
Can failure corrupt another component?
Can the system continue?

Nazm goal

Structured concurrency should eventually combine with failure domains.

Potential conceptual layers:

scope
 ├── task
 ├── task
 └── supervisor/resource domain

Nazm should distinguish:

• computation failure;
• task failure;
• resource failure;
• process failure;
• node failure.

Memory safety alone is not fault tolerance.

2.8 Haskell — The Semantic and Effect-Control Barrier

Lesson

Separating pure computation from effects provides enormous reasoning power.

Nazm goal

Nazm does not need to become purely functional.

But effects should become visible enough that the compiler can reason about them.

Possible effects include:

io
alloc
panic
spawn
block
network
filesystem
clock
random
ffi
unsafe

The compiler should increasingly answer:

What can this function do beyond transforming its inputs?

That information benefits:

• humans;
• optimizers;
• security;
• critical systems;
• AI agents;
• testing.

2.9 Java — The Portability, Robustness and Managed Runtime Barrier

What Java solved

• portable binary representation;
• managed memory;
• removal of pointer arithmetic;
• runtime verification;
• large portable standard platform;
• multithreading support;
• safer application programming.

Trade-off

Its traditional model depends heavily on:

VM
managed runtime
garbage collector
runtime metadata
JIT or bytecode execution

These are excellent trade-offs for many applications, but inappropriate for some:

• tiny embedded systems;
• kernels;
• hard real-time environments;
• extremely predictable latency requirements;
• certain native interoperability scenarios.

Nazm lesson

Portability must not require a mandatory VM.

Nazm’s portability model should primarily be:

portable semantics
+
portable source/Core IR
+
target-specific native generation

A VM or JIT may exist as an optional execution tier.

2.10 Python — The Human Productivity Barrier

What Python demonstrated

Human time is often more expensive than machine time.

A powerful language should minimize:

• ceremony;
• visual noise;
• unnecessary declarations;
• boilerplate;
• incidental complexity.

Barrier remaining for systems work

A highly dynamic runtime makes many low-level properties harder to guarantee statically:

• exact representation;
• predictable allocation;
• native performance without specialization;
• static resource bounds;
• bare-metal execution.

Nazm lesson

Nazm must treat readability and development speed as first-class performance metrics.

The language should pursue:

Python-like cognitive accessibility
without requiring Python-like runtime semantics.

Readable syntax is not cosmetic.

It is part of reliability.

2.11 Go — The Large-Software and Concurrency Complexity Barrier

What Go solved particularly well

• simple syntax;
• fast builds;
• explicit package dependencies;
• strong tooling;
• easy deployment;
• goroutines;
• channels;
• pragmatic server programming;
• standardized formatting.

Lesson

Developer throughput is a language-design concern.

A compiler that generates excellent code but takes excessive time or requires complex build orchestration has failed one dimension of performance.

Nazm goal

Treat:

compile time
incremental check time
tool startup
dependency resolution
diagnostics latency

as language-product performance.

Concurrency must also be easier than raw threads.

2.12 Rust — The Memory-Safety-without-GC Barrier

What Rust changed

Rust demonstrated that many failures traditionally accepted as unavoidable in systems programming can be prevented statically.

Examples include large classes of:

• use-after-free;
• double free;
• invalid references;
• unsafe aliasing;
• data races.

Trade-off

Exposing ownership and lifetime reasoning directly to programmers can introduce cognitive and type-system complexity.

Nazm research goal

Investigate whether Nazm can retain similar safety power while making common ownership patterns more implicit or value-oriented.

Potential direction:

observe
exclusive mutation
move/consume
initialize

with richer compiler-internal region reasoning.

The objective is not:

hide ownership until something breaks.

The objective is:

make safe ownership correspond naturally to programmer intent.

This remains a research problem until demonstrated.

2.13 Zig — The Hidden-Cost and Toolchain Barrier

Lesson

Performance problems frequently originate from invisible behaviour.

A developer should be able to determine whether code may:

• allocate;
• block;
• perform I/O;
• panic;
• synchronize;
• call foreign code;
• spawn work.

Nazm goal

Nazm should pursue semantic cost transparency.

This does not necessarily mean banning all abstraction.

Instead, high-level syntax should lower to behaviour that compiler tooling can expose precisely.

Example tooling:

nazm explain-cost foo

could eventually report:

allocations: 2 potential / 1 survives optimization
blocking: none
spawn: 4 tasks
dynamic dispatch: none
bounds checks: 3
copies: 1 surviving
FFI: none

2.14 CUDA — The Heterogeneous Parallelism Barrier

What CUDA solved

CPU-centric language models do not naturally expose thousands of parallel execution lanes.

New complexity

Heterogeneous computing introduces:

• host/device memory;
• data transfer;
• kernels;
• synchronization;
• occupancy;
• divergent execution;
• memory hierarchy;
• architecture-specific optimization.

Nazm long-term goal

Nazm should eventually support heterogeneous computation without splitting applications into unrelated programming languages.

Potential conceptual direction:

ordinary Nazm function
        ↓
compiler determines/accepts execution constraints
        ↓
CPU / SIMD / GPU / accelerator specialization

This is a long-term research goal.

The compiler must not pretend arbitrary code can automatically become efficient GPU code.

2.15 Julia — The Two-Language Performance Barrier

Historical barrier

Scientific developers often prototype in one language and rewrite performance-critical portions in another.

That creates:

• duplicated code;
• foreign interfaces;
• maintenance burden;
• optimization barriers;
• split expertise.

Nazm goal

Avoid a compulsory two-language architecture.

The code that expresses the algorithm should, where feasible, be the code that becomes the optimized implementation.

This requires:

• specialization;
• strong IR;
• escape analysis;
• vectorization;
• layout optimization;
• accelerator lowering.

2.16 Swift — The Safe-Native-Ergonomics Barrier

Lesson

Native languages do not need to present unsafe or highly technical syntax for ordinary application development.

Nazm goal

Use progressive disclosure.

Simple programs should look simple.

Low-level complexity should become visible only when the programmer needs low-level control.

2.17 Kotlin — The Adoption and Pragmatism Barrier

Lesson

A technically superior language can fail if adoption requires rewriting the world.

Nazm goal

Interoperability is part of language strategy.

Nazm should eventually interoperate strongly with existing systems rather than demanding complete rewrites.

Primary interoperability priorities should likely include:

C ABI
native static/shared libraries
system libraries
LLVM ecosystem
existing OS APIs

Higher-level ecosystem bridges may follow.

2.18 ML / OCaml — The Typed-Abstraction and Compiler-Construction Barrier

Lesson

Algebraic data types, exhaustive pattern matching, local type inference and compositional modules can make complex symbolic programs concise without surrendering static reasoning.

Nazm goal

User-defined product and sum types should be first-class, and pattern matching should make state machines, compilers, protocols and error handling explicit rather than encoding them through integer tags and parallel arrays.

The lesson is semantic compression, not a mandate to reproduce the entire ML module/type system.

2.19 TypeScript — The Large Dynamic-Ecosystem Tooling Barrier

Lesson

A language can add powerful static tooling to a large existing ecosystem without requiring every boundary to become statically pure. Structural typing, editor services and gradual adoption show that tooling quality can drive language adoption.

Nazm goal

Nazm should make semantic tooling, language-server services, migration and interoperability first-class, while avoiding a type system whose complexity exists mainly to model unrestricted dynamic-language patterns Nazm does not have.

2.20 WebAssembly — The Portable Sandboxed Execution Barrier

Barrier

Native machine code is efficient but tied to target ABIs and host authority. Browser and plugin environments require portable, sandbox-friendly execution with explicit host integration.

Nazm lesson

Portability should not require one heavyweight VM, and sandboxing should not require a separate source language.

Nazm goal

WebAssembly should become a first-class compilation target where the language subset and host capabilities are explicit. The same semantic source should be usable for browser, server, plugin and contract-oriented WASM environments where their host APIs permit it.

2.21 Solidity / EVM — The Deterministic Smart-Contract Barrier

Barrier

On-chain programs run under consensus. Ordinary assumptions about filesystem access, wall clock, networking, unrestricted loops and unmetered computation do not hold. Persistent state, external calls, ABI compatibility and resource cost become part of correctness.

Nazm lesson

A smart-contract language is not merely a normal language with a different code generator. Determinism, persistent state, external-call boundaries, storage layout and resource metering must be visible to the compiler.

Nazm goal

A future Web3 profile should permit EVM-oriented smart contracts without making EVM-specific semantics part of General Nazm. ABI, storage and event artefacts should be generated from typed semantic definitions rather than duplicated handwritten descriptions.

2.22 Move — The Digital-Asset Resource-Safety Barrier

Barrier

Ordinary copy/discard semantics are dangerous for scarce digital assets. A token, capability or ownership resource may need to be impossible to duplicate or silently destroy.

Nazm lesson

Some values represent resources, not ordinary freely copyable data. Asset conservation is a type/resource-semantics problem, not merely a library convention.

Nazm goal

Nazm should research an asset/resource kind that composes with its broader ownership constitution and can express “cannot duplicate”, “cannot silently discard”, “must transfer/store/explicitly consume”, without forcing resource semantics onto ordinary values.

2.23 Solana / Account-Oriented On-Chain Execution — The High-Throughput State-Access Barrier

Barrier

Some decentralized runtimes separate executable program code from mutable account/state objects and require programs to declare or receive the state they may access. Throughput depends on making access sets and resource budgets explicit enough for the runtime to schedule safely.

Nazm lesson

Explicit state authority can improve both security and parallel execution. A compiler that understands signer, writable/read-only state and cross-program call boundaries can reject mistakes before deployment.

Nazm goal

A future Web3 profile should be able to target account-oriented VMs such as sBPF/SVM-style environments through typed state and capability adapters, while keeping the source-language semantics chain-neutral where possible.

2.24 Decentralized Systems — The Consensus and Ambient-Nondeterminism Barrier

Barrier

A normal program can consult ambient time, randomness, filesystem state, process environment or the network. A consensus-executed program cannot permit each validator to observe a different world.

Nazm lesson

Determinism is not merely a testing preference in decentralized systems. It is a correctness condition.

Nazm goal

Effects and capabilities should eventually allow the compiler to prove that a contract profile has no undeclared nondeterministic authority. Time, randomness, oracle data and external state must arrive through explicit execution-environment capabilities whose semantics are defined by the target profile.

3. Historical Barrier Compression

The previous history can be reduced to a smaller set of root barriers.

Nazm should attack these roots instead of copying each language.

B1 — Machine Control vs Portability

Historical tension:

direct hardware control
↔
portable software

Nazm goal:

portable semantics with explicit target-specific escape hatches.

B2 — Abstraction vs Performance

Historical tension:

high-level abstraction
↔
predictable native execution

Nazm goal:

zero-cost or explainable-cost abstractions.

B3 — Safety vs Runtime Overhead

Historical tension:

manual memory
↔
managed GC runtime

Nazm goal:

static ownership/resource reasoning with no mandatory tracing GC.

Optional managed allocation models may exist where appropriate.

B4 — Safety vs Ergonomics

Historical tension:

strict ownership reasoning
↔
easy programming

Nazm goal:

compiler-internal sophistication with a simpler intent-oriented surface model.

B5 — Concurrency vs Understandability

Historical tension:

threads/shared memory
↔
safe composable concurrency

Nazm goal:

structured tasks + ownership-aware transfer + higher-level messaging.

B6 — Concurrency Safety vs Fault Tolerance

Preventing a data race does not explain how a service recovers when a component fails.

Nazm goal:

combine task safety with explicit failure domains and supervision concepts where appropriate.

B7 — Productivity vs Execution Speed

Historical tension:

Python-like development
↔
C-like execution

Nazm goal:

high-level syntax compiled through strong specialization/optimization.

B8 — Portability vs Native Optimization

Nazm goal:

portable language semantics with machine-specific optimization chosen late in lowering.

B9 — CPU Generality vs Accelerator Throughput

Nazm goal:

one language with multiple lowering targets rather than mandatory separate accelerator languages.

B10 — Generality vs Verifiability

Nazm goal:

profiles and restrictions.

General Nazm can remain expressive.

Critical Nazm can reject constructs that defeat analyzability.

B11 — Rich Features vs Language Complexity

Nazm goal:

small semantic kernel.

New surface features must preferably desugar into established primitives.

B12 — Human Readability vs Machine Readability

Traditional source is designed mainly for humans.

AI tools often infer semantics by reading text.

Nazm goal:

both humans and machines receive first-class representations of program meaning.

B13 — Fast Execution vs Fast Development

Nazm must optimize both:

program runtime
and
compiler/developer latency.

B14 — Optimization vs Predictability

Aggressive optimization can make performance surprising.

Nazm goal:

optimization observability.

Compiler tooling should explain important transformations and surviving costs.

B15 — Security vs Ambient Authority

Traditional programs often inherit broad OS authority.

Nazm goal:

capability-aware software boundaries.

B16 — Reliability vs Testing Alone

Testing cannot prove absence of every failure class.

Nazm goal:

combine:

types
static analysis
contracts
property tests
fuzzing
mutation testing
differential testing
formal verification where justified

B17 — Evolution vs Compatibility

Languages accumulate mistakes.

Nazm goal:

explicit language editions/versioning and migration tooling rather than indefinite semantic ambiguity.

B18 — Human/AI Intent vs Token Cost

Traditional languages were designed primarily around human typing, compiler parsing and runtime performance.

AI-era development adds a new cost dimension:

context tokens
generation tokens
repair tokens
tool-result tokens
repository-context tokens

Nazm goal:

maximize verified semantic value per unit of AI context while preserving human readability and compiler precision.

B19 — General Execution vs Consensus Determinism

Historical tension:

ambient OS authority
↔
identical execution on independent validators

Nazm goal:

profile-controlled deterministic execution where nondeterministic inputs exist only through explicit target capabilities.

B20 — Ordinary Values vs Scarce Digital Assets

Historical tension:

copy/discard convenience
↔
asset conservation and ownership integrity

Nazm goal:

resource/asset semantics that prevent accidental duplication or loss without infecting every ordinary value with affine restrictions.

B21 — General Computation vs Metered Computation

Historical tension:

unbounded local computation
↔
consensus-executed gas / compute / storage budgets

Nazm goal:

make resource cost visible enough that profiles may meter, bound or statically reject execution without changing the meaning of ordinary operations.

B22 — Chain Portability vs Chain-Specific State Models

Historical tension:

one contract source
↔
EVM storage, WASM host APIs, account models, chain-specific ABI

Nazm goal:

keep core semantics chain-neutral and isolate unavoidable chain semantics behind typed profile capabilities, standard libraries and backend adapters.

4. Nazm Grand Mission

Nazm aims to become:

A human-readable, machine-native, AI-native, memory-safe-by-default, concurrency-first, high-performance programming language and compiler platform capable of scaling from ordinary software to systems programming, servers, embedded computing, cybersecurity, AI/HPC, WebAssembly, decentralized/Web3 execution and restricted high-assurance environments while making machine cost, effects, authority, resource use, token cost and correctness evidence unusually visible.

The ambition is best-in-class by measured dimension, not “one implementation choice wins every workload.” Native, embedded, critical, WASM and Web3 environments may use different runtimes and backends while preserving one semantic language.

The objective is not merely to run programs.

Nazm should increasingly be able to answer:

What does this program mean?

What can this function do?

What resources does it require?

What does it own?

What may it mutate?

Where can this data flow?

What can fail?

What hardware will execute it?

What runtime costs remain?

What AI-context cost does this structure create?

Why is this program considered safe?

What changed semantically after this patch?

What evidence supports this release?

5. Non-Negotiable Grand Goals

G01 — Human Readability

Nazm source should optimize for comprehension.

Goals:

• low visual noise;
• consistent grammar;
• limited special cases;
• predictable control flow;
• strong naming conventions;
• useful inference without semantic ambiguity;
• excellent diagnostics;
• canonical formatting;
• progressive disclosure.

Principle

Clarity outranks clever brevity.

Five readable characters are better than one obscure operator.

G02 — Machine-Native Execution

Native AOT execution is a primary execution mode.

Nazm must not require:

• JVM;
• CLR;
• browser;
• tracing GC;
• heavy VM

for basic native programs.

Potential optional modes may include:

• interpreter;
• JIT;
• REPL;
• VM;
• accelerator execution.

But native execution remains foundational.

G03 — Performance Predictability

“Fast” is not enough.

Performance should be explainable.

Compiler/tooling should eventually expose:

• allocations;
• copies;
• dynamic dispatch;
• synchronization;
• bounds checks;
• reference-count operations if present;
• vectorization;
• inlining;
• stack/heap placement;
• host/device transfers.

G04 — Memory Safety Without Mandatory GC

Safe Nazm should prevent major memory errors by construction.

Target classes include:

use-after-free
double free
invalid dereference
uninitialized read
invalid mutable aliasing
dangling references
data races

Unsafe escape hatches will still be necessary for systems work.

They must be:

• explicit;
• local;
• auditable;
• capability-controlled where practical.

G05 — Intent-Oriented Ownership and Aliasing Ergonomics

Nazm should make ownership, aliasing and reclamation safe without forcing ordinary code to carry lifetime syntax whose only purpose is to explain compiler internals.

The goal is not to predetermine that every heap-backed value has value semantics. Different semantic kinds may legitimately exist when their observable behaviour demands it:

immediate value
shared immutable value
owned/shared mutable handle
runtime-managed shared handle
future resource/asset value

Assignment, parameter passing, return, mutation and task transfer must have explicit language meaning for each kind. Existing observable aliasing must not be rewritten merely to simplify implementation.

User-defined records already have settled meaning: they are nominal value types, whose copy behaviour — including that of any shared handle they contain — the specification defines. Ownership research may still investigate copy elision, unique ownership, regions or new resource/value kinds where they solve new problems — hypotheses to test against real workloads, not a constitution imposed on every existing type — and none of it may silently change what an existing record value observably does.

The surface objective remains intent-oriented:

read / observe
mutate
share
transfer / consume
return / publish

with expensive ownership operations explainable by compiler tooling.

G06 — Deterministic Resource Lifetime

Resources should have predictable ownership and cleanup.

Applies to more than memory:

• files;
• sockets;
• locks;
• devices;
• mappings;
• GPU resources;
• tasks;
• transactions.

Resource ownership should become part of the semantic model.

G07 — Concurrency First

Concurrency should not be an afterthought.

Nazm must eventually support a coherent model spanning:

• tasks;
• structured concurrency;
• ownership-safe communication;
• channels/messages;
• parallel loops;
• async I/O;
• task cancellation;
• task failure.

Concurrency syntax should remain smaller than concurrency semantics.

G08 — Data-Race Safety

Safe concurrent Nazm should prevent data races by default.

This does NOT mean:

• all race conditions disappear;
• all deadlocks disappear;
• distributed systems become deterministic.

These must remain separately modeled problems.

G09 — Failure Isolation

Long-running systems need more than memory safety.

Nazm should research failure domains inspired by proven fault-tolerant architectures.

Questions include:

Who owns a task?
Who observes its failure?
Can failure corrupt siblings?
What gets cancelled?
What restarts?
What state survives?

G10 — Effect Awareness

Important externally observable behaviour should become statically visible where practical.

Candidate effects:

io
alloc
panic
spawn
block
network
filesystem
clock
random
ffi
unsafe
device

Effects should support:

• reasoning;
• documentation;
• optimization;
• testing;
• sandboxing;
• AI analysis.

G11 — Capability-Oriented Authority

Effect:

This code may perform file I/O.

Capability:

This code possesses authority to read this resource.

These are different.

Nazm must preserve the distinction.

Long-term capabilities may include:

FileRead
FileWrite
NetworkConnect
NetworkListen
ProcessSpawn
DeviceAccess
Unsafe
SecretRead
Clock
Random

G12 — Information-Flow Awareness

Cybersecurity and privacy need more than memory safety.

Long-term provenance/taint concepts may describe:

Untrusted(Network)
Secret
Credential
PII
Sanitized(Html)
Validated(Command)

Potential compiler questions:

Can Secret reach Log?
Can Untrusted reach Shell?
Was NetworkInput validated?
Can this credential cross this boundary?

This remains research until formalized.

G13 — High-Assurance Profile

Nazm should eventually define a Critical Profile with intentionally restricted semantics.

Potential restrictions:

• no unbounded recursion;
• bounded allocation;
• restricted heap use;
• restricted dynamic dispatch;
• restricted unsafe;
• explicit overflow behaviour;
• bounded channels;
• analyzable concurrency;
• deterministic initialization;
• restricted FFI;
• explicit resource bounds.

The goal is analyzability.

Not feature parity with General Nazm.

G14 — Heterogeneous Compute

Future Nazm should target more than scalar CPUs.

Potential execution targets:

CPU
SIMD
GPU
NPU
DSP
FPGA-related kernels
special accelerators

The compiler should retain enough semantic information to specialize computation appropriately.

No claim of automatic optimal mapping is permitted.

G15 — Scientific and AI Performance

Nazm should eventually support first-class efficient:

• vectors;
• matrices;
• tensors;
• numerical kernels;
• parallel reductions;
• accelerator buffers;
• mixed precision;
• model inference;
• training kernels where appropriate.

Avoid forcing performance-sensitive users into a second implementation language.

G16 — AI-Native Semantics

AI-native does not mean:

language syntax that calls an LLM.

It means the compiler exposes stable machine-readable meaning.

AI tooling should eventually consume:

AST/CST
symbol graph
type graph
effect graph
ownership graph
call graph
dependency graph
control-flow graph
diagnostics
fixes
contracts
test evidence
semantic hashes
build provenance

AI proposes changes.

Compiler semantics judge them.

G17 — Semantic Change Detection

Text differences are not always semantic differences.

Nazm should research stable definition identities and semantic hashing.

Long-term possibility:

old source hash != new source hash
but
old semantic hash == new semantic hash

This can improve:

• incremental compilation;
• caching;
• AI review;
• build systems;
• regression analysis.

G18 — Incremental Compilation

Changing one function should not require recompiling the universe.

Desired architecture:

source edit
   ↓
semantic dependency graph
   ↓
minimum invalidation
   ↓
minimum recheck
   ↓
minimum code generation

Incrementality should operate on semantic dependency, not only timestamps.

G19 — Fast Compiler

Compile speed is product performance.

Measure independently:

• lexer/parser speed;
• type checking;
• semantic analysis;
• code generation;
• linking;
• incremental rebuild;
• clean build;
• peak compiler memory.

Do not hide slow frontend behaviour behind a fast backend.

G20 — Multi-Tier Compilation

Potential future tiers:

Tier 0
nazm check

Tier 1
interpreter / JIT

Tier 2
fast native development build

Tier 3
optimized release

Tier 4
profile-guided / whole-program / critical build

Each tier must preserve language semantics.

G21 — Multiple Backend Strategy Only When Justified

Possible long-term:

Cranelift
→ development/JIT/fast AOT

LLVM
→ optimized production AOT

But a second backend is not automatically desirable.

Backend diversity must provide measurable value.

It also creates a powerful future differential-testing opportunity.

G22 — Small Semantic Kernel

Core semantic concepts should remain deliberately small.

Candidate kernel:

Value
Type
Place
Ownership
Region
Effect
Capability
Task
Message
Contract
Profile

A proposed language feature should answer:

Which kernel concept requires this feature?

If no answer exists, the proposal may be accidental complexity.

G23 — No Accidental Hidden Cost

High-level abstraction is allowed.

Invisible cost without introspection is not desirable.

Eventually tooling should answer:

Why did this allocate?
Why did this copy?
Why did this block?
Why wasn't this vectorized?
Why did this escape?
Why is this dynamic?

G24 — Explicit Arithmetic Semantics

Integer overflow behaviour must never be accidental backend behaviour.

Profiles/build modes must define:

• checked;
• trapping;
• wrapping;
• saturating

semantics explicitly.

Floating-point semantics must also distinguish required reproducibility from permitted hardware optimization.

G25 — Explicit Layout and ABI Boundary

Most code should not care about representation.

Systems code sometimes must.

Nazm eventually needs explicit mechanisms for:

• C-compatible layout;
• packed representation;
• alignment;
• endian behaviour;
• calling convention;
• symbol export;
• linker sections.

Representation guarantees must never be inferred from current compiler accident.

G26 — Adaptive Representation Research

Where layout is not externally observable, the compiler may eventually choose:

AoS
SoA
hybrid
compressed representation
specialized representation

based on usage.

This is research.

It requires strict rules concerning:

• address identity;
• FFI;
• serialization;
• atomics;
• reflection;
• separate compilation.

G27 — Excellent Interoperability

Nazm should enter existing systems incrementally.

Initial priority:

C ABI

Long-term:

• C++;
• system libraries;
• platform APIs;
• GPU APIs;
• Python extension interfaces;
• other ecosystems where demand justifies it.

A language that requires total rewrite creates an adoption barrier.

G28 — Cross Compilation

Cross compilation should become a normal workflow rather than a specialist ritual.

Target dimensions:

architecture
OS
ABI
CPU features
runtime profile
link strategy

Build identity must record them.

G29 — Embedded / Bare-Metal Capability

Future Embedded Profile should support:

• no OS;
• optional/no heap;
• no mandatory runtime;
• static initialization;
• linker control;
• interrupt handlers;
• volatile access;
• MMIO;
• atomics;
• deterministic allocation;
• ARM/RISC-V class targets.

G30 — Real-Time Awareness

Hard real-time cannot be promised by syntax alone.

A future real-time profile must analyze or constrain:

• allocation;
• blocking;
• locks;
• scheduling;
• recursion;
• queue bounds;
• worst-case execution behaviour.

“Fast” and “real-time” are not synonyms.

G31 — Reproducible Builds

Given identical declared inputs, Nazm should aim to reproduce identical build outputs where the selected toolchain permits it.

Build identity should eventually include:

compiler identity
language edition
source hashes
dependency hashes
target
CPU features
flags
runtime profile
external linker/toolchain identity

Time, random state and filesystem ordering must not silently modify semantic output.

G32 — Supply-Chain Provenance

A Nazm artifact should increasingly be able to answer:

Who built me?
From which source?
Using which compiler?
Using which dependencies?
For which target?
Under which configuration?
What tests verified me?

G33 — Compiler Trust

Self-hosting is not sufficient.

Trust must be layered.

Potential evidence stack:

specification
reference implementation
self-host implementation
differential testing
property testing
fuzzing
mutation testing
bootstrap comparison
reproducible builds
release provenance

G34 — Formal Verification Where It Pays

Nazm should not attempt to formally prove every ordinary program.

Formal techniques should become progressively available.

Possible levels:

Level 0 — type checking
Level 1 — safety analyses
Level 2 — contracts
Level 3 — flow analysis
Level 4 — selected proof obligations
Level 5 — Critical Profile verification

Verification burden should be proportional to assurance requirement.

G35 — Contracts and Invariants

Potential contracts:

requires
ensures
invariant

Compiler/tooling may use them for:

• static proof;
• runtime checking;
• optimization assumptions where proven;
• documentation;
• property testing;
• AI reasoning.

Unchecked assumptions must never silently become optimizer facts.

G36 — Diagnostics as a Public Interface

Diagnostics are part of the language product.

They must be:

• stable where promised;
• structured;
• source-precise;
• deterministic;
• human-readable;
• machine-readable.

Long-term form:

diagnostic code
severity
message
primary range
secondary ranges
semantic entity
fix candidates
documentation

G37 — Machine-Applicable Fixes

Compiler fixes should carry preconditions.

Example:

source revision/hash
expected original span
replacement
validation command

A stale patch must fail rather than edit the wrong program.

This is essential for AI-native development.

G38 — Canonical Formatting

One canonical formatter reduces accidental variation.

Goals:

• stable output;
• idempotence;
• semantic preservation;
• minimal style arguments;
• predictable diffs.

G39 — Language Server / Semantic Service

IDE tooling and AI tooling should eventually share one semantic engine.

Avoid implementing separate inconsistent understanding for:

compiler
LSP
AI agent
formatter
linter
documentation

G40 — Package and Build Simplicity

Dependency/build behaviour should be explicit and reproducible.

Goals:

• deterministic resolution;
• clear package graph;
• minimal configuration;
• offline capability;
• lock files;
• provenance;
• security metadata.

G41 — Standard Library Discipline

The standard library must not become an uncontrolled dumping ground.

Potential layers:

core
alloc
std
platform
network
concurrency
crypto interfaces
accelerator

Embedded/critical programs should be able to depend on smaller layers.

G42 — Security as Language Architecture

Security is not only cryptography.

Nazm security goals include:

• memory safety;
• capability control;
• taint/provenance;
• constant-time primitives where appropriate;
• hardened parsing;
• safe FFI;
• dependency provenance;
• sandboxing;
• secure defaults.

G43 — Secret Handling

Long-term security research should consider secret-aware values.

Questions:

Should secret memory be zeroized?
Can it appear in debug output?
Can it be copied?
Can it cross task boundaries?
Can it enter logs?

Do not invent syntax before the semantic problem is defined.

G44 — Fault Injection and Resilience Testing

Critical and distributed software should be testable under failure.

Future tooling may inject:

• allocation failure;
• task failure;
• I/O failure;
• network interruption;
• timeout;
• cancellation;
• device error.

Resilience must be measured rather than assumed.

G45 — Mutation Testing

Mutation testing should remain a first-class compiler/toolchain verification technique.

Especially valuable for:

• checker rules;
• diagnostics;
• optimizations;
• safety passes;
• bootstrap compiler.

A test suite that passes while deliberate defects survive is incomplete evidence.

G46 — Fuzzing

Nazm should eventually fuzz:

lexer
parser
formatter
type checker
IR verifier
optimizer
code generator
package metadata
debug information

Compiler input is adversarial input.

G47 — Differential Testing

Where two implementations exist:

reference vs selfhost
interpreter vs native
LLVM vs future backend
optimized vs unoptimized

equivalent programs should agree.

Differential testing is one of Nazm’s highest-value verification tools.

G48 — AI-Assisted Compiler Development

AI may:

• generate tests;
• propose changes;
• investigate failures;
• produce patches;
• suggest optimizations.

But verification authority remains deterministic tooling.

Architecture:

AI proposal
   ↓
compiler/static checks
   ↓
tests
   ↓
mutation/property/fuzz evidence
   ↓
human/release policy

Never:

AI says correct
→ merge.

G49 — Self-Hosting

Nazm should remain capable of implementing its own compiler.

Self-hosting provides:

• real workload pressure;
• bootstrapping;
• ecosystem validation;
• compiler performance benchmark;
• language expressiveness evidence.

Self-hosting is a milestone, not the final goal.

G50 — Verified Self-Evolution

Long-term Nazm may become unusually capable of improving itself using AI-assisted development.

The acceptable model is:

observe
→ propose
→ compile
→ verify
→ compare
→ approve
→ adopt

The unacceptable model is uncontrolled autonomous compiler mutation.

6. AI-Era Token Efficiency Constitution

Token efficiency is a first-class language, compiler, tooling and ecosystem property.

This requirement exists because software development is moving toward a model in which:

Humans
   ↓
intent
architecture
constraints
trade-offs
approval

AI Agents
   ↓
implementation
refactoring
testing
migration
debugging
maintenance
documentation

Source code is increasingly consumed not only by humans and compilers but repeatedly by:

• coding agents;
• review agents;
• security agents;
• test-generation agents;
• documentation agents;
• compiler agents;
• architecture-analysis agents;
• retrieval systems;
• context-building systems.

Therefore the future cost of a programming language includes:

runtime cost
+
memory cost
+
compile cost
+
human cognitive cost
+
AI context cost
+
AI generation cost
+
AI repair cost

Nazm must optimize all of them.

G51 — AI-Era Token Efficiency

Nazm must treat token efficiency as a first-class language performance concern.

G52 — Semantic Density, Not Code Golf

Token efficiency must NOT mean making Nazm cryptic.

Rejected objective:

maximum meaning
÷
minimum characters

Actual objective:

useful semantic information
──────────────────────────
human + machine interpretation cost

Nazm should maximize semantic density while preserving:

• readability;
• predictability;
• searchability;
• debuggability;
• structural clarity;
• deterministic parsing;
• AI comprehension.

A shorter program that requires substantially more reasoning is not token-efficient in the meaningful sense.

G53 — Three-Way Optimization

Nazm syntax must optimize simultaneously for:

Human readability
        ▲
       / \
      /   \
     /     \
AI efficiency ─── Compiler precision

No corner may dominate the others absolutely.

A syntax that is excellent for humans but extremely verbose for agents is undesirable.

A syntax that is compact for LLM tokenizers but unreadable to humans is undesirable.

A syntax that is convenient for the parser but creates unnecessary ceremony for humans and agents is undesirable.

Nazm should seek the Pareto-efficient region among all three.

G54 — Token Efficiency Is Broader Than Source Syntax

Nazm token efficiency must be designed across the entire development lifecycle.

At least these layers must be measured separately:

1. Source-code token efficiency
2. Type/signature token efficiency
3. Error-message token efficiency
4. Compiler diagnostic token efficiency
5. Agent semantic-query efficiency
6. Patch/edit token efficiency
7. Test-output efficiency
8. Build-output efficiency
9. Dependency-context efficiency
10. Documentation efficiency
11. Machine protocol efficiency
12. Repository-context efficiency
13. Incremental-change efficiency
14. AI reasoning iteration efficiency

A language with concise source but extremely verbose compiler/tooling protocols is not fully token-efficient.

G55 — Source Token Efficiency

Common programming operations should require minimal unnecessary ceremony.

Avoid repetitive patterns such as:

type repeated where already known
module repeated where already known
namespace repeated unnecessarily
boilerplate constructors
boilerplate getters/setters
boilerplate resource cleanup
boilerplate async wrappers
boilerplate error propagation
boilerplate trait/interface forwarding

Inference and defaults may remove redundancy where semantics remain unambiguous.

The governing rule:

Do not require a programmer or an AI agent to repeatedly state information the compiler can already prove.

G56 — Explicitness Budget

Explicitness is valuable when it communicates information that matters.

It is wasteful when it merely satisfies syntax.

Nazm should distinguish:

semantic explicitness

from:

ceremonial explicitness

Semantic explicitness examples:

unsafe boundary
ownership transfer
capability grant
FFI
critical resource bound
meaningful effect

These may deserve explicit syntax.

Ceremonial repetition should generally be eliminated.

G57 — Token-Efficient Type System

A sophisticated type system can become extremely token-expensive.

Nazm should therefore seek:

strong static guarantees
+
low annotation burden

through sound inference where practical.

Prefer:

infer locally
declare at important boundaries

Potential boundaries where explicit typing remains valuable:

• public APIs;
• FFI;
• critical-system interfaces;
• ambiguous generic boundaries;
• capability/effect boundaries.

G58 — Token-Efficient Error Handling

Error handling frequently creates significant source expansion.

Nazm should seek a model that remains:

• explicit enough to be safe;
• compact enough for ordinary propagation;
• visible to the type/effect system;
• easy for AI agents to reason about.

Avoid forcing large repetitive error-propagation structures where the programmer’s intent is simply:

propagate this failure

But never compress error handling so aggressively that failure paths become invisible.

G59 — Token-Efficient Concurrency

Concurrency syntax must avoid the historical pattern where a small logical operation requires large amounts of:

• callback plumbing;
• promise chaining;
• async annotations;
• synchronization boilerplate;
• cancellation plumbing;
• cleanup code.

Structured concurrency should allow the semantic structure itself to remove boilerplate.

Example conceptual form:

scope {
    spawn fetch_a()
    spawn fetch_b()
}

where scope semantics already define lifetime and joining behavior.

Do not force agents to repeatedly generate lifecycle code the compiler/runtime can enforce.

G60 — Token-Efficient Resource Management

Resource safety should reduce code rather than add large cleanup ceremonies.

Ownership and deterministic cleanup should allow:

acquire
use
scope ends

instead of repeatedly generating explicit cleanup paths for every exit route.

The compiler should carry more of the proof burden than the source.

G61 — Token-Efficient Generics

Generic systems can become extremely syntax-heavy.

Nazm should avoid unnecessary repetition of:

• generic constraints;
• lifetime-like annotations;
• capability requirements;
• associated type information

when these can be inferred reliably.

But hidden inference must remain inspectable.

Tooling should be able to answer:

What did the compiler infer here?

G62 — Token-Efficient Imports and Modules

AI agents regularly spend context tokens understanding module structure.

Nazm should make module relationships:

• explicit;
• simple;
• predictable;
• minimally repetitive.

Avoid deep ceremonial namespace syntax.

Imports should expose enough information for static analysis without forcing repetitive qualification everywhere.

G63 — Token-Efficient Standard Library API Design

API design heavily affects generated-code token volume.

Standard-library APIs should optimize for:

small composable vocabulary
+
consistent naming
+
orthogonal operations

rather than hundreds of nearly overlapping APIs.

A small number of predictable primitives improves:

• human learning;
• AI generation;
• documentation retrieval;
• autocomplete;
• semantic search;
• maintenance.

G64 — Token-Efficient Naming Without Cryptic Naming

Nazm should not encourage meaningless abbreviations merely to save tokens.

Bad:

mgr
ctx
cfg
x1
doit
proc2

when meaning is lost.

But language-level concepts should also avoid unnecessarily long ceremonial names.

Token efficiency means:

short enough to repeat economically
+
clear enough to understand without explanation

Canonical terminology is especially important for AI agents.

One concept should preferably have one standard name.

G65 — Grammar Regularity Is Token Efficiency

Irregular syntax increases reasoning tokens.

If an AI must remember many exceptions, the source may be short while inference becomes expensive.

Therefore Nazm should prefer:

regular grammar
consistent declarations
consistent control flow
consistent type construction
consistent resource rules

over special-case shorthand.

Predictability reduces reasoning cost.

G66 — Semantic Compression

The strongest form of token efficiency does not come from shorter keywords.

It comes from enabling one construct to encode a large amount of verified meaning.

Example:

scope

may semantically imply:

child lifetime containment
joining
cancellation boundary
resource cleanup
failure propagation policy

If those guarantees would otherwise require many lines of manual code, the semantic construct provides substantial token compression.

Nazm should pursue this kind of verified semantic compression.

G67 — Compiler-Backed Semantic Compression

Whenever the compiler can prove a property, source code should not need to repeatedly restate it.

Candidate examples:

ownership
lifetime
drop order
task joining
effect propagation
capability propagation
generic specialization
layout selection
bounds elimination

The principle:

Move repeatable proof work from source tokens into compiler semantics.

This is one of the major ways Nazm can become both safer and more token-efficient.

G68 — AI Context Efficiency

For AI agents, repeatedly sending entire files is wasteful.

Nazm tooling should eventually support semantic context retrieval.

Instead of providing:

50,000 tokens of source

an agent could request:

definition Foo
callers of Foo
effects of Foo
types related to Foo
tests covering Foo
recent semantic changes to Foo

and receive only relevant context.

Desired flow:

Agent
   ↓
semantic query
   ↓
Nazm compiler database
   ↓
minimal sufficient context

This may produce much larger token savings than syntax shortening.

G69 — Minimum Sufficient Context Principle

Nazm AI tooling should attempt to provide the smallest context sufficient to perform a task correctly.

For example:

modify function X

should not automatically require sending:

entire repository

Instead the compiler may derive:

X
types used by X
direct semantic dependencies
affected contracts
relevant callers
tests
capability/effect constraints

This becomes the agent’s task context.

G70 — Semantic Context Packets

Nazm should research a compact machine representation for agent context.

Conceptually:

ContextPacket {
    task
    target_definitions
    relevant_types
    invariants
    effects
    capabilities
    dependencies
    tests
    diagnostics
}

These packets should be:

• deterministic;
• versioned;
• compact;
• semantically sufficient;
• source-linked.

An agent should not need to rediscover repository structure every session.

G71 — Semantic Delta Protocol

AI development is usually incremental.

If only one function changed, the next agent interaction should not require retransmitting everything.

Nazm should eventually expose:

semantic delta

such as:

definitions changed: 2
types changed: 0
effects changed: 1
new callers affected: 3
tests invalidated: 5

This can dramatically reduce agent context consumption.

G72 — Patch Token Efficiency

AI agents should return structured edits rather than entire regenerated files whenever possible.

Preferred:

semantic edit / minimal patch

over:

rewrite 4,000-line file

Benefits:

• fewer output tokens;
• fewer accidental regressions;
• easier review;
• lower merge conflict;
• lower inference cost;
• stronger stale-edit checking.

G73 — Stable Definition Identity

AI context efficiency becomes much stronger if definitions have stable semantic identities.

Instead of repeatedly locating:

function by filename + textual search

tools may refer to:

definition ID

A stable semantic identity can support:

• compact patches;
• agent queries;
• caching;
• dependency graphs;
• semantic history.

G74 — Token-Efficient Diagnostics

Diagnostics sent to humans and agents have different optimal representations.

Nazm should support both.

Human:

clear explanation
source excerpt
help

Machine:

code
span
entity
expected
actual
fix

Do not force an AI agent to parse hundreds of prose tokens if a compact structured representation conveys the same fact.

Example:

{
  "code": "E0412",
  "def": "D98A",
  "expected": "Int",
  "found": "Text",
  "span": [128, 139]
}

The human-readable explanation can be generated separately.

G75 — Diagnostic Verbosity Levels

Tooling should support modes such as:

human
compact
machine
explain

This prevents CI and AI agents from paying token cost for decorative prose they do not need.

G76 — Token-Efficient Build and Test Output

AI agents frequently consume enormous quantities of build logs.

Nazm tooling should provide concise structured summaries by default.

Example:

FAIL 3/812

E1042 src/net.nz:92
E3310 src/task.nz:140

affected tests:
net.timeout
task.cancel
task.scope

Full logs remain retrievable on demand.

The default should communicate signal, not volume.

G77 — Progressive Error Disclosure

Diagnostics can follow:

summary
   ↓
relevant evidence
   ↓
full explanation on request

AI agents and humans should not receive every available detail automatically.

This improves both cognitive and token efficiency.

G78 — Documentation Token Efficiency

Documentation should be structured for selective retrieval.

Instead of forcing agents to consume entire manuals, language documentation should have stable machine-addressable sections for:

syntax
semantics
examples
invariants
errors
profiles
version changes

Documentation should support semantic retrieval rather than only page-based retrieval.

G79 — Specification Token Efficiency

Language specifications should minimize duplicated normative rules.

One rule should ideally have one canonical definition with references from dependent sections.

Duplicated specification text creates:

• token waste;
• contradictions;
• stale documentation;
• AI confusion.

G80 — Repository Token Efficiency

Nazm project structure should help agents reason locally.

Prefer:

cohesive modules
clear boundaries
small interfaces
explicit dependency direction

over giant files and implicit coupling.

Language architecture affects source token efficiency; repository architecture affects agent token efficiency.

Both matter.

G81 — Tokenizer Independence

Nazm must NOT optimize itself for one company’s current tokenizer.

LLM tokenizers will change.

Therefore measurements should include both tokenizer-independent and tokenizer-dependent metrics.

Tokenizer-independent:

bytes
Unicode scalar count
lexical token count
AST nodes
semantic operations
source lines

Tokenizer-dependent benchmarking may include multiple representative tokenizers.

No syntax decision should depend solely on one proprietary tokenizer’s current segmentation behavior.

G82 — Multi-Tokenizer Benchmarking

Where practical, benchmark source against several tokenizer families.

Measure:

LLM tokens / source file
LLM tokens / semantic operation
LLM tokens / AST node
LLM tokens / API definition
LLM tokens / completed task

The important metric is not:

Nazm token count alone

but:

tokens required to correctly understand and modify a program.

G83 — Agent Task Token Benchmark

Nazm should eventually create an AI-era benchmark suite.

Example tasks:

add validation
fix compiler error
add field
refactor API
implement function
trace bug
add concurrency
change data type
repair test
perform security review

For each task measure:

input tokens
output tokens
tool tokens
number of iterations
compile attempts
failed patches
time to verified success

Compare Nazm against relevant languages.

G84 — Total Agent Cost Metric

A useful future metric:

Total Agent Cost
=
input tokens
+
output tokens
+
tool/context tokens
+
repair iterations

A syntax saving 5% of source tokens but causing twice as many repair iterations is worse.

Optimize verified task completion, not superficial source compression.

G85 — Token-to-Correctness Efficiency

Nazm should research:

verified result
────────────────
agent tokens consumed

as a development-efficiency metric.

Potential normalized metric:

Verified Change per Million Tokens

This would make AI-era language efficiency measurable rather than rhetorical.

G86 — Semantic Tokens vs Text Tokens

In the long term, AI agents should increasingly communicate with Nazm tooling in semantic units.

Instead of:

"find this text and replace it"

prefer:

replace expression in definition D102
add parameter to definition D88
update all callers

This turns communication from text-oriented into program-oriented interaction.

G87 — AI-Native Intermediate Communication

Humans may continue writing ordinary .nz source.

Agents may increasingly use:

semantic queries
structured diagnostics
structured edits
definition identifiers
dependency information
compiler proofs

This means human syntax does not need to become cryptic merely to save AI tokens.

The compiler acts as the compression/intelligence layer between human source and AI agents.

G88 — Human Architecture, Agent Implementation

Nazm should explicitly anticipate a future development model:

Human responsibilities
──────────────────────
problem selection
requirements
architecture
risk decisions
trade-offs
security policy
performance targets
approval

AI responsibilities
───────────────────
implementation
test generation
refactoring
migration
routine debugging
documentation maintenance
repetitive optimization

These boundaries are not absolute.

But the language and toolchain should be optimized for this collaboration model.

G89 — Human Intent Artifacts

If humans increasingly operate at architecture level, Nazm tooling should eventually make architectural intent machine-readable.

Potential artifacts:

contracts
capability policies
performance budgets
resource limits
module boundaries
security invariants
domain profiles
architecture decisions

AI agents can then implement against declared constraints rather than guessing architecture from existing source code.

G90 — Intent-to-Code Efficiency

The ultimate token-efficiency target is not:

fewest tokens in final source

It is:

fewest tokens needed to move from
human intent
to
verified implementation

This includes:

requirements
agent context
generated code
diagnostics
repairs
tests
review

Nazm should optimize the entire path.

G91 — No Token Efficiency at the Cost of Language Longevity

Token prices, context-window sizes and model architectures will change.

Nazm may live for decades.

Therefore token efficiency must derive primarily from enduring principles:

• low redundancy;
• semantic density;
• regular grammar;
• small vocabulary;
• strong inference;
• structured tooling;
• incremental context;
• machine-readable semantics.

Do not distort permanent language syntax to exploit temporary model economics.

G92 — Token Efficiency and Readability Conflict Rule

When token count and human readability conflict, evaluate total cost.

Do NOT automatically choose shorter syntax.

Example:

cryptic syntax:
12 tokens

clear syntax:
16 tokens

If the clear syntax substantially reduces misunderstandings and repair iterations, the 16-token version is more efficient overall.

Token efficiency must account for interpretation cost.

G93 — Repetition Elimination Rule

Nazm should systematically investigate repeated source patterns.

Whenever developers/agents repeatedly generate the same structural pattern, ask:

Is this real application logic?
or
Is this compiler-deducible ceremony?

If it is ceremony, consider eliminating it through:

• inference;
• language semantics;
• library abstraction;
• compiler-generated behavior;
• structured defaults.

G94 — AI-Era Benchmark Comparison

When Nazm matures, compare it with relevant languages not only by runtime.

Future comparison dimensions should include:

No row may be filled with assumptions.

Only measurements.

G95 — Token Efficiency as a Language Performance Dimension

Nazm performance must therefore be defined across at least:

execution performance
memory performance
compiler performance
concurrency performance
energy performance
human cognitive performance
AI token performance
AI task-completion performance

Token efficiency is not a documentation concern.

It is a language performance property.

G96 — AI-Era North-Star Metric

A possible future composite target is:

Intent → Verified Software Efficiency

which measures the cost required to transform a clearly stated human requirement into a compiler-verified, tested implementation.

Inputs may include:

human specification size
agent input tokens
agent output tokens
tool tokens
number of iterations
build/test executions
elapsed compute

Output:

verified semantic change

This metric should remain experimental until a fair methodology exists.

G97 — Token Constitution

Nazm shall pursue:

Maximum verified semantic value per unit of human attention, machine execution, and AI context.

The priority is not merely fewer characters.

The priority is eliminating waste from the entire software-development loop.

Nazm should therefore strive to make programs:

short enough for AI
clear enough for humans
precise enough for compilers
rich enough for static reasoning
explicit enough for systems work
compact enough for repeated agent interaction

without turning the language into cryptic shorthand.

G98 — Updated Ultimate Nazm Equation

The conceptual Nazm equation becomes:

C machine access
+
C++ zero-cost abstraction ambition
+
Python readability/productivity ambition
+
Go simplicity/tooling/concurrency
+
Rust static safety
+
Erlang failure isolation
+
Zig cost transparency
+
SPARK assurance discipline
+
CUDA heterogeneous compute
+
Julia scientific performance/productivity
+
AI-native semantic tooling
+
AI-era token efficiency
-----------------------------------------
                 NAZM

Again, this does not mean literal feature accumulation.

The target is root-problem synthesis.

G99 — Final AI-Era Principle

Future software engineering may increasingly shift from:

human writes every line

toward:

human defines architecture + intent + constraints
                    ↓
AI agents implement and maintain
                    ↓
compiler/toolchain verifies
                    ↓
human governs important decisions

Nazm should be designed for that future from the beginning.

Therefore an excellent Nazm program should not merely execute efficiently.

It should also be efficient to communicate, understand, generate, modify, validate and repair by both humans and AI systems.

That is a fundamental language requirement.

6A. Best-in-Class Compiler and Decentralized/Web3 Constitution

The goals below extend the original ninety-nine goals without changing their authority class. They are ambitions, not status claims. They exist because “best of the best” must be translated into engineering dimensions, and because decentralized execution introduces requirements ordinary native software does not.

G100 — Best-in-Class by Evidence, Not Slogan

Nazm should pursue the strongest practical combination of:

clarity
safety
performance
compile latency
memory efficiency
portability
reliability
determinism
security
verification
interoperability
AI efficiency

No universal score may hide trade-offs. Every “best” claim names a comparator, workload, machine/profile and evidence class.

G101 — One Semantic Core, Multiple Backends

Nazm should support several execution environments without forking program meaning.

Potential backend families:

LLVM/native
Cranelift/JIT or dev AOT if justified
WebAssembly
EVM-oriented contract backend
sBPF/SVM-oriented backend
future accelerator backends
future verified/restricted backends

Backends translate settled semantics. They do not invent new source-language meaning.

G102 — Backend Contract Precision

Every backend boundary should consume an explicit representation whose semantics, ABI assumptions, failure behaviour and target inputs are known. Backend caches should key the actual transformation input where possible rather than a fragile approximation of upstream dependencies.

G103 — WebAssembly as a First-Class Portable Target

Nazm should eventually target WebAssembly for:

• browser components;
• sandboxed server plugins;
• edge runtimes;
• portable extensions;
• WASM-oriented smart-contract environments.

The source language must not become browser-specific. Host authority belongs in imported capabilities/interfaces.

G104 — Web3 as a Restriction Profile, Never a Dialect

A future Web3 profile must use the same Nazm semantics and may only:

• refuse nondeterministic or unavailable operations;
• restrict allocation/control flow/resource use;
• grant chain-specific capabilities;
• impose additional verification obligations;
• choose a contract backend and ABI.

It must never reinterpret ordinary arithmetic, ownership, evaluation order or error semantics merely because code is on-chain.

G105 — Deterministic Consensus Execution

A contract-capable profile should make consensus determinism statically checkable where possible.

Disallowed ambient sources should include, unless supplied by an explicit deterministic host capability:

wall clock
process environment
filesystem
arbitrary network
ambient randomness
thread scheduling observation
unspecified platform state

Target-provided time, randomness, oracle or block metadata must be explicit inputs/capabilities with defined semantics.

G106 — Metered and Explainable Resource Cost

Web3 execution introduces gas/compute/storage budgets. Nazm should eventually explain and, where possible, statically bound:

compute
storage reads
storage writes
memory
allocations
external calls
cryptographic host calls
event/log output
loop bounds

Where a static upper bound is impossible, the compiler should distinguish that from an unknown implementation detail.

G107 — Persistent State as Explicit Authority

Persistent contract state must not look like an ordinary hidden global variable.

The compiler should eventually know:

• what state a function may read;
• what state it may mutate;
• who authorizes the mutation;
• which layout/version is stored;
• which external calls can observe intermediate state.

G108 — Digital Asset / Resource Safety

Nazm should research an asset/resource semantic kind suitable for tokens, capabilities, ownership certificates and other scarce values.

Potential guarantees:

no accidental duplication
no silent discard where conservation is required
explicit transfer
explicit authorized destruction
well-defined storage ownership

This must compose with, not replace, ordinary Nazm ownership semantics.

G109 — Financial Numeric Correctness

Smart contracts and financial systems require arithmetic beyond a single signed machine integer. Nazm should eventually support or standardize:

fixed-width signed/unsigned integers
large integers such as 128/256-bit where targets require them
fixed-point decimal/rational representations with explicit scale
checked conversion
explicit rounding rules
no implicit floating-point money semantics

Numeric semantics must be target-independent unless a profile explicitly exposes a target-specific primitive.

G110 — Typed Cryptographic and Address Primitives

Addresses, hashes, signatures and public keys should not all degrade into unstructured byte arrays at API boundaries.

Nazm should prefer typed library/profile primitives with explicit algorithms and lengths while keeping cryptographic implementations in audited libraries or target host functions rather than making every algorithm a language keyword.

G111 — Contract Interface / ABI Generation

From one typed source definition the toolchain should eventually be able to generate target artefacts such as:

contract ABI
client bindings
event schemas
storage/interface metadata
source maps
interface fingerprints

Duplicated handwritten ABI descriptions are a correctness risk.

G112 — Storage Layout and Upgrade Safety

Persistent-state layout can outlive a compiler version. Nazm should eventually make contract storage layout explicit, inspectable and version-aware.

An upgrade should be able to answer:

Is the old state readable?
Which fields moved or changed?
Is migration required?
Did an interface or storage compatibility contract break?

G113 — External-Call and Reentrancy Awareness

The compiler should eventually model external contract/program calls as effects with explicit authority and state-ordering consequences.

Where a target admits reentrant execution, tooling should be able to identify dangerous patterns such as:

state read
external call
state write based on stale assumption

The goal is analysis and explicitness, not pretending all reentrancy can be universally prohibited.

G114 — Signer and Authorization Semantics

Contract APIs should make authorization requirements visible in types, capabilities or contracts.

The compiler should eventually help answer:

Who may invoke this transition?
Which signer/authority is required?
Which state may that authority modify?

Authentication policy remains application logic; authority flow should not remain invisible.

G115 — Chain-Neutral Core, Typed Host Adapters

EVM storage, WASM host imports, account-oriented state and future chain models differ. Nazm should isolate these differences behind typed backend/profile adapters.

Core language semantics should not acquire a keyword merely because one chain exposes a particular syscall or account convention.

G116 — EVM Backend Goal

Nazm should be architecturally capable of targeting EVM-compatible environments.

Possible implementation routes may evolve:

Nazm semantic contract model
        ↓
contract IR
        ↓
Yul/other verified intermediate route
        ↓
EVM bytecode

or a direct backend later if evidence justifies it.

The goal is semantic correctness and tooling quality, not owning every low-level assembler immediately.

G117 — WASM Contract Backend Goal

For chains and runtimes that execute WebAssembly, Nazm should reuse the ordinary WASM backend where possible and isolate chain-specific host functions in the Web3 profile/standard library.

One WASM code generator should not be duplicated into a “blockchain WASM” compiler unless the execution semantics genuinely differ.

G118 — sBPF/SVM-Style Backend Goal

Nazm should be capable of targeting account-oriented BPF-derived contract environments where the program code and mutable account state are separate.

The compiler should aim to understand signer, writable/read-only state, account ownership/type constraints and cross-program calls sufficiently to produce useful static diagnostics.

G119 — Move and Resource-Oriented Interoperability

Nazm should study Move-style resource semantics as evidence, not promise binary compatibility prematurely.

Interop or a compatible backend is acceptable only when Nazm’s asset/resource guarantees can be mapped without weakening either language’s safety assumptions.

G120 — On-Chain / Off-Chain Semantic Continuity

Where feasible, shared domain logic should be reusable between off-chain native/server code and on-chain code.

The contract profile may refuse operations, but a pure function valid in both profiles should mean the same thing in both.

This reduces duplicated business logic and makes differential testing possible.

G121 — Contract Testing as Compiler Tooling

Future Web3 tooling should support:

unit tests
state-transition/property tests
fuzzing
mutation testing
scenario simulation
contract differential tests
upgrade compatibility tests
resource-budget tests

Testing must run against the semantics of the target backend, not only an optimistic mock.

G122 — Smart-Contract Security Analysis

A mature Web3 profile should make the compiler/toolchain capable of analysing classes such as:

• arithmetic/rounding mistakes;
• missing authorization;
• invalid state transitions;
• asset duplication/loss;
• unsafe external-call ordering;
• storage-layout incompatibility;
• unexpected capability use;
• unbounded resource behaviour where the profile forbids it.

No compiler can prove application business logic correct by default. That limitation must remain explicit.

G123 — Formal Contract Verification Path

Web3 and Critical profiles should share as much contract/proof infrastructure as semantics permit.

Future constructs may express:

requires
ensures
invariant
resource invariant
state-transition invariant
asset conservation invariant

and lower either to runtime checks, static analysis or proof obligations according to profile.

G124 — Reproducible Contract Builds

On-chain deployment magnifies compiler provenance risk. Nazm should eventually support reproducible contract artefacts with:

source digest
compiler identity
profile/backend identity
target configuration
ABI/storage metadata
dependency provenance
reproducible build instructions

A contract address or bytecode hash is not a substitute for knowing how it was produced.

G125 — Audit Artifact Generation

The compiler should eventually be able to emit a compact audit bundle describing:

public entry points
authorities
state reads/writes
external calls
effects
resource estimates
storage layout
unsafe/foreign boundaries
contracts/invariants
compiler and dependency provenance

The bundle is evidence input for auditors, not an automatic certification.

G126 — Cross-Chain Architecture Without Semantic Fragmentation

Supporting several chains must not produce several subtly incompatible Nazm dialects.

If a target requires a fundamentally different semantic rule, the project must either:

1. express it as a profile restriction/capability;
2. isolate it in an explicit foreign/host boundary; or
3. decline that target.

“Target support” is not worth corrupting language coherence.

G127 — Multi-Objective Optimizer

Nazm’s optimizer should eventually support explicit goals such as:

latency
throughput
code size
energy
memory
compile time
gas/compute units
critical predictability

No one optimization profile is best for firmware, cloud services, HPC and contracts. The semantics remain one; optimization objectives differ.

G128 — Best-in-Class Development Loop

The compiler should optimize the full edit→check→test→build loop, not only generated machine code.

Target properties include:

• instant incremental semantic feedback where possible;
• deterministic structured diagnostics;
• precise affected-test selection;
• content-addressed reuse where it earns its cost;
• fast dev backend/JIT where justified;
• aggressive release optimization separately.

G129 — Best-in-Class Semantic Observability

A future programmer or agent should be able to ask the compiler not only “did it compile?” but:

what changed semantically?
what did this allocate?
what can this call?
what can it mutate?
what authority does it require?
what state does it touch?
what may block?
what may fail?
what resource budget remains?
what tests and callers are affected?

The compiler’s semantic model should become a product interface.

G130 — Universal Capability Without Universal Runtime

Nazm’s long-term ambition may span:

CLI and applications
servers and distributed systems
OS/runtime components
embedded and bare metal
cybersecurity
AI/HPC and accelerators
WASM plugins
decentralized/Web3 contracts
critical/high-assurance subsets

This does not imply one runtime, allocator, scheduler, standard-library surface or backend is appropriate everywhere.

The universal part is the semantic foundation and toolchain discipline.

7. What “Super Fast” Means

Nazm must never use “fast” as one number.

Performance contains multiple independent dimensions.

P1 — Scalar CPU Performance

Compare equivalent algorithms against:

C
Rust
Zig

Goal:

be competitive with leading native systems implementations.

Do not promise universal superiority.

P2 — Memory Efficiency

Measure:

• peak RSS;
• heap allocation;
• allocation count;
• stack consumption;
• fragmentation;
• metadata;
• task overhead.

P3 — Startup Latency

Important for:

• CLI;
• serverless;
• utilities;
• embedded startup.

Native programs should not automatically inherit heavy-runtime startup.

P4 — Tail Latency

Measure:

p50
p95
p99
p99.9

Average latency alone is insufficient.

P5 — Throughput

Measure under:

• single core;
• multiple cores;
• high concurrency;
• I/O load.

P6 — Compilation Speed

Measure:

clean check
incremental check
clean build
incremental build
optimized build
self-host build

P7 — Compiler Memory

A compiler that requires enormous RAM is not universally usable.

Peak memory must be tracked as a regression metric.

P8 — Concurrency Density

Eventually measure:

• bytes/task;
• spawn latency;
• scheduling latency;
• context switch;
• channel send;
• cancellation;
• task completion.

P9 — Scaling

Measure throughput against core count.

Avoid claims based only on maximum throughput.

Look for:

1
2
4
8
16
32...

cores.

P10 — SIMD

Measure auto/manual vectorization.

Compiler must explain failed vectorization where practical.

P11 — Accelerator Performance

Future GPU/NPU comparisons must include:

• transfer cost;
• kernel launch;
• occupancy;
• throughput;
• synchronization.

Never compare GPU kernel time while hiding host/device transfer.

P12 — Energy Efficiency

For embedded, mobile and data-center systems, operations-per-joule can matter as much as operations-per-second.

Future benchmark architecture should permit energy measurement.

P13 — AI Token Performance

Measure:

• source tokens;
• context tokens;
• task-completion tokens;
• patch tokens;
• repair iterations;
• semantic context size;
• tool-output tokens.

Performance in the AI era includes communication cost.

8. Performance Claim Rule

No marketing performance statement may become an architecture fact without:

benchmark source
hardware specification
OS
compiler versions
flags
dataset
measurement method
variance
comparison implementation

Examples of prohibited unsupported statements:

Nazm is faster than C.
Nazm is 10x faster than Rust.
Nazm has zero overhead.
Nazm uses less memory than every language.
Nazm always uses fewer AI tokens.

Acceptable:

On benchmark X, commit Y, target Z, Nazm measured N under documented conditions.

9. What “Error-Free” Means

Nazm cannot guarantee the absence of all software errors.

Logical errors, incorrect requirements, hardware faults and compiler defects can still exist.

Therefore “error-free” must be decomposed.

Compiler-preventable target classes

Nazm should aim to eliminate or strongly reduce:

syntax ambiguity
type mismatch
uninitialized access
dangling references
use-after-free
double free
invalid aliasing
data races
unchecked resource lifetime
unhandled important failure
unsafe narrowing
unintended overflow
out-of-bounds access
capability violation
known-invalid information flow

Statically reducible but not universally eliminable

deadlock
livelock
starvation
resource exhaustion
algorithmic complexity attacks
timing bugs
distributed race conditions

Cannot generally be solved by language safety

wrong business requirement
incorrect algorithm
malicious specification
hardware defect
cosmic radiation
incorrect external system
compromised compiler/toolchain

Nazm architecture must never market language safety as universal correctness.

10. Domain Profiles

One semantic language.

Different permitted capabilities.

General Profile

Target:

• applications;
• CLI;
• servers;
• services;
• developer tooling.

Allows broad stdlib and runtime features.

Systems Profile

Target:

• OS components;
• runtimes;
• databases;
• storage engines;
• networking;
• security tools.

Requires stronger control over:

• allocation;
• layout;
• ABI;
• FFI;
• atomics;
• unsafe code.

Embedded Profile

Target:

• MCU;
• robotics;
• firmware;
• IoT;
• controllers.

Needs:

no_std capability
optional/no heap
static allocation
MMIO
interrupts
volatile
cross compilation
small binaries
deterministic startup

Cybersecurity Profile

Target:

• hardened services;
• parsers;
• agents;
• cryptographic systems;
• security tooling.

Needs:

• memory safety;
• capability control;
• provenance;
• secret handling;
• hardened parsing;
• dependency trust.

AI/HPC Profile

Target:

• inference;
• training components;
• scientific computing;
• simulation;
• numerical systems.

Needs:

• SIMD;
• tensor/vector representation;
• accelerator memory;
• specialization;
• CPU/GPU interoperability;
• distributed computation.

Web3 / Decentralized Execution Profile

Target:

• smart contracts;
• decentralized applications;
• protocol state machines;
• token/asset systems;
• chain runtime programs;
• portable WASM contract environments.

Requires, depending on target:

deterministic execution
restricted capabilities
explicit persistent state
resource / gas / compute metering
checked and target-appropriate numerics
typed addresses / hashes / signatures
asset/resource safety
contract ABI generation
storage-layout/version discipline
external-call effect analysis
reproducible deployment artefacts

Web3 is a restriction profile and backend family, never permission to fork Nazm semantics. Chain-specific state or host operations belong behind typed profile capabilities/adapters.

Critical Profile

Target research domains:

• aerospace;
• spacecraft;
• avionics;
• industrial control;
• safety-critical robotics;
• high-integrity infrastructure.

Requires severe restrictions and evidence.

Nazm must NEVER claim that ordinary Nazm is aerospace-certified.

Certification is dependent on:

language subset
toolchain qualification
development process
system architecture
testing
verification
regulatory evidence

The goal is to eventually make Nazm capable of participating in such environments.

11. Proposed Semantic Kernel

The long-term language should attempt to derive many features from a small number of concepts.

11.1 Value

What data exists?

11.2 Type

What values and operations are valid?

11.3 Place

Where is a value stored or projected?

11.4 Ownership

Who is responsible for a resource?

11.5 Region

For what period/context may access exist?

11.6 Effect

What observable operation may occur?

11.7 Capability

What authority does code possess?

11.8 Task

What independently schedulable work exists?

11.9 Message

What ownership/information crosses concurrency boundaries?

11.10 Contract

What must be true before/after computation?

11.11 Profile

Which capabilities and semantic freedoms are permitted in this environment?

11.12 Semantic Identity

What stable machine identity represents this definition across edits?

11.13 Context Packet

What is the minimum semantic information required for an AI agent or tool to act correctly?

11.14 Resource

A value whose duplication, destruction or transfer carries semantic obligations. Ordinary values must not become resources merely because Web3 exists.

11.15 Persistent State

State whose lifetime exceeds one process/execution and whose reads/writes may require explicit authority, version/layout rules and metering. This may remain a profile/library abstraction if the core kernel does not need a new primitive.

11.16 Execution Environment

The explicitly supplied host capabilities, target facts and resource limits under which a program executes. This is the conceptual home for deterministic contract hosts without turning ambient process state into invisible semantics.

11.17 Resource Cost Model

A structured description of costs relevant to a profile: allocations, blocking, CPU work, storage access, gas/compute units, host calls or other metered operations. The cost model is an analysis/tooling concept unless a profile makes a limit semantic.

These additions are candidate semantic responsibilities, not a command to add four new keywords or IR nodes. The Feature Admission Rule below still applies.

12. Feature Admission Rule

Before adding a language feature, answer:

1. Which historical barrier does it solve?
2. Is the barrier still real?
3. Can existing primitives solve it?
4. What semantic complexity does it add?
5. What compile-time complexity does it add?
6. What runtime cost does it introduce?
7. What source-token cost does it introduce?
8. What AI-context cost does it introduce?
9. Can tooling explain that cost?
10. Does it hurt analyzability?
11. Does it affect Critical/Embedded profiles?
12. Can it be removed later?
13. How is it tested?
14. How will AI tools understand it?

If these cannot be answered, the feature is not ready.

13. Syntax Philosophy

Nazm syntax should be:

familiar
minimal
regular
searchable
parseable
machine-editable
human-readable
token-efficient

Avoid unnecessary symbolic density.

Avoid multiple unrelated ways to express the same fundamental operation unless use cases justify them.

Surface convenience is welcome when desugaring is precise.

14. Progressive Disclosure

Beginner:

simple values
functions
conditions
loops
collections

Intermediate:

types
generics
modules
errors
tasks

Advanced:

ownership controls
effects
capabilities
contracts
FFI

Expert:

layout
atomics
SIMD
unsafe
intrinsics
embedded
accelerator
critical verification

Simple programs must not require expert concepts.

Expert programs must not require abandoning the language.

15. Compiler Architecture Goal

Long-term conceptual pipeline:

UTF-8 Source
      ↓
CST
      ↓
HIR
      ↓
Typed Core
      ↓
MIR
      ↓
Monomorphised / profile-specialised MIR
      ↓
LIR / target contract
      ↓
┌───────────────┬───────────────┬────────────────────┐
│ Native        │ WebAssembly   │ Contract backends  │
│ LLVM/other    │               │ EVM / sBPF / ...  │
└───────────────┴───────────────┴────────────────────┘

This is conceptual responsibility separation.

Do NOT create empty layers merely to match the diagram.

Each IR must earn existence.

16. IR Responsibilities

CST

Lossless syntax and editing.

HIR

Resolved language structure.

Typed Core

Stable semantic meaning.

MIR

Control flow, ownership, places, effects, analysis.

Mono MIR

Specialization and representation decisions.

LIR

Small backend-facing machine-independent contract.

17. IR Principle

Higher IR:

preserve meaning

Lower IR:

preserve execution

Every lowering step must have explicit invariants.

18. Optimization Constitution

An optimization must never change defined program semantics.

Every important optimization class should eventually receive:

• positive tests;
• negative tests;
• property tests;
• differential tests;
• mutation tests where practical.

Potential optimization families:

constant folding
constant propagation
dead-code elimination
inlining
escape analysis
stack promotion
copy elimination
devirtualization
specialization
loop transformations
vectorization
layout specialization
PGO
LTO

19. AI-Native Compiler Protocol

AI should never need to reconstruct everything from compiler prose.

Future semantic interface:

definition(id)
type_of(id)
references(id)
callers(id)
callees(id)
effects(id)
capabilities(id)
ownership(id)
contracts(id)
tests_for(id)
semantic_hash(id)
impact_of(change)
context_for(task)
semantic_delta(old,new)

This interface should power:

• Claude Code;
• other coding agents;
• IDE;
• refactoring;
• review;
• documentation;
• static analysis.

20. Human–AI–Compiler Authority Model

Human
  │
  ├──── intent / policy
  │
AI Agent
  │
  ├──── proposal
  │
Compiler
  │
  ├──── semantic validation
  │
Verification Toolchain
  │
  ├──── evidence
  │
Human / release policy
  │
  └──── acceptance

AI is not the semantic authority.

The compiler is not the product authority.

Human policy controls adoption.

21. Research Register Requirements

Every major speculative idea must live in a research register.

Minimum fields:

research ID
hypothesis
motivation
historical barrier
proposed mechanism
dependencies
prototype
benchmark
safety implications
token-efficiency implications
failure criteria
result
decision

Candidate Nazm research areas:

• mutable value semantics;
• region inference;
• effect inference;
• semantic hashes;
• content-addressed compiler;
• automatic data layout;
• M:N runtime;
• green/growable stacks;
• information-flow types;
• ownership-safe accelerator memory;
• heterogeneous scheduling;
• critical-system subset;
• formalized concurrency;
• AI semantic interface;
• semantic context packets;
• token-to-correctness efficiency.

22. Research Failure Is Allowed

A futuristic language must permit experiments to fail.

If evidence shows that:

idea X is slower,
idea Y is too complex,
idea Z cannot remain sound,
idea W is shorter but causes more AI repair iterations,

then Nazm should remove or redesign the idea.

The project must optimize for truth, not attachment to previous design decisions.

23. Architecture Tension Ledger

Some goals naturally conflict.

These conflicts must remain visible.

T1 — Readability vs explicit machine detail

Solution direction:

progressive disclosure.

T2 — Safety vs unrestricted low-level control

Solution:

safe default + explicit unsafe boundary.

T3 — Compile speed vs maximum optimization

Solution:

compilation tiers.

T4 — Portability vs target specialization

Solution:

portable semantics + late target lowering.

T5 — General expressiveness vs critical-system analyzability

Solution:

profiles/restricted subsets.

T6 — Automatic memory management vs deterministic latency

Solution:

ownership/regions as foundation; optional managed strategies.

T7 — Concurrency convenience vs scheduling predictability

Solution:

separate task semantics from runtime scheduler policy.

T8 — AI automation vs trust

Solution:

machine-verifiable gates.

T9 — Token reduction vs human clarity

Solution:

optimize total interpretation and repair cost, not raw token count.

T10 — Short source vs stable semantics

Solution:

prefer semantic compression over cryptic syntax.

24. Language Evolution

Nazm should avoid compatibility paralysis.

Potential strategy:

language editions
+
migration tooling
+
clear deprecation lifecycle

Breaking changes may be acceptable before stable releases.

After stability, evolution needs explicit compatibility policy.

25. Backward Compatibility Is Not Absolute

Compatibility has costs.

Never preserve a dangerous or fundamentally flawed semantic rule forever merely because old experimental programs use it.

Before 1.0, correctness should generally outrank compatibility.

After stability, migration strategy becomes part of language design.

26. Standard Library Philosophy

The language should remain useful with minimal runtime.

Potential hierarchy:

nazm.core
nazm.alloc
nazm.std
nazm.concurrent
nazm.net
nazm.system
nazm.crypto
nazm.accel

Exact names are not specified.

The point is dependency layering.

27. Package Ecosystem Security

Long-term package system should consider:

• locked dependency graphs;
• checksums;
• provenance;
• signatures where justified;
• vulnerability metadata;
• capability declaration;
• reproducible builds;
• vendoring/offline mode.

28. Critical Systems Principle

The critical profile must prioritize:

predictability
analyzability
boundedness
traceability
evidence

over:

maximum convenience
dynamic behaviour
unrestricted metaprogramming
implicit allocation

Critical programming is a different operating environment, not merely a compiler flag.

29. Aerospace / Space Goal

Long-term research should make Nazm technically suitable for evaluation in domains involving:

• flight software;
• spacecraft systems;
• satellite control;
• mission software;
• telemetry;
• embedded autonomy.

Required capabilities potentially include:

deterministic execution
bounded resources
cross compilation
radiation-aware system design support
hardware interfaces
formal contracts
static analysis
traceability
reproducible toolchain
qualified subset

The language project alone cannot certify a spacecraft.

Do not make that claim.

30. Cybersecurity Goal

Nazm should attempt to remove entire exploit categories before runtime.

Defense layers:

memory safety
type safety
capabilities
provenance
safe parsing
dependency integrity
unsafe isolation
sandboxing
secure libraries

Compiler warnings alone are insufficient.

31. Systems Design Goal

Nazm should be able to implement:

• operating-system components;
• network services;
• databases;
• storage systems;
• runtimes;
• compilers;
• device-facing software.

That means high-level convenience cannot remove:

• memory layout control;
• concurrency control;
• FFI;
• atomics;
• deterministic destruction;
• architecture access.

32. AI Goal

Nazm should eventually be unusually strong for implementing AI systems because it can combine:

Python-like readability ambition
+
native execution
+
tensor/vector capability
+
safe concurrency
+
GPU/NPU lowering
+
AI-native development tooling
+
AI-era token efficiency

But these are independent milestones.

Do not market an unfinished compiler as an AI platform merely because this document contains the goal.

33. Performance Benchmark Families

A mature Nazm benchmark suite should include:

Core compute

• integer;
• floating point;
• branches;
• function calls;
• generics/specialization.

Memory

• allocation;
• deallocation;
• arrays;
• maps;
• strings;
• copies.

Systems

• file I/O;
• sockets;
• parsing;
• serialization.

Concurrency

• task spawn;
• channels;
• contention;
• fan-in/fan-out;
• cancellation.

Compiler workload

• Nazm compiler compiling Nazm.

Scientific

• matrix operations;
• numerical loops;
• reductions.

AI

• tensor kernels;
• inference primitives.

Embedded

• code size;
• stack use;
• no-heap execution.

Web3 / deterministic execution

• contract compile time;
• bytecode/object size;
• gas / compute units;
• storage reads/writes;
• state-transition throughput;
• deterministic replay;
• cross-contract/program calls;
• upgrade compatibility;
• fuzz/property failures found;
• audit artefact size/quality.

AI-agent development

• implementation tasks;
• refactoring tasks;
• compiler-error repair;
• architecture-constrained changes;
• security fixes;
• semantic-context retrieval;
• patch size;
• repair iterations.

34. Comparator Policy

Choose comparator languages according to barrier.

Runtime:

C
Rust
Zig

Concurrency/productivity:

Go
Erlang where appropriate

High-level productivity:

Python

Scientific:

Julia
C++

Accelerator:

CUDA

Critical:

Ada/SPARK
C with appropriate safety processes

Web3 / smart contracts:

Solidity / EVM toolchain
Move-family languages where resource safety is the question
Rust-based chain toolchains where account/program execution is the question
WASM contract languages/toolchains where portability is the question

Never compare chain runtimes as though gas, host calls and state models were identical. Choose a comparator for the exact target and workload.

AI-era token efficiency:

C
Rust
Go
Python
Zig

using identical tasks and documented agent/tool conditions.

Never produce one universal ranking.

35. Minimum Claim Evidence

A claim requires:

spec
implementation
tests
measurement
limitations

A major safety claim additionally requires adversarial testing.

A critical-systems claim additionally requires formalized semantics and process evidence.

An AI-token-efficiency claim additionally requires:

task definition
model/tool setup
token accounting method
context supplied
number of iterations
verification outcome

36. Grand Success Criteria

Nazm succeeds if ordinary developers can write software close to their intent while the compiler retains enough knowledge to provide low-level efficiency and strong evidence.

A mature Nazm developer should increasingly receive:

human-readable program
+
native binary
+
semantic diagnostics
+
cost explanation
+
safety analysis
+
dependency provenance
+
AI-efficient semantic context
+
test evidence

from one coherent toolchain.

37. Explicit Non-Goals

Nazm is NOT trying to:

• copy every language feature;
• win every microbenchmark;
• eliminate every software bug;
• automatically parallelize every algorithm;
• remove all unsafe code from systems programming;
• replace every language immediately;
• make one runtime appropriate for every domain;
• make AI the correctness authority;
• certify software merely by compiling it;
• hide hardware when hardware matters;
• expose hardware complexity when it does not matter;
• optimize permanent syntax for one temporary tokenizer;
• minimize token count at the cost of human comprehension;
• turn blockchain concepts into mandatory semantics for ordinary programs;
• promise identical runtime libraries across native, embedded, WASM and Web3 targets;
• hide gas/compute/storage cost behind “automatic” abstractions when a profile meters them;
• claim smart-contract correctness merely because code compiled or passed static analysis;
• chase every blockchain VM or chain at the cost of semantic coherence.

38. Anti-Bloat Constitution

Before language expansion, prefer:

library
→ compiler intrinsic
→ annotation
→ profile rule
→ existing semantic composition

before adding new fundamental syntax.

New syntax is the most expensive option.

Syntax survives for decades.

39. The “One Language Everywhere” Interpretation

Nazm’s vision of broad domain coverage means:

one semantic foundation

not:

one identical runtime
one identical standard library
one identical set of permissions
one identical optimization strategy

Different environments require different execution policies.

That is not fragmentation if semantics remain coherent.

40. North-Star Domain Matrix

This table describes goals, not current implementation. A Web3 cell marked “Required” means required for that future profile to make the stated claim; it does not mean the feature exists today.

41. Language Quality Metrics

Nazm should eventually measure itself across:

correctness
safety
runtime speed
memory efficiency
compile time
binary size
startup
concurrency scalability
diagnostic quality
code readability
tool determinism
reproducibility
ecosystem interoperability
AI token efficiency
AI task-completion efficiency

No single metric defines success.

42. Developer Experience Metrics

Future experiments should measure:

• time to first successful program;
• time to understand diagnostic;
• time to fix type error;
• amount of annotation required;
• incremental check latency;
• code required for common tasks;
• frequency of unsafe escape;
• percentage of diagnostics automatically repairable;
• code review comprehension.

Human performance is performance.

43. AI Developer Experience Metrics

Future AI evaluation:

compile success
test success
semantic correctness
number of repair iterations
diagnostic interpretation success
stale-fix rejection
minimality of patch
semantic regression rate
input tokens
output tokens
tool tokens
context tokens

Compare:

plain compiler prose
vs
structured Nazm semantic interface

This provides evidence that AI-native design actually helps.

44. Compiler Self-Knowledge Goal

A future Nazm compiler should increasingly understand not merely syntax and types but program relationships.

Semantic graph may include:

definitions
references
calls
types
effects
capabilities
ownership
resources
tests
contracts
modules
build inputs
semantic identities

This semantic graph becomes foundational for:

• incrementality;
• AI agents;
• refactoring;
• security analysis;
• change impact;
• token-efficient context delivery.

45. Verification Ladder

Nazm should progressively climb:

syntax
 ↓
types
 ↓
ownership
 ↓
effects
 ↓
capabilities
 ↓
concurrency safety
 ↓
contracts
 ↓
information flow
 ↓
selected formal proof

Not every program needs the highest rung.

46. Runtime Philosophy

Runtime functionality must be modular.

Possible runtime components:

allocator
task scheduler
reactor
panic machinery
threading
I/O
stack management
GC — if an optional managed mode is ever justified

A bare-metal program should not drag in server runtime features.

47. Scheduler Principle

Language task semantics should not be irreversibly tied to the first scheduler implementation.

Potential runtime evolution:

OS threads
        ↓
hybrid runtime
        ↓
M:N scheduler

if evidence justifies it.

Semantics must remain stable while implementation improves.

48. Automatic Parallelism Rule

The compiler may parallelize only when it can preserve defined semantics.

Nazm must not promise magical parallelization.

Programmer-visible constructs for parallel intent may still be necessary.

49. Data Layout Rule

Compiler-selected layout is allowed only where representation is not part of observable semantics.

FFI and explicit-layout types must remain stable.

50. Unsafe Constitution

Unsafe operations must never mean:

compiler stops caring.

Unsafe means:

the programmer/compiler component assumes explicitly documented obligations that the type system cannot prove.

Every unsafe primitive needs:

• safety contract;
• allowed use;
• invalid use;
• tests;
• review.

51. Ecosystem Adoption Goal

Nazm should become adoptable incrementally.

Desired migration pattern:

existing C/C++/other native project
        ↓
one Nazm component
        ↓
shared ABI
        ↓
more components if valuable

No rewrite mandate.

52. Self-Hosting Trust Rule

Maintain independent semantic/reference evidence even after self-hosting.

A compiler proving itself with itself creates common-mode risk.

Self-hosting should add evidence, not remove independent evidence.

53. Release Evidence Goal

A future release report should eventually resemble:

SOURCE VERIFIED
LANGUAGE TESTS VERIFIED
DIFFERENTIAL TESTS VERIFIED
MUTATION VERIFIED
FUZZ VERIFIED
BOOTSTRAP VERIFIED
REPRODUCIBILITY VERIFIED
TARGET MATRIX VERIFIED
PERFORMANCE REGRESSION VERIFIED
TOKEN-EFFICIENCY REGRESSION VERIFIED
PROVENANCE VERIFIED

Not merely:

tests passed.

54. Historical Lesson Summary

Nazm should learn:

from C: respect the machine.

from C++: abstraction can remain native, but complexity accumulates.

from Python: humans matter.

from Java: portability and managed safety can transform software deployment.

from Erlang: failure isolation matters as much as successful execution.

from Go: simplicity, build speed and tooling are language features.

from Rust: systems safety does not require mandatory GC.

from Zig: invisible behaviour deserves suspicion.

from SPARK: high assurance requires restrictions and evidence.

from Haskell: visible effects improve reasoning.

from CUDA: hardware parallelism sometimes requires new execution models.

from Julia: high-level scientific productivity and low-level performance should not require two codebases.

from Swift: native safety and approachable syntax can coexist.

from Kotlin: interoperability and pragmatism accelerate adoption.

from ML/OCaml: algebraic data, exhaustive matching and inference can compress complex symbolic programs without surrendering static meaning.

from TypeScript: semantic tooling and incremental adoption can be adoption features as important as syntax.

from WebAssembly: portable sandboxing can be a compilation target rather than a separate source language.

from Solidity/EVM: consensus execution makes determinism, storage layout, ABI and resource cost part of correctness.

from Move: scarce digital assets need resource semantics stronger than ordinary copy/discard conventions.

from account-oriented chains: explicit state-access authority can improve security and parallel scheduling.

from the AI era: context and reasoning tokens are part of software-development cost.

Nazm must synthesize lessons, not syntax.

55. Ultimate Nazm Equation

C machine access
+
C++ zero-cost abstraction ambition
+
Python readability/productivity ambition
+
Go tooling/concurrency simplicity
+
Rust static safety
+
Erlang failure isolation
+
Zig cost transparency
+
SPARK assurance discipline
+
Haskell effect reasoning
+
CUDA heterogeneous compute
+
Julia scientific performance/productivity
+
WebAssembly portable sandboxing
+
Move-style resource-safety lessons
+
EVM smart-contract determinism and ABI lessons
+
account-oriented decentralized execution lessons
+
modern AI semantic tooling
+
AI-era token efficiency
-----------------------------------------
            NAZM

This equation is conceptual.

It does not mean literal feature equivalence.

56. The Hardest Research Question

The most important question is not:

How do we add all these features?

It is:

What is the smallest semantic system from which most of these properties can emerge without contradiction?

Current candidate answer revolves around:

ownership
regions
effects
capabilities
tasks
messages
contracts
profiles
semantic identity

This hypothesis must be tested.

57. Definition of Futuristic

“Futuristic” does not mean unusual syntax.

Nazm becomes futuristic if it meaningfully improves unresolved problems such as:

• human + AI collaborative programming;
• safe systems development;
• predictable high-level performance;
• semantic incremental compilation;
• heterogeneous hardware;
• provenance-aware security;
• evidence-producing builds;
• verified self-host development;
• token-efficient agent workflows.

58. Definition of Machine-Native

Machine-native means:

• hardware-aware when necessary;
• native code generation;
• direct ABI interoperability;
• no mandatory virtual machine;
• explicit memory/layout controls;
• SIMD/accelerator capability;
• small-runtime possibility.

59. Definition of AI-Native

AI-native means:

• stable semantic APIs;
• machine-readable diagnostics;
• semantic identities;
• deterministic tools;
• safe automatic edits;
• change-impact information;
• compiler-verifiable agent workflows;
• minimum-sufficient-context delivery;
• semantic delta protocols.

It does NOT require embedding AI inference inside every compiled program.

60. Definition of Human-Readable

Human-readable means:

• local reasoning;
• predictable grammar;
• limited implicit behaviour;
• clarity at use sites;
• explainable costs;
• excellent diagnostics;
• progressive disclosure;
• consistent formatting.

61. Definition of Token-Efficient

Token-efficient means:

• low unnecessary redundancy;
• high semantic density;
• regular grammar;
• concise but meaningful naming;
• compiler-backed inference;
• structured diagnostics;
• semantic context retrieval;
• minimal patches;
• low repair iteration count;
• efficient intent-to-verified-code flow.

It does NOT mean:

• code golf;
• cryptic symbols;
• tokenizer-specific hacks;
• sacrificing human comprehension for shorter source.

62. Definition of Safe

Safe means specific guarantees.

Every guarantee must name its scope.

Examples:

memory safe
data-race safe
bounds safe
type safe
capability safe

Never use “safe” without specifying what safety property is guaranteed.

63. Definition of Reliable

Reliable includes:

safety
determinism
failure containment
resource control
testing
verification
reproducibility
observability

Reliability is broader than memory safety.

64. Long-Term Maturity Stages

Stage A — Correct language core

Semantics and compiler correctness.

Stage B — Self-hosted language

Nazm builds Nazm.

Stage C — Safe systems language

Ownership/resource semantics mature.

Stage D — Concurrency-native language

Structured concurrency and data-race safety mature.

Stage E — Semantic tooling language

Incremental/AI-native compiler interfaces mature.

Stage F — Token-efficient agent-development platform

Semantic context packets, delta protocols, structured edits and AI task metrics mature.

Stage G — High-performance general language

Native performance and optimization mature.

Stage H — Embedded/systems platform

Bare-metal and architecture controls mature.

Stage I — Heterogeneous compute language

SIMD/GPU/accelerator model matures.

Stage J — Portable / decentralized execution platform

WebAssembly and at least one evidence-backed Web3 contract backend mature under deterministic, capability-restricted and resource-metered profile semantics.

Stage K — High-assurance profile

Formalized restricted semantics mature. Critical and Web3 verification infrastructure may share contracts/proof machinery where their semantic obligations overlap.

These stages may overlap, but evidence must remain independent.

65. Current Development Discipline

This goal file must never instruct an agent to implement everything immediately.

At every stage:

specify
→ implement minimum coherent slice
→ test
→ measure
→ attack
→ document
→ expand

Never:

add twenty features
→ hope architecture emerges.

66. Instructions to Claude Code and Future Agents

When using this document:

1. Treat it as long-term direction.
2. Do not mark goals implemented because they appear here.
3. Cross-reference the capability matrix for current truth.
4. Cross-reference specifications for semantics.
5. Cross-reference tests for evidence.
6. Cross-reference benchmarks for performance claims.
7. Put speculative concepts in the research register.
8. Do not implement future phases without dependency justification.
9. Preserve current verified behaviour while evolving architecture.
10. Challenge this document when evidence contradicts it.
11. Treat token efficiency as a measurable performance property.
12. Do not optimize syntax for a single tokenizer.
13. Prefer semantic compression over cryptic brevity.
14. Prefer minimum sufficient semantic context for agents.
15. Prefer structured edits over whole-file rewrites where safe.

67. Mandatory Agent Question Before Major Work

Before a significant implementation, an agent should be able to answer:

Which barrier are we solving?

Why now?

What prerequisite is already satisfied?

Which semantic invariant changes?

What existing verified behaviour can regress?

What runtime cost changes?

What token/context cost changes?

What evidence will prove success?

What result would cause us to reject this design?

If these answers are missing, implementation is premature.

68. Goal File / Status File Separation

This file should change rarely.

NAZM_LANGUAGE_GOALS.md answers:

Where are we ultimately going?

A capability matrix answers:

What exists today?

A roadmap answers:

What comes next?

A specification answers:

What exactly does the language mean?

A research register answers:

What are we still uncertain about?

A benchmark report answers:

How does it actually perform?

An AI/token benchmark report answers:

How efficiently can agents understand and produce verified changes?

A release report answers:

What exactly did we verify?

Never collapse these into one document.

69. AI-Era Development Model

Nazm should explicitly anticipate a future development workflow:

Human
  ↓
problem selection
architecture
constraints
trade-offs
risk decisions
approval

AI agents
  ↓
implementation
tests
refactoring
migration
routine debugging
documentation
repetitive optimization

Compiler + verification toolchain
  ↓
semantic checks
safety checks
tests
mutation
fuzzing
bootstrap
reproducibility
provenance

Human
  ↓
governance
approval
release

This model does not remove humans from programming.

It moves humans toward intent, architecture, governance and high-value decisions while automation takes more implementation burden.

70. Intent-to-Verified-Software Efficiency

The ultimate AI-era optimization target is not:

fewest source tokens

It is:

fewest total resources needed to move from
human intent
to
verified implementation

Resources include:

human attention
AI input tokens
AI output tokens
tool tokens
compiler work
repair iterations
test runs
review effort
runtime compute

Nazm should seek Intent → Verified Software Efficiency.

This may become one of the defining performance dimensions of the language.

71. Final North Star

Nazm should allow a developer to express intent at a high level without forcing them to surrender knowledge or control of the machine.

The compiler should understand enough semantics to protect the programmer from major classes of failure, optimize aggressively, expose meaningful costs, support concurrent and heterogeneous execution, communicate precise program meaning to humans, IDEs and AI agents, and provide compact semantic context for automated development.

For portable sandboxed and decentralized execution, the same semantics should be lowerable through WebAssembly and contract-oriented backends while profiles restrict ambient authority, enforce determinism, expose persistent state and make metered resource cost visible.

For Web3, smart-contract features must remain a restriction/profile/backend concern rather than contaminating ordinary Nazm with chain-specific meaning. Asset/resource safety, authorization, ABI/storage generation and contract verification should reuse the general ownership, effects, capabilities, contracts and provenance architecture wherever sound.

For critical domains, the same semantic foundation should be restrictable into profiles that prioritize analyzability, determinism and evidence.

For low-level domains, the programmer must still be able to reach the hardware.

For high-level domains, those details should disappear when irrelevant.

For AI-assisted development, program meaning must be available through deterministic semantic interfaces rather than guessed from source text.

For token efficiency, the language must minimize unnecessary ceremony while avoiding cryptic syntax, and the toolchain must minimize the amount of context an agent needs to complete a verified change.

For performance, claims must come from measurements.

For safety, claims must name guarantees.

For reliability, claims must come with evidence.

For future evolution, experimental ideas must remain removable until proved.

The ultimate objective is not:

one language with every feature.

It is:

one coherent semantic foundation that removes as many historical programming barriers as possible while preserving human clarity, machine efficiency, safety, determinism, evidence, control, portable/decentralized execution, and AI-era token efficiency.

That is the long-term Nazm goal.