# SKYNET800 (alfa) Killing AI hallucinations with resonance > Source: > Published: 2026-07-11 04:24:05+00:00 Hmm… For now, after reading through the code and trying to organize what I found, I think it looks something like this: I may be interpreting some parts differently from how you intend them, but I currently see **four connected tracks inside one project**: | Track | What appears to exist publicly now | A natural way to expose it | |---|---|---| SKYNET-800 application | A Windows/Python application for BTC/USDT data, ClickHouse storage, DCM calculations, calibration, news processing, charts, and visualization | Runnable application, screenshots, short architecture map | DCM / resonance forecasting method | Dog, Cat, Manul, limbs, Mirror, shifted points, and related deterministic time/price calculations | One worked example, frozen predictions, evaluation dataset | Code Factory | A detailed multi-agent design in `LEGEND.md` | Those tracks may be parts of one unified NeoDal model, but they lead to **different questions, audiences, demonstrations, and evaluation methods**. The public repository currently gives the clearest access to the **application and DCM implementation**. I found a detailed design for Code Factory in the legend, but I did not yet identify the full public implementation of the agent pool, shared task system, or Trust Graph. That may simply mean that this part is planned, partial, experimental, or located elsewhere. A small status map near the beginning of the README could make the whole project much easier to enter without removing any of the larger ideas: | Component | Possible status label | |---|---| | Desktop forecasting application | Implemented alpha | | DCM calculations | Implemented and evolving | | ClickHouse migration | In progress | | Code Factory | Planned / experimental / partially implemented | | Trust Graph and persistent agent state | Planned / experimental | | Physical-resonance interpretation | Conceptual or separate research hypothesis | | RNG/seed-recovery application | Proposed research direction | The exact labels would of course be yours. The useful distinction is simply between **implemented**, **experimental**, **planned**, and **conceptual**. I also think the word **hallucination** is covering several different failure modes: | Failure type | Example in this project | Usual way to check it | |---|---|---| Factual hallucination | An LLM invents an API, library behavior, source, or fact | Official documentation and source verification | Specification drift | A long coding session forgets an early requirement or mixes versions | Requirement traceability and acceptance checks | Software failure | Generated code fails, changes the wrong component, or breaks another feature | Execution and tests | Memory contamination | An incorrect conclusion is saved and reused by later agents | Provenance, versioning, invalidation, rollback | Forecast error | A predicted time, price, or direction differs from the later observation | Chronological evaluation | Output variability | The same inputs produce different sampled responses | Repeated fixed-condition runs | The Code Factory seems especially relevant to **specification drift, version confusion, memory management, and coding failures**. The deterministic DCM calculation addresses a different property: the same inputs and rules can produce the same output without sampled text generation. That may be useful, but determinism and correctness are separate questions. A deterministic forecast can still miss, just as a deterministic program can contain a reproducible bug. So there may not need to be one universal anti-hallucination benchmark. Each track can have its own evaluation path. The highest-leverage path seems to be: This does not require a complete benchmark, a full refactor, or a hosted service. A single example could connect the project vocabulary to observable operations: ``` Input data / selected points ↓ Dog, Cat, and Manul calculations ↓ limb / Mirror / calibration adjustments ↓ prediction generated at a recorded time ↓ predicted time, price, and direction ↓ later observed result ``` A small record could be enough: ``` { "created_at": "UTC timestamp", "code_commit": "Git commit", "data_cutoff": "latest data visible when the prediction was made", "input_points": [], "dcm_values": { "dog": null, "cat": null, "manul": null }, "adjustments": [], "prediction": { "time": null, "price": null, "direction": null }, "observed_result": {}, "status": "pending | hit | miss | no-signal" } ``` This would not by itself prove forecasting performance. Its more immediate value would be that: The main Python file currently contains many different responsibilities. That is not a judgement about whether the application works. It matters because a future Code Factory needs clear units for retrieval, ownership, editing, and testing. The application already appears to contain natural boundaries such as: ``` Market-data ingestion ↓ Storage / ClickHouse ↓ DCM core calculations ↓ Calibration and adjustment ↓ Chart rendering / GUI News ingestion ↓ Translation / frequency analysis ↓ News GUI Configuration Logging Backup / restore Event and result records ``` Those boundaries could first be documented without moving any code. Later, the same boundaries could become: The first step therefore does not necessarily have to be “split every function into a separate file.” A safer progression could be: The same structure that helps a human maintainer usually also gives a code-oriented LLM better retrieval cues. It is not a perfect equivalence, but meaningful names, locality, interfaces, and dependency structure are useful signals for both. Putting the pieces together, the project could be presented as a tree rather than one indivisible claim: ``` SKYNET-800 / NeoDal │ ├── Alpha application │ ├── Market data │ ├── ClickHouse storage │ ├── DCM calculations │ ├── Calibration │ ├── Charts │ └── News analysis │ ├── DCM forecasting method │ ├── Dog / Cat / Manul │ ├── limbs │ ├── Mirror │ ├── shifted points │ └── prediction records and evaluation │ ├── Code Factory │ ├── Product Owner │ ├── Architect │ ├── Coder │ ├── Tester │ ├── Memory Analyst │ ├── Trust Graph │ └── persistent shared state │ └── Broader research directions ├── collective-intelligence interpretation ├── physical resonance ├── hardware └── RNG/security applications ``` This separation would not say that the branches are unrelated. It would make their relationship easier to inspect. It would also let different readers enter through different parts: My overall impression is that there is already a substantial application here, plus a much broader architecture and theory around it. The main difficulty for an outside reader is not a lack of material; it is that several layers currently arrive through the same doorway. The lowest-cost, highest-value change would probably be to expose those layers, show one end-to-end DCM example, and make the existing functional boundaries visible. From there, each track has a natural next artifact and evaluation path. Whichever track you choose to foreground first, separating the runnable application, the DCM method, the Code Factory architecture, and the broader hypotheses would make it much easier for different readers to inspect, discuss, test, and build on the project.