Research

The systems underneath the service.

Valen Systems publishes the architecture, tests, limitations, and operating questions behind its work without exposing private implementation details.

Rubian

A working command-line operating environment used to exercise persistent users, services, files, projects, authenticated system connections, and benchmark work.

Explore Rubian →

Kestowv

The systems layer, runtime model, process architecture, and source of coordination mathematics beneath the current work.

Understand Kestowv →

Benchmark campaigns

Equal-work testing, correctness gates, repeated trials, telemetry, limitations, and the receipts behind named measurements.

Review the method →

Studies and documentation

Operating-system scheduling, accelerators, memory, machine reliability, and the problems guiding Valen Systems' research.

Read the studies →

Research sponsorship

Support continued engineering, disclosed testing, documentation, and the recovery of historical technical work.

Support the work →

Technical direction

Troy Mallory invented Rubian and Kestowv and leads the technical direction behind Project Valux, Rubian, and Kestowv.

Meet the company →

Research crossed into a public runtime.

The architecture validated in Kestowv became PR 9174, passed JRuby maintainer review, expanded across runtime integrations, and entered the JRuby 10.1+ release line.

Read the JRuby deployment See all deployments

Systems research for data centers meets power, cooling, hardware state, workloads, recovery, and human operations at the facility. Continue to infrastructure

The research starts with work that doesn't behave well enough.

A service retries without recovering. A release starts but fails its health check. An operator repeats the same investigation across several tools. Those are useful places to begin because the problem has a shape we can test.

Kestowv supplies service and resource controls for controlled pilots. Rubian gives people a programmable environment for inspecting and operating the system. Our wider work asks how those foundations can make machines and the organizations running them more useful.

Read the evidence. Then choose a question of your own.

Published methods and limitations matter as much as the result. A benchmark may answer one workload question; a recovery test answers another. Neither one should have to carry a claim about the whole company.

If the work connects to a problem in your environment, a defined evaluation is the next conversation. If you want to fund the research itself, the support program is a separate path.

Discuss an evaluation See research support

Follow the question into the work.

The research library connects machine constraints, recorded measurements and operating methods. Start with the question you need to answer, then inspect the work behind it.

Where useful computation is lost

Scheduling, locality, memory traffic and coordination costs can leave a busy machine doing less useful work. The studies examine those constraints one at a time.

What a measurement establishes

Compare equal work and inspect correctness, conditions and limits. Throughput, response time and energy answer different questions.

How an operator uses the system

Discovery, reusable commands, shared workspaces and service recovery have their own guides. They are not all the same operating problem.

How the research connects

Read the architectural history beside the specific upstream contribution and current technical direction.

Working through a hardware or runtime decision? Explore compute evaluations