For software and equipment vendors
A vendor usually reaches us with a capability their product is missing or a computation that has become the expensive part of running it. Geometric solvers and optimisation engines have been bought this way for decades. And it is a duller transaction than a consulting engagement: you get a component with a contract, and it either passes the acceptance test on your workload or you have paid only for finding out.
The boundary
The word gets used loosely. This is the list we write down before anything is integrated, because every item on it is something a vendor eventually needs and would rather not discover in production.
Written down, with the shapes and the ranges. A component whose contract lives in someone’s head is not a component.
Where it sits in your product, what it calls, what calls it, and what it needs from the environment around it.
What it does when the input is malformed, the workload is larger than expected, or the answer would take too long, all specified before integration.
How you turn it off. Any component we ship can be removed from the path without taking your product down with it.
What it reports about itself, so your operations team can see it working instead of inferring it from complaints.
The test it has to pass on your workload. Agreed before the work starts, so neither of us is arguing about success afterwards.
Before you talk to us
Everything above is a claim about how we draw a boundary, and a page is a poor place to take that on faith. So here are three you can check without speaking to anybody: one you can read, one you can verify, and one you can run on your own numbers. We license none of them. They are the same hands and the same discipline as the components we do license, published where you can read them before any money moves.
Read it · MIT
Our operations-research library, published whole: 251 functions across 30 namespaces, zero dependencies. If you want to see what we mean by an input, an output and a stated range, open a namespace and look. And the solvers behind our browser calculators are the same family of code.
github.com/Flexiana/orhofVerify it · EPL-2.0 or GPL-2.0+
A dependent-type theorem prover in Clojure with a ~1,200-line trusted kernel, against which 222 of 222 catalogued operations-research algorithms now carry a machine-checked proof. Where testing a component is not enough, this is the shape of the alternative and the size of its cost.
How the proof worksRun it · in your browser
Two of them solve their problem exactly by enumeration, so what comes back is the optimum and no ranking heuristic stands in for it. What you type stays in your browser. It is the smallest honest demonstration we can offer a vendor: your figures, our arithmetic, no account and no call.
Run one on your numbersThese three do not show a component built for your workload. The validation stage below buys you that. But they do show the standard we hold to when nobody has paid us yet, and a vendor is buying that standard as much as the code.
How it is bought
Three stages, and either of the first two can be the last. You sign for an integration only after it has been tested on your own workload, and you know the price of each stage before it starts.
One
Bounded, priced up front, and run against your workload. The benchmark is yours. It answers whether the improvement holds at your scale, and no is one of the answers.
Two
The component, the integration, the acceptance test and the rollback path. Scope agreed in advance with a named owner for every piece of work that is not ours.
Three
Maintenance, versioning and support, priced against what the component is worth to your product. The hours it took us do not come into it.
The arithmetic
When a component goes inside your product, three different numbers get confused with each other: what your end customer saves, what you can capture of that through price or retention or lower delivery cost, and what you pay us. They are rarely close. So a proposal that treats them as one number is a proposal that has not been thought through.
We work them separately and show you all three. The same discipline rules out fee structures that cannot survive their own arithmetic — a gainshare taking fifteen percent of the benefit caps the return at under seven to one before anyone counts integration, which is the reason we do not propose one.
What we decline
Where a component needs commissioning across sites, the equipment knowledge and the site access belong to you or to a partner you already have. We will not quote for both and discover the second half later.
If nobody on your side is named for it, the honest description is not "minimal integration", it is an unowned risk, and we would rather say so before the contract than after it.
A function running faster is not money. We ask how the improvement becomes removable capacity or avoided spending, and if that chain does not close, there is nothing here worth buying.
If an existing library or a simpler process change gets you most of the way, that is the answer, and it is a short conversation instead of a proposal.
FAQ
An engine, library, API, plug-in or deployable service, with its inputs and outputs written down, the integration points named, and stated behaviour when it fails. Plus the acceptance test it has to pass on your workload before you owe anything beyond the validation fee.
No. Deployment inside your own environment is a supported architecture, and for most vendors it is the sensible one. Remote delivery describes where we sit, and your data stays where you put it.
You get the failure behaviour and the fallback path in writing before you integrate anything, because a component that has never been specified under failure is one you cannot put in front of your own customers.
Sometimes you should build it, and the audit says so when it is. The case for licensing is when the method is a year of specialist work that is not your product, and the case against is when it is close enough to your core that you want the capability in-house. That is a reasonable conversation to have before either of us spends money.
Named before we start. Usually your engineers with us alongside, sometimes us, occasionally a partner you already work with. What we will not do is leave it unowned and call it minimal.
Paid validation on your own workload, then bounded implementation, then a recurring licence. The number depends on the workload and what the improvement is worth to you, so it is set after validation and never guessed before it.
Yes, and we would rather you did. orhof, our operations-research library, is published whole under MIT. Rainbow, our theorem prover, is open source under Clojure’s own dual licence, and four calculators on this site run the same class of solver in your browser on figures you type. We license none of the three, so what they show you is the standard: the way a boundary gets written down, and what we do when the honest answer is a proof. A vendor who has read a namespace of orhof knows more about working with us than any reference call would tell them.
For vendors
The inputs, the workload, and what it has to beat. The answer is one of three: there is a method worth licensing, you should build it yourselves, or what you already use is good enough.
