# CHAT ARCHITECTURE ANCHOR Purpose: stop new chats from reconstructing or inventing the system incorrectly. This is a compact navigation anchor, not a replacement for code. ## Hard rule CODE > current runtime artifacts/data > project docs > prior chat conclusions > assistant inference. If a claim is not verified in code/data, label it HYPOTHESIS. Never redesign a subsystem merely because a new chat lacks context. ### Current mandatory handoff For the current capital-gate / LAB research thread, a new chat MUST read: - `docs/NEXT_CHAT_HANDOFF.md` - `docs/CAPITAL_GATE_RESEARCH_ANCHOR.md` Before creating or extending capital-gate code, audit the existing LAB infrastructure first. At minimum inspect `lab.combatsolo.info` and the research LAB modules under `tredersolo.online/modules/*lab*`. Treat `datasetis.info/tools/research_equity_capital_gate.php` as a disposable research probe, not canonical architecture. `combatsolo.info` remains READ-ONLY unless explicitly authorized otherwise. ## Canonical operational loop The production loop is: `DATASET -> Jeffrey/Combat -> DATASET feedback` - DATASET owns market ingestion/normalization, Passport/runtime/profile contracts and the data/control plane. - Jeffrey/Combat is the trading consumer: it reads DATASET contracts, makes the strategy/execution decision, manages DEMO/LIVE lifecycle and produces realized trading outcomes. - Jeffrey/Combat publishes performance/outcome aggregates back to DATASET through the supported feedback transport/API. DATASET must not read Jeffrey runtime files directly. - SOLO (`tredersolo.online`) is not a production dependency in this loop. It is the unrestricted research/LAB plane: replay, experiments, new variables, profile research and validation. Production must remain operational without SOLO. See `COMBAT_PERFORMANCE_FEEDBACK_V1.md` for the feedback contract. ## System ownership ### DATASET (`datasetis.info`) Owns market-data ingestion/normalization and research/profile infrastructure: Parser0/1/2, Coin Passport, market/orderbook/native5m data, profile generation/library/competition infrastructure. Profile runner target flow is documented in: - `datasetis.info/modules/profile_runner/README.md` - `datasetis.info/modules/profile_runner/rolling_engine_v1.php` - `datasetis.info/modules/profile_runner/causal_feature_builder_v1.php` Current documented profile-runner lifecycle: rolling 24h challenger window, hourly due/rebuild logic, Champion/Challenger SHADOW competition, 1h common-forward evaluation. Production activation/promotion remains gated/disabled until parity/orchestration qualification; verify current code/config before claiming live status. ### Coin Passport Current builder: - `datasetis.info/modules/coin_passport_atomic/lib/Coin2AtomicDatasetBuilder.php` Purpose: describe the current state of ONE coin (atom) from local measurements plus compressed environment/context. Passport is updated from current DATASET sources. Do not reinterpret it as a market-prediction engine. Current Passport contains both measurements and interpretation blocks. `wave` and `pattern` are provisional/research structures; do not treat their empty/null fields as established live measurements. ### COMBAT (`combatsolo.info`) Execution/consumer domain. It consumes DATASET artifacts/profiles but also obtains execution-time exchange data where code does so. Do not claim all Combat data comes exclusively from DATASET. ### DEMO / LIVE execution invariant Mandatory architecture anchor: `docs/DEMO_LIVE_EXECUTION_ANCHOR.md`. There are only two strategies: LONG and SHORT. DEMO and LIVE are execution modes, not separate strategies. DEMO is the primary trading/decision contour and writes authoritative `OPEN/CLOSE` events to `DemoSignalJournal`; LIVE is the follower/mirror that consumes those DEMO events and executes them on the LIVE account when its role/key is enabled. Never reverse this relationship. Jeffrey qualification order is DEMO first: validate DEMO LONG, then DEMO SHORT, then both together, then TRADE CONFIG/profile switching. LIVE keys are enabled only after those DEMO tests pass. While Jeffrey has no LIVE key, absence of LIVE positions is expected and must not be diagnosed as a mirror failure. Known Passport consumer/research enrichment: - `combatsolo.info/engine/strategies/research_feature_collector_v2.php` Known DEMO runner inspected: - `combatsolo.info/engine/strategies/exhaustion_short_demo_runner.php` `ResearchFeatureCollectorV2` is analysis/research enrichment and does not itself block entry; verify consumer code before claiming a Passport field controls execution. ## Core research idea We do NOT assume the market is predictable from arbitrarily many variables. External future information can arrive unpredictably. Atom-first model: - one coin = atom; - Passport = where the atom is now + useful compressed context; - trajectory = sequence of Passport/feature states through time; - many coins are used mainly to test repeatability/robustness, not to build a giant 500/600-body market geometry. Algebra = coordinates/measurements. Geometry = relationships and temporal trajectory of those coordinates. Do not create an infinite recursive transform factory. ## Profile generator: do not confuse with Passport The profile generator intentionally operates on a rolling 24h window and profiles compete. Do NOT automatically conclude that a small generator feature set is a data hole just because Passport is richer. Historical causal builder inspected: - `datasetis.info/modules/profile_runner/causal_feature_builder_v1.php` Before changing generator inputs, test whether an additional independent coordinate materially improves profile competition/stability. Do not dump the whole Passport into the generator by default. ## Variables / LAB Old 6.68c feature information map: - `tredersolo.online/modules/history_fingerprint_lab/storage/stage_668c/current/feature_information_map.json` Important identity rule: a variable is source + formula + window/timeframe. Same concept at 15m, 1h, 4h is not automatically the same variable. Old map contains 85 source:column entries but 84 unique column names because `turnover_pulse_1h` exists in LOCAL and GLOBAL. Variable audit statuses should distinguish at least: - CORE measurement - DERIVED/REDUNDANT - EVIDENCE_SUPPORTED - NO_EVIDENCE / UNRESOLVED - INTERPRETATION Do not call a variable nonworking from code inspection alone; usefulness needs historical evidence. 180D is a hard historical examination, not necessarily the latest calendar 180 days. Data quality, causal integrity, compatibility and representativeness matter more than recency alone. Current missing-variable runner: - `tredersolo.online/modules/history_fingerprint_lab/tools/missing_variable_180d_discovery_v1.php` It already contains selected temporal/path descriptors; do not describe it as purely static. It is narrower event/reversal research, not a full atom-trajectory representation test. ## Passport dynamic-state / "суслик" concept Status: CONCEPT / HYPOTHESIS until implemented and historically qualified. Do not describe this section as current production behavior unless code/runtime verifies it. Passport is intended as a rich DYNAMIC calculation of the current state of each coin, not merely a warehouse of stored features. Target scale discussed: roughly 600 coins and potentially ~1500 calculated coordinates/pattern measurements per coin. Exact counts are not requirements. Target tick cycle: `new tick -> DATASET recalculates current Passport(atom) -> profile/entry contract requests the NECESSARY subset -> algebra + geometry + evidence/validity gate -> ORDER or SKIP -> continue observation -> next tick recalculates again`. Important distinctions: - Passport may calculate/hold far more coordinates than any one order consumes ("принцип суслика": Combat does not see/use everything, but the information exists in the current Passport). - Do NOT call the consumer subset "minimal" by default. It is the NECESSARY proven subset. A profile may legitimately require 5, 30, 100 or more Passport parameters if their added value survives evidence testing. - Combat/profile must not consume all Passport fields merely because they exist. - Number of variables is not the optimization target. Add/use a parameter while it gives reproducible forward value (confidence/WinRate/economics) at sufficient natural traffic; reject additions that improve only TRAIN or collapse useful traffic. - Current generator limits such as max 5 conditions are implementation constraints, not an architectural law. - Passport measures/describes; it must not silently become a second trading generator. Decision semantics: - Missing, stale, invalid or geometrically incompatible required data must NOT be converted into the opposite signal or an invented probability. - `UNKNOWN / INSUFFICIENT_EVIDENCE` is a knowledge state. `SKIP/FLAT` is the resulting trading action. Observation continues. - No order on this tick does not mean stop observing the coin. On the next tick Passport is recalculated and the same contract can be evaluated again. - Absence of evidence for X is not evidence for NOT-X. Confidence concept: - Confidence must be empirically calibrated/frozen-forward; it is not a decorative percentage and is not automatically equal to WinRate. - Separate DATA SUFFICIENCY from CONFIDENCE. If required evidence is insufficient, confidence may be undefined and the result is `UNKNOWN -> SKIP`. - A new outcome should normally become another observation/evidence item; it must not automatically retrain the decision model on every tick. Algebra + geometry gate: - Algebra checks current coordinate values/constraints. - Geometry checks relationships, trajectory and whether the current atom state fits the proven region/path. - Statistical WinRate alone must not override an impossible/incompatible state. Geometry is intended as an independent validity check before trusting historical confidence. - Candidate LAB idea: measure distance/trajectory relative to the proven profile region and test a geometry gate before confidence. This is not yet proven. Generator selection concept: - Search for the NECESSARY proven parameter set, not the smallest or largest set. - A next parameter is justified only by marginal evidence gain that survives frozen-forward validation and acceptable traffic/economics. - Rich Passport and selective profile consumption are complementary: `rich observation -> necessary projection -> proven decision`. ## Wave ordering Current direction from owner: grow Passport first; Wave is already mixed/provisional and should later be reduced/removed where Passport measurements make it redundant. Do not build new Wave architecture now unless explicitly requested. ## Anti-confusion checklist for every new chat 1. Identify the subsystem being discussed. 2. Read this anchor. 3. Inspect the actual relevant code/config/runtime artifact before making architecture claims. 4. Separate VERIFIED FACT from HYPOTHESIS. 5. Do not infer missing data merely from a narrow consumer contract. 6. Do not change production code from a conceptual discussion. 7. Heavy full-universe research on production VDS requires explicit approval; short read-only inspections/tests are okay when requested. 8. If code contradicts this anchor, code wins and this anchor should be updated. ## Current open audits - Passport coverage/freshness/null-rate across the full current universe. - Exact profile-generator feature contract and whether its minimality is intentional/effective. - Generator/Champion/Challenger/Combat parity: map source -> generated profile fields -> evaluator -> execution consumer. - Passport numeric registry vs old 84: matches, genuinely new information, old measurements currently absent. - LAB test of whether additional independent generator coordinates improve competition without hypothesis explosion. Last refreshed: 2026-09-16.