About

tiyuvta is an AI research lab that studies model efficiency end to end and publishes the evidence — wins, bounded limits, and refuted hypotheses alike. This page covers what the name means, who runs the lab, how it pays for itself, what it is deliberately not doing, and — because you should ask — what it is not yet.


the name

tiyuvta — the evidence decides

tiyuvta (Aramaic) is the Talmud's verdict of conclusive refutation: a position is tested against the recorded evidence, and when the evidence wins, the debate ends — not because an authority said so, but because the source did. That is not a metaphor for the lab's method; it is the method. Hypotheses are preregistered with kill gates before the run starts, negative results are published with the same care as positive ones, and every claim on this site links to the raw log that would refute it if it were wrong.


who runs it

Founded and operated by its engineer

tiyuvta is founded and operated by Avi Fenesh — systems engineer at AWS ElastiCache, maintainer of Valkey GLIDE, independent ML researcher. The lab's engine, memra, is a from-scratch Rust+CUDA inference engine built in the open — its public research record is the lab's track record. The team is deliberately small: the engineering that wrote the kernels is the engineering on call.


the operating model

Research is the goal; serving is how it is funded

The lab studies model efficiency end to end — draft-head training, expert pruning and healing, precision assignment, speculative decoding — and it sells inference built on its own engine, memra. Serving revenue buys the hardware the research and training run on. That ordering is deliberate: the lab does not need to win market share to succeed — it needs the inference product to cover the cost of the GPUs its research runs on, while publishing reliability numbers that hold up to inspection.

The engine is public because the receipts are the moat. Every kernel is bit-audited against a CPU reference, every serving behavior is gated, and every published number has its raw run logs committed in the repo. A larger fleet could copy the code tomorrow; what it cannot copy without changing how it works is the discipline of showing the raw data next to every claim.

The operating model, named plainly: the lab is one engineer plus agents. In practice that means API keys are issued manually and an engineer reads every access request — expect a person, not a provisioning pipeline — and it is why every claim on this site carries a receipt: you should not have to trust a small lab, you should be able to check it.

The discipline extends to this site: page weight and third-party loads are CI gates, not goals. Lighthouse across every route on the 2026-08-07 build: performance 98–100, accessibility 100. A slow site selling fast inference would be a self-refuting claim — run Lighthouse yourself.


what tiyuvta is not doing

Non-goals

Stating what the lab is not working on is part of the method — a scope this narrow only holds if the exclusions are explicit.

  • No AGI claims. The lab studies model efficiency; it makes no claims about paths to general intelligence.
  • No model-menu breadth. One model class, served deeply — not a catalog of hundreds served shallowly.
  • No scale pretense. The fleet is small and the site says so; there is no enterprise theater above the fold.
  • No benchmarks-as-marketing. Published numbers are regression tracking with receipts — self-competition against the lab's own prior runs, not a scoreboard against other providers.
  • No unfalsifiable claims. Every claim on the site is written so an outside engineer could refute it from the linked raw logs, and the bounded exceptions are published unprompted.

what tiyuvta is not yet

Read this before you depend on it

The rest of this site tells you what the lab does well. This section is the other half. Each gap is stated with the control that compensates for it today — not as a substitute, as the honest current state.

No SOC2

There is no compliance certificate. Compensating control: the engine, its gate batteries, and the raw logs behind every published number are public in the memra repo — you can audit the actual system instead of a report about it.

No multi-region

The fleet is small and single-region. Compensating control: a status page on separate infrastructure (coming soon), so when the serving region has a problem you can still see exactly what and since when.

No 99.99 SLA

The lab does not sell a number it has not earned. Compensating control: deploys drain, they don't drop — in-flight requests complete before a replica restarts — and measured reliability stats are published as receipts rather than promised as targets.

The edge is the tuning, not the hardware

Nobody should care what hardware a provider owns — what matters is how precisely the engine is tuned to the silicon it serves on. Every kernel here is written, bit-audited, and regression- tracked against the exact deployment target; that is where the published numbers come from. The boards say which rig measured them (rented pods today; rig labels never move after the fact) — because a number without its silicon is not a number.