BL-IS-000: The Instrument Catalog

Status: RELEASED

Classification: PUBLIC

Revision: 1

Date: 2026-09-07

1. What an instrument is here

An instrument is a piece of software whose only job is to measure one thing and emit a machine-readable artifact. It does not trade, it does not decide, and it does not carry an opinion about what the result should be.

The programme built 105 of them across 20,647 lines. They are the most transferable asset in this record, because a method is only reproducible to the extent that the thing which measured it can be reproduced.

2. The construction rule that makes them trustworthy

Every research script is glue. The logic lives in a separate module with tests written before the measurement runs.

That separation exists for one reason. A sign error inside a research script is invisible: the script runs, produces a number, and the number is plausible. Moving the logic into a module and leaving the script to load data and print results makes the sign a thing a test asserts rather than a thing a reviewer squints at.

R-28 states the rule and R-25 states its consequence: a verdict is valid only when it comes from an in-repository instrument with tests attached.

R-25 was written after an acceptance script that lived outside the repository, had no tests, reported a coverage figure of zero percent that was false, and then was lost entirely. Nothing about that measurement could be reconstructed or checked afterwards.

3. The catalog

3.1 Inference

3.2 Simulation and cost

3.3 Characterisation

These compute no returns at all, which is deliberate. A characterisation instrument that can produce a profit figure will eventually be asked to.

3.4 Audit

BL-IS-016 is the one most programmes do not build. It re-runs a prior measurement and compares the output against the published figure. The anchor audit in BL-IN-006 used it as its first step, reproducing a prior gate result to the basis point on all four reported quantities before that gate was re-examined.

An audit instrument that cannot first reproduce what it is auditing has no standing to disagree with it.

4. Two instruments that failed

Both are published, because the pair is the evidence that the retraction happened.

An execution cost instrument that double-counted adverse selection. It subtracted the markout and also subtracted a spread term that already contained it. The instrument found the error itself and marked its own output superseded. Artifacts E-0013 and E-0014 are the original and the replacement, and both remain in the register.

An acceptance script that reported a false result and was lost. No artifact survives, which is itself the finding. It is recorded in the provenance section of BL-A-001 alongside five other artifacts whose producing instrument did not survive into the repository.

R-26 requires that an instrument found to be wrong retracts its own output and is retained alongside its replacement, rather than being quietly deleted.

5. Envelope parameters are inputs

Every cost-bearing instrument takes its envelope parameters as arguments rather than holding them as constants.

cost_model(fee_schedule, channel, slippage_assumption, funding_series)

This is a requirement rather than a convenience, and R-27 states it. A reader substituting their own fee tier must be able to re-run any cost-bound verdict in this record without editing logic, and a constant buried in a function makes that impossible to do safely.

The verdicts in BL-EC-001 section 7 are only usable because of this property.

6. What publishing the implementations found

The reference implementations under 05_INSTRUMENTS/src/ were produced as a translation and verification pass: preserve the logic exactly, translate the commentary, package it for a reader.

The pass has found five defects the instruments had carried through the programme unnoticed. The pattern in what it found is more interesting than any of them individually.

None was found by using the instruments. All five were found by writing down what an instrument was supposed to do, next to what it did.

That is worth stating plainly because it is an argument for publication as a quality mechanism rather than as a communication exercise. A specification and an implementation that never meet cannot disagree. Putting them side by side is what makes a disagreement visible, and most of these had survived every prior review precisely because nobody had been required to state the intended behaviour in a form the code could contradict.

The first is the one to take seriously. It moved a number in the published record, and it moved it against us: what had been reported as no phase being significantly positive is, corrected, seven of twenty-four phases significantly negative. BL-IS-004 section 8 carries it.

The fourth is the one that changed how the remaining passes are run. It is the second defect, not a second instrument: the identical guard, misplaced the identical way, in the other simulation path of the file that had already been corrected once. A guard sitting ahead of a branch it does not belong to travels with the loop it lives in, so it is copied wherever that loop is copied. Finding one is a reason to read every other loop in the same file, and the item is not closed until that has been done. Correcting one path and closing the ticket is what left the second one standing for a month.

The fifth is included even though it changes nothing, because a published record should not emit a silent NaN out of its own arithmetic and because the next caller of that function may not have a range test behind it.

A sixth finding is a different kind and is recorded separately, in BL-SD-000 section 7.4. Nine pinned cases from two source suites were absent from their published counterparts, with nothing recorded about the omission. All nine are restored and all nine pass unchanged, so no implementation was wrong. What was missing was the evidence that they were right.

That is not a defect in the code and it is not nothing either. The porting standard requires a dropped case to be named and justified, precisely because a case that is quietly absent cannot be told apart from a case that never existed. Two of the nine had no equivalent anywhere in their file: a portfolio return with a negative short-leg mean, in a file where every other such case used two positive legs, and a bracket stop gapping through its level and having to fill worse while still paying slippage.

A seventh finding is of the same kind again, in the other direction. The fragility conditioning layer's rank-weight construction was described in its source as bounding the weight range between the best and worst name in a leg at two to one. It bounds it at three to one, exactly, at every leg size. Nothing in the arithmetic changed and no measurement moves. The description was wrong in the direction that matters, because a leg weighted three to one is more concentrated than a two-to-one description implies, and the only reason to state that bound is to say how much concentration the weighting permits. It surfaced because a test was written to assert the documented bound and failed. BL-SD-045 section 11 carries it.

That is the argument for publication as a quality mechanism, made once more and more cheaply than the others. Nobody re-derived the construction. A test was written from the prose, and the prose turned out not to describe the code.

An eighth finding arrived the same way and closed a guard rather than a claim. The oracle-premium instrument's gap segmentation accepted any timestamp series and cast it to floating point. A test built its nanosecond timestamps by multiplying an index array, which on this platform defaults to a 32-bit integer, and an epoch in nanoseconds does not fit in one. The wrapped array came back as a single contiguous segment and looked entirely ordinary to the gap test. The published function now rejects a series that is not non-decreasing, which covers that case and the more obvious one of input that was never sorted.

A ninth is of the same shape as the fifth. The settlement-flow screen's empty-control path built a one-element array holding infinity and took its 95th percentile, which numpy answers with NaN and a warning rather than with infinity. The leg failed either way, since a median compared against NaN is False, but the null was reported as a missing value rather than as an unbounded one, and those say different things about why a leg failed. Both legs in BL-SD-021 had controls, so nothing moves.

The pattern in the last four findings is worth naming. None of them was found by reasoning about the code. Each was found by writing a test that asserted what the documentation said, or by building an input a careful caller might build, and watching what happened. That is a cheaper discovery mechanism than review, and it only exists once an implementation and a written specification are in the same place.

Three smaller guards were added in the same pass and are noted in the CHANGES block of the module that carries each: a non-finite weight now raises rather than folding silently into a turnover figure, a non-positive entry price now raises rather than producing a meaningless stop level, and a negative slippage argument now raises rather than quietly crediting the strategy with the adversity it is supposed to be charged.

7. Test posture, stated honestly

The alpha research core is densely tested. Test counts grew from 506 to 694 across the second programme, and each new instrument arrived with its tests written first.

The surrounding system is not. Roughly 57 percent of the operational Python modules carry no test coverage, including parts of the live execution path, and there is no continuous integration configuration in the repository, so tests run when somebody runs them.

Two test files in the repository import a module that was deleted and will fail at collection.

That asymmetry is deliberate in one direction and not in the other. Testing the research core first was correct, because a wrong number there produces a wrong verdict. Leaving the operational path untested is a debt rather than a decision, and it is recorded here rather than left for a reader to discover.

8. What is published

All sixteen instruments carry a specification, BL-IS-001 through BL-IS-016. No identifier is cited anywhere in this record without a document behind it.

Three things are published, and they are not the same thing.

Specifications, for all sixteen. What the instrument measures, the assumptions it rests on, its failure modes, and what it does not do. The last of those is usually the most useful section.

Reference implementations, for seven, under 05_INSTRUMENTS/src/ with 172 tests. These are the inference, simulation and cost instruments: the ones a reader would need to re-run a verdict in this record against their own envelope. The characterisation and audit instruments are specified but not published as code, because their value to an outside reader is the method rather than the implementation, and each is a short program against a substrate the reader does not have.

Strategy decision cores, thirty-four modules under 05_INSTRUMENTS/strategies/ with 760 tests, covering forty-four dossiers and the maker engine, eleven dossiers in part. BL-IS-017 says which eleven and which half of each. Every closed family in the Kill Ledger now cites running code, and so does the engine the first programme built to trade them. These are not instruments and are catalogued separately in BL-IS-017, which also carries the order in which the remaining families arrive. An instrument measures something; a strategy core decides something. Keeping them in separate trees keeps that distinction visible to a reader who only wants one of the two.

The production regime gate is withheld entirely under the classification policy in BL-FM-004 section 4.

One gap is worth naming rather than leaving to discovery. BL-IS-016, verdict reproduction, exists in the source only as an inline first step inside the anchor audit rather than as a reusable module. Its specification therefore gives the pattern as pseudocode instead of a function signature the source does not have. That is the most reusable idea in the catalog and the least reusable code in it.

Rewriting was a correctness exercise rather than a cosmetic one. Section 6 records what it found. Re-verification confirms that an implementation matches the documented research; it is explicitly not a re-test of whether any strategy is profitable.

Copyright (c) 2026 Bijective Labs. All rights reserved.