noulxp 0.4.0__tar.gz

noulxp-0.4.0/.gitignore

@@ -0,0 +1,14 @@
+__pycache__/
+*.pyc
+.pytest_cache/
+.ruff_cache/
+*.egg-info/
+build/
+dist/
+.venv/
+# Packages are large: they live outside the repository.
+/packages/
+*.onnx
+*.onnx.data
+*.gguf
+*.safetensors

noulxp-0.4.0/CHANGELOG.md

@@ -0,0 +1,165 @@
+# Changelog
+
+## 0.4.0 (2026-09-30)
+
+- **OpenDXP is now NoulXP.** Another open-source project already used the name
+  OpenDXP, so the standard, the package, the command and the badge take a name
+  of their own: `pip install noulxp`, `noulxp serve`, `noulxp check`, the
+  manifest `noulxp.json`, the versions `noulxp/0.1` and `noulxp/0.2`, and the
+  badge "NoulXP compatible". The format, the answers and the protocol are those
+  of 0.3.1.
+- Packages made before the rename run as they did: a runtime reads `odxp.json`
+  when a package has no `noulxp.json`, and `odxp/0.1` and `odxp/0.2` as the same
+  versions under the old name. Converters write only the new names.
+- The HTTP binding's header is `NoulXP-Version` (was `OpenDXP-Version`) and the
+  MCP server calls itself `noulxp`. `NOULXP_TOKEN` replaces `OPENDXP_TOKEN`,
+  which is still read.
+- `opendxp` on PyPI is now a redirect: `pip install opendxp` installs `noulxp`,
+  `import opendxp` (and every `opendxp.*` module) is `noulxp`, and the `opendxp`
+  command runs `noulxp`, each with a note to switch.
+
+## 0.3.1 (2026-09-30)
+
+- **Fixed: `opendxp serve` answered no faster than ~40 ms a request on Linux.**
+  An answer's headers and body left in two writes with Nagle's algorithm on, so
+  on a kept-alive connection the body waited for the client's delayed ACK of
+  the headers. Answers now leave in one write, with `TCP_NODELAY`. Julia 1 on an
+  NVIDIA A40, one client: 27.6 decisions/s (p50 62 ms) before, 161.6 (p50
+  7.5 ms) after. macOS was not affected.
+- **`opendxp serve` reads the requests that wait together** (`--batch N`,
+  default 32; 1 answers one at a time as before). A request that finds its
+  model idle is read at once, in its own thread, as `predict` reads it; requests
+  that arrive while the model reads queue, and one thread reads them together
+  (`predict_many`). On an A40 at 64 clients, Julia 1 answered 262 decisions/s
+  (78 one at a time; 300 with fused attention), Laya multilingual 191 (87);
+  one client, 178 (p50 6 ms). `--batch-rows` decodes a causal-letters
+  package's rows together (AnyJev at one client: p50 119 to 66 ms).
+- The server's listen backlog is 128; it was socketserver's 5, past which a
+  burst of new clients was reset.
+- `opendxp bench`'s HTTP client turns Nagle's algorithm off, as curl, requests
+  and browsers do: http.client sends a request's headers and body apart.
+- Requests are validated with one compiled validator per schema, not a new one
+  per request.
+- **`opendxp export --opset 23`** (laya, julia): attention as ONNX's fused
+  `Attention` operator instead of a chain of small ones, with the mask expanded
+  to the shape onnxruntime's kernels take. On an A40 through onnxruntime 1.30,
+  6 to 14% more decisions per second one request at a time (Julia 1: 199 to
+  210); on an x86 server CPU 1.6 to 2.0 times; on an Apple M4 CPU, Julia 1 from
+  26.1 to 30.9. onnxruntime runs the operator on CUDA from 1.30: the runtime
+  refuses such a package on CUDA with an older onnxruntime rather than let
+  attention fall back to the CPU. encoder-markers reads the opset from the
+  manifest's weights entry.
+
+## 0.3.0 (2026-09-30)
+
+- **`opendxp calibrate`** (SPEC.md 7.1): fits a package's temperatures, one per
+  question type, to labelled requests (an option's key, a distribution, or an
+  answer object per question) and writes a calibration.json, with accuracy, KL,
+  Brier and ECE before and after, on the labels and on `--test`. The model is
+  read once; each temperature is the least mean KL(label || answer), from a
+  log-spaced grid refined by golden-section search. On the typed-decisions test
+  split, 50 held-out requests labelled with one option each brought Julia 1's
+  mean confidence from 0.96 to 0.72, its accuracy (ECE 0.236 to 0.044), and the
+  benchmark's distributions took its KL from the gold from 2.78 to 0.23, with
+  the same decisions. `--hard-labels` fits to each label's leading option, to
+  how often the model is right, when the labels are distributions.
+- **`--calibration FILE`** on `run`, `serve`, `mcp` and `bench`, and
+  `load(..., calibration=...)`: answer with another calibration.json than the
+  package's. The package's conformance file is still replayed at its own
+  (`conformance.replay` included), discovery names the file by its sha256, and
+  reports say `"calibration": "package"` otherwise.
+- Runtimes have `readouts(items)` (each request read once, answered at any
+  calibration) and `distributions(..., calibration)`.
+- Fixed: the cache of content-free priors was keyed without the temperature, so
+  a runtime answering at two calibrations reused a prior read at the other.
+
+- **`opendxp bench`**: how fast a package (the reference runtime, in this
+  process) or any OpenDXP server (over the HTTP binding, at several concurrency
+  levels) answers: requests and decisions per second, latency percentiles,
+  errors by status and, with `--usd-per-hour`, the cost per 1,000 decisions.
+  Its clients back off on 429 and 503 as real ones do. Standard library only.
+- **Rows read together** (causal-letters): `batch_rows` decodes up to that many
+  rows (a request's questions and rotations) in one llama.cpp call, each its
+  own sequence from empty memory; `batch_cache` shares one cache among them or
+  gives each its own (`per-row`). It is a serving choice, not part of a package:
+  `opendxp check --batch-rows N` says whether it keeps a package compatible on
+  a given machine. `predict_many` answers several requests' rows together.
+- A request's rows are planned before any is read (typed layouts included),
+  then combined; the cache of content-free priors is never filled from a
+  planning pass.
+- **Requests read together** (encoder-markers): `predict_many` runs several
+  requests' questions through the graph in passes of rows of similar length
+  (within 1.25 times the shortest, plus 16 tokens; at most 32 rows). Padding is
+  masked, so each answer is the one `predict` gives. On an NVIDIA A40, Julia 1's
+  89 conformance rows take 243 ms together against 625 ms one at a time; a pass
+  filled up to a token budget instead padded short rows to a long one's length
+  and was slower than no batching. Static-shape providers (Core ML) answer one
+  at a time as before.
+- The ONNX exporter names the graph's dimensions (`batch`, `tokens`, `options`)
+  instead of declaring `torch.export.Dim` ranges, which torch 2.8 refused for
+  models that treat a dimension of 1 specially.
+- **No silent fallbacks.** An onnxruntime provider asked for by name that does
+  not load (a CUDA 13 build on CUDA 12, say) is an error instead of a run on the
+  CPU, and reports list the providers that loaded. A causal-letters run on the
+  CPU stays there: a GPU build of llama.cpp no longer offloads its matrix
+  products (`op_offload`).
+- The encoder converters refuse transformers older than 5.2: 4.57 computes
+  ModernBERT differently, and its packages exported without an error, agreed
+  with the model they were traced from, and failed their conformance files.
+- **Precision** (SPEC.md 8.1): `precision="exact"` (`--precision exact` on
+  check, bench, serve and mcp) asks a GPU for float32 products: ONNX Runtime's
+  CUDA provider without TF32, llama.cpp's CUDA and HIP backends accumulating
+  F16 and BF16 products in float32. On an NVIDIA A40 every encoder package then
+  gives the CPU's numbers (5e-5 instead of up to 0.0067), and AnyJev from its
+  BF16 weights passes its conformance file (0.0082 instead of 0.049),
+  costing 1 to 50 % of the speed. Reports name the precision they ran at.
+- `conformance.replay` runs a package's conformance file through a runtime that
+  is already loaded, so an engine can check a package as it serves it.
+- `opendxp bench` clients keep their connection open between requests, as SDKs
+  do.
+- `scripts/prefix_sharing.py` works for every layout: it keeps the last row in
+  the cache and decodes only the tokens a row adds.
+
+## 0.2.0
+
+OpenDXP 0.2: a wire protocol, and models asked in rotation. Every 0.1 package
+still runs, and converters keep writing `odxp/0.1` unless a package needs 0.2.
+
+- **HTTP binding** (SPEC.md 11): `POST /v1/systemone`, `GET /v1/models` with
+  each model's conformance summary, `GET /healthz`, an error schema, bearer
+  tokens and CORS by named origin. `opendxp serve` implements it with the
+  standard library and refuses to listen beyond the machine without a token.
+- **MCP binding** (SPEC.md 12): `opendxp mcp` gives every package to AI agents
+  as a tool over stdio, with the request and response schemas as its input and
+  output schemas. It speaks the current MCP revision (per-request metadata,
+  `server/discover`) and the `initialize` handshake of earlier clients.
+- **Typed layouts** (SPEC.md 6.7): a causal-letters prompt can lay out each
+  question type on its own (labels by position or attached to their options,
+  a listing, a legend for descriptions), inside the model's chat template, each
+  row encoded whole. States can be rendered as indented JSON or as a
+  conversation, with a text for an empty state (3.2).
+- **Rotations** (SPEC.md 6.8): a question asked once per cyclic shift of its
+  options, the shifts combined by log-mean or mean, with an optional
+  content-free prior divided out first.
+- `opendxp export anyjev` and `--runtime anyjev`: AnyJev (Nokia) at L0, any
+  instruction-tuned model asked the way anyjev 0.2.0 asks it, checked against
+  anyjev's own Decider. Validated on Qwen3-1.7B (VALIDATION.md).
+- Packages declare `odxp/0.1` or `odxp/0.2`; this implementation runs both,
+  and `opendxp validate` checks that a package's files declare its manifest's
+  version.
+
+## 0.1.0
+
+The first release of OpenDXP, the Open Decision Exchange Protocol, and its
+reference implementation.
+
+- The standard, `odxp/0.1`: packages (`odxp.json` and the files it names by
+  SHA-256), the `encoder-markers` and `causal-letters` profiles, calibration,
+  conformance files and compatibility levels, with JSON Schemas for every file.
+- Reference runtimes on ONNX Runtime and llama.cpp (CPU and GPU builds).
+  `--device auto` uses CUDA when available and the CPU otherwise; Core ML,
+  OpenVINO, QNN and DirectML are used when named.
+- `opendxp export` for Laya, Julia 1 and Decider; `opendxp conformance
+  generate` from the models' own code; `opendxp check`, `validate`, `run` and
+  `info`.
+- The OpenDXP 0.1 request set: 52 requests, 91 questions, 11 languages.

noulxp-0.4.0/CONTRIBUTING.md

@@ -0,0 +1,50 @@
+# Contributing to NoulXP
+
+NoulXP is a standard first and code second. A change to what a package means
+is a change to SPEC.md, the schemas and the reference runtime together.
+
+## What is most useful
+
+- **A model the profiles cannot describe.** Open an issue with the model, the
+  exact input construction of its own code, and what `template.json` or
+  `prompt.json` would need. This is how the standard grows.
+- **A converter** for another model family (Von, open-jev, Kev, Nimble, ...):
+  `src/noulxp/export/<family>.py`, a native adapter in `src/noulxp/native/`
+  that runs the model's own code, and the validation results.
+- **Another engine.** The standard is language-neutral. An engine in Rust,
+  Go or JavaScript that passes the conformance files of the published
+  packages is the strongest test of the spec; report where SPEC.md was
+  ambiguous.
+- **Backend results**: `noulxp check --device <backend>` on hardware we do not
+  have (CUDA, OpenVINO, QNN, DirectML, ROCm), with the report JSON.
+
+## Rules for changes
+
+1. **Normative changes** (anything in SPEC.md that uses MUST, SHOULD or MAY,
+   the schemas, `src/noulxp/spec.py`) need an issue first, and bump the
+   standard's version when they change what an existing package means.
+2. **Conformance files are generated by the model's own code**, never by the
+   reference runtime, and record which code and versions produced them. A
+   converter that needed model-specific logic in the runtime to pass has not
+   passed: move that logic into the declarative files or propose a spec change.
+3. **No invented numbers.** VALIDATION.md and the paper report only what a
+   report file in the repository or the packages supports.
+4. **Nothing in a package executes.** No templates with logic, no pickles, no
+   `trust_remote_code`.
+
+## Development
+
+```bash
+python -m venv .venv && . .venv/bin/activate
+pip install -e ".[dev,onnx]"
+pytest                      # no downloads; a tokenizer is built in memory
+ruff check src tests scripts && ruff format --check src tests scripts
+```
+
+The request set lives in `scripts/build_requests.py`; run it to regenerate
+`src/noulxp/data/requests-0.1.jsonl`. Changing it changes the standard's
+conformance set: packages then need their conformance files regenerated.
+
+Commits: one logical change each, with a message that says what changed and
+why. Sign-off is not required. By contributing you agree that your
+contribution is licensed under Apache-2.0.

noulxp-0.4.0/LICENSE

@@ -0,0 +1,176 @@
+                                 Apache License
+                           Version 2.0, January 2004
+                        http://www.apache.org/licenses/
+
+   TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
+
+   1. Definitions.
+
+      "License" shall mean the terms and conditions for use, reproduction,
+      and distribution as defined by Sections 1 through 9 of this document.
+
+      "Licensor" shall mean the copyright owner or entity authorized by
+      the copyright owner that is granting the License.
+
+      "Legal Entity" shall mean the union of the acting entity and all
+      other entities that control, are controlled by, or are under common
+      control with that entity. For the purposes of this definition,
+      "control" means (i) the power, direct or indirect, to cause the
+      direction or management of such entity, whether by contract or
+      otherwise, or (ii) ownership of fifty percent (50%) or more of the
+      outstanding shares, or (iii) beneficial ownership of such entity.
+
+      "You" (or "Your") shall mean an individual or Legal Entity
+      exercising permissions granted by this License.
+
+      "Source" form shall mean the preferred form for making modifications,
+      including but not limited to software source code, documentation
+      source, and configuration files.
+
+      "Object" form shall mean any form resulting from mechanical
+      transformation or translation of a Source form, including but
+      not limited to compiled object code, generated documentation,
+      and conversions to other media types.
+
+      "Work" shall mean the work of authorship, whether in Source or
+      Object form, made available under the License, as indicated by a
+      copyright notice that is included in or attached to the work
+      (an example is provided in the Appendix below).
+
+      "Derivative Works" shall mean any work, whether in Source or Object
+      form, that is based on (or derived from) the Work and for which the
+      editorial revisions, annotations, elaborations, or other modifications
+      represent, as a whole, an original work of authorship. For the purposes
+      of this License, Derivative Works shall not include works that remain
+      separable from, or merely link (or bind by name) to the interfaces of,
+      the Work and Derivative Works thereof.
+
+      "Contribution" shall mean any work of authorship, including
+      the original version of the Work and any modifications or additions
+      to that Work or Derivative Works thereof, that is intentionally
+      submitted to Licensor for inclusion in the Work by the copyright owner
+      or by an individual or Legal Entity authorized to submit on behalf of
+      the copyright owner. For the purposes of this definition, "submitted"
+      means any form of electronic, verbal, or written communication sent
+      to the Licensor or its representatives, including but not limited to
+      communication on electronic mailing lists, source code control systems,
+      and issue tracking systems that are managed by, or on behalf of, the
+      Licensor for the purpose of discussing and improving the Work, but
+      excluding communication that is conspicuously marked or otherwise
+      designated in writing by the copyright owner as "Not a Contribution."
+
+      "Contributor" shall mean Licensor and any individual or Legal Entity
+      on behalf of whom a Contribution has been received by Licensor and
+      subsequently incorporated within the Work.
+
+   2. Grant of Copyright License. Subject to the terms and conditions of
+      this License, each Contributor hereby grants to You a perpetual,
+      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+      copyright license to reproduce, prepare Derivative Works of,
+      publicly display, publicly perform, sublicense, and distribute the
+      Work and such Derivative Works in Source or Object form.
+
+   3. Grant of Patent License. Subject to the terms and conditions of
+      this License, each Contributor hereby grants to You a perpetual,
+      worldwide, non-exclusive, no-charge, royalty-free, irrevocable
+      (except as stated in this section) patent license to make, have made,
+      use, offer to sell, sell, import, and otherwise transfer the Work,
+      where such license applies only to those patent claims licensable
+      by such Contributor that are necessarily infringed by their
+      Contribution(s) alone or by combination of their Contribution(s)
+      with the Work to which such Contribution(s) was submitted. If You
+      institute patent litigation against any entity (including a
+      cross-claim or counterclaim in a lawsuit) alleging that the Work
+      or a Contribution incorporated within the Work constitutes direct
+      or contributory patent infringement, then any patent licenses
+      granted to You under this License for that Work shall terminate
+      as of the date such litigation is filed.
+
+   4. Redistribution. You may reproduce and distribute copies of the
+      Work or Derivative Works thereof in any medium, with or without
+      modifications, and in Source or Object form, provided that You
+      meet the following conditions:
+
+      (a) You must give any other recipients of the Work or
+          Derivative Works a copy of this License; and
+
+      (b) You must cause any modified files to carry prominent notices
+          stating that You changed the files; and
+
+      (c) You must retain, in the Source form of any Derivative Works
+          that You distribute, all copyright, patent, trademark, and
+          attribution notices from the Source form of the Work,
+          excluding those notices that do not pertain to any part of
+          the Derivative Works; and
+
+      (d) If the Work includes a "NOTICE" text file as part of its
+          distribution, then any Derivative Works that You distribute must
+          include a readable copy of the attribution notices contained
+          within such NOTICE file, excluding those notices that do not
+          pertain to any part of the Derivative Works, in at least one
+          of the following places: within a NOTICE text file distributed
+          as part of the Derivative Works; within the Source form or
+          documentation, if provided along with the Derivative Works; or,
+          within a display generated by the Derivative Works, if and
+          wherever such third-party notices normally appear. The contents
+          of the NOTICE file are for informational purposes only and
+          do not modify the License. You may add Your own attribution
+          notices within Derivative Works that You distribute, alongside
+          or as an addendum to the NOTICE text from the Work, provided
+          that such additional attribution notices cannot be construed
+          as modifying the License.
+
+      You may add Your own copyright statement to Your modifications and
+      may provide additional or different license terms and conditions
+      for use, reproduction, or distribution of Your modifications, or
+      for any such Derivative Works as a whole, provided Your use,
+      reproduction, and distribution of the Work otherwise complies with
+      the conditions stated in this License.
+
+   5. Submission of Contributions. Unless You explicitly state otherwise,
+      any Contribution intentionally submitted for inclusion in the Work
+      by You to the Licensor shall be under the terms and conditions of
+      this License, without any additional terms or conditions.
+      Notwithstanding the above, nothing herein shall supersede or modify
+      the terms of any separate license agreement you may have executed
+      with Licensor regarding such Contributions.
+
+   6. Trademarks. This License does not grant permission to use the trade
+      names, trademarks, service marks, or product names of the Licensor,
+      except as required for reasonable and customary use in describing the
+      origin of the Work and reproducing the content of the NOTICE file.
+
+   7. Disclaimer of Warranty. Unless required by applicable law or
+      agreed to in writing, Licensor provides the Work (and each
+      Contributor provides its Contributions) on an "AS IS" BASIS,
+      WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or
+      implied, including, without limitation, any warranties or conditions
+      of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A
+      PARTICULAR PURPOSE. You are solely responsible for determining the
+      appropriateness of using or redistributing the Work and assume any
+      risks associated with Your exercise of permissions under this License.
+
+   8. Limitation of Liability. In no event and under no legal theory,
+      whether in tort (including negligence), contract, or otherwise,
+      unless required by applicable law (such as deliberate and grossly
+      negligent acts) or agreed to in writing, shall any Contributor be
+      liable to You for damages, including any direct, indirect, special,
+      incidental, or consequential damages of any character arising as a
+      result of this License or out of the use or inability to use the
+      Work (including but not limited to damages for loss of goodwill,
+      work stoppage, computer failure or malfunction, or any and all
+      other commercial damages or losses), even if such Contributor
+      has been advised of the possibility of such damages.
+
+   9. Accepting Warranty or Additional Liability. While redistributing
+      the Work or Derivative Works thereof, You may choose to offer,
+      and charge a fee for, acceptance of support, warranty, indemnity,
+      or other liability obligations and/or rights consistent with this
+      License. However, in accepting such obligations, You may act only
+      on Your own behalf and on Your sole responsibility, not on behalf
+      of any other Contributor, and only if You agree to indemnify,
+      defend, and hold each Contributor harmless for any liability
+      incurred by, or claims asserted against, such Contributor by reason
+      of your accepting any such warranty or additional liability.
+
+   END OF TERMS AND CONDITIONS

noulxp-0.4.0/NOTICE

@@ -0,0 +1,21 @@
+NoulXP, the open exchange protocol for decision models
+Copyright 2026 System One Models
+
+This product includes software derived from:
+
+- laya (convaiinnovations/laya), Apache-2.0: the input construction reproduced
+  declaratively in the Laya converter (laya/common.py build_sequence,
+  render_options, clamp_temperature, temp_bucket).
+- Julia 1 (SupersonicLabs/Julia-1, revision a85b127321d580d65176c89ced8273f305745d85),
+  Apache-2.0: the JuliaDecisionModel inference subset in noulxp/export/julia.py
+  (julia/model.py), the input construction reproduced in its template
+  (julia/data.py sequence()), and its inference path rebuilt in
+  noulxp/native/julia.py (model.py, data.py, router/engine.py, typed.py).
+- Decider (github.com/Mapika/decider at 23579f7a, decider-ai 1.6.0), Apache-2.0:
+  the prompt layout, labels, isolated score levels and temperatures reproduced
+  declaratively in the Decider converter (decider/prompt.py, prompt_fast.py,
+  systemone.py, temperature.py, engine_gguf.py), and its request rendering,
+  prompt construction and GGUF readout rebuilt in noulxp/native/decider.py.
+
+NoulXP packages converted from these models carry the models' own weights and
+remain under the models' licences.

noulxp-0.4.0/PAPER.md

@@ -0,0 +1,74 @@
+# Paper outline
+
+Working title: **NoulXP: a portable runtime standard for calibrated
+single-pass decision models**
+
+This file tracks the paper: its argument, its sections, and which experiments
+are done. Numbers come from [VALIDATION.md](VALIDATION.md) and are measured,
+never estimated.
+
+## The argument
+
+1. A new kind of model answers typed questions about a state (choose one of
+   these options, score on this scale, is this true) with a calibrated
+   probability for every option, in one forward pass. Laya, Julia 1 and
+   Decider are three of them, from three teams, with three architectures.
+2. Each ships its own inference code. Running, deploying or comparing them
+   means installing, trusting and wrapping each one. Formats such as ONNX and
+   GGUF carry the weights but not the rest: how the input is built from the
+   request, where the answer is read, how it is calibrated.
+3. NoulXP puts the rest in the package as data (a template or a prompt, and
+   temperatures), so one engine runs every model with no code written for it
+   and nothing from the package executed.
+4. Faithfulness is testable: the package carries a conformance file of what
+   the model's own code answers, and an engine passes when it reproduces it
+   within 0.01 with the same decisions.
+5. Two profiles cover the models we know of: bidirectional encoders that
+   score a marker token per option, and causal language models read at an
+   answer letter.
+
+## Sections
+
+1. **Introduction.** System One models; the cost of one runtime per model;
+   the contribution: the standard, the conformance method, a reference
+   implementation and three conversions.
+2. **Background.** Calibrated classification and temperature scaling (Guo et
+   al., 2017); marker-based encoders (Laya, Julia 1); letter-probability
+   readout from language models (Decider); ONNX and GGUF as weight formats;
+   loading model code at run time (`trust_remote_code`) and why a standard
+   should not need it.
+3. **The standard.** Requests and answers; packages with nothing executable;
+   the two profiles; calibration as data; conformance files and the
+   comparison rule; compatibility levels.
+4. **Reference implementation.** Runtimes for both profiles on ONNX Runtime
+   and llama.cpp; converters that copy no weights (ONNX external data pointing
+   into the published safetensors); conformance generation from the models'
+   own code; the System One Engine and the registry, which run packages and
+   show the badge.
+5. **Evaluation.** The experiments below.
+6. **Discussion.** What the tolerance means; backend numerics; sharing
+   computation versus exactness; what 0.1 leaves open (SPEC.md 14).
+7. **Conclusion.**
+
+## Experiments
+
+| # | Question | Status |
+| --- | --- | --- |
+| E1 | Do packages reproduce their models' own answers on a CPU? | **Done.** 6 packages, 3 families, 52/52 cases each, all decisions equal, differences at the 4-decimal rounding floor. |
+| E2 | Does a declarative input description give the same tokens as the models' own code? | **Done.** Decider: 149/149 rows identical. Laya and Julia: input construction tested against their own code (tests/). |
+| E3 | Can a model's own ONNX export become a package without exporting again? | **Done.** Julia 1's published graph, renamed and pointed at its checkpoint: 52/52, and 100/100 on its authors' parity cases. |
+| E4 | Do packages stay faithful on accelerator backends? | **Partly.** Julia on Core ML passes (level 3). Decider on Metal keeps every decision but not the probabilities (max 0.036). CUDA, ROCm, OpenVINO, QNN, DirectML to do. |
+| E5 | What moves a causal model's probabilities? | **Done on one machine.** Flash attention off on the CPU: up to 0.014. Metal: 0.036 whatever the attention or cache settings. |
+| E6 | What does sharing the prompt prefix cost in faithfulness? | **Done on one machine.** CPU: 1.8x faster over the set, up to 0.018, and one near-tie decision of 91 changed; Metal: 1.6x faster, nothing added. To repeat on an x86 server. |
+| E7 | What does a package cost? | **Done on one machine.** 3 to 5 MB of graph per encoder package, no weight copies; load and latency per backend. Server numbers to do. |
+| E8 | Is 0.01 the right tolerance? | **To do.** The distribution of differences, and of decision flips, across backends and quantisations. |
+| E9 | Can someone else convert a model from the spec alone? | **To do.** A Laya Studio fine-tune and a model from outside the three families, converted by their authors. |
+
+## Before submission
+
+- E4, E6 and E7 on an x86 server CPU and at least one NVIDIA GPU.
+- E8 with quantised variants (int8 ONNX, Q4 GGUF) as derived packages.
+- E9 with at least one team outside System One Models.
+- Credit and permission: the model authors (Convai Innovations, Supersonic
+  Labs, Mark Marosi) are named for their models and asked before their
+  results are published.