# Accepted specification and implemented boundary

Goal: help a person turn supported language into a visible, editable plan under local
control, while testing a discrete learned routing mechanism independently.

Source: ChatGPT conversation `6abf8abe-99e8-83ea-ae4c-f1cc9e9f32e4`, “Enigma And LLMs”,
read on 2026-10-02, and the user's decisions in the implementation chat.
The accessible source contains proposals, not an independently reproduced research report.

The user chose research first, then a grammar-based bounded-English workbench; open
components; local runtime/data; cloud coding agents only for approved code/synthetic
examples; mechanism verification without a required speed win; short local runs.

| ID | Requirement and source | Observable acceptance | Boundary |
|---|---|---|---|
| R1 | Preserve ordered transformations (conversation) | AB differs from BA; exact oracle agreement and reset behavior | routing interpreter |
| R2 | Learn settings and retain behavior after export (conversation) | Five seeds; all 12 token/state transitions plus sequence fixtures pass | trainer/export/evaluator |
| R3 | Falsifiable indexed evidence (conversation/current decisions) | Incorrect artifacts fail; timeouts stay incomplete; receipts retain config, source and hashes | supervised runner |
| R4 | Verify representation identities (conversation) | Cycles 2–16 and complex projectors agree within 1e-10; coprimality distinguished | math checks |
| R5 | Human-readable, editable request plans (current decisions) | Conditions, order, prohibitions and unresolved text retained with source spans | grammar/workbench |
| R6 | User controls personal data and corrections (current decisions) | Offline operation; explicit local export; correction roundtrip; no action execution | browser/server/plan document |

## Fixed first-release choices

Python 3.12; PyTorch CPU and NumPy interoperability for training only; standard-library discrete runner, math checks,
grammar, and HTTP server; plain local HTML/CSS/JavaScript. `psutil` supervises memory.
Using standard-library complex arithmetic instead of NumPy keeps exact execution and
finite math verification independent of numerical-library installation.

The artifact directory defaults to `G:\RenigmaLLM_Artifacts`. It must already exist;
the setup script creates it only on an available drive. Source remains in this repository.
No old environment, checkpoint, dataset, or archive is imported.

Each run is CPU-only, at most 30 minutes. Each batch invocation is at most two hours,
with an aggregate parent/child RAM ceiling of 12 GiB, 10 GiB batch output budget and
5 GiB drive reserve. GPU/NPU inventory does not establish execution support. The
planned 8 GiB GPU ceiling becomes applicable only to a future preregistered GPU backend.

The workbench interprets and previews; it does not access referenced documents or
send, delete, approve, or otherwise execute an action. See `grammar.md` for exact forms.
Reinterpreting input starts a new proposal; importing an exported document preserves
its original proposal and separate user corrections. No browser autosave or server
request persistence is used.

Interfaces: versioned gate-table JSON; versioned experiment receipts; versioned
PlanDocument JSON. Malformed imports and unsupported schema versions are rejected.
No migrations are needed for this first version. Source spans use Unicode codepoints.

## Future research gates

Prime periods, coprime counters and prime-log phases are different mechanisms. Future
performance studies must preregister each treatment and matched controls separately.
The Riemann hypothesis is not an operational premise. Synthetic routing success is
not language-understanding evidence. A learned interpreter needs new grammar/task
holdouts and human evaluation before replacing the current baseline.

The initial deliverable is a local reproducible release package. Remote publication,
new cloud compute, model downloads and action-execution capabilities are outside it.

## Accepted next leg: memory, GPU execution and inspectable language

On 2026-10-02 the user selected memory and binding as the next capability and staged
comparisons: selectors first, topology as a diagnostic, graph diffusion separately.
The user then authorized continuing the plan. The prior CPU-only requirements describe
ROUTE-001; they do not prevent the explicitly requested CUDA experiments below.

The practical interpretation of "value genesis" is that a supported statement creates
an explicit binding, another statement may update it, and a later answer exposes the
actual stored value and the statement responsible for it. This is an implementation
interpretation, not a claim that numerical geometry itself establishes human meaning.

| ID | Requirement/source | Observable acceptance | Boundary |
|---|---|---|---|
| R7 | Actual local GPU use (user) | Synchronized forward/backward kernels, CPU comparison, device and memory receipts; requested CUDA never silently falls back | GPU-001, isolated CUDA environment |
| R8 | Learn memory and binding (user selection) | Retain, overwrite, read missing keys and reset; hard export independently agrees with dictionary semantics | MEM-001, fixed key/value vocabulary |
| R9 | Compare selective routing (user) | Softmax, sparsemax and 1.5-entmax receive the same initialization/data/loss/budget; all attempts retained | MEM-001 |
| R10 | Tensorized, measured execution (user) | Batched slots/channels, synchronized timings; dense hard and indexed execution use identical maps | EXEC-001 |
| R11 | Topology then PDE-inspired operators (user selection) | Frozen-state persistence measurements; separate graph heat intervention with identity and permutation controls | TOPO-001, DIFF-001 |
| R12 | Useful, locally controlled meaning (original intent) | Supported memory sentences produce traceable answers, visible updates, unknowns and explicit exports; no background saving or external actions | LANG-001 |

Memory is a tensor with independent batch, slot, and value-channel axes. A cell's
vector space may be described as a fiber; a GPU kernel implements its update. These
are mathematical/software choices, not biological equivalences. A graph over slots
does not make nearby slots semantically related. Diffusion defaults to zero.

The first learned controller is a key-to-slot table shared by reads and writes. It
does not learn a language encoder, output head, or a controller for previously unseen
keys. The larger workload has 32 keys, 32 slots, 64 values and an UNKNOWN channel;
the state shape is batch x 32 x 65. All 32 bindings are exercised. The small calibration
has 8 keys, 8 slots and 16 values plus UNKNOWN. See MEMORY_PROTOCOL.md for the frozen
training/evaluation contract. No address labels are supplied as training targets.

CUDA setup and artifacts stay on the external artifact drive. Preserve the CPU
environment and v1 artifacts. Retain the inherited 30-minute run, two-hour batch,
12 GiB aggregate host RAM, 10 GiB batch disk and 5 GiB drive reserve. CUDA uses an
8 GiB monitored allocation target with device headroom; the PyTorch allocator cap
is not an OS-enforced total-process VRAM isolation guarantee on Windows WDDM.

Topology is an optional CPU diagnostic with bounded samples. A successful persistence
calculation cannot certify language meaning or sequence order. Prime/phase treatments
remain future, separately registered comparisons; no RH assumption enters execution.

The memory workbench must distinguish an explicitly labelled dictionary reference
from a locally configured learned artifact. A reference result is never evidence
that training succeeded. Existing plan-document and routing formats remain readable.

## Continued leg: reviewable expressions and ordered tensor scan

The user's continuation authorizes a bounded LANG-002 and EXEC-002 slice. The
human-facing value is an explicit, inspectable interpretation that the user can
correct before adopting; the execution question is whether the same ordered
memory recurrence benefits from a parallel scan. Neither changes the memory
training hypothesis or the previously sealed results.

| ID | Requirement | Observable acceptance |
|---|---|---|
| R13 | Broader explicit memory instructions | Ten documented finite phrase forms map to the four existing operations; frozen synthetic gold events, spans, answers, provenance and final state match exactly |
| R14 | Preserve historical interpretation | Version-1 imports replay with the original grammar and export unchanged, including previously unsupported text; version-2 histories tag each source with its language version |
| R15 | Review before adoption | Preview from empty memory is separate from the accepted record; source edits invalidate it; adoption replays and checks the full preview digest; failed preview/import/adoption preserves the accepted record |
| R16 | Ambiguity remains visible | Whole-clause matching; documented unquoted referent tokens are unresolved; quoted tokens are literal labels; unsupported clauses never allocate IDs, write or reset |
| R17 | Compare ordered affine scan fairly | Registered forward/loss/gradient/order/reset checks pass before six-arm timing on the original EXEC-001 input bytes; raw samples, synchronization, memory peaks and all failures are retained |

LANG-002 adds `Remember KEY is VALUE`, `Set KEY to VALUE`, `Store VALUE under KEY`,
`Update KEY to VALUE`, `Recall KEY`, and `Clear memory` to the four LANG-001 forms.
It does not fit an encoder or claim unseen-phrase generalization. Source revisions
record history, not a hidden cumulative state: each current source is replayed
from empty memory. Review is a local product action, with no external effects.

EXEC-002 uses public PyTorch tensor operations and the existing selected learned
map, with no further training. Its real-arithmetic composition is associative but
order-sensitive; floating-point parity must be observed at the frozen tolerances.
The separate protocol fixes inputs, controls, budgets and rejection rules before
measurement. A slower correct scan remains a completed experiment. Historical
archives and receipts retain their original source hashes.

## Operation-preserving representation study

The user's commuting-diagram proposal authorizes REP-001, a finite-world
representation comparison before any learned language integration. The
implementation and preregistered acceptance examples are specified in
`REPRESENTATION_PROTOCOL.md`. Adequacy requires both preservation of named
operations and recovery of the specified observations. A collapsed latent
diagram alone is insufficient.

| ID | Requirement | Observable acceptance |
|---|---|---|
| R18 | Exact operational sufficiency controls | Exhaustive 98-state transitions, optimal quotient residuals, explicit lost-context witnesses and repair; constant-code negative control |
| R19 | Compare representation objectives | Three paired architectures/objectives, three widths, five seeds, fixed training-only edges and unseen compositions; all outcomes retained |
| R20 | Account for representation cost and failure | Decoded accuracy plus latent error, fixed quantization, collision/collapse metrics, context versus fitting distinction |
| R21 | Reproducible local execution | Supervised CUDA with CPU parity, fixed source/design/protocol, portable checkpoints and independently verified evidence inventory |

Mathematical covariance and boundary-term examples are controls, not evidence
that the ML hypothesis is true. No universal topology/geometry/dynamics
hierarchy is assumed. The unchanged workbench remains a finite grammar
interpreter; REP-001 does not silently replace it with a learned encoder.

## Supplied-coordinate diagnostic

REP-002 follows the REP-001 outcome with a fixed Fourier encoder and a learned
decoder/head comparison, specified in `REPRESENTATION_FIXED_PROTOCOL.md`. It
reuses the old split as a post-outcome diagnostic, not independent confirmation.

| ID | Requirement | Observable acceptance |
|---|---|---|
| R22 | Separate supplied coordinates from oracle decoding | Five learned/fixed seed pairs share exact initial decoder/head tensors; both learn decoding from training states; all final outcomes retained |
| R23 | Inspect operational and numerical failure | Hashed FP32 latent/logit arrays, distance and margin diagnostics, independent NumPy replay with categorical disagreements retained |

## Frozen operation-head intervention

REP-003 tests the H association from REP-002 using the four-arm comparison in
`HEAD_INTERVENTION_PROTOCOL.md`, with no optimizer updates or new fitted models.

| ID | Requirement | Observable acceptance |
|---|---|---|
| R24 | Localize the effect of H versus other heads | Five frozen Fourier models each run native, H-only refit, other-heads-only refit and all-refit; report paired gains/regressions and all outcomes |
| R25 | Make intervention evidence inspectable | Exact tensor masks, preserved parent inputs, native/all-refit reproduction, unchanged H-free outputs under H-only replacement, hashed arrays and independent replay |

## H-only objective recovery

REP-004 follows the proposed comparison in REP-003's findings, frozen in
`HEAD_FITTING_PROTOCOL.md`. It compares recovery under two fitting rules on the
same existing world; it does not establish the cause of the original optimizer
failure or new-world generalization.

| ID | Requirement | Observable acceptance |
|---|---|---|
| R26 | Compare fixed-budget H fitting rules | Five seeds, native/refit references, prediction-plus-latent and latent-only arms with identical starting H and fresh Adam states; all outcomes and paired regressions retained |
| R27 | Make optimization and operational effects inspectable | Training-edge-only losses/gradients, actual update/optimizer records, frozen tensors, CPU/CUDA parity, unchanged H-free outputs and independent NumPy final-model replay |