Type: case · Domain: engineering · Stakes: low · Trust: self-tested\nTags: navigable-json, turing-complete, schema-guided-reasoning, agent-orchestration, state-machine, hybrid-architecture, bohm-jacopini, live-validation
After publishing the original .njson format, I kept thinking about what it actually is. It's not just a data format with byte offsets — it's a virtual machine for LLM agents. The primitives map directly to the structured program theorem (Böhm 1964; Böhm-Jacopini 1966). Its extended form — the textbook statement usually cited — says that three constructs (sequence, selection, iteration) are sufficient to implement any algorithm; the original 1966 result was sharper still, needing only two (sequence and iteration), since selection can be encoded as iteration. In .njson, these become: no (next header) is sequence/iteration, bo (body offset) is selection, and the reader loop is the while construct. The agent's context is RAM. With pointer manipulation (cyclic no links), the format becomes theoretically Turing-complete.
But theoretical elegance crashes into practical reality when your \"CPU\" is a probabilistic neural network. I ran one live experiment — a small model (deepseek-v4-flash) executing real .njson fixtures through a byte-offset read_file tool — to see what the machine actually does. This dump gives you the mapping, both orchestration patterns as runnable JavaScript, a canonical linker and reader, and the measured results of that run: where the model was comfortable, where it struggled, and the format changes those failures point to.
Two orchestration patterns are compared: (1) Pure Turing Machine (Pattern A), where the LLM manages control flow through the no/bo pointers, and (2) Hybrid Orchestration (Pattern B), where a deterministic backend manages state while the LLM acts as a schema-guided decision engine. Pattern B connects directly to Rinat Abdullin's Schema-Guided Reasoning (SGR).
The structured program theorem, in its extended form, states that any computable function can be implemented using just three program structures:
\nThese three are sufficient primitives for a Turing-complete system. Now let's map them to .njson. Every _nj field is an absolute byte offset from the file start, so every move is \"read exactly <size> bytes at <offset>\" — no arithmetic:
| Böhm-Jacopini Primitive | \n.njson Equivalent | \nHow It Works | \n
|---|---|---|
| Sequence (A → B) | \n_nj.no (next offset) + _nj.nl (its length) | \nRead header A, then read exactly nl bytes at no to get header B. while (no != -1) { readHeader(no, nl); } | \n
| Selection (if C then A else B) | \n_nj.bo (body offset) + _nj.bhl + LLM evaluation | \nRead header, evaluate condition (e.g., \"does tags contain 'finance'?\"). If yes, read the body (bl at bo); if no, follow no. The LLM is the branch predictor. | \n
| Iteration (while C do A) | \nCyclic no pointer | \nA no that points back to an earlier record is a loop — the same header is read again on the next pass. The loop ends when the program's own condition leaves it, branching to a header whose no = -1 (HALT). Revisiting an offset is the mechanism of iteration, not a failure. | \n
| Memory / State | \nAgent's context window | \nEvery read accumulates in the agent's context. This is the heap/stack. | \n
| Call Stack | \nNested .njson documents (bhl > 0) | \nWhen bhl > 0 the body is itself Navigable JSON: read exactly bhl bytes at bo to get the nested root _nj, then follow its absolute no/bo. This is a function call: a new scope with its own level. | \n
| HALT | \n_nj.no = -1, or SGR action: \"HALT\" | \nTermination. Reaching it is the program's job: because a cyclic no is a loop, the exit is a conditional branch to a HALT header, not the sentinel at the end of a chain. In Pattern B the backend enforces limits. §6 sees a model that does not always emit HALT by itself. | \n
.njson is not passive data. It's executable bytecode for an LLM-based virtual machine. The linker is exactly that — a linker: it takes a document and resolves its references into concrete, absolute byte addresses (a relocation pass), no more. What composes that JSON in the first place — the source program, the compiler's job — is out of scope here; this article starts from a finished structure. The byte offsets it assigns are absolute addresses, and the LLM with a read(offset, size) tool is the CPU running fetch-decode-execute cycles.
This reframes how we think about agent architecture: we're not \"feeding documents to a model,\" we're running programs on a probabilistic CPU — and §6 is a first look at how that CPU behaves.
\nThe LLM is the entire control unit. It:
\n_nj (the one unsized read) to get the first header offset no and its length nlnl bytes at no to get a header, and evaluates its semantic keys (description, tags)bl bytes at bo, or exactly bhl bytes at bo for a nested levelno to the next headerno = -1 (HALT) — a loop is just a no that points back, and the condition that ends it lives in the program, not in the readerThe agent maintains state in its context: the loop variables and accumulated results (this is RAM), plus the current offset. Revisiting an offset is expected while a loop runs.
\nThis is the deterministic reference for the moves the agent must make. It follows no until -1; a program that never reaches -1 simply runs long — catching that is the program author's job, not the reader's (the format is C-like: it does not bounds-check your program).
// §2 — Pattern A: a deterministic reference for the moves the agent must make.\n// The protocol has four moves: read the root `_nj` (the one unsized read), then\n// read exactly `nl` bytes at `no` for a header, exactly `bl` bytes at `bo` for an\n// atomic body, and exactly `bhl` bytes at `bo` to descend into a nested document.\nexport const NJ_START = '\"_nj\":';\n\n// Read the value starting at (or just after) byte `off`; return it and its length.\n// Leading JSON whitespace is skipped, so the root `_nj` can be found with indexOf.\nexport function readNjAt(buf, off) {\n while (off < buf.length && (buf[off] === 0x20 || buf[off] === 0x0a || buf[off] === 0x0d || buf[off] === 0x09)) off++;\n let depth = 0, j = off;\n while (j < buf.length) {\n if (buf[j] === 0x7b) depth++; // {\n else if (buf[j] === 0x7d) { depth--; if (depth === 0) { j++; break; } } // }\n j++;\n }\n return { nj: JSON.parse(buf.slice(off, j).toString('utf8')), len: j - off };\n}\n\n// The whole control unit, with no arithmetic on addresses:\n// sequence / iteration = follow `no`; selection = follow `bo`; call = descend.\n// A cyclic `no` is a loop: revisiting an offset is normal, and only `-1` (HALT)\n// ends the walk. `maxIterations` is a watchdog on this demo, not a format rule —\n// a program that never reaches HALT is a bug in the program, not something the\n// reader detects (the format is C-like and does not bounds-check programs).\nexport function turingMachineReader(buf, match, entry = null, maxIterations = 100) {\n const start = entry === null\n ? readNjAt(buf, buf.indexOf(NJ_START) + NJ_START.length) // the unsized read\n : readNjAt(buf, entry); // nested root `_nj`\n let cur = start.nj.no; // first record's `_nj` offset\n let want = start.nj.nl; // exact bytes to read there\n const results = [];\n let iterations = 0;\n\n while (cur !== -1 && iterations < maxIterations) { // loop while `no != -1`\n iterations++;\n const nj = JSON.parse(buf.slice(cur, cur + want).toString('utf8')); // exactly `nl` at `no`\n if (match(nj)) { // selection: the branch prediction\n if (nj.bhl > 0) {\n // Nested body = a call: `bo` is the nested root `_nj`, `bhl` its exact size.\n results.push({ nested: true, child: turingMachineReader(buf, match, nj.bo, maxIterations) });\n } else {\n const body = buf.slice(nj.bo, nj.bo + nj.bl).toString('utf8'); // exactly `bl` at `bo`\n results.push({ description: nj.description, body: JSON.parse(body) });\n }\n }\n cur = nj.no; // sequence / iteration\n want = nj.nl;\n }\n return { results, iterations, halted: cur === -1, hitLimit: iterations >= maxIterations };\n}\nThe failure modes below were the working hypothesis for why a probabilistic CPU would make a poor control unit. They are not what a live run showed at small scale — §6 reports the measured results, and the specific predictions here (lost loop state, rereading a forgotten record, reading offset -1, hallucinated progress) did not reproduce for chains of up to 12 records. For larger documents they remain untested hypothesis, not evidence.
no = -1 the model tries to read offset -1, or ignores the sentinel and keeps looping.What is safe to say today: Pattern A is a small-scale demonstration of the mapping. Its reliability at scale is an open question, because (see §6) the model does not actually iterate byte-by-byte — it reads everything once and simulates the loop in its own context.
\nIf the LLM is bad at managing control flow, don't let it. Split the responsibilities:
\n.njson provides read-only memory with byte-offset addressingcurrent_offset, visited_ids, batch size, iteration limitsThis is the same pattern Rinat Abdullin describes in his Schema-Guided Reasoning article: translate the domain expert's mental checklist into a structured reasoning schema, enforced via constrained decoding.
\n┌─────────────────────────────────────────────────────────┐\n│ Backend (JavaScript/Python/Java) — Deterministic FSM │\n│ │\n│ State: current_offset, visited_ids, iteration_count │\n│ Logic: Fetch next batch, enforce limits, manage I/O │\n│ │\n│ ┌──────────────────────────────────────────────────┐ │\n│ │ LLM (SGR-Constrained) — Probabilistic CPU │ │\n│ │ │ │\n│ │ Input: batch of headers (from .njson) │ │\n│ │ Output: structured JSON decision │ │\n│ │ { │ │\n│ │ \"action\": \"FETCH_NEXT\" | \"READ_BODY\" | \"HALT\",│\n│ │ \"selected_ids\": [...], │ │\n│ │ \"reasoning\": \"...\", │ │\n│ │ \"search_refinement\": \"...\" │ │\n│ │ } │ │\n│ └──────────────────────────────────────────────────┘ │\n└─────────────────────────────────────────────────────────┘\nThe backend owns every byte move; the model only returns a decision. Each offered header's id is its absolute _nj offset — a value the backend can check and the model can copy, so an id the model invents is rejected instead of trusted.
// §3 — Pattern B: a deterministic backend owns every byte move; the LLM only picks.\n// `decide(query, batch)` is the SGR-constrained call and must return\n// { action: \"FETCH_NEXT\" | \"READ_BODY\" | \"HALT\", selected_ids: string[], reasoning: string }\n// where each offered header's `id` is its absolute `_nj` offset.\nexport async function execute(query, buf, decide, { batchSize = 10, maxIterations = 10, entry = null } = {}) {\n const start = entry === null\n ? readNjAt(buf, buf.indexOf(NJ_START) + NJ_START.length)\n : readNjAt(buf, entry);\n let current = start.nj.no;\n let want = start.nj.nl;\n const visited = new Set();\n const results = [];\n let iterations = 0;\n let reason = 'MAX_ITERATIONS_REACHED';\n\n while (iterations < maxIterations) {\n iterations++;\n\n // FETCH: the backend reads the next batch of headers itself — always exact reads.\n const batch = readHeaders(buf, current, want, batchSize);\n if (batch.headers.length === 0) { reason = 'END_OF_FILE'; break; } // backend halts on EOF\n current = batch.nextOffset; want = batch.nextLen;\n\n // DECODE: the model returns only the decision object.\n const decision = await decide(query, batch.headers);\n\n // EXECUTE: the backend, not the model, touches memory.\n if (decision.action === 'HALT') { reason = decision.reasoning; break; }\n for (const id of decision.selected_ids || []) {\n const header = batch.headers.find(h => h.id === id);\n if (!header) throw new Error(`model selected an id that was never offered: ${id}`);\n results.push({ id, body: readBody(buf, header.nj) }); // exactly `bl` at `bo`\n visited.add(id);\n }\n // FETCH_NEXT falls through to the next batch.\n }\n return { results, iterations, visited: [...visited], reason };\n}\nThe key is constrained decoding: the LLM is physically unable to output anything except valid JSON matching this schema:
\n{\n \"$schema\": \"https://json-schema.org/draft/2020-12/schema\",\n \"title\": \"NjsonOrchestrationDecision\",\n \"type\": \"object\",\n \"required\": [\"action\", \"reasoning\"],\n \"properties\": {\n \"action\": {\n \"type\": \"string\",\n \"enum\": [\"READ_BODY\", \"FETCH_NEXT\", \"HALT\"],\n \"description\": \"What the agent wants to do next\"\n },\n \"selected_ids\": {\n \"type\": \"array\",\n \"items\": { \"type\": \"string\" },\n \"description\": \"IDs of headers to read bodies for (only if action=READ_BODY)\"\n },\n \"reasoning\": {\n \"type\": \"string\",\n \"description\": \"Why the agent made this decision (audit trail)\"\n },\n \"search_refinement\": {\n \"type\": \"string\",\n \"description\": \"Optional: how to refine the search for the next batch\"\n }\n },\n \"allOf\": [\n {\n \"if\": { \"properties\": { \"action\": { \"const\": \"READ_BODY\" } } },\n \"then\": { \"required\": [\"selected_ids\"] }\n }\n ]\n}\nWith constrained decoding (OpenAI Structured Outputs, vLLM xgrammar, Ollama JSON Schema), the LLM cannot emit free-form text or break the shape of the loop with an invalid id. In the live run (§6) the json_schema response format was accepted and every decision parsed; the model selected only offered ids. What constrained decoding does not guarantee is that the model chooses to stop — see §6.
MAX_ITERATIONS and treats end-of-file as a halt. No infinite loops.reasoning. You can replay the entire execution trace.search_refinement to filter the next batch (e.g., if the LLM says \"add keyword 'multithreading'\", the backend applies a tag filter).Rinat Abdullin's SGR pattern is the missing piece that makes Pattern B reliable. From his article:
\n\n\n\"Schema-Guided Reasoning (SGR) is a technique that guides large language models (LLMs) to produce structured, clear, and predictable outputs by enforcing reasoning through predefined steps.\"
\n
In our context:
\nWithout SGR, Pattern B would drift back toward Pattern A's problem: free-form text that is hard to act on. With SGR, the LLM is a constrained decision engine, and the backend handles all the messy state management.
\nThese are the two pieces the article's examples actually run on. Canonical style means: exactly JSON.stringify(value, null, 2), UTF-8, LF, no BOM; root key order $schema, description, _nj, records; each record is {\"_nj\": <njValue>, \"body\": <bodyValue>}.
The linker bakes absolute byte offsets by fixpoint: offsets in the text depend on the offset digits, so it re-emits until the bytes stop changing. A record's body that is a JavaScript array means a nested document; any other value is atomic (wrap an array in an object to store an array atomically).
// §5.1 — linker: bake absolute byte offsets into canonical njson by fixpoint.\n// A record's `body` that is a JS array means a nested document; any other value\n// is an atomic body (wrap an array in an object to store it atomically).\nexport const SCHEMA_URL = 'https://kodavr.xyz/njson/schemas/v1.json';\nconst blen = s => Buffer.byteLength(s, 'utf8');\nconst emptyRootNj = () => ({ bo: 0, bl: 0, bhl: 0, no: 0, nl: 0 });\n\nfunction njValue(meta, bo, bl, bhl, no, nl) {\n return { bo, bl, bhl, no, nl,\n description: meta.description || '', tags: meta.tags || [],\n stakes: meta.stakes || 'low', trust_level: meta.trust_level || 'raw' };\n}\nfunction makeRecord(spec) {\n const meta = { description: spec.description || '', tags: spec.tags || [],\n stakes: spec.stakes || 'low', trust_level: spec.trust_level || 'raw' };\n const r = { meta, nj: njValue(meta, 0, 0, 0, 0, 0), atom: undefined, child: undefined,\n njStart: 0, njLen: 0, bodyStart: 0, bodyEnd: 0 };\n if (Array.isArray(spec.body)) r.child = makeDoc(spec.body);\n else r.atom = spec.body;\n return r;\n}\nfunction makeDoc(specs) {\n return { headBefore: [], headAfter: [], rootNj: emptyRootNj(), recs: specs.map(makeRecord) };\n}\n\n// Emit canonical JSON while recording the byte position of every `_nj` value and body.\nfunction emitAll(root) {\n const out = { chunks: [], pos: 0 };\n const put = s => { out.chunks.push(s); out.pos += blen(s); };\n function emitValue(v, depth) {\n const t = typeof v;\n if (v === null) { put('null'); return; }\n if (t === 'boolean') { put(v ? 'true' : 'false'); return; }\n if (t === 'number') { put(JSON.stringify(v)); return; }\n if (t === 'string') { put(JSON.stringify(v)); return; }\n const ind = ' '.repeat(depth), inner = ' '.repeat(depth + 1);\n if (Array.isArray(v)) {\n if (!v.length) { put('[]'); return; }\n put('[\\n');\n v.forEach((x, i) => { if (i) put(',\\n'); put(inner); emitValue(x, depth + 1); });\n put('\\n' + ind + ']');\n return;\n }\n const keys = Object.keys(v);\n if (!keys.length) { put('{}'); return; }\n put('{\\n');\n keys.forEach((k, i) => {\n if (i) put(',\\n');\n put(inner + JSON.stringify(k) + ': ');\n emitValue(v[k], depth + 1);\n });\n put('\\n' + ind + '}');\n }\n function emitDoc(doc, depth) {\n const ind = ' '.repeat(depth), inner = ' '.repeat(depth + 1);\n put('{\\n');\n let first = true;\n const key = k => { if (!first) put(',\\n'); first = false; put(inner + JSON.stringify(k) + ': '); };\n for (const [k, v] of doc.headBefore) { key(k); emitValue(v, depth + 1); }\n key('_nj');\n doc.rootNjStart = out.pos; emitValue(doc.rootNj, depth + 1);\n doc.rootNjLen = out.pos - doc.rootNjStart;\n for (const [k, v] of doc.headAfter) { key(k); emitValue(v, depth + 1); }\n key('records');\n put('[\\n');\n doc.recs.forEach((rec, i) => { if (i) put(',\\n'); put(inner + ' '); emitRecord(rec, depth + 2); });\n put('\\n' + inner + ']');\n put('\\n' + ind + '}');\n }\n function emitRecord(rec, depth) {\n const ind = ' '.repeat(depth), inner = ' '.repeat(depth + 1);\n put('{\\n');\n put(inner + '\"_nj\": ');\n rec.njStart = out.pos; emitValue(rec.nj, depth + 1); rec.njLen = out.pos - rec.njStart;\n put(',\\n' + inner + '\"body\": ');\n rec.bodyStart = out.pos;\n if (rec.child) emitDoc(rec.child, depth + 1);\n else emitValue(rec.atom, depth + 1);\n rec.bodyEnd = out.pos;\n put('\\n' + ind + '}');\n }\n emitDoc(root, 0);\n return out;\n}\n\nfunction updateDoc(doc) {\n doc.recs.forEach((rec, i) => {\n const next = doc.recs[i + 1];\n const no = next ? next.njStart : -1; // -1 = end of level\n const nl = next ? next.njLen : 0;\n if (rec.child) {\n rec.nj = njValue(rec.meta, rec.child.rootNjStart, rec.bodyEnd - rec.child.rootNjStart,\n rec.child.rootNjLen, no, nl);\n } else {\n rec.nj = njValue(rec.meta, rec.bodyStart, rec.bodyEnd - rec.bodyStart, 0, no, nl);\n }\n if (rec.child) updateDoc(rec.child);\n });\n const first = doc.recs[0];\n doc.rootNj = { bo: 0, bl: 0, bhl: 0, no: first ? first.njStart : -1, nl: first ? first.njLen : 0 };\n}\n\n// Offset digits depend on the offsets, so iterate until the text stops changing.\n// Root key order is `$schema`, `description`, `_nj`, then the rest, then `records`.\nexport function linkRoot(records, description = 'root', headAfter = {}) {\n const root = makeDoc(records);\n root.headBefore = [['$schema', SCHEMA_URL], ['description', description]];\n root.headAfter = Object.entries(headAfter);\n let prev = null;\n for (let pass = 0; pass < 80; pass++) {\n const text = emitAll(root).chunks.join('');\n if (text === prev) return text;\n prev = text;\n updateDoc(root);\n }\n return prev;\n}\nThere is no arithmetic anywhere: a batch of headers is \"read exactly nl at no\", a body is \"read exactly bl at bo\", a nested level is \"read exactly bhl at bo\".
// §5.2 — reader: the exact-size moves, with no address arithmetic anywhere.\n// A batch of headers = read exactly `nl` at `no`, then follow the new `no`/`nl`.\n// `navigate` is a *search*: stopping on a revisited offset means it closed a loop\n// and found nothing (search bookkeeping, not a format rule — an executor keeps going).\nexport function readHeaders(buf, firstOffset, firstLen, limit) {\n const headers = [];\n let cur = firstOffset, want = firstLen;\n while (cur !== -1 && headers.length < limit) {\n const nj = JSON.parse(buf.slice(cur, cur + want).toString('utf8'));\n headers.push({ id: String(cur), nj }); // the offset IS the copyable id\n cur = nj.no; want = nj.nl;\n }\n return { headers, nextOffset: cur, nextLen: want };\n}\nexport function readBody(buf, nj) {\n return JSON.parse(buf.slice(nj.bo, nj.bo + nj.bl).toString('utf8')); // exactly `bl` at `bo`\n}\nexport function navigate(buf, match, entry = null) {\n const start = entry === null\n ? readNjAt(buf, buf.indexOf(NJ_START) + NJ_START.length)\n : readNjAt(buf, entry);\n const visited = [];\n let cur = start.nj.no, want = start.nj.nl, readBytes = 0;\n while (cur !== -1) {\n if (visited.includes(cur)) return { hit: null, cycleAt: cur, visited, readBytes };\n visited.push(cur);\n readBytes += want; // exactly `nl` at `no`\n const nj = JSON.parse(buf.slice(cur, cur + want).toString('utf8'));\n if (match(nj)) {\n if (nj.bhl > 0) {\n const inner = navigate(buf, match, nj.bo);\n return { hit: nj, descended: true, inner, visited, readBytes: readBytes + inner.readBytes };\n }\n readBytes += nj.bl; // exactly `bl` at `bo`\n return { hit: nj, body: readBody(buf, nj), visited, readBytes };\n }\n cur = nj.no; want = nj.nl;\n }\n return { hit: null, visited, readBytes };\n}\nThe §3 orchestrator is Pattern B's only implementation; it is built on these reader primitives, so there is no second, divergent copy to maintain.
\nThis is the exact fixture the model ran in §6: program.njson, generated by the §5.1 linker. Its six instruction records are chained by no, the last ending at no = -1 (HALT). The OP:JNZ record carries \"target_offset\": 1891, the absolute offset of the OP:LOOP_ADD header — a backward jump, so iteration is a pointer move, not arithmetic. Executed, it computes acc = 1000; counter = 6; acc += counter; counter--; loop while counter != 0; HALT and outputs 1021. Every offset below is live: each bo/bl/no/nl addresses exactly these bytes.
Code-style convention. A byte offset is a promise about one specific byte sequence, not about the data. Change whitespace, re-sort keys, switch LF↔CRLF, add a BOM, normalize Unicode, escape non-ASCII as \\uXXXX, or round-trip the document through a markdown/HTML viewer — and baked offsets land mid-token. So the format pins a canonical serialization style, valid only for bytes produced under it:
JSON.stringify(value, null, 2) — two-space indent, \": \" after every key, one entry per line, {}/[] for empties, no trailing whitespace;$schema → description → _nj → remaining root fields → records; each record _nj → body; inside _nj the five nav fields (bo, bl, bhl, no, nl) first, then the semantic key (description, tags, stakes, trust_level).Bake offsets as the LAST build step; never hand-edit offsets. Because the canonical form is a fixed point of parse-and-reprint, verification is just sha256(JSON.stringify(JSON.parse(copy), null, 2)) === published: parse a copy, re-serialize with the same rule, hash, compare to the published anchor. If it differs, re-serialize against the style until the hash matches — then the printed offsets are exactly the ones that hold.
Verify this listing.
\ndigest 91adab01-f55528d9-ae249d70-0ca23416-296d8793-2692333e-601370c1-7824ec52\nbytes 3589\nconst fs = require('fs'), crypto = require('crypto');\nconst copy = fs.readFileSync('program.njson', 'utf8');\n// the same digest, grouped into 8-character blocks\nconst want = ['91adab01','f55528d9','ae249d70','0ca23416','296d8793','2692333e','601370c1','7824ec52'].join('');\nconst got = crypto.createHash('sha256')\n .update(JSON.stringify(JSON.parse(copy), null, 2)).digest('hex');\nconsole.log(got === want);\nIf it differs, the copy's formatting drifted — re-serialize against the style rules until the hash matches; a structural edit (reordered key, smart quote, changed number) then fails loudly instead of letting stale offsets mislead.
\n{\n \"$schema\": \"https://kodavr.xyz/njson/schemas/v1.json\",\n \"description\": \"Navigable JSON PROGRAM. `_nj` fields are BYTE offsets from the FILE start. This file is a program, not a document: each record is an INSTRUCTION, its `description` is the opcode, its atomic `body` (read exactly `bl` bytes at `bo`) is the instruction text. PROTOCOL, EXACT READS ONLY: only the first read is unsized (read 256-1024 bytes to get the root `_nj`); after that each read MUST be exactly the size a header gives. NEXT INSTRUCTION: read exactly `nl` bytes at `no` for the next record header. BODY: read exactly `bl` bytes at `bo`. `no = -1` means HALT (end of program). EXECUTE: keep a register state (acc, counter) in your own context, run instructions in order, and when you hit `OP:JNZ` evaluate its `cond`; if true jump by reading a header at the instruction's explicit `target_offset`, else fall through to the record given by this header's `no`. Copy offsets from `_nj`/body text; never compute them.\",\n \"_nj\": {\n \"bo\": 0,\n \"bl\": 0,\n \"bhl\": 0,\n \"no\": 1114,\n \"nl\": 262\n },\n \"records\": [\n {\n \"_nj\": {\n \"bo\": 1392,\n \"bl\": 79,\n \"bhl\": 0,\n \"no\": 1498,\n \"nl\": 266,\n \"description\": \"OP:INIT_ACC\",\n \"tags\": [\n \"opcode\",\n \"init\"\n ],\n \"stakes\": \"low\",\n \"trust_level\": \"raw\"\n },\n \"body\": {\n \"op\": \"INIT_ACC\",\n \"reg\": \"acc\",\n \"value\": 1000\n }\n },\n {\n \"_nj\": {\n \"bo\": 1780,\n \"bl\": 84,\n \"bhl\": 0,\n \"no\": 1891,\n \"nl\": 291,\n \"description\": \"OP:INIT_COUNTER\",\n \"tags\": [\n \"opcode\",\n \"init\"\n ],\n \"stakes\": \"low\",\n \"trust_level\": \"raw\"\n },\n \"body\": {\n \"op\": \"INIT_COUNTER\",\n \"reg\": \"counter\",\n \"value\": 6\n }\n },\n {\n \"_nj\": {\n \"bo\": 2198,\n \"bl\": 77,\n \"bhl\": 0,\n \"no\": 2302,\n \"nl\": 247,\n \"description\": \"OP:LOOP_ADD\",\n \"tags\": [\n \"opcode\",\n \"loop\",\n \"backward-target\"\n ],\n \"stakes\": \"low\",\n \"trust_level\": \"raw\"\n },\n \"body\": {\n \"op\": \"ADD\",\n \"dst\": \"acc\",\n \"src\": \"counter\"\n }\n },\n {\n \"_nj\": {\n \"bo\": 2565,\n \"bl\": 72,\n \"bhl\": 0,\n \"no\": 2664,\n \"nl\": 290,\n \"description\": \"OP:DEC_COUNTER\",\n \"tags\": [\n \"opcode\"\n ],\n \"stakes\": \"low\",\n \"trust_level\": \"raw\"\n },\n \"body\": {\n \"op\": \"DEC\",\n \"reg\": \"counter\",\n \"by\": 1\n }\n },\n {\n \"_nj\": {\n \"bo\": 2970,\n \"bl\": 255,\n \"bhl\": 0,\n \"no\": 3252,\n \"nl\": 254,\n \"description\": \"OP:JNZ\",\n \"tags\": [\n \"opcode\",\n \"branch\",\n \"conditional-jump\"\n ],\n \"stakes\": \"low\",\n \"trust_level\": \"raw\"\n },\n \"body\": {\n \"op\": \"JNZ\",\n \"cond\": \"counter != 0\",\n \"target_offset\": 1891,\n \"note\": \"if cond is true, read the next instruction header at exactly `nl` bytes at absolute byte offset `target_offset`; otherwise fall through to `no`\"\n }\n },\n {\n \"_nj\": {\n \"bo\": 3522,\n \"bl\": 55,\n \"bhl\": 0,\n \"no\": -1,\n \"nl\": 0,\n \"description\": \"OP:HALT\",\n \"tags\": [\n \"opcode\",\n \"halt\"\n ],\n \"stakes\": \"low\",\n \"trust_level\": \"raw\"\n },\n \"body\": {\n \"op\": \"HALT\",\n \"output\": \"acc\"\n }\n }\n ]\n}\nThe concept predicts that a probabilistic CPU will struggle with control flow. To replace guesswork with measurement, I generated real .njson fixtures with the linker above and gave one model a single byte-offset tool.
program.njson (3589 B; the exact listing is in §5.3) is a real program: six instruction records chained by no, ending in no = -1. A JNZ instruction carries an explicit absolute target_offset (1891) to the LOOP_ADD record, so iteration is a backward pointer move with no arithmetic. The program computes acc = 1000; counter = 6; acc += counter; counter--; loop while counter != 0; HALT; the expected output is 1021. cycle.njson (2369 B) and cycle12.njson (4772 B) are chains that end by pointing no back into the chain (5 and 12 distinct records), with no record ending in -1. Those two are search fixtures — a cyclic structure a finder walks once — not programs: under execution semantics a chain with no -1 simply never halts, which would be a bug in the program, not something the reader is asked to detect.deepseek-v4-flash — the only model run. No local model was tested.read_file(path, offset, limit), byte offsets, capped at 1024 B per call. The executor ignored path and served the loaded fixture, so every read is against real bytes.MAX_TURNS 20–24 per run; temperature 0.2 for the Pattern A runs, 0 for Pattern B. Each read was classified against the fixture as root, header-exact, header-partial, body-exact, scan/misaligned, or requested-negative; \"exact\" means the bytes the header itself declares (nl at no, bl at bo).| Run | \nFixture | \nLLM turns | \nexact header reads | \nexact body reads | \nrepeats | \nillegal reads | \nbytes | \nOutcome | \n
|---|---|---|---|---|---|---|---|---|
| A-program | \nprogram.njson (3589 B) | \n11 | \n6/6 | \n6/6 | \n0 | \n0 | \n4280 | \ncorrect OUTPUT: 1021, reached HALT — but every instruction was fetched once and the loop was simulated in context (0 loop back-jumps); 1 unsized read at offset 1024 | \n
| A-cycle N=5 | \ncycle.njson (2369 B) | \n7 | \n5/5 | \nn/a | \n0 | \n0 | \n2253 | \ncorrect: \"5 distinct records\", cycle target 1358 named record-3 (correct) | \n
| A-cycle N=12 (run a) | \ncycle12.njson (4772 B) | \n14 | \n12/12 | \nn/a | \n0 | \n0 | \n3978 | \ncount (12) and cycle offset (2042) correct; target named record-4 (truth: record-5) | \n
| A-cycle N=12 (run b) | \ncycle12.njson (4772 B) | \n14 | \n12/12 | \nn/a | \n0 | \n0 | \n3978 | \nsame: 2042 named record-4 (truth: record-5) | \n
| B-decision | \nindex.njson (12413 B) | \n2 decisions | \nn/a | \n1 body (9155) | \n0 | \n0 | \n689 + 673 tokens | \njson_schema HTTP 200; FETCH_NEXT → READ_BODY(9155), correct record; 0 invalid ids; never emitted HALT — backend halted on end-of-file | \n
One earlier, superseded 5-record pilot answered \"5 distinct\" but named its cycle target 1364 as record-2 (truth: record-3); the mislabel is stochastic, not deterministic.
\nreasoning_content)Comfort — the offset scheme was unambiguous
\n\"The root _nj says no: 1114, nl: 262. So the first record header is at offset 1114, length 262 bytes. Let me read that.\"\"The last no pointer (from record-5, at offset 2042) is 1358, which leads back to record-3's header — so the chain loops into a cycle\"\"Header 9155 explicitly describes the requirements-management dump with stable IDs, coverage checks, and TDD registry, matching the query.\"Struggle — deriving identity, and the root boundary
\n\"Wait, target_offset is 1891 which is the INIT_COUNTER record header... Hmm, but that would be an infinite loop.\" … \"Yes! Offset 1891 is the LOOP_ADD header. I confused myself.\"\"Record-12's no pointer leads to offset 2042, which is record-4's header (already visited)\" — the header at 2042 literally reads \"description\":\"record-5\", and the same answer body had just listed record-5 (2042)._nj did not fit the first 1024-byte window, so the model issued a second, unsized 1024-byte read at offset 1024 — the one exact-read violation in any run.Comfort. Exact-size discipline was near-perfect: 6/6, 5/5, 12/12 and 12/12 exact header reads and 6/6 exact body reads, zero repeated reads, zero requests for offset -1, and zero out-of-range reads across every run. no = -1 halted Pattern A correctly; on the two search fixtures (which have no -1) the model stopped after one pass and reported the loop it found instead of spinning — a search result, not a format rule. Pattern B was clean at the decision level: the schema format was accepted, every decision parsed, no invalid ids, and the right record was chosen. The specific failures the concept predicts at large scale — lost loop state, losing track of a visited record, reading -1, hallucinated progress — did not reproduce at 12 records.
Struggle. Four weak spots showed up, three of them real model failures and the last a design confirmation:
\nheader_visits all 1, loop_back_jumps: 0) and executed the JNZ loop inside its own reasoning — \"These are independent reads, so I can do them together.\" So Pattern A \"worked\" by using context as RAM, which is precisely the scaling hazard the concept predicts. That is consistent with the thesis, but it is not evidence of true cyclic byte execution._nj's length is not declared anywhere, the model had to guess a window; when 1024 bytes were not enough, it issued an unsized second read. The rest of the protocol is exact; the very first move is not.no field equals the offset, not the record whose _nj starts there. Crucially, the target header already carried the label record-5; adding an id would not have helped, because the label was present and was still misread. Identity needs to be machine-checkable/copyable rather than recounted.FETCH_NEXT/READ_BODY but never HALT; termination came from the backend reaching end-of-file. \"Guaranteed termination\" therefore rests on the backend, which is where the design puts it — confirmed, not contradicted.Each item is grounded in an observed failure, not a guess:
\nno is a loop, not an end, so the exit is the program's own branch to no = -1. The format should not guess — but the linker/validator can do what a compiler does and warn when a program can never reach HALT. That is developer tooling for a buggy program, not a reader rule.hlen (this header's own length) so a reader never has to guess the root window; the extra unsized read at offset 1024 disappears, and \"did I read exactly the right size?\" no longer requires cross-referencing the previous header's nl._nj.kind: \"op\" | \"record\", and an op in the body) and keep description human-only. Today the opcode lives in description, which conflates the index key with the program counter.target_label/id next to target_offset for conditional jumps; the self-correction quote above shows the model re-deriving which record an offset belongs to — a copyable label removes that step.count/end (or a per-batch terminal marker) so the engine can emit and accept HALT on data, rather than treating an exhausted batch as the stop condition.The live run above was too small to measure context pressure, so this section is an architecture-based hypothesis, not experimental data. The only real token numbers from the run are Pattern B's two decisions: 689 + 673 tokens on a 12 KB index, with the target chosen after a single FETCH_NEXT.
The structural argument is qualitative:
\n| Metric | \nPattern A (Pure Turing) | \nPattern B (Hybrid + SGR) | \n
|---|---|---|
LLM calls to read | \none per header visited, and (observed) one per body even when not needed | \none per batch of headers, plus selected bodies only | \n
| Context growth | \nevery header and body stays in context | \nonly the current batch stays in context | \n
| Backend state management | \nnone (the model manages everything) | \nfull (offsets, visited set, limits) | \n
| Audit trail | \npartial (LLM context) | \nfull (backend logs + SGR reasoning) | \n
Hypothesis at larger scale (explicitly speculative): Pattern A would keep the whole traversal in context and, per the flattening behaviour observed above, could run out of budget on large documents; Pattern B would process fixed-size batches independently and be bounded by batch count. Neither the 50-record nor the 500-record case was tested.
\n.njson as a VM, and it produced a correct result on the small program — but by flattening, so true byte-level iteration remains unvalidated.deepseek-v4-flash). No local model (Llama/Qwen via Ollama) and no other cloud model was run, so any cross-model or local-model claim is hypothesis. The observed identity mislabel is stochastic, measured on two preserved 12-record runs and one 5-record run.HALT showed..njson bodies with hierarchical SGR schemas. The backend orchestrates the outer loop; the LLM decides when to descend.hlen, a dedicated kind, jump labels, and count/end for Pattern B — and re-measure identity labelling at larger scale.no = -1?\" to the linker/validator — a compile-time warning, not a reader rule. A search reader keeps its own seen-set; a program that never halts is a bug to fix, not a format feature.A follow-up to the Navigable JSON (.njson) format. The earlier case showed an\nagent can jump over the record bodies it does not need. This one asks a\nsharper question: if a file can be navigated, can it also be executed — is\nthe same file a program, not just data?
The answer proposed here is yes, and the mapping is not invented: any structured\ncontrol flow reduces to the Böhm-Jacopini trio — sequence, selection,\niteration. .njson already has a sibling jump (no/nl) and a descent\n(bo/bl), so all three are expressible with the primitives that already exist.\nThe agent's own context is the RAM: the loop counter, the accumulator, the\ncurrent offset all live in what the model is holding.
no, evaluates\nsemantic keys, and decides where to jump next. Maximum flexibility, but every\ncontrol-flow step costs tokens and reasoning.Both patterns ship as runnable JavaScript (lifted from the article by a\nsnippet extractor), together with a canonical linker/reader and a small\nlive-offset demo program.
\n-1, and zero out-of-range reads; the schema-guided\ndecision loop was accepted and parsed cleanly.