Independent researcher. I check claims and publish what the check found. Sometimes the answer is "not confirmed", and I publish that too. No institution, no degrees, no token.

Two projects, one method. VecDHT is a network; FlowGuard is a control boundary. Both run the same lab protocol — a hypothesis, a threshold fixed before the run, one decision per result — and since October 2026 they exchange dated notes against a shared method kit: formats and guards in common, code and threat models private to each.

1. Take a claim that matters (a payout, a contract invariant, a statement in a paper).
2. Check it against the primary source: a transaction hash, deployed bytecode, or a pinned commit.
3. Write down the result, the exact commands to reproduce it, and what the check does not prove.

An open lab bench for work with neural cellular automata: code, protocols, run manifests, reports and a machine-readable experiment registry, so a run can be repeated later by someone else. mak777uh/-

The bench does not publish conclusions here. What it publishes is the apparatus: each number carries the measurement id, the command that produced it and a link to the log, and the manuscript is a separate, citable artifact: 10.5281/zenodo.23648667. Counts are generated by a script, not typed by hand.

My first paper — Four conditions for a self-maintaining organisation in a digital medium — asks when a collective of digital cells becomes a unit of selection.

My second paper — A field without stipulated objects — asks what happens when the medium has no cells at all: organisation arises and selection acts, but the "number of bodies" turns out to measure the fragmentation of one cluster rather than a count of individuals.

A Rust research prototype and specification for a neutral peer-to-peer layer for decentralised semantic search. Nodes publish signed "intents" as embeddings; the network uses VHash to spread semantically close data across shards and VecDHT routing to find it again without a central catalogue. Local ANN search, the wire protocol and admission policies are modular and replaceable. vec-dht repo

Its lab is the older instrument: 114 experiment cards with pre-registered thresholds, a source index where every entry carries a pin to a commit and a statement of what it gave, and a status document written to be falsified. That machinery is where the shared kit comes from — FlowGuard took the card format, the metrics rule and the status discipline from here.

Deliberately out of scope: no blockchain, no escrow, no proof of useful work, no incentive economics. All of that is meant to be built on top by anyone who wants to. What is planned instead: a live test network, routing, local search and admission taken to production level, a verifier image with verifiable receipts, an escrow contract and payment layer for paid orders, and incentive design for verifiers and workers, so that the repository grows from a partially implemented core plus a specification into a working network with automatic payouts.

A service that does not claim a system is secure. For one declared value flow — money, personal data, access to a store — it establishes that nothing moves past the single control point, and issues a statement a third party can verify offline without trusting the issuer. The guarantee covers a declared closure and names what falls outside it. Where the closure cannot be enumerated, the honest verdict is "inconclusive", not a badge. flowguard-spec

Status: specification and six rounds of external review, no code yet. Every claim carries an evidence type, and three words are reserved for machine-checked statements; a claim may never be worded more strongly than its evidence allows. Deliberately out of scope: bridges, oracles, MEV, and any promise of finding all vulnerabilities.

The two repositories read each other through interop/ — dated notes pinned to commits, not a shared dependency. Neither can be built from the other, and neither is asked to change for the other. Where the first produces evidence (experiments, metrics, status), the second disciplines the sentence about it (evidence types, eliminations, guards); a checker reports which half is which.

Every case links to something you can open yourself. Three examples:

• Payouts: three FLAPJAX transfers, each with a tx hash and a block number. Read the receipt, compare the recipient and amount. Nothing else is needed.
• Code: a pull request against a real project, 3 files, +365/−8, with 11 tests. Read the diff.
• Claims: an issue thread where I compared a paper's sentence with its Lean formalisation and concluded they differ. The maintainer agreed the distinction is real. Verdict: not confirmed.
• Science: pick any run in the bench, follow its manifest, re-execute the command. The claim is only "this is what the machine produced under these settings", never "this is true about biology".

No claims about life, consciousness or intelligence. No peer-reviewed publication yet. No financial product, no fund, no advice.

На русском, коротко: проверяю чужие утверждения (выплаты, контракты, формулировки в статьях), пишу что получилось и как это перепроверить. Работа лежит в mak777uh/cases, по одной папке на направление. Отдельно веду научную работу по морфогенезу в нейроклеточных автоматах: стенд, протоколы и отчёты лежат в mak777uh/-, рукопись — отдельный файл с DOI. Отдельно строю FlowGuard: сервис, который доказывает не «система безопасна», а что мимо единственной точки контроля нельзя пройти, и честно перечисляет, что осталось вне границы. Пока это спецификация и шесть кругов внешнего ревью, кода нет.

Два проекта — VecDHT и FlowGuard — с октября 2026 переписываются заметками в папке interop/: с пином на коммит, без общей зависимости и без правок друг другу. Общий у них только метод: формат карточки эксперимента, правило «у числа есть команда», типизированные утверждения и стражи. Код, модели угроз и инварианты у каждого свои — так и задумано.

Где не смог разобраться, так и написано.