Skip to content

, Philosophy

How we think, written down so it can be held against us.

Most companies publish values. This is closer to an engineering document: a set of positions we have taken, each with the thing it costs us stated alongside it.

01Why we exist

Rudvanth builds AI systems that solve real-world problems, and turns that knowledge into products that scale globally.

Everything else, the engineering work, the research, the open-source releases, the products, is a means to that. The sentence is short on purpose. If a decision does not serve it, it does not get made here.

The conviction underneath it is that the constraint in enterprise AI stopped being model capability some time ago and became assurance: the ability to show, with evidence, that a system is behaving correctly in a specific domain. That work is made of domain knowledge and engineering discipline rather than parameters, which is why it does not get commoditised by the next model release, and why it is worth building a company around.

Build quietly.
Publish thoughtfully.
Evidence, not adjectives.

02How we think

Three habits of mind that shape almost every decision here.

02.1

Start from the measurement

Before asking how to build something, we ask how we would know it was working. If that question has no answer, the project has a problem that no amount of engineering will fix, and it is better to discover that in week one than in month six.

02.2

Prefer the boring mechanism

Given two designs that both work, we take the one with fewer moving parts, fewer novel dependencies and a failure mode somebody can debug at 3am. Novelty belongs in the research, not in the plumbing underneath a production system.

02.3

Argue with the artefact, not the opinion

Disagreements get resolved by building the smallest thing that settles them. A benchmark, a spike, a counter-example. Meetings do not converge; evidence does.

03Engineering principles

What we hold ourselves to when writing software, whether for a client or for ourselves.

03.1

The harness ships with the feature

Evaluation lives in the repository, runs in CI, and gates releases. Anything that only runs when somebody remembers will stop running by the second month.

03.2

Design for the handover

Every system is written to be operated by people who did not build it. Runbooks, architecture notes and legible naming are part of the deliverable, not a phase that gets cut when the schedule tightens.

03.3

Own the interfaces, rent the rest

Model providers, cloud vendors and libraries are replaceable and should be replaceable. We put the abstraction where the volatility is, and we do not build the parts that are already commodities.

03.4

Simple, then correct, then fast

In that order, and never skipping. Optimising something that is wrong just produces a wrong answer sooner.

04Research principles

Rudvanth Labs is judged on whether it produces things other people can use, not on volume.

04.1

Few questions, held for years

Four research tracks, not twelve. Depth compounds and breadth does not, and a lab with a dozen directions has none.

04.2

Publish the negative result

“We tried this and it did not work, here is the measurement” is the most useful and least published category of finding. We publish ours.

04.3

Show the uncertainty

Inter-annotator disagreement, confidence intervals, the cases the method fails on. A result that hides its error bars is advertising.

04.4

Research answers to production

Every track exists because a real system needed it. When a research direction stops touching anything anyone is shipping, we close it rather than let it drift.

05How we think about AI responsibility

Not a compliance statement. These are engineering positions with costs attached.

05.1

Refusal is a feature, not a failure

A system that says “I do not know” when the evidence is absent is more valuable in a regulated setting than one that is right more often on average. We build and test for calibrated abstention explicitly.

05.2

The human stays accountable

We build systems that make a qualified person faster and better-informed. We do not build systems designed to remove that person from a decision that carries consequences for someone else.

05.3

Provenance over persuasion

Fluency is not evidence. Where an output influences a decision, it carries its sources, and we measure whether those sources actually support it rather than assuming a citation is a guarantee.

05.4

Client data is not training data

Never, in any form, including as synthetic data derived from it. This is absolute and it is in every contract we sign.

05.5

Say no to the wrong use case

Some applications should not be built, and some should not be built by us. We would rather lose the engagement than ship something we would not want used on our own families.

06Product philosophy

How something earns the right to be called a product here.

06.1

Products come from delivery, not from whiteboards

Every product in our pipeline began as a problem we hit inside a real engagement. It is the only origin story we trust, because it comes with a customer already attached.

06.2

Status is published, always

Research, prototype, private beta, shipped. Nothing appears on the products page before it exists, and the labels are reviewed every quarter. This costs us the credibility a fuller roadmap would buy from people who do not read closely, and we accept that.

06.3

Ten users who need it

We would rather build with a handful of organisations who will tell us the truth than for a market we have imagined.

06.4

Depth before adjacency

A product gets to be excellent at one thing before it is allowed to be adequate at five.

07Open source

What we publish, what we do not, and why the line sits where it does.

07.1

Methods out, implementations in

Evaluation harnesses, benchmark definitions, annotation protocols and findings are published. The specific product implementations we intend to commercialise are not. We will describe how something works before we hand over the thing itself.

07.2

Permissive by default

Code under Apache-2.0, data and benchmarks under Creative Commons. The durable advantage is knowing how to apply the thing, not controlling who may read it.

07.3

Maintained or archived, never abandoned

A repository with no commits for a year and eleven open issues damages us more than no repository would. Anything we stop maintaining gets archived with a note saying so.

08Long-term thinking

What the phrase actually commits us to, rather than what it usually decorates.

08.1

Decisions get a decade horizon

We ask what a choice looks like in 2036, not next quarter. That rules out a great deal, shortcuts in data handling, revenue that compromises the research, commitments we cannot keep at ten times the size.

08.2

Growth that we own

The company is funded by the work it does. That is slower than the alternative and it means nobody else sets the clock, chooses the direction, or decides when we have run out of time.

08.3

Compounding over spikes

Open source, published research and durable client relationships all pay back slowly and then all at once. We optimise for the assets that are worth more every year rather than the tactics that work once.

08.4

Say the true thing

About what is shipped, about what we do not know, about whether we are the right people for a piece of work. Reputations are built at the speed of the slowest honest answer, and they are the only asset here that cannot be rebuilt.

If any of this sounds like how you work

We would rather hear from people who read this page and recognised something than from people who read the services list.

Work with us