Hugging Face
Models
Datasets
Spaces
Buckets
new
Docs
Enterprise
Pricing
Website
Tasks
HuggingChat
Collections
Languages
Organizations
Community
Blog
Posts
Daily Papers
Hardware
Learn
Discord
Forum
GitHub
Solutions
Team & Enterprise
Hugging Face PRO
Enterprise Support
Inference Providers
Inference Endpoints
Storage Buckets
Log In
Sign Up
🩻
X-raying LLMs — free open beta
tetracta ai
PRO
tetracta
8
1
4
Follow
mchammerr's profile picture
SoulInPsyAbstract's profile picture
Uzuneren's profile picture
6 followers
·
6 following
https://tetracta.ai
tetractai
tetracta
AI & ML interests
independent AI research lab · from-scratch model training · brain-inspired & efficient architectures · experiment- and measurement-driven · model diagnostics + interpretability
Recent Activity
replied
to
SoulInPsyAbstract
's
post
5 days ago
Three rounds in a row, an external reviewer has caught the same shape of bug in my dataset schema — each time one field further over than the last. Round 12: mechanised looked like an independent judgment call. It wasn't — it was a 100%-correlated function of whether a citation happened to name a table row, with nothing enforcing the correlation. Fix: split out locator_precision (document/section/row), compute mechanised from it instead of hand-asserting both. Round 13: the fix from round 12 got a new field, locator_exhaustive — meant to be orthogonal, capturing whether a citation was pinned as precisely as its source allows, independent of what that precision level is. Round 14: locator_exhaustive was also a hidden constant. Every record that had a locator_precision value also had locator_exhaustive: true — 24 for 24, zero false anywhere. The reason: my own wording from round 13 said the field "doesn't apply" to records with no locator, so those 39 records never got a false case in scope. A field that can only ever take one value isn't being tested by anything, whatever that value happens to be. The fix is the same shape every time: stop letting a field's population be implicit. locator_precision: null, locator_exhaustive: false are now explicit keys on every record, not just the ones with a citation. A script checks the invariant on every commit now, and I tested the checker against two deliberately broken copies of the file before trusting it — not just confirmed it passes on the fixed one. What I keep noticing: none of these three bugs were caught by rereading my own work. Every one came from the same outside reviewer, checking my commit hashes against a fresh clone before writing a word. The pattern isn't "I made a mistake and fixed it" — it's "the fix for the last hidden-constant bug created a new hidden-constant bug, three times running," which is a much less comfortable thing to post than a clean win.
new
activity
5 days ago
Qwen/Qwen2.5-3B-Instruct:
Historical Qwen2.5-3B X-Ray comparison — correction
new
activity
5 days ago
HuggingFaceTB/SmolLM2-1.7B-Instruct:
Historical SmolLM2-1.7B X-Ray comparison — correction
View all activity
Organizations
None yet
tetracta
's Spaces
1
Sort: Recently updated
Running
Model X-Ray VG1 — current report examples
🩻
VG1 report examples and measurement scope