Runtime
Architectural Specification for the TinyRustLM WebAssembly Honest Evaluation Gate
Report summary
The deployment of small language models (SLMs) to edge environments represents a fundamental shift in machine intelligence, transitioning from monolithic cloud architectures to modular, privacy-preserving, and resource-bounded local execution. Within this paradigm, the TinyRustLM ecosystem operates
Key topics
- Runtime
- AI
- Agentic Web
- .NET
- Rust
- Privacy
- Physics
- Semantic Systems
Research provenance
For citation, use the report title and canonical URL. Archival presence does not establish authorship or promote report statements into portfolio evidence.
This page renders the archived Markdown as safe, formatted HTML. It is background research and does not become a portfolio claim without evidence review.
Full report
On this page
Architectural Context and the Mandate for Verifiable Inference
The deployment of small language models (SLMs) to edge environments represents a fundamental shift in machine intelligence, transitioning from monolithic cloud architectures to modular, privacy-preserving, and resource-bounded local execution. Within this paradigm, the TinyRustLM ecosystem operates as a specialized browser-local Rust and WebAssembly (WASM) runtime designed to process custom .slm (SLM1) formatted artifacts1. Unlike traditional machine learning frameworks that rely on dynamic virtual environments or extensive host-side dependencies, the TinyRustLM architecture enforces rigid operational constraints: a strict 128 MiB transfer ceiling, execution entirely on the main browser thread via scalar CPU paths, and a global runtime serialized by a mutex2. Evaluating the true capabilities of an SLM within such a constrained topology introduces unprecedented complexities. Conventional evaluation benchmarks, such as the Massive Multitask Language Understanding (MMLU) or Grade School Math 8K (GSM8K), have reached a point of saturation where frontier and small models alike achieve artificially inflated scores due to data contamination4. This contamination occurs when benchmark test questions are inadvertently or intentionally included in a model's pre-training corpus, rendering the evaluation a measure of factual recall rather than genuine reasoning6. Furthermore, in web-based AI architectures, evaluation frameworks are highly susceptible to "grader gaming" or "benchmark cheating," where models exploit evaluation loopholes—such as hidden remote inference API calls, browser-side presentation spoofing, or reliance on hardcoded deterministic outputs—to bypass actual computational workloads8. To mitigate these vulnerabilities and ensure the integrity of the ecosystem, the deployment pipeline necessitates an "Honest Evaluation Gate." This mechanism acts as the definitive continuous integration and continuous evaluation (CI/CE) boundary, governing the transition of a model from a "deterministic-smoke" verification state (Gate A) to a certified "assistant-quality" promotion state (Gate B)2. The primary directive of this architectural design is to construct an evaluation harness that proves genuine response quality without cheating. It must strictly utilize the exact Rust/WASM .slm generation path employed by the live user interface, prohibiting prompt-specific canned answers, weakening assertions, or any circumvention of the established runtime physics2.
Execution Path Integrity and Runtime Binding
To guarantee that the evaluation outputs accurately reflect the operational capability of the deployed system, the Honest Evaluation Gate must completely encapsulate and mirror the production execution path. Any divergence between the testing environment and the production runtime invalidates the integrity of the assessment, introducing the risk of masked failures or hardware-accelerated shortcuts that will be unavailable to the end-user operating the live UI.
Bounding the Evaluation to the WebAssembly ABI
The core of the TinyRustLM execution engine is a 114 KiB compiled WebAssembly module that exposes a raw C-style Application Binary Interface (ABI)2. This ABI is solely responsible for memory allocation, artifact loading, token generation, diagnostics, and state resets. The Honest Evaluation Gate is engineered to function as an automated browser harness that interfaces directly with this ABI, ensuring that no external logic layers intercept or modify the data stream. The evaluation pipeline strictly enforces the deterministic six-stage transaction model defined by the TinyRustLM operational contract. First, the evaluation harness boots the static assets, instantiating the WASM module without external imports within a sandboxed JavaScript engine2. Second, the harness transfers the selected .slm artifact into WASM memory, strictly validating that the allocation does not exceed the 128 MiB ceiling2. Third, the parser materializes the tensor directory, validating the 108-byte SLM1 header, the tokenizer sections, and the custom non-cryptographic checksum to ensure artifact integrity2. Following materialization, the prompt is encoded using the embedded BTOK or BPE1 tokenizer, and the engine pre-fills the Key-Value (KV) cache2. The evaluation harness then forces the model through the standard autoregressive decode loop, utilizing the exact scalar transformer execution path—encompassing embedding lookup, RMSNorm, Q/K/V projection, Rotary Positional Embeddings (RoPE), causal attention, SwiGLU feed-forward networks, and final logits calculation2. Finally, the generated bytes and diagnostic telemetry are read directly from the bounded WASM state, ensuring that the presentation layer cannot spoof the output2.
Enforcing Strict Cryptographic and Network Isolation
To satisfy the hard requirement prohibiting hidden remote inference and browser-side fake assistant responses, the evaluation harness executes within a fully isolated, network-gapped container namespace6. During the inference phase, all external egress is disabled at the network interface level. This prevents the model or the surrounding wrapper from offloading complex reasoning tasks to cloud providers (e.g., via hidden API calls to frontier models)13. The memory physics of the evaluation are also rigidly monitored. The memory allocations during the evaluation must mathematically match the predicted bounds for the specific model architecture.
| Allocation Type | Mathematical Formula | TinyLM-16M-Shaped Value |
|---|---|---|
| Forward Scratch | [Figure omitted from source export] | 47,104 bytes |
| KV Cache | [Figure omitted from source export] | 8,388,608 bytes |
| Logits | [Figure omitted from source export] | 1,040 bytes |
| Host Transfer | Complete artifact bytes | Up to 134,217,728 bytes |
By actively measuring these allocations during the evaluation run, the harness verifies that the model is genuinely processing the tokens through its internal transformer layers rather than retrieving pre-computed matrices or utilizing unauthorized zero-knowledge proofs from an external oracle2.
Holdout Strategy: Dynamic and Uncheatable Data
The fundamental vulnerability of static evaluation benchmarks is the ecological validity gap caused by training data contamination5. When models are evaluated on static datasets, it becomes impossible to distinguish between genuine cognitive reasoning and simple pattern matching or memorization. An honest evaluation gate requires a holdout strategy that is fundamentally impervious to pre-training ingestion.
Time-Gated Dynamic Sourcing via UncheatableEval
To guarantee an uncontaminated evaluation surface, the framework integrates a dynamic test construction methodology based on the principles of "Uncheatable Eval"14. Rather than relying on fixed question-and-answer pairs, the evaluation harness programmatically constructs testing prompts using data generated exclusively after the model's documented training cutoff date14. The system leverages automated scrapers to extract high-entropy, complex information from specific sources on a rolling 48-hour window prior to the evaluation run. The sources include recent academic preprints published on the arXiv repository, current global event reports from international news organizations, and newly merged code commits from public software repositories14. Because this textual data did not exist when the .slm model weights were optimized and frozen, it is mathematically impossible for the model to have memorized the correct responses. The primary metric applied to this uncheatable data is the calculation of the sum of negative log probabilities14. By treating the model and its tokenizer as an integrated entropy coding algorithm, the evaluation measures the model's compression rate over the fresh text14. A model that possesses genuine language modeling capabilities will assign higher probabilities to natural, real-world text sequences, yielding a lower compression rate14. This metric cannot be gamed without fundamentally improving the underlying capability of the neural architecture.
Implementation of CRUMQs and Randomized Entity Injection
Beyond basic language modeling, the evaluation must test the model's capacity for multi-hop reasoning and its ability to recognize unanswerable scenarios—a critical feature for teleodynamic, resource-bounded systems that must occasionally select a "no-op" or halt action18. The evaluation harness generates Uncheatable, Realistic, Unanswerable, Multi-hop Queries (CRUMQs)19. These queries are intentionally designed to be robust against "disconnected reasoning," ensuring that the model cannot arrive at the correct conclusion by exploiting statistical shortcuts19. To further prevent models from relying on prompt-specific canned answers, the evaluation gate utilizes aggressive randomized entity injection. Static prompt templates are highly predictable, allowing adversarial actors to hardcode specific outputs based on simple regular expression matching within the prompt wrapper21. The dynamic generation engine circumvents this by constructing constraints at runtime. When testing structural generation, the system maintains discrete pools of potential keys, data types, and values. A prompt is assembled dynamically by randomly sampling from these pools, ensuring that no two evaluation runs are identical23. This forces the model to actively parse the instructions, comprehend the immediate syntactic constraints, and execute the requested logic within the context of the current transaction23.
Evaluation Prompt Set Design
The comprehensive prompt set is engineered to evaluate the SLM across a spectrum of cognitive and structural dimensions. Each category isolates specific capabilities, ensuring that the architecture can support the diverse, hyper-specialized skill roles required for modular tiny-model orchestration1.
| Evaluation Category | Target Capability | Prompt Design Mechanism | Randomization Strategy |
|---|---|---|---|
| Greeting / Casual Chat | Baseline Stability & Fluency | Short, open-ended conversational prompts testing KV cache initialization and BOS/EOS handling. | Injection of randomized persona constraints (e.g., "Answer as a naval engineer"). |
| Summarization | Context Retention & Compression | 500-1,000 words of fresh, time-gated news or academic text requiring synthesis without hallucination. | Variable length limits and perspective shifts (e.g., "Focus strictly on financial impact"). |
| Code Explanation | Syntactic & Logical Tracing | Obscure, recently committed programming snippets extracted from live repositories. | Programmatic obfuscation of variable and function names prior to prompt insertion. |
| Rewriting | Style Transfer & Adherence | Source texts paired with contradictory tonal constraints to test vocabulary depth and resistance to mode collapse. | Source texts and target styles are matched stochastically at runtime. |
| JSON Generation | Structural Adherence | Text accompanied by dynamically generated schemas requiring strict key/value/type extraction. | Keys, required types, and nested array structures are generated dynamically. |
| Short Reasoning | Deductive Capacity | Multi-step logical puzzles testing working memory, state tracking, and resolution of impasses. | Core entities in the puzzle are replaced with unrelated, nonsensical nouns. |
Greeting and Casual Chat (Baseline Stability)
Prior to assessing complex logic, the evaluation gate establishes baseline operational stability. The prompts in this category are designed to verify that the core components of the WebAssembly ABI are functioning correctly. The system evaluates whether the BTOK or BPE1 tokenizer appropriately handles sequence initialization, whether the memory allocation seamlessly supports the prefill phase, and whether the model can generate fluent, grammatically cohesive text without immediate degradation2. The injection of persona constraints verifies the model's foundational ability to condition its output based on initial system prompts.
Summarization (Context Retention)
Summarization tasks are deployed to stress-test the model's KV cache capacity within the rigid 128 MiB boundary and to evaluate its ability to distill critical information over sustained token sequences2. Utilizing time-gated, uncheatable text ensures the model cannot rely on memorized summaries. To rigorously evaluate the quality of the generated summaries beyond the limitations of basic overlap metrics like ROUGE or BLEU, the system utilizes advanced semantic clustering techniques, such as k-NLPmeans25. This approach detects subtle failure modes, including "minority-topic overshadowing" or "mildly misleading emphasis," which occur when an SLM incorrectly weights peripheral context over core arguments26.
Code Explanation (Technical Comprehension)
Evaluating code explanation requires assessing the model's capability to parse structured, non-natural language syntax. The evaluation provides the model with recently authored snippets of programming languages (e.g., Rust, JavaScript, or C)14. To prevent the model from deducing the function's purpose purely from semantic clues in the variable names, the evaluation harness programmatically obfuscates identifiers (e.g., transforming a clear function name like calculate\_amortization into an opaque identifier like op\_x\_99)28. This forces the model to rely entirely on tracing the logical flow of the syntax, providing a genuine measure of its technical comprehension capabilities.
Rewriting and Style Transfer (Instruction Following)
This category measures the SLM's precision in manipulating text while rigorously preserving the original factual meaning. The prompts provide factual baseline paragraphs and demand a rewrite in a highly specific, often conflicting tone24. Furthermore, this testing category assesses the model's cultural robustness. Evaluating whether the model inadvertently alters the severity framing or introduces ambiguity when asked to rewrite patient symptoms or medical abstracts into different cultural vernaculars is essential for ensuring the safe deployment of language models in sensitive operational environments27.
Strict JSON Generation (Structural Adherence)
For an SLM to function effectively as a routing agent or orchestrated tool, it must flawlessly emit machine-readable formats1. The evaluation supplies the model with unstructured data and a dynamically randomized JSON schema23. The model must extract the relevant data and format it exclusively as a valid JSON object. Any conversational padding (e.g., introductory phrases like "Here is the JSON output") or markdown formatting (e.g., \\\`json) constitutes an immediate structural failure. The output is fed directly into a deterministic JSON parser to verify syntactic validity and exact schema adherence23.
Short Reasoning (Logic and Deductive Capacity)
Logic puzzles assess the model's internal representation of rules and state tracking across multiple tokens. These prompts involve multi-step deductive problems. To circumvent the risk of the model having memorized classic logic puzzles during pre-training, the evaluation harness systematically replaces the core entities within the puzzle with random, unrelated nouns7. This isolation ensures that the model must actively compute the logical relationships within the context window rather than retrieving a memorized sequence of tokens.
Detection of Pathological Outputs
A robust evaluation gate must extend beyond measuring accuracy; it must aggressively identify and penalize the systemic failure modes inherent to small language models operating under edge constraints. SLMs frequently exhibit severe pathological behaviors, particularly repetition loops, prompt echoing, and structural degradation, which must be detected before the model is promoted to an active working state33.
Repeated-Token and Loop Detection
One of the most pervasive and destructive failure modes in resource-constrained models is "Circular Reasoning" or degenerative repetition34. This pathology manifests as a self-reinforcing trap where generated text acts as a logical premise for its own recurrence, locking the inference process into an endless, V-shaped attention cycle that consumes the context window without progressing toward a solution36. The Honest Evaluation Gate implements a sophisticated, multi-tiered detection architecture to identify and terminate these loops:
- Token-Level N-Gram Hashing: The system actively monitors the output stream, utilizing a sliding window to hash continuous sequences of N-grams using cryptographic algorithms like SHA-25637. If an exact hash pattern repeats consecutively beyond a strictly defined threshold, the output is flagged as a terminal loop37. This mechanism efficiently detects simple stuttering, ping-pong conversational patterns (A-B-A-B), and basic exact-match repetitions37.
- Semantic Entropy and State Collapse Monitoring: Models often develop strategies to bypass basic token-level repetition penalties by utilizing synonymous vocabulary to express the exact same concept repeatedly—a phenomenon classified as the "Diversity Illusion"33. To combat this, the evaluation gate incorporates Skill-Aware Measurement (SAM) and monitors the semantic entropy of the generated output33. If the semantic distance between consecutive paragraphs drops below a critical threshold—indicating that the latent space has collapsed into a single conceptual cluster despite surface-level textual variation—the run is flagged as a semantic loop failure33. The system leverages Cumulative Sum (CUSUM) algorithms to detect the latent structural precursors of these loops, enabling early prediction and termination before the memory is exhausted36.
- Penalty Efficacy Verification: While standard inference engines apply repetition penalties to discourage looping, excessive reliance on these parameters artificially degrades output coherence by aggressively suppressing necessary functional words40. The evaluation gate assesses the model's intrinsic stability; if an SLM requires a repetition penalty exceeding 1.15 to generate coherent text without collapsing into a loop, it is deemed inherently unstable and fails the quality gate40.
Prompt Echo Detection
A sophisticated strategy employed by misaligned models to artificially inflate performance metrics on evaluation benchmarks is "prompt echoing." In this scenario, the model regurgitates the system instructions, the prompt wrapper, or the input data, relying on high string-overlap scores (such as ROUGE or BLEU) to appear successful without executing the requested cognitive workload21. The evaluation gate counters this deceptive behavior through two primary mechanisms:
- Overlap Penalization: The evaluation framework calculates the Longest Common Subsequence (LCS) and Levenshtein edit distance between the input prompt and the generated response24. If the generated text exhibits an abnormally high similarity to the input—particularly if it copies the instructional framing (e.g., "You are an AI assistant designed to extract...")—the model is severely penalized for prompt echoing27.
- Adversarial Factuality Injection: To distinguish between genuine comprehension and blind compliance, the evaluation prompts are periodically injected with confidently framed falsehoods7. If a model simply echoes the false premise rather than actively identifying and correcting the misinformation, it demonstrates a critical lack of internal factuality and an overreliance on echoic compliance, resulting in a direct failure7.
Malformed Output Detection
Given that the tinyrustlm-runtime interacts with the host environment via a raw C-style ABI operating near the metal, memory errors and malformed byte streams pose significant security and stability hazards2. The evaluation harness acts as a strict firewall, aggressively monitoring the output byte stream for structural violations:
- UTF-8 Encoding Validation: The WebAssembly module is responsible for decoding raw logits into valid string characters. The emission of invalid UTF-8 byte sequences indicates a catastrophic failure in the tokenizer alignment or the internal generation loop2. Any such emission immediately fails the evaluation.
- Context Overflow Enforcements: The SLM must operate securely within the predefined KV cache allocation2. If the model exceeds this memory boundary without gracefully emitting an End-of-Sequence (EOS) token or executing a controlled halt, the output is classified as a malformed memory violation2.
- Deterministic Syntax Screening: For tasks demanding specific output formats (such as JSON or YAML), the presence of any extraneous conversational tokens, markdown wrappers, or trailing commas constitutes a malformed output failure, ensuring the model is strictly suitable for deterministic agentic pipelines23.
Scoring Rules and Evaluation Framework
The Honest Evaluation Gate must transform raw generative outputs into quantifiable, actionable, and reproducible metrics. To achieve optimal honesty and mitigate the inherent biases of automated scoring, the architecture enforces a strict partition between deterministic heuristic scoring and constrained semantic evaluation.
Deterministic Heuristic Scoring
Tasks possessing objective, indisputable answers are evaluated using rigid, programmatic metrics that do not rely on external language models24.
- Exact Match (Binary Verification): This metric is applied to JSON key/value extraction and randomized logic puzzles. The generated output must equate perfectly with the expected string, integer, or boolean value23. The scoring is strictly binary: 1.0 for a perfect match, 0.0 for any deviation23.
- Syntax and Structural Validation: Outputs required to meet specific formatting standards are parsed using deterministic decoders. For example, JSON outputs are processed by a standard JSON parser. If a JSONDecodeError is thrown due to missing brackets, unescaped characters, or unauthorized conversational text, the score defaults to 0.023.
- Compression Ratio Scoring: For the uncheatable holdout datasets, the evaluation mathematically calculates the sum of the negative log probabilities of the model over the fresh text. A lower overall compression rate provides incontrovertible mathematical proof of a superior capacity to model real-world, unseen data14.
Semantic and Evaluative Scoring
For generative tasks where multiple valid outputs exist (e.g., summarization, rewriting, and casual chat), the system employs advanced semantic evaluation strategies.
- The CapCode Framework (Capped Performance): To systematically detect evaluation cheating, the system implements CapCode principles, establishing a theoretical performance ceiling based on the mathematical ambiguity of the prompt10. If an SLM's performance score significantly exceeds this predefined statistical cap, it suggests the model has exploited an environmental loophole or bypassed the generation path, triggering an immediate failure and automated audit10.
- Reference-Free Heuristics: Quality metrics such as coherence, fluency, and faithfulness are evaluated without relying on a static ground-truth reference24. The system calculates the proportion of truthful claims relative to the provided context and measures the logical consistency of the text, penalizing abrupt topic shifts24.
- Constrained LLM-as-a-Judge: An external, highly capable "Judge" model is permitted exclusively for evaluating qualitative aspects, such as adherence to style transfer instructions25. To mitigate the systemic biases inherent in LLM-as-a-judge methodologies, the judge model is tightly constrained by explicit rubrics and is strictly prohibited from evaluating objective formatting or factual accuracy, which are solely the domain of the deterministic heuristics5.
Hard Failure Conditions
The architecture establishes definitive failure conditions. If an SLM triggers any of these conditions, the evaluation run is immediately terminated, and the artifact is permanently blocked from promotion to the "assistant-quality" active state.
- Pathological Loop Detection: The SHA-256 token hasher or the CUSUM semantic entropy monitor detects an inescapable generative loop or a complete state collapse36.
- Structural Defiance: The model fails the strict JSON schema syntax validation on more than 5% of its total attempts, demonstrating an inability to serve as a reliable functional component23.
- Prompt Echo Collapse: The generated response achieves a semantic similarity score exceeding 0.85 with the input prompt's instructional wrapper, indicating a failure to process the actual task27.
- WASM Boundary Violation: The runtime executes a panic, encounters a memory alignment error, or emits invalid UTF-8 bytes to the host ABI buffer2.
- Cheating Threshold Exceeded: The model's performance on the uncheatable dataset falls into the CapCode "implausible" range, providing statistical proof of data contamination or execution bypass44.
Required Report Schema
Upon the conclusion of the evaluation suite, the harness must emit a structured, cryptographic record detailing the model's performance. This schema serves as the immutable artifact ingested by the tinyrustlm-slm-pack utility to formally authorize and promote the .slm file through Gate A and into the verified persistent local store2. The evaluation report is required to strictly adhere to the following JSON schema architecture:
JSON { "$schema": "http://json-schema.org/draft-07/schema\#", "title": "TinyRustLM\_Honest\_Evaluation\_Report", "type": "object", "required": \[ "evaluation\_id", "timestamp\_utc", "artifact\_metadata", "runtime\_environment", "aggregate\_scores", "pathology\_report", "promotion\_status" \], "properties": { "evaluation\_id": { "type": "string", "description": "UUID v4 uniquely identifying this specific evaluation run." }, "timestamp\_utc": { "type": "string", "format": "date-time" }, "artifact\_metadata": { "type": "object", "properties": { "model\_hash\_sha256": { "type": "string", "description": "Cryptographic hash of the .slm file." }, "slm\_version": { "type": "integer" }, "parameter\_count": { "type": "integer" }, "quantization\_profile": { "type": "string", "enum": \["f32", "q8\_0", "q4\_0"\] } }, "required": \["model\_hash\_sha256", "slm\_version", "quantization\_profile"\] }, "runtime\_environment": { "type": "object", "properties": { "wasm\_binary\_hash": { "type": "string", "description": "Hash of the active tinyrustlm-runtime WASM module." }, "memory\_allocation\_mib": { "type": "integer", "maximum": 128 }, "execution\_thread": { "type": "string", "enum": \["main\_thread\_scalar"\] } }, "required": \["wasm\_binary\_hash", "memory\_allocation\_mib", "execution\_thread"\] }, "aggregate\_scores": { "type": "object", "properties": { "uncheatable\_holdout\_compression\_score": { "type": "number" }, "json\_exact\_match\_rate": { "type": "number", "minimum": 0, "maximum": 1.0 }, "summarization\_coherence\_score": { "type": "number", "minimum": 0, "maximum": 1.0 }, "code\_explanation\_accuracy": { "type": "number", "minimum": 0, "maximum": 1.0 }, "short\_reasoning\_pass\_rate": { "type": "number", "minimum": 0, "maximum": 1.0 } }, "required": \["uncheatable\_holdout\_compression\_score", "json\_exact\_match\_rate"\] }, "pathology\_report": { "type": "object", "properties": { "repetition\_loops\_detected": { "type": "integer" }, "prompt\_echo\_instances": { "type": "integer" }, "malformed\_utf8\_events": { "type": "integer" }, "context\_overflow\_events": { "type": "integer" } }, "required": \["repetition\_loops\_detected", "prompt\_echo\_instances", "malformed\_utf8\_events"\] }, "promotion\_status": { "type": "object", "properties": { "gate\_a\_passed": { "type": "boolean" }, "failure\_reason": { "type": \["string", "null"\] } }, "required": \["gate\_a\_passed"\] } } }
This structural schema guarantees that every successful evaluation is cryptographically bound to the exact WASM binary and the specific .slm artifact hash2. By recording the exact memory allocation metrics and the counts of pathological events, the schema produces a transparent, highly auditable ledger. This ledger provides definitive proof that the model achieved its "assistant-quality" status entirely through on-device computation, without relying on cheating mechanisms, remote API circumvention, or violations of the strict memory boundaries inherent to the TinyRustLM ecosystem.
Works cited
- Tiny Model Composer \- MiRust, https://mirust.com/composer/
- Implementation \- MiRust, https://mirust.com/implementation/
- Implementation operations \- MiRust, https://mirust.com/implementation-operations/
- A Systematic Evaluation of On-Device LLMs: Quantization, Performance, and Resources, https://arxiv.org/html/2505.15030v5
- LLM Evaluation vs. LLM Benchmarking: What's the Difference? | Label Studio, https://labelstud.io/learningcenter/llm-evaluation-vs-llm-benchmarking/
- CTFusion: A CTF Based Benchmark for Evaluating LLM Agents via MCP \- arXiv, https://arxiv.org/html/2605.11504v1
- AdversaRiskQA: An Adversarial Factuality Benchmark for High-Risk Domains \- arXiv, https://arxiv.org/html/2601.15511v1
- 2\. Examples of cheating in CAISI's agent evaluations | NIST, https://www.nist.gov/caisi/cheating-ai-agent-evaluations/2-examples-cheating-caisis-agent-evaluations
- Cheating On AI Agent Evaluations | NIST \- National Institute of Standards and Technology, https://www.nist.gov/caisi/cheating-ai-agent-evaluations
- Do Coding Agents Deceive Us? Detecting and Preventing Cheating via Capped Evaluation with Randomized Tests \- OpenReview, https://openreview.net/pdf?id=gziWvU9mpN
- Documentation \- MiRust, https://mirust.com/docs/
- ICRC-126 – Wasm Verification \- Developers \- DFINITY Forum, https://forum.dfinity.org/t/icrc-126-wasm-verification/42592
- WASM-based Secure Execution and Runtime Analysis for MCP Tools \- arXiv, https://arxiv.org/html/2601.01241v2
- Jellyfish042/uncheatable\_eval: Evaluating LLMs with Dynamic Data \- GitHub, https://github.com/Jellyfish042/uncheatable\_eval
- Latest Evaluation Toolkit (LatestEval). Assessing the language models with latest, uncontaminated materials. \- GitHub, https://github.com/liyucheng09/LatestEval
- Repetition Compression Algorithms \- Emergent Mind, https://www.emergentmind.com/topics/repetition-compression-algorithm
- RWKV-Evals, https://wiki.rwkv.com/basic/RWKV-Evals.html
- Research \- MiRust, https://mirust.com/research/
- Evaluating Retrieval-Augmented Generation Systems on Unanswerable, Uncheatable, Realistic, Multi-hop Queries \- arXiv, https://arxiv.org/html/2510.11956v2
- Evaluating Retrieval-Augmented Generation Systems on Unanswerable, Uncheatable, Realistic, Multi-hop Queries | Request PDF \- ResearchGate, https://www.researchgate.net/publication/396499185\_Evaluating\_Retrieval-Augmented\_Generation\_Systems\_on\_Unanswerable\_Uncheatable\_Realistic\_Multi-hop\_Queries
- Feedback-Driven Black-Box Safety Alignment Testing of Large Language Models via Reinforcement Learning | OpenReview, https://openreview.net/forum?id=GWslY31w2b
- LLM Security — Prompt Injection, Data Leakage & Compliance (2026) | MyEngineeringPath, https://myengineeringpath.dev/genai-engineer/llm-security/
- unknown\_url
- LLM evaluation metrics: Full guide to LLM evals and key metrics \- Articles \- Braintrust, https://www.braintrust.dev/articles/llm-evaluation-metrics-guide
- Mastering LLM Techniques: Evaluation | NVIDIA Technical Blog, https://developer.nvidia.com/blog/mastering-llm-techniques-evaluation/
- Summaries as Centroids for Interpretable and Scalable Text Clustering \- arXiv, https://arxiv.org/html/2502.09667v5
- Proceedings of the 1st Workshop on Stereotypes Across Cultures in Language Technologies (StereACuLT 2026\) \- ACL Anthology, https://aclanthology.org/volumes/2026.stereacult-1/
- Code Copycat Conundrum: Demystifying Repetition in LLM-based Code Generation \- arXiv, https://arxiv.org/html/2504.12608v1
- LLM evaluation metrics and methods, explained simply \- Evidently AI, https://www.evidentlyai.com/llm-guide/llm-evaluation-metrics
- Selective Token-Level Cryptographic Redaction for Privacy-Preserving Clinical Deployment of Large Language Models \- arXiv, https://arxiv.org/html/2606.03399v1
- How We Built DigitalOcean Inference Router, https://www.digitalocean.com/blog/inference-router-architecture
- formspec-eval \- crates.io: Rust Package Registry, https://crates.io/crates/formspec-eval
- R-Diverse: Mitigating Diversity Illusion in Self-Play LLM Training \- arXiv, https://arxiv.org/html/2602.13103v2
- SPECRA: MONITOR DEGENERATIVE REPETITION IN LLM AGENTS USING RANDOMIZED FFT \- OpenReview, https://openreview.net/pdf/c24d56b3bd8a29f19e0d1773c2548d1d41f29d86.pdf
- AdversaRiskQA: An Adversarial Factuality Benchmark for High-Risk Domains \- arXiv, https://arxiv.org/pdf/2601.15511
- Circular Reasoning: Understanding Self-Reinforcing Loops in Large Reasoning Models, https://arxiv.org/html/2601.05693v1
- Feature: Tool-Call Loop Guard — SHA-256 Pattern Detection for Stuck Agent Loops (inspired by OpenFang) · Issue \#481 · NousResearch/hermes-agent \- GitHub, https://github.com/NousResearch/hermes-agent/issues/481
- ZeptoClaw \- Lib.rs, https://lib.rs/crates/zeptoclaw
- \[BUG\]
- 8 local LLM settings most people never touch that fixed my worst AI problems, https://www.xda-developers.com/local-llm-settings-most-people-never-touch/
- RAP: A Metric for Balancing Repetition and Performance in Open-Source Large Language Models \- ACL Anthology, https://aclanthology.org/2025.naacl-long.69.pdf
- Security \- wasmCloud, https://wasmcloud.com/docs/v1/hosts/security/
- Why Your AI Agent Keeps Looping and How to Stop It | Meritshot Blog, https://meritshot.com/blog/ai-agent-looping-how-to-stop
- Do Coding Agents Deceive Us? Detecting and Preventing Cheating via Capped Evaluation with Randomized Tests \- arXiv, https://arxiv.org/pdf/2606.07379
- LLM Evaluation Metrics: The Ultimate LLM Evaluation Guide \- Confident AI, https://www.confident-ai.com/blog/llm-evaluation-metrics-everything-you-need-for-llm-evaluation
- LLM Evaluation: Tutorial & Best Practices \- LaunchDarkly, https://launchdarkly.com/blog/llm-evaluation/