Products

An instrument, not a product line.

Each product is software we built for a problem where the answer matters — with its own second instrument checking it, the way we build for clients. There are three, and each is here because its domain met the four conditions below, not because a roadmap reached it.

Plate 1 · five domains through the gate, two built

What has to be true before we build one

All four, or the domain does not get a product. The same four decide whether we take on client work — see Services.

The answer matters

Someone acts on it, and being wrong is expensive.

Nothing independent checks it

The incumbent is a single engine marking its own work.

A different second computation is possible

There is a genuinely other way to reach the answer — not a re-run of the same one.

The failure is silent

The characteristic error produces a plausible answer rather than a crash.

The anatomy

Every instrument has the same six parts.

Only one of them changes between domains. That is the whole claim, and it is the difference between a practice and a portfolio.

Facts: A model of the domain that knows no rules at all — quantities, dates, identities, relationships. It is deliberately ignorant of what will be computed from it, which is what lets one fact model outlive several rule sets.
Rules: Data, not code. Compiled into a ruleset and digested to a hash, so a result can be replayed years later under the rules it was actually computed under rather than today’s.
Engine: Applies the rules to the facts. It is the part everybody builds, and on its own it is the part nobody should believe.
Checker: Answers the same question by a different route, written from the specification rather than from the engine. It shares no code with the thing it checks, and it is built to be able to disagree.
Comparison: Figure by figure, never in aggregate. Two totals can agree while their parts disagree in opposite directions, and a comparison that only checks the bottom line has a blind spot the size of its own arithmetic.
Record: The answer, pinned to the rules, the engine version and the inputs that produced it — appended, never overwritten, so a correction is a new record rather than a rewritten one.

The rules are the only part that is jurisdiction-shaped. The checker is the only part that is expensive — because a second independent implementation of the same specification is exactly as much work as the first, and there is no honest way to make it cheaper.

Plate 2 · the same six parts, in any domain

Built

CLAVIS

Two independent engines for statutory income tax. The statute it implements is India's; the method is not.

CLAVIS computes a return under the Income-tax Act, then computes it again with a separately written engine that shares no code with the first. Where the two disagree, it says so. Where it cannot establish a figure, it says that too, rather than reporting a confident zero.

Domain: Statutory income tax (India)
Status: Live
Conditions met: 4 / 4
In the register: 4 checks

NEXIO

An agent proposes. A deterministic layer refuses to take its word for it.

Nexio finds people worth contacting, and the useful half is what happens after the model has spoken. A language model proposes an address from a pattern; it has no way to know whether that address exists, and it is not built to care. A separate layer then checks the proposal against things that cannot be reasoned into being true — DNS and MX records, the mail provider’s own fingerprint, published sender policy, and whether the domain accepts every address put to it.

Domain: Agent output, checked against the world
Status: Live
Conditions met: 4 / 4
In the register: 0 checks

CIPHER

A measure that reports a relationship in pure noise — and the correction that stops it.

Transfer entropy is asymmetric: unlike correlation it can distinguish which of two series carries information about the other. It is also POSITIVELY BIASED — a histogram entropy estimator finds finite-sample patterns in noise, so unrelated series return a non-zero value. Most of the engineering here is the correction rather than the measurement, and most of the architecture record is a list of approaches that were built, examined and rejected.

Domain: Causal measurement over high-frequency time series
Status: In build
Conditions met: 4 / 4
In the register: 1 checks

The boundary

A product is the method, proven in a real domain.

Three domains done once is a stronger claim than one domain done three times. The products show the method surviving real data; the register is where every check behind them is published — including the ones that went against us.

Read the register →

What an instrument is not

It is not a licence to build in a domain we have not checked. Every one of these began as a question somebody could not answer, and the ones that never became products failed a condition rather than a business case — usually the third, because most domains have no genuinely different second route to the same answer.