Products

An instrument, not a product line.

ProServiq is the practice. A product is where the method is embodied — built in a domain where the answer matters and nothing independent checks it. There are three, and each is here because a domain earned it rather than 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 an instrument. The fourth is the one that disqualifies most software ideas.

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

The reference instrument for Indian statutory income tax.

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: Indian statutory income tax
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 an argument that the method survives a real domain.

Three domains done once is a stronger claim than one domain done three times — which is why the register, and not this hall, is where the evidence lives. An instrument here is a place the method was worth embodying permanently. It is not the business.

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.