BL-IN-000: The Incident Register

BIJECTIVE LABS

BIJECTIVE LABS . SEP 7, 2026

BL-IN-000: The Incident Register

Status: RELEASED

Classification: PUBLIC

Revision: 1

Date: 2026-09-07

1. Why this volume exists

Every rule in BL-D-009 was written after something went wrong. This volume is where the something is recorded.

A research organisation that publishes only its method presents a tidier account than the one it lived. The method reads as though it were designed, when in practice each clause was added in response to a specific failure that had already cost something. Publishing the failures is what makes the method credible, and it is the part an outside reader cannot obtain except by making the same mistakes.

None of these incidents cost capital. All of them cost time, and several produced verdicts that were wrong until they were caught.

2. The six case studies

ID	Incident	Class	What it produced
`BL-IN-001`	The impossible win rate	Cost arithmetic never performed	Layer 0 of the falsification chain
`BL-IN-002`	Gross, not net	K1, absent cost term	R-01, the first rule in the register
`BL-IN-003`	The look-ahead beta	K5, point-in-time violation	The walk-forward harness, made mandatory
`BL-IN-004`	The contaminated universe	K4, sample concentration	R-19, and the universe registry
`BL-IN-005`	The dead feed	K2, verified once	R-18, and subscribe-failure logging
`BL-IN-006`	The hour we never controlled	K5, selection without a selector	R-09, and an automated robustness instrument

Read in order they form a progression. The first two are about not doing the arithmetic. The middle two are about doing the arithmetic on the wrong numbers. The last two are about the measurement apparatus lying to you in ways no arithmetic detects.

3. The failure classes

Eleven catalogued incidents across the first programme resolve into six root causes. The classes matter more than the individual incidents because they predict where the next one comes from.

Class	Failure	Case study
K1	Missing value defaulted to zero, where zero is meaningful	`BL-IN-002`
K2	Verified once, assumed verified forever	`BL-IN-005`
K3	Safety filter depending on a single field that can be absent
K4	Sample concentration unchecked	`BL-IN-004`
K5	Point-in-time violation	`BL-IN-003`, `BL-IN-006`
K6	Unbounded resource or accounting growth

Two classes have no case study in this volume and both are documented in BL-D-006 section 2.

K3 appeared when an intermittently empty instrument-type field allowed non-crypto instruments into a live universe. The remedy was a hardcoded denylist behind the automated filter, on the principle that a safety filter should not have a single point of failure upstream of it.

K6 appeared as an unbounded event list that exhausted memory and took a production machine down for roughly 38 hours. The remedy was bounded sinks with retention policies, and raw data moved to a durable store rather than held in cache.

4. The pattern across all six

Four properties recur, and they are more useful than any individual incident.

The system reported itself healthy in five of six cases. Containers were up, loops were running, connections showed as connected, and error counts were zero. Liveness and correctness are unrelated properties, and monitoring the first tells you nothing about the second.

The error was uniform rather than random in four of six. A systematic measurement error does not present as noise. It presents as a coherent world in which everything is slightly disappointing, and it preserves the relative ordering between strategies while being wrong about all of them.

In four of six, the trigger came from outside the work. A question about whether the code rather than the strategy was at fault. A demand to verify sample cleanliness before trusting a verdict. A recorder that had written no files. A discrepancy noticed while building something unrelated. In only two cases did the team investigating a hypothesis find the defect in their own instrument.

Every remedy was code, not vigilance. A denylist, a walk-forward harness, a bounded sink, an error log, a robustness function that raises when given a single phase. Rules that depend on someone remembering are rules with a decay rate.

5. One failure class, three directions

Three of the failures in this record are the same thing wearing different clothes, and the programme did not notice that until all three were written down next to each other.

In each case a sample was selected toward a conclusion by a mechanism nobody had recognised as a selector.

Toward a positive conclusion. A universe filter ranked instruments on how much they moved. It therefore preferred low-grade listings that move for reasons unrelated to any tradeable mechanism, and 87 percent of a 39,250-event sample came from one of them. The verdict was retracted. BL-IN-004.

Toward a negative conclusion. A spread census was computed on seven instruments drawn from a lake captured per liquidation event. Only instruments active enough to trigger a liquidation ever entered that lake, which filters precisely toward the most liquid names, which are the names with the narrowest spreads. The census returned a median of 1.31 basis points and an economic door was closed on it. Re-measured across all 676 instruments, the median is 5.26.

The source records the lesson in one sentence, and it is better than any paraphrase: the sample was not small; it was selected toward the conclusion.

Toward no conclusion in particular. A rebalance hour was inherited from an era boundary and used across nineteen pre-registrations without ever being recognised as a choice. The phase actually used ranked third most favourable of twenty-four. BL-IN-006.

What makes the class dangerous is that none of the three looks like a sampling problem from inside.

The first had a large n. The second had a clean instrument and a defensible question. The third had a locked pre-registration and a phase nobody had selected. In every case the number of observations was adequate or the process was correct, and the sample was still pointing at an answer before the measurement began.

Sample size is the wrong diagnostic here, and reaching for it is what let two of these survive review. The right question is narrower and harder: what determined which observations exist? A filter that ranks on movement, a recorder that fires on events, an era boundary that sets a clock. None of those is a sampling decision on its face, and all three are.

R-19 catches the first by requiring decomposition before any verdict. BL-IS-004 catches the third by enumerating the phase space automatically. The second is caught by neither, and the only defence the programme found against it is the one that eventually worked: ask where the sample came from, before asking whether it is large enough.

6. Retractions

Three published results in this record were withdrawn or revised after review. All three remain in place with the correction attached.

What was published	What replaced it
A dislocation strategy `REJECTED` on 39,250 events	Inconclusive; 87 percent of the sample was one instrument
A branch closed on unconditional statistics	Closure withdrawn, then re-established from four independent directions
Momentum at +14.11 bps per week, t=2.49, +7.3 pct annualised	Median +8.72 bps, t approximately 1.4, roughly +4.5 pct annualised

An instrument also retracted its own output. An execution cost measurement was found to double-count adverse selection, marked itself superseded, and was replaced. Both artifacts are published as E-0013 and E-0014, because the pair is the evidence that the retraction happened.

7. What this volume does not contain

Incidents that cost capital, because there were none. No strategy in this programme reached live deployment, and the single live venue touch produced zero fills.

Incidents from the operational side of the system that did not affect a research conclusion. Deployments, migrations, and container failures are in Volume VIII where they belong.

Any incident discovered after 2026-08-03. The register closes with the archive.