Skip to content
#edge computing Open access

MESIN INTI — Market Data Engine with Gates That Can Say No

Sep 2026 · Zenodo (CERN European Organization for Nuclear Research)

Abstract

NO-ORDER. This is data-engineering and verification discipline. It is not a signal service, not investment advice, and makes no claim about returns. The engine described has never sent an order and is not built to send one. What this record contains A market-data pipeline built so that every stage carries a guard, and every guard can refuse. This deposit publishes the discipline around the pipeline — the gate definitions, the exit-code contract, the published data contract, and a dated record of the author’s own guards being deliberately broken to prove they can fail. The tuned values (thresholds, weights, calibration constants, the frozen reference library) are private by design and appear nowhere in this deposit. The measurement that cost something On 26 August 2026 a sabotage campaign was run against the author’s own guards: twenty deliberate single-point code changes at load-bearing places — threshold comparisons, fences, secret boundaries, hash-chain links — each applied to a copy, then reverted, with the first guard to raise an alarm recorded. Result: 17 of 20 caught (85%). Three survived. All three survivors are published with their specimen fingerprints, not deleted. Two sentences written in the original report at the time are kept unchanged in the published version, and both of them lower the number: “Mutant 14 is an equivalent mutant — counted as survived as it is, not discarded to make the score look better.” “The 20 mutants were chosen by hand at meaningful points, not at random; this score is therefore not a full mutation score.” Scope, stated plainly: this campaign was run on AB APPS, a sibling system built under the same discipline, not on the engine in this record. The same campaign on this engine is declared work, not completed work. No number is claimed that was not measured. Six gates, each with a defined failure condition G1 · CAUSAL — only settled periods are used; entry at t+1, never t. Turns red when a value that exists only in the future appears in a present-time calculation. G2 · ZONE — predictors and outcome-forensics are separated at birth and their intersection is asserted empty. Turns red when a feature is found to derive from the label it predicts. G3 · FROZEN — cut-offs are established in-sample, then frozen and fingerprinted. Turns red when a parameter was tuned after out-of-sample results were seen. G4 · JUDGE — purged cross-validation with embargo, executed by a judge structurally separate from the engine, including a label-shuffle test. Turns red when the model still wins after the labels are shuffled. G5 · COST — slippage, fees, fill feasibility. Turns red when the edge does not survive realistic costs. G6 · REPEAT — two runs with a fixed seed must produce byte-identical fingerprints. Turns red when they do not. A gate that cannot turn red is decoration. Every gate above has a stated way to fail. Exit-code contract 0 = PASS · 1 = RED, with the number reported · 2 = CANNOT CHECK, with a statement of exactly what is needed in order to check. Code 2 is not code 0. A check that could not run has not passed. Reporting “unknown” as “safe” is the most common quiet failure in data work, and this contract exists to make it impossible here. What a reader can verify without asking the author Run python verify_manifest.py. Every published file is fingerprinted in manifest.sha256; the script re-computes the fingerprints and reports any file that differs or is missing. Run python make_synthetic.py twice and compare the two SHA-256 hashes. They must match — that is gate G6 demonstrated rather than asserted. Load the published synthetic dataset and assert that no quarantined outcome column is present — that is gate G2, checkable in one line. Read the survivor section of the sabotage report, which names the blind spots the author did not catch. What is deliberately not here No pipeline source code. No thresholds, weights, or calibration constants. No historical performance figures, win rates, or backtest results. No live or historical market data. The published data contract carries 17 feature columns; the pipeline measures 24. The difference is withheld on purpose and is not an omission. On “lab-grade” The author works in a hospital laboratory that undergoes accreditation, and rebuilt those techniques — documented methods, validation before use, provenance, specimen rejection criteria, calibration records — as code. This software is not accredited and not certified. No accreditation body has assessed it, and none of the standards referenced in this record has been awarded to it. “Lab-grade” describes how the work is built. It is not a credential the work holds. Standards this work is structured against FAIR (Wilkinson et al. 2016) and FAIR for Research Software (Barker et al. 2022); the Software Citation Principles (Smith, Katz & Niemeyer 2016); and the criteria ACM defines for Artifacts Evaluated — Functional (ACM v1.1, 2020): documented, consistent, complete, exercisable. No badge has been awarded by any of these bodies. The structure follows the published criteria; the assessment has not been sought.

View source

Similar papers

#computer vision Review Sep 2017

Agile Software Development Methods: Review and Analysis

This publication proposes a definition and a classification of agile software development approaches and analyses ten software development methods that can be characterized as being "agile" against the defined criterion.

P. Abrahamsson, O. Salo, Jussi Ronkainen et al. · 727 citations · ⚡54
#computer vision Jun 2008

The impact of agile practices on communication in software development

The study shows that agile practices improve both informal and formal communication, but indicates that, in larger development situations involving multiple external stakeholders, a mismatch of adequate communication mechanisms can sometimes even hinder the communication.

M. Pikkarainen, Jukka Haikara, O. Salo et al. · 401 citations · ⚡48
#machine learning Review Open access Oct 2014

Software development in startup companies: A systematic mapping study

The results indicate that software engineering work practices are chosen opportunistically, adapted and configured to provide value under the constrains imposed by the startup context.

Nicolò Paternoster, Carmine Giardino, M. Unterkalmsteiner et al. · 394 citations · ⚡54

Related blog posts

Microsoft Research Blog Oct 29, 2026

Microsoft Research Focus – Edition #97

Host Sowbhagya Suresh shares some of the latest news and cutting-edge research from across Microsoft—from understanding the challenges facing coding agents to uncovering how people use AI at work and improving extended-range weather forecasting. The post Microsoft Research Focus – Edition #97 appeared first on Microsoft Research.

MIT News · Artificial Intelligence Oct 28, 2026

Making machines that can listen

Professor Paris Smaragdis develops computers with superhuman hearing for applications like speech recognition, music understanding, and environmental monitoring.

Microsoft Research Blog Oct 21, 2026

Solving a 31-year-old grand challenge in mathematics – the KLS conjecture

For decades, a fundamental question about the difficulty of computing in high-dimensional spaces has resisted proof. New research resolves this question, removing a major theoretical obstacle to understanding the efficiency of randomized algorithms used across science and computing. The Kannan–Lovász–Simonovits (KLS) conjecture was proposed in 1995. It asks whether, for a broad class of high-dimensional […] The post Solving a 31-year-old grand challenge in mathematics – the KLS conjecture appear…

We use cookies to run the site and, with your consent, for analytics and to show ads. See our Cookie Policy.