Gamified Underlying Navigation Zones 3.15.0

Copyright 19/07/2026 Corentin Amice

Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and

Co-authored by DeepSeek, Corentin Amice, "The Mirror", "The Calibration Hammer" and "The Dancing Hammer".

---

GUNZ 3.15.0 — Gamified Underlying Navigation Zones

ISA · Runtime · Library

---

1. Overview

GUNZ 3.15.0 (Gamified Underlying Navigation Zones) is a deterministic, offline‑scanner runtime for discrete‑clock systems. It produces compressed resonance maps — stability topographies — that describe optimal operating frequencies for any process governed by a fixed‑quantum clock. The format targets AI‑driven feedback loops, heterogeneous hardware deployment, and long‑term archival.

The bytecode ISA (§2) enables AI agents to programmatically orchestrate complex multi‑zone scans, deterministic conditional logic via PURE_CALL, and library composition — all without runtime recompilation. The ISA's primary purpose is orchestration, not bulk scanning: a typical dynamic program issues a handful of ZONE instructions (each defining a playground — an FPS range to explore) and lets the static‑lane evaluator (§3.4) process millions of FPS candidates. Implementations may support only static‑lane programs (rejecting dynamic programs at load time) and still be conformant; the bytecode VM is an optional extension for advanced autonomous exploration.

The specification is split into four independent layers:

• GUNZ‑ISA – bytecode format and instruction semantics.
• GUNZ‑RT – execution runtime (memory, lanes, map generation).
• GUNZ‑LIB – library profiles, resonance map format, fingerprinting, and integrity.
• GUNZ‑NET (future companion specification; currently under construction)

A normative Conformance chapter specifies test vectors that any compliant implementation must satisfy.

Normative vs. Informative – Sections marked as (Informative) contain recommendations; all other sections are normative.

---

1.1 Minimal Conformance Profile (Static Lane, Trusted Code)

A conformant GUNZ implementation that targets the Minimal Profile must implement the following:

• Bytecode header parsing (§2.2) – Accept only the static lane opcode set. Reject unknown major versions. Reject unknown minor versions unless explicitly declared forward‑compatible. Validate magic, time_unit ≤ 12, and target_ticks ≥ 1.

• Static opcode subset – Implement HALT, ZONE, SKIP_ZONE, SCAN_RES, and EXPORT. All other opcodes (including LOOP, IMPORT, JOIN, STREAM, PURE_CALL) must be rejected with GUNZ_MALFORMED_BYTECODE.

• Resonance Evaluator (§3.11) – Implement Phase 1 dense scan and Phase 2 stability width. Use integer arithmetic in the base time unit, half‑to‑even rounding (§4.5.1), and the deterministic standard deviation algorithm (§4.5.3). Enforce max_scan_iterations and total_max_scan_iterations (§3.4.1), failing with GUNZ_ITERATION_LIMIT_EXCEEDED if exceeded.

• Map output (§4.2, §4.2.1) – Produce 16‑byte map entries with canonical ordering, run‑length consolidation, and the long‑jump sentinel. Compute the XXH3‑64 checksum over the entries. Write a valid map header with map_version matching the specification.

• Error reporting – Return GUNZ_Result codes as defined in §3.3. No additional diagnostic strings or structured error payloads are required.

The Minimal Profile does not require:

• Dynamic lane opcodes, the bytecode VM, or fuel accounting.
• PURE_CALL, STREAM, IMPORT, JOIN, or any callback infrastructure.
• Sandboxing, environment snapshots, or attestation.
• Thread safety or reference counting (single‑threaded use is assumed).
• Streaming, sparse maps, long‑term scan, or compressed statistics.
• Structured diagnostic strings or machine‑readable error payloads.

An implementation satisfying the Minimal Profile is fully conformant for all GUNZ programs that do not use dynamic opcodes, callbacks, or network features. Implementors may optionally support higher conformance tiers (dynamic lane, sandboxing, etc.) by following the normative sections of this specification.

---

2. GUNZ‑ISA (Bytecode)

2.1 Binary Encoding

• All multi‑byte integers are encoded in little‑endian byte order.
• The bytecode is tightly packed; no padding bytes exist between fields.
• Operands immediately follow their opcode without alignment padding.
• The header is exactly 32 bytes for all version 3.x revisions. Future major versions may define a different header size; implementations shall reject unknown major versions.
• Minor version handling: Implementations shall reject bytecode with an unknown minor version (within the same major version) unless that minor version has been explicitly declared forward‑compatible by the implementation.
• Decoding is host‑endianness‑independent by construction: the bytecode is always little‑endian, and a correct decoder converts fields to host byte order. A mismatch of the magic field after correct little‑endian decoding shall be rejected.
• Unaligned accesses (normative): The bytecode stream is intentionally tightly packed; decoders must perform unaligned multi‑byte reads using portable methods (e.g., byte‑by‑byte reassembly or memcpy). Failure to handle unaligned accesses correctly is non‑conforming. The evaluator's hot path operates on native‑aligned structures constructed at plan‑build time (§3.4.1), so unaligned accesses are a decoding concern only.

2.2 Header (32 bytes, fully aligned)

Offset	Size	Field	Description
0	u32	magic	0x47554E5A
4	u32	version	0x0003000F (major 3, minor 15)
8	u32	quantum	Clock granularity in the base time unit (0 = use library quantum)
12	u32	target_ticks	Ticks to reach (e.g., 1140). Must be ≥ 1; target_ticks = 0 shall be rejected with GUNZ_MALFORMED_BYTECODE.
16	u32	mult_num	Advance multiplier numerator
20	u32	mult_den	Denominator
24	u8	round_mode	0 = floor, 1 = nearest (half‑to‑even), 2 = ceil, 3 = truncate. All modes apply only to non‑negative operands; negative inputs are undefined and shall be rejected.
25	u8	hold_frames	Hold frames after target
26	u8	sep_frames	Input‑separation frames
27	u8	time_unit	Decimal exponent such that one base time unit = 10⁻ᵗⁱᵐᵉ_ᵁⁿⁱᵗ seconds. Examples: 0 = seconds, 3 = milliseconds, 6 = microseconds, 9 = nanoseconds, 12 = picoseconds. All time values in the header and evaluator are expressed in this unit. Normative maximum: time_unit ≤ 12; larger values shall be rejected with GUNZ_MALFORMED_BYTECODE.
28	u16	flags	See table below
30	u16	library_id	0 = none (or custom)

Flags (u16):

Bits	Name	Description
0‑4	(reserved)	Must be 0
5	long_term_scan	When set, the scanner shall evaluate multiple consecutive blocks for each FPS candidate, accumulating statistics over the configured measurement window (see §3.11 and §4.9).
6	analytical_boundary	Deprecated. Implementations shall ignore this flag; users must not rely on it. This bit is reserved for future use.
7	sandboxed_callbacks_required	When set, any PURE_CALL in the program must be executed in a sandboxed environment that physically prevents side effects (§3.7). If the runtime cannot provide such sandboxing, the program shall be rejected with GUNZ_INVALID_LIBRARY.
8‑14	lane_requirements	Bitmask of required runtime capabilities (0 = Static Lane only)
8	(reserved)	Must be 0; ignored by lane‑requirement checks
9	(reserved)	Must be 0
10	sparse_map	When set, the map generator shall merge any omitted intervals' run lengths into the next emitted entry's fps_delta_start, preserving spatial correctness.
11	streaming	Enable streaming map output
12	deduplicate	Enable deterministic fingerprint deduplication
13	(reserved)	Must be 0
14	(reserved)	Must be 0
15	(reserved)	Must be 0

lane_requirements (bits 8‑14) declares which optional features the program requires; a scanner that does not support a required feature must reject the program.
The header contains no runtime‑only state (e.g., dynamic/static lane classification); that is determined at load time (see §2.4).

2.3 Opcodes

Opcodes not explicitly listed in this section are reserved and shall cause the decoder to reject the bytecode with GUNZ_MALFORMED_BYTECODE. Reserved opcodes are assigned for future standard extensions.

2.3.1 Static Lane Opcodes (0x00‑0x0C)

These opcodes are deterministic and may only be used by programs that satisfy the Static Lane criteria of §2.4.

Opcode	Mnemonic	Operands	Description
0x00	HALT	–	End of program.
0x01	LOOP	u16 count, u16 block_bytes	Repeat the following block_bytes bytes count times. The block is self‑delimiting; decoders skip it in constant time by advancing `block_byte...