Sync GitHub main af692537c27175c8410bf57a747be0caf23718e2 (part 6)

research/publications/2026-09-17_recursive-epistemics_v1.8/MANUSCRIPT.md

@@ -918,6 +918,22 @@ Die Real-Body-/Wesen-Arbeiten formulieren eine Infrastrukturregel, die über das
 
 Profile & Identity ergänzt die Persistenzschicht um versionierte technische Konfiguration, Digest, Revision, Lineage und Snapshotbindung. Für Experimente können damit `profile_id`, Revision, Profil-Digest und Snapshot-Digest gemeinsam gebunden werden. Das verbessert Reproduzierbarkeit, ohne den Profilbegriff psychologisch aufzuladen. Ein Profil ist eine deklarierte technische Identität; der dynamische neuronale Zustand und der vollständige kausale Checkpoint bleiben getrennte Objekte.
 
+## 24.9 Frozen-Environment FE-3 als backend-neutrale Ausführungsgrenze
+
+Die Beschleunigungsintegration trennt inzwischen nicht nur neuronale Backend-Parität von wissenschaftlicher Evidenz, sondern auch zwei verschiedene Closed-Loop-Nachweise. Der ältere Builder-D3c-Pfad bleibt ein Playground-naher Engineering-Kontrollpfad. Zusätzlich existiert nun ein kanonischer FE-3-Adapter zwischen `FrozenWorldSession` und dem backend-neutralen `ExecutionBackend`.
+
+Der Adapter erzeugt pro Tick aus dem aktuellen Weltzustand einen exakten `BoundaryFrame`, kodiert daraus einen deterministischen externen Stromvektor, führt genau den aktuellen Backend-Tick aus, dekodiert Spikes in einen `ActionCommand` und gibt diesen an die eingefrorene Welt zurück. Dadurch hängt der nächste Sensorzustand kausal von der Backend-Ausgabe ab. CPU-Referenz und CUDA verwenden dieselbe Schnittstelle; der CUDA-Kernel selbst wird für diese Kopplung nicht verändert.
+
+Für die erste Hardware-Abnahme ist ein versioniertes Manifest `FE3_DETERMINISTIC_TARGET_V1.json` eingefroren. Entscheidend sind identischer Manifest-Hash, identischer Live-Input-Fingerprint und exakte D3c-Trajektorienparität. Die Execution Fingerprints von CPU und CUDA müssen dagegen absichtlich verschieden bleiben, weil Backend-Identität Teil der Provenienz ist.
+
+Dieser Stand ist Engineering-Infrastruktur. Hosted CI kann Adapter, Manifest und CPU-Kontrollen prüfen; die physische CPU-vs-CUDA-FE-3-Abnahme auf der RTX-Referenzhardware bleibt ein eigener realer Nachweis. Weder Adapterimplementierung noch ein später grüner Hardware-Lauf erzeugen automatisch DATA, EVID, einen Speedup-Claim oder Aussagen über PAN-Hyperstate, Lernen oder Kognition.
+
+## 24.10 Frontend-Projektion der Backend- und Evidenzgrenze
+
+Der Dashboard-Stand bildet diese Grenze nun direkt aus kanonischen Quellen ab. Die Integrationsprojektion unterscheidet drei Zustände: **kanonisch integriert**, **softwareseitig verifiziert** und **physisch auf Referenzhardware akzeptiert**. Die ersten beiden Zustände können aus Quellstruktur, Backend-Capabilities und dem selbstverifizierenden FE-3-Manifest abgeleitet werden. Der dritte Zustand wird ausschließlich dann als erfüllt dargestellt, wenn ein geprüftes, datiertes `HARDWARE_ACCEPTANCE_<date>.json` im kanonischen Dokumentationspfad vorliegt.
+
+Die gleiche Information erscheint kontextabhängig an mehreren Stellen: im Playground als Promotion-/Integrationspfad, im Release-Bereich als Engineering-Acceptance, im wissenschaftlichen Observatory als explizite Evidenzgrenze und unter `OLD` nur als Archiv-/Kompatibilitätshinweis. Damit wird Frontend-Vollständigkeit nicht mit wissenschaftlicher Reife verwechselt. Insbesondere bleibt ein grüner Hardware-Status **Engineering Verification**; DATA/EVID benötigen weiterhin den separaten preregistrierten Forschungs- und Reviewpfad.
+
 
 ---
 
@@ -3352,6 +3368,31 @@ Vor positiver DATA dürfen weder selbstorganisierter Werkzeuggebrauch noch unive
 Dieser Strang erhält hohe Priorität, weil er eine direkte Falsifikation der These ermöglicht, MHRN müsse externes Faktenwissen intern memorieren: erfolgreiche Nutzung neuer Inhalte aus einer neuen Quelle bei erhaltener Aufgabenleistung würde eine gelernte Informationsnutzungsstrategie stützen; Scheitern würde die stärkere Interpretation begrenzen.
 
 
+## 58.7 Wave-6/7-Vertragsgrenzen für strukturelle Plastizität und Lernen
+
+Parallel zur noch ausstehenden physischen RTX-3060-Akzeptanz werden zwei
+Semantiklinien vorbereitet. Wave 6 formalisiert die bereits vorhandene
+Self-Organization-Pipeline als fail-closed Approval-/Barrier-Vertrag.
+`MANUAL_ONLY` benötigt eine explizite Autorisierung; automatisierte Modi
+benötigen einen gehashten Policy-Vertrag und bei `PREREGISTERED_AUTO` einen
+vorab eingefrorenen Policy-Artefaktstand. Safety-, Journal-, Barrier- und
+Scientific-Freeze-Grenzen bleiben davon unabhängig und können nicht durch eine
+menschliche oder algorithmische Freigabe übergangen werden.
+
+Wave 7 inventarisiert die reale CPU-Lernsemantik und die aktuell davon
+abweichende CUDA-Referenz. Die CPU-Linie verwendet geordnete nearest-neighbour
+Pair-STDP-Ereignisse, einen Same-Tick-Nullbeitrag, exponentielle
+Eligibility-Traces und verzögerten Reward. Die CUDA-Referenz besitzt zusätzlich
+eine STP-Kandidatensemantik, ein Credit Window und Weight Decay. Diese
+Unterschiede werden nicht durch Toleranzen verdeckt, sondern blockieren den
+Freeze eines gemeinsamen Learning-Vertrags.
+
+Beide Linien sind Engineering-/Governance-Arbeit. Sie erzeugen weder DATA noch
+EVID und autorisieren insbesondere nicht die Wave-5B-PAN-Ausführung. Erst ein
+reviewter Freeze und anschließende prospektive Cross-Backend-Tests können eine
+stärkere Aussage tragen.
+
+
 ---
 
 # Anhang — Quellen und Vorarbeiten

research/publications/2026-09-17_recursive-epistemics_v1.8/manifest.json

@@ -17,13 +17,13 @@
     "research/publications/2026-09-17_recursive-epistemics_v1.8/parts/02_genealogy.md": "2f7cf90d1b9c42f2e0416b9cfe0491ecc2ecf6efe9e379ecc2a64dbb760cfbaa",
     "research/publications/2026-09-17_recursive-epistemics_v1.8/parts/03_research_object.md": "4315da520648e011b51711a9c4d5d159d94d0d28f7020be1c45f9fb86e94c713",
     "research/publications/2026-09-17_recursive-epistemics_v1.8/parts/04_empirical_programme.md": "c2c36425fed7679cf28f121db586072008d8b095d2ad087c6a2f703b4f0135ab",
-    "research/publications/2026-09-17_recursive-epistemics_v1.8/parts/05_infrastructure.md": "20cfef2ce60e1fff6b1513c2eebd41db2b0439be84b7afa0ef0d482999c16e56",
+    "research/publications/2026-09-17_recursive-epistemics_v1.8/parts/05_infrastructure.md": "e16b770b44db55fc75580366bcc03532d7ff6668c4e4052a8bfa152a131dfb2d",
     "research/publications/2026-09-17_recursive-epistemics_v1.8/parts/06_epistemology.md": "9cb93af030023287cff61993003b32e7d825bc8650d1afca6ea1c267dfbddfa2",
     "research/publications/2026-09-17_recursive-epistemics_v1.8/parts/07_integrity.md": "9bcb30fc6d54316ffea169e64641305fff2e1fb8cc466cb3f5f484584dd55483",
     "research/publications/2026-09-17_recursive-epistemics_v1.8/parts/08_ethics_safety.md": "a37b07493cac7aad9a67a9e027fe5b31cf64bd6879d52df971b7b4b7639e3f11",
     "research/publications/2026-09-17_recursive-epistemics_v1.8/parts/09_recursive_epistemics.md": "30bc513d87ba63426d364c102761e9f224dd6a9d7f1d11401165491d0e0c8052",
     "research/publications/2026-09-17_recursive-epistemics_v1.8/parts/10_synthesis.md": "352543e696d9271d6c0b04dcc520a305058bef7ec8e39534670197c1eaaf6266",
-    "research/publications/2026-09-17_recursive-epistemics_v1.8/parts/11_open_landscape.md": "a7d45fcf19657e23e394e78de6a69741474029b4777a4c59d07401be0dfb4f3d",
+    "research/publications/2026-09-17_recursive-epistemics_v1.8/parts/11_open_landscape.md": "ae4350b0fb955639364666170983ff22dd190ccf4a215290babf6cafbf20d3be",
     "research/publications/2026-09-17_recursive-epistemics_v1.8/edition.json": "dca9dc789bd92aa41991dddc98ed8672d1f1af3f371ec4f79438e8e666d7eebf",
     "research/publications/2026-09-17_recursive-epistemics_v1.8/sources/references.json": "aa0e2f7f6b7bede9ece3578cea255f3e261d4053945cb90aeac319f2ad7d75d5",
     "research/publications/2026-09-17_recursive-epistemics_v1.8/sources/chat_reconstruction.json": "9fc8029d19d0a9c882bb9b462e59469166d4caaa9815446d10f5d6b8ce900acb",
@@ -34,7 +34,7 @@
     "scripts/build_publication_edition.py": "eaf21d5a78370fac34d067e60e336216e9ea03f7309c39f7037b7c00f8aacde9"
   },
   "output_sha256": {
-    "MANUSCRIPT.md": "40d1448a9689fbbeaa360aa5a3ee0ded6500d5822f2c0e43057666fa875c1579",
+    "MANUSCRIPT.md": "f519972efaea76e2e8cbe17e447e9d461b136c0b2670b6e7785e87280aa88d3c",
     "README.md": "b2601fa9aedb21a1ee1f8b858c2b5e2802d3a57593ec981562266837893adce8",
     "REFERENCES.md": "c10fd57799365317be351ed82dad9a207086cfba436d78e4944ef182c6622ef8",
     "references.bib": "eaaa74850a7d7223ff13885eeb27a0497aaf328e63f1cfb89d9fa5cf798e6c4d",

research/publications/2026-09-17_recursive-epistemics_v1.8/parts/05_infrastructure.md

@@ -91,3 +91,19 @@ Die Real-Body-/Wesen-Arbeiten formulieren eine Infrastrukturregel, die über das
 ## 24.8 Technische Identität als reproduzierbare Konfiguration
 
 Profile & Identity ergänzt die Persistenzschicht um versionierte technische Konfiguration, Digest, Revision, Lineage und Snapshotbindung. Für Experimente können damit `profile_id`, Revision, Profil-Digest und Snapshot-Digest gemeinsam gebunden werden. Das verbessert Reproduzierbarkeit, ohne den Profilbegriff psychologisch aufzuladen. Ein Profil ist eine deklarierte technische Identität; der dynamische neuronale Zustand und der vollständige kausale Checkpoint bleiben getrennte Objekte.
+
+## 24.9 Frozen-Environment FE-3 als backend-neutrale Ausführungsgrenze
+
+Die Beschleunigungsintegration trennt inzwischen nicht nur neuronale Backend-Parität von wissenschaftlicher Evidenz, sondern auch zwei verschiedene Closed-Loop-Nachweise. Der ältere Builder-D3c-Pfad bleibt ein Playground-naher Engineering-Kontrollpfad. Zusätzlich existiert nun ein kanonischer FE-3-Adapter zwischen `FrozenWorldSession` und dem backend-neutralen `ExecutionBackend`.
+
+Der Adapter erzeugt pro Tick aus dem aktuellen Weltzustand einen exakten `BoundaryFrame`, kodiert daraus einen deterministischen externen Stromvektor, führt genau den aktuellen Backend-Tick aus, dekodiert Spikes in einen `ActionCommand` und gibt diesen an die eingefrorene Welt zurück. Dadurch hängt der nächste Sensorzustand kausal von der Backend-Ausgabe ab. CPU-Referenz und CUDA verwenden dieselbe Schnittstelle; der CUDA-Kernel selbst wird für diese Kopplung nicht verändert.
+
+Für die erste Hardware-Abnahme ist ein versioniertes Manifest `FE3_DETERMINISTIC_TARGET_V1.json` eingefroren. Entscheidend sind identischer Manifest-Hash, identischer Live-Input-Fingerprint und exakte D3c-Trajektorienparität. Die Execution Fingerprints von CPU und CUDA müssen dagegen absichtlich verschieden bleiben, weil Backend-Identität Teil der Provenienz ist.
+
+Dieser Stand ist Engineering-Infrastruktur. Hosted CI kann Adapter, Manifest und CPU-Kontrollen prüfen; die physische CPU-vs-CUDA-FE-3-Abnahme auf der RTX-Referenzhardware bleibt ein eigener realer Nachweis. Weder Adapterimplementierung noch ein später grüner Hardware-Lauf erzeugen automatisch DATA, EVID, einen Speedup-Claim oder Aussagen über PAN-Hyperstate, Lernen oder Kognition.
+
+## 24.10 Frontend-Projektion der Backend- und Evidenzgrenze
+
+Der Dashboard-Stand bildet diese Grenze nun direkt aus kanonischen Quellen ab. Die Integrationsprojektion unterscheidet drei Zustände: **kanonisch integriert**, **softwareseitig verifiziert** und **physisch auf Referenzhardware akzeptiert**. Die ersten beiden Zustände können aus Quellstruktur, Backend-Capabilities und dem selbstverifizierenden FE-3-Manifest abgeleitet werden. Der dritte Zustand wird ausschließlich dann als erfüllt dargestellt, wenn ein geprüftes, datiertes `HARDWARE_ACCEPTANCE_<date>.json` im kanonischen Dokumentationspfad vorliegt.
+
+Die gleiche Information erscheint kontextabhängig an mehreren Stellen: im Playground als Promotion-/Integrationspfad, im Release-Bereich als Engineering-Acceptance, im wissenschaftlichen Observatory als explizite Evidenzgrenze und unter `OLD` nur als Archiv-/Kompatibilitätshinweis. Damit wird Frontend-Vollständigkeit nicht mit wissenschaftlicher Reife verwechselt. Insbesondere bleibt ein grüner Hardware-Status **Engineering Verification**; DATA/EVID benötigen weiterhin den separaten preregistrierten Forschungs- und Reviewpfad.

research/publications/2026-09-17_recursive-epistemics_v1.8/parts/11_open_landscape.md

@@ -348,3 +348,28 @@ Die Interface-Integration eröffnet einen eigenen, aber mit Stage 4–6 verbunde
 Vor positiver DATA dürfen weder selbstorganisierter Werkzeuggebrauch noch universeller gemeinsamer Repräsentationsraum behauptet werden. Der Decoder/Tool-Plane bleibt ein expliziter konventioneller Boundary-Baustein; wissenschaftlich geprüft wird, welche Teile der Auswahl, Nutzung, zeitlichen Erwartung und Rückkopplung tatsächlich vom neuronalen System gelernt werden.
 
 Dieser Strang erhält hohe Priorität, weil er eine direkte Falsifikation der These ermöglicht, MHRN müsse externes Faktenwissen intern memorieren: erfolgreiche Nutzung neuer Inhalte aus einer neuen Quelle bei erhaltener Aufgabenleistung würde eine gelernte Informationsnutzungsstrategie stützen; Scheitern würde die stärkere Interpretation begrenzen.
+
+
+## 58.7 Wave-6/7-Vertragsgrenzen für strukturelle Plastizität und Lernen
+
+Parallel zur noch ausstehenden physischen RTX-3060-Akzeptanz werden zwei
+Semantiklinien vorbereitet. Wave 6 formalisiert die bereits vorhandene
+Self-Organization-Pipeline als fail-closed Approval-/Barrier-Vertrag.
+`MANUAL_ONLY` benötigt eine explizite Autorisierung; automatisierte Modi
+benötigen einen gehashten Policy-Vertrag und bei `PREREGISTERED_AUTO` einen
+vorab eingefrorenen Policy-Artefaktstand. Safety-, Journal-, Barrier- und
+Scientific-Freeze-Grenzen bleiben davon unabhängig und können nicht durch eine
+menschliche oder algorithmische Freigabe übergangen werden.
+
+Wave 7 inventarisiert die reale CPU-Lernsemantik und die aktuell davon
+abweichende CUDA-Referenz. Die CPU-Linie verwendet geordnete nearest-neighbour
+Pair-STDP-Ereignisse, einen Same-Tick-Nullbeitrag, exponentielle
+Eligibility-Traces und verzögerten Reward. Die CUDA-Referenz besitzt zusätzlich
+eine STP-Kandidatensemantik, ein Credit Window und Weight Decay. Diese
+Unterschiede werden nicht durch Toleranzen verdeckt, sondern blockieren den
+Freeze eines gemeinsamen Learning-Vertrags.
+
+Beide Linien sind Engineering-/Governance-Arbeit. Sie erzeugen weder DATA noch
+EVID und autorisieren insbesondere nicht die Wave-5B-PAN-Ausführung. Erst ein
+reviewter Freeze und anschließende prospektive Cross-Backend-Tests können eine
+stärkere Aussage tragen.

research/publications/papers/2026-09-20_mhrn-research-software_v0.1/PAPER.md

@@ -209,3 +209,169 @@ This software paper does not promote any experiment from DATA to EVID.
 - Hazan, H., et al. (2018). BindsNET: A machine learning-oriented spiking neural networks library in Python. *Frontiers in Neuroinformatics*.
 - Pehle, C., & Pedersen, J. E. (2021). Norse — A deep learning library for spiking neural networks. Documentation/software publication.
 - MHRN repository documentation and governed research artefacts, version 0.6.0-alpha.6.
+
+
+### Playground-to-core promotion path
+
+MHRN exposes a controlled promotion path for experimental Playground
+components. The first promoted component family is the typed neural-I/O
+boundary contract. Canonical definitions live in
+`src/embodiment/neural_io_contracts.py`; the historical Playground module is
+a compatibility re-export, preserving existing callers while preventing the
+core from depending on Playground.
+
+The Dashboard Playground surfaces a promotion catalog and
+transfer-verification action. This action is deliberately not a runtime
+source-code editor: it verifies already promoted contracts or reports the
+contract/gate required for a future repository change. Promotion status is
+engineering provenance and does not constitute DATA or EVID.
+
+
+### Canonical neural-I/O codec plane
+
+A second staged promotion moved deterministic encoders/decoders and a
+framework-neutral neural-I/O area adapter from Playground ownership into the
+MHRN Embodiment package. Compatibility re-exports preserve existing Playground
+callers, while the core remains independent of Playground. This pattern allows
+experimental mechanisms to mature into reusable infrastructure without
+retroactively turning exploratory observations into scientific evidence.
+
+
+### Canonical execution and verification plane
+
+A third promotion wave adds a backend-neutral ExecutionBackend protocol and canonical parity/determinism modules. The protocol exposes bounded initialize, step, run, snapshot, restore, and capability operations while requiring continuation state to remain independent of device-local pointers or handles.
+
+The parity layer distinguishes exact discrete-event parity (D1), bounded continuous-state parity with fail-closed non-finite handling (D2), and behavioral/causal parity (D3). Stable execution fingerprints use canonical serialization of seed, configuration identity, backend identity/version, tick count, and contract version. Counter-based stochastic release, same-tick update ordering, and delay-ring semantics are shared runtime primitives.
+
+The existing Playground remains an integration and reference workspace but delegates Builder parity and release RNG semantics to these canonical modules. CUDA Driver/NVRTC and recurrent/plasticity kernels remain Playground-owned pending the next backend-extraction wave.
+
+These changes are software architecture and verification infrastructure. They do not demonstrate CPU/CUDA scientific equivalence, performance superiority, or new empirical support for PAN or learning mechanisms.
+
+
+### Canonical CUDA extraction boundary
+
+A later engineering integration wave moves the previously Playground-owned
+CUDA infrastructure behind the backend-neutral execution contract. The
+extraction is protected by explicit architecture gates: canonical acceleration
+code may not import Playground, moved CUDA kernels must remain byte-identical
+to their frozen reference sources, and CUDA plasticity is labelled
+`NON_CANONICAL_DRAFT / ALIGNMENT_PENDING` until the common learning contract
+is implemented by both CPU and CUDA paths.
+
+CPU and CUDA executions intentionally retain different execution fingerprints
+because backend identity is provenance. Cross-backend equivalence is evaluated
+with D1/D2/D3 contracts, not by forcing backend fingerprints to match. Wave 4
+contains a named opt-in physical D1/D2 acceptance test; D3 closed-loop
+equivalence remains outside the wave pending the Frozen-Environment contract.
+
+Kernel byte preservation is verified in hosted CI. Post-extraction execution
+of the canonical facade on physical RTX-class hardware is tracked separately
+and remains pending until the dedicated hardware-acceptance runner is executed.
+These statements are Engineering Verification only and create no DATA or EVID.
+
+
+### Frozen-environment verification layer
+
+For closed-loop backend comparison, MHRN now treats environment state and
+causal input provenance as versioned verification inputs. A frozen-environment
+manifest records environment identity/configuration, the RNG contract, sensor
+schedule, action and reward schemas, episode policy, initial world state where
+applicable, and exact BoundaryFrames for boundary replay. The artifact is
+serialized through stable canonical JSON and is self-checked against its
+manifest SHA-256.
+
+The engineering acceptance ladder separates FE-1 exact boundary integrity,
+FE-2 repeated deterministic world replay, and FE-3 causal trajectory parity.
+FE-3 comparisons reuse the canonical D3 parity implementation rather than a
+second environment-specific comparator. Hosted CI currently exercises FE-1,
+ten-repeat replay, and a CPU/self D3c control. Physical CPU-versus-CUDA
+closed-loop D3 remains pending. These are software verification results and do
+not constitute scientific DATA or EVID.
+
+
+### Physical cross-backend acceptance boundary
+
+The engineering acceptance workflow now distinguishes two CUDA closed-loop
+levels. First, the existing live Playground Builder can run the same
+deterministic configuration with CPU and CUDA neural execution while retaining
+the world/body loop on CPU; the canonical parity layer compares spike/state
+outputs together with actions, targets, rewards and body-trajectory digests.
+This provides a physical **Builder D3c bridge** on supported NVIDIA hardware.
+
+Second, the stricter Frozen-Environment FE-3 contract remains open. The
+canonical Wave-4 CUDA facade is intentionally a bounded replay backend and does
+not yet accept a causal sensor observation on each continuation tick. MHRN
+therefore does not treat a passing Builder bridge as completed FE-3. The
+hardware report records `full_fe3_accepted=false` until a backend-neutral live
+adapter connects FrozenEnvironment observations, neural execution, canonical
+readout and ActionCommand generation without resetting backend state.
+
+This distinction is an engineering-governance result, not scientific DATA or
+EVID.
+
+### Canonical Frozen-Environment live backend bridge
+
+The Frozen-Environment verification layer now includes a backend-neutral live-input bridge. For each FE-3 tick, the current frozen world state is serialized as a canonical BoundaryFrame, deterministically encoded into external currents, advanced through the same ExecutionBackend continuation surface, decoded into an ActionCommand, and applied back to FrozenWorldSession.
+
+The initial acceptance fixture is frozen as `research/verification/frozen_environment/FE3_DETERMINISTIC_TARGET_V1.json`. CPUReferenceBackend and CUDABackend expose the same live-input extension without changing the recurrent CUDA kernel. Hosted CI validates the manifest and adapter; physical CPU-versus-CUDA FE-3 remains an explicit hardware-acceptance step.
+
+Cross-backend execution fingerprints are intentionally different because backend identity is provenance. FE-3 equivalence instead requires the same manifest, identical live-input fingerprint, and exact canonical D3c trajectory parity. This remains Engineering Verification and does not create DATA, EVID, a speedup claim, or evidence for PAN, learning, or cognitive capability.
+
+
+### Dashboard projection of acceleration acceptance
+
+The dashboard now projects canonical acceleration status instead of inferring it
+from Playground controls. A single backend status block reports canonical CUDA
+capabilities, the verified FE-3 manifest identity, and the latest reviewed
+physical hardware-acceptance artifact when one exists. The UI deliberately
+distinguishes `integrated`, `software_verified`, and physical
+`passed`/`pending` states.
+
+The same source is rendered differently by workspace: Playground exposes the
+promotion path, Release exposes engineering acceptance, the scientific
+Observatory exposes the DATA/EVID boundary, and OLD only documents retained
+compatibility surfaces. Absence of a dated
+`HARDWARE_ACCEPTANCE_<date>.json` is rendered fail-closed as physical
+acceptance pending. This projection is engineering provenance and does not
+promote any CUDA/FE-3 result to DATA or EVID.
+
+
+## PAN semantic promotion boundary (Wave 5A)
+
+After canonicalizing neural I/O, execution backends, parity/determinism and the
+CUDA execution layer, the next integration step is intentionally semantic
+rather than accelerative. MHRN now contains a draft backend-neutral PAN
+hyperstate contract under `src/homeostasis/pan_contract.py`.
+
+The contract records the exact state surface, update order and current
+Playground reference coefficients for health, energy, activity EMA,
+consolidation, amplitude, information proxy and apoptosis eligibility. The
+Playground PAN runtime consumes these values from the canonical draft instead
+of owning an independent set of constants.
+
+This is an engineering integration artifact, not a scientific result. The
+contract status is `DRAFT_NOT_FROZEN`; RQ-PAN-SEM-001 remains open, physical
+FE-3/CUDA hardware acceptance remains pending, and PAN is not treated as
+scientifically validated or backend-equivalent. The separation is deliberate:
+semantic freeze precedes GPU promotion so that future CPU/CUDA PAN comparisons
+test one explicit contract rather than two evolving implementations.
+
+
+### Governed structural and learning contracts
+
+Two later integration waves deliberately separate semantics from hardware.
+Wave 6 defines fail-closed structural approval modes and a stable policy
+artifact hash around the existing proposal/coordinator/journal/undo pipeline.
+Manual approval is necessary but never sufficient: barrier availability,
+journal health, topology permission and the scientific freeze remain
+independent hard gates.
+
+Wave 7 inventories the existing CPU STDP/eligibility/reward rule together with
+the non-canonical CUDA plasticity reference. The draft explicitly records
+current mismatches in STP, edge identity, reward-credit semantics and weight
+decay. Those mismatches prevent cross-backend learning from being labelled
+canonical until a reviewed common contract is frozen and implemented by both
+paths.
+
+These are engineering governance artifacts, not empirical learning or
+structural-plasticity evidence.

research/registry/hypotheses.acceleration.yaml

@@ -0,0 +1,266 @@
+- id: H-CUDA-DET-001-A
+  research_question: RQ-CUDA-DET-001
+  hypothesis: Bei identischem Source Freeze, Execution-Fingerprint, Seed, Input und Anfangszustand erzeugt derselbe CUDA-Vertrag in Wiederholungsläufen exakt dieselbe Spike-Ereignisfolge.
+  status: untested
+  evidence: []
+  created: '2026-09-28'
+  updated: '2026-09-28'
+
+- id: H-CUDA-DET-001-B
+  research_question: RQ-CUDA-DET-001
+  hypothesis: Ein spezifizierter Counter-RNG erzeugt für dieselben Schlüsselwerte reproduzierbare stochastische Entscheidungen unabhängig von Thread-Scheduling und Warp-Timing.
+  status: untested
+  evidence: []
+  created: '2026-09-28'
+  updated: '2026-09-28'
+
+- id: H-CUDA-DET-001-C
+  research_question: RQ-CUDA-DET-001
+  hypothesis: Änderungen von Blockgröße oder Schedule, die laut eingefrorenem Vertrag keine arithmetische Semantik ändern dürfen, verändern die registrierte D1-Ereignissignatur nicht.
+  status: untested
+  evidence: []
+  created: '2026-09-28'
+  updated: '2026-09-28'
+
+- id: H-CUDA-PAR-001-A
+  research_question: RQ-CUDA-PAR-001
+  hypothesis: Für den präregistrierten Modell- und Parameterraum stimmen CPU- und CUDA-Spikefolgen exakt überein.
+  status: untested
+  evidence: []
+  created: '2026-09-28'
+  updated: '2026-09-28'
+
+- id: H-CUDA-PAR-001-B
+  research_question: RQ-CUDA-PAR-001
+  hypothesis: Membran- und Adaptationszustände bleiben zwischen CPU und CUDA innerhalb der vorab registrierten numerischen Toleranz.
+  status: untested
+  evidence: []
+  created: '2026-09-28'
+  updated: '2026-09-28'
+
+- id: H-CUDA-PAR-001-C
+  research_question: RQ-CUDA-PAR-001
+  hypothesis: Bei aktivierter präregistrierter Plastizität bleiben Gewichte, Eligibility- und STP-Zustände zwischen CPU und CUDA innerhalb der vorab registrierten Toleranzen.
+  status: untested
+  evidence: []
+  created: '2026-09-28'
+  updated: '2026-09-28'
+
+- id: H-CUDA-SCALE-001-A
+  research_question: RQ-CUDA-SCALE-001
+  hypothesis: Oberhalb einer prospektiv zu bestimmenden Crossover-Größe reduziert das CUDA-Backend die Wall-Time pro simuliertem Neuron-Tick gegenüber der CPU-Referenz, ohne die registrierten Paritätsgrenzen zu verletzen.
+  status: untested
+  evidence: []
+  created: '2026-09-28'
+  updated: '2026-09-28'
+
+- id: H-CUDA-SCALE-001-B
+  research_question: RQ-CUDA-SCALE-001
+  hypothesis: Der gemessene GPU-Speicherbedarf lässt sich aus Neuronen-, Kanten-, History- und Delay-Ring-Größen innerhalb einer vorregistrierten Abweichung vorhersagen.
+  status: untested
+  evidence: []
+  created: '2026-09-28'
+  updated: '2026-09-28'
+
+- id: H-GATE-IR-001-A
+  research_question: RQ-GATE-IR-001
+  hypothesis: Jeder im Studienumfang unterstützte Gate-Typ besitzt einen deterministischen Referenzoperator mit festgelegter Eingabe-, Ausgabe- und Fehlersemantik.
+  status: untested
+  evidence: []
+  created: '2026-09-28'
+  updated: '2026-09-28'
+
+- id: H-GATE-IR-001-B
+  research_question: RQ-GATE-IR-001
+  hypothesis: Referenzinterpreter und PTX-Lowering erzeugen für denselben gültigen Gate-Graph innerhalb der präregistrierten numerischen Toleranz äquivalente Ausgaben.
+  status: untested
+  evidence: []
+  created: '2026-09-28'
+  updated: '2026-09-28'
+
+- id: H-GATE-IR-001-C
+  research_question: RQ-GATE-IR-001
+  hypothesis: Für die spezifizierte Fehlerklasse werden ungültige Gate-IR-/ABI-Konfigurationen vor Kernel-Ausführung fail-closed abgelehnt.
+  status: untested
+  evidence: []
+  created: '2026-09-28'
+  updated: '2026-09-28'
+
+- id: H-PAN-SEM-001-A
+  research_question: RQ-PAN-SEM-001
+  hypothesis: Ein versionierter PAN-Zustandsvertrag kann alle continuation-kritischen Hyperstate- und Ressourcenfelder ohne Simulationsschritt verlustfrei packen und wiederherstellen.
+  status: untested
+  evidence: []
+  created: '2026-09-28'
+  updated: '2026-09-28'
+
+- id: H-PAN-SEM-001-B
+  research_question: RQ-PAN-SEM-001
+  hypothesis: Ein eingefrorener Update-Order-Vertrag erzeugt bei identischem Zustand und Input deterministisch dieselbe PAN-Zustandsentwicklung.
+  status: untested
+  evidence: []
+  created: '2026-09-28'
+  updated: '2026-09-28'
+
+- id: H-PAN-GPU-001-A
+  research_question: RQ-PAN-GPU-001
+  hypothesis: Bei strukturell eingefrorenem Netzwerk bleiben die definierten PAN-Hyperstate-Felder zwischen CPU- und CUDA-Ausführung innerhalb vorregistrierter Toleranzen.
+  status: untested
+  evidence: []
+  created: '2026-09-28'
+  updated: '2026-09-28'
+
+- id: H-PAN-GPU-001-B
+  research_question: RQ-PAN-GPU-001
+  hypothesis: Ein GPU-PAN-Lauf kann aus demselben kanonischen Checkpoint gestartet und in einen kanonisch äquivalenten Fortsetzungszustand zurückgeführt werden.
+  status: untested
+  evidence: []
+  created: '2026-09-28'
+  updated: '2026-09-28'
+
+- id: H-CUDA-STRUCT-001-A
+  research_question: RQ-CUDA-STRUCT-001
+  hypothesis: Dieselbe freigegebene StructuralProposal-Sequenz erzeugt an definierten Host-Barrieren dieselbe logische Topologie und dieselben stabilen edge_id-/neuron_id-Zuordnungen.
+  status: untested
+  evidence: []
+  created: '2026-09-28'
+  updated: '2026-09-28'
+
+- id: H-CUDA-STRUCT-001-B
+  research_question: RQ-CUDA-STRUCT-001
+  hypothesis: CSR-Rebuild, Schedule-Neuberechnung und GPU-Repacking nach einer strukturellen Barriere erhalten den kanonischen Zustand und ermöglichen deterministische Fortsetzung unter dem neuen Topology-Generation-Fingerprint.
+  status: untested
+  evidence: []
+  created: '2026-09-28'
+  updated: '2026-09-28'
+
+- id: H-CUDA-CL-001-A
+  research_question: RQ-CUDA-CL-001
+  hypothesis: Bei identischen eingefrorenen BoundaryFrames und eingefrorener Umwelt stimmen CPU- und CUDA-Decoder-Aktionen über die gesamte registrierte Episode überein.
+  status: untested
+  evidence: []
+  created: '2026-09-28'
+  updated: '2026-09-28'
+
+- id: H-CUDA-CL-001-B
+  research_question: RQ-CUDA-CL-001
+  hypothesis: In einer deterministischen Live-Umwelt erzeugen CPU- und CUDA-Netzbackends dieselbe Folge aus Aktion, Umweltzustand, nächster Observation und berechnetem Reward.
+  status: untested
+  evidence: []
+  created: '2026-09-28'
+  updated: '2026-09-28'
+
+- id: H-CUDA-CL-001-C
+  research_question: RQ-CUDA-CL-001
+  hypothesis: Eine absichtlich eingeführte Backend-Abweichung wird durch mindestens eine der registrierten D1-, D2- oder D3c-Trajektorienprüfungen fail-closed erkannt.
+  status: untested
+  evidence: []
+  created: '2026-09-28'
+  updated: '2026-09-28'
+
+- id: H-SIM-INTEROP-001-A
+  research_question: RQ-SIM-INTEROP-001
+  hypothesis: Ein präregistrierter gemeinsamer Punktneuron-/Synapsen-Subset kann in MHRN und Brian 2 mit expliziter Einheiten-, Integrator-, Delay- und RNG-Abbildung ausgeführt und auf gemeinsame Endpunkte verglichen werden.
+  status: untested
+  evidence: []
+  created: '2026-09-28'
+  updated: '2026-09-28'
+
+- id: H-SIM-INTEROP-001-B
+  research_question: RQ-SIM-INTEROP-001
+  hypothesis: Der Interoperabilitätsrunner zeichnet Simulatorversion, Modellbeschreibung, Einheitenabbildung, Backend, Integrator, Seed/RNG-Vertrag und Artifact-Hashes vollständig genug auf, um denselben Vergleich unabhängig zu rekonstruieren.
+  status: untested
+  evidence: []
+  created: '2026-09-28'
+  updated: '2026-09-28'
+
+
+- id: H-CUDA-PAR-002-A
+  research_question: RQ-CUDA-PAR-002
+  hypothesis: Bei identischer kanonischer Konfiguration, Seed-, Backend-, Versions- und Tick-Spezifikation ist der Execution Fingerprint deterministisch und unabhaengig von Mapping-Einfuegereihenfolge; mindestens eine geaenderte spezifizierte Identitaetskomponente erzeugt einen anderen Fingerprint.
+  status: untested
+  evidence: []
+  created: '2026-09-29'
+  updated: '2026-09-29'
+
+- id: H-CUDA-PAR-002-B
+  research_question: RQ-CUDA-PAR-002
+  hypothesis: Fuer die registrierte Fehlerklasse werden leere Evidenz, NaN/Inf-Zustaende, Spike-Ereignisabweichungen und kausale D3-Trajektorienabweichungen durch den kanonischen Paritaetsvertrag fail-closed erkannt.
+  status: untested
+  evidence: []
+  created: '2026-09-29'
+  updated: '2026-09-29'
+
+
+- id: H-FE-001-A
+  research_question: RQ-FE-001
+  hypothesis: Zwei Builds aus identischen kanonischen Frozen-Environment-Eingaben erzeugen dasselbe Manifest-Artefakt und denselben Manifest-SHA256; jede claim-relevante Artefaktmanipulation wird fail-closed erkannt.
+  status: untested
+  evidence: []
+  created: '2026-09-30'
+  updated: '2026-09-30'
+
+- id: H-FE-001-B
+  research_question: RQ-FE-001
+  hypothesis: Zehn Wiederholungen desselben FE-2-Vertrags mit identischem Anfangszustand, RNG-Vertrag und deterministischer Aktionspolicy erzeugen bit-identische kanonische Trajektorien-Digests.
+  status: untested
+  evidence: []
+  created: '2026-09-30'
+  updated: '2026-09-30'
+
+- id: H-FE-001-C
+  research_question: RQ-FE-001
+  hypothesis: Der kanonische D3c-Paritaetsvergleich akzeptiert identische FE-3-Trajektorien und erkennt absichtliche Action-, Reward-, State-, Manifest- oder RNG-Abweichungen fail-closed.
+  status: untested
+  evidence: []
+  created: '2026-09-30'
+  updated: '2026-09-30'
+
+
+- id: H-STRUCT-APPROVAL-001-A
+  research_question: RQ-STRUCT-APPROVAL-001
+  hypothesis: Jeder Mutationsversuch ohne modus-spezifische Autorisierung, verfuegbare Structural Barrier, gesundes Journal und erlaubenden Scientific Freeze wird fail-closed abgelehnt.
+  status: untested
+  evidence: []
+  created: '2026-10-01'
+  updated: '2026-10-01'
+
+- id: H-STRUCT-APPROVAL-001-B
+  research_question: RQ-STRUCT-APPROVAL-001
+  hypothesis: Der Policy-Artifact-Hash ist bei identischem Vertrag, Modus und Config deterministisch und aendert sich bei einer relevanten Policy- oder Modusaenderung.
+  status: untested
+  evidence: []
+  created: '2026-10-01'
+  updated: '2026-10-01'
+
+- id: H-LEARN-SEM-001-A
+  research_question: RQ-LEARN-SEM-001
+  hypothesis: Die aktuelle CPU-Referenz erzeugt fuer dieselbe geordnete Spike-/Reward-Sequenz und denselben Checkpointzustand deterministisch dieselben Gewichte, Eligibility-Traces und Pending-Rewards.
+  status: untested
+  evidence: []
+  created: '2026-10-01'
+  updated: '2026-10-01'
+
+- id: H-LEARN-SEM-001-B
+  research_question: RQ-LEARN-SEM-001
+  hypothesis: Nach Freeze eines gemeinsamen Learning-Vertrags stimmen CPU- und CUDA-Gewichte, Eligibility- und STP-Zustaende innerhalb praeregistrierter Toleranzen ueber denselben Ereignis-/Reward-Verlauf ueberein.
+  status: untested
+  evidence: []
+  created: '2026-10-01'
+  updated: '2026-10-01'
+
+- id: H-LEARN-SEM-001-C
+  research_question: RQ-LEARN-SEM-001
+  hypothesis: Absichtlich eingefuehrte Abweichungen in Same-Tick-Ordering, Weight Decay, STP oder Reward-Credit-Semantik werden durch den spaeteren kanonischen Learning-Paritaetsvertrag fail-closed erkannt.
+  status: untested
+  evidence: []
+  created: '2026-10-01'
+  updated: '2026-10-01'
+
+- id: H-CPU-PAR-001-A
+  research_question: RQ-CPU-PAR-001
+  hypothesis: Fuer jeden der 20 vorab eingefrorenen Seeds erzeugen zwei unabhaengig neu aufgebaute CPU-Laeufe mit identischem Netzwerk-, Stimulus- und Anfangszustandsvertrag exakt dieselbe geordnete Spike-Ereignisfolge und denselben kanonischen Endzustands-Digest.
+  status: untested
+  evidence: []
+  created: '2026-10-01'
+  updated: '2026-10-01'

research/registry/questions.acceleration.yaml

@@ -0,0 +1,265 @@
+- id: RQ-CUDA-DET-001
+  domain: Deterministic Accelerated Execution
+  question: Unter welchen eingefrorenen Ausführungsbedingungen kann ein CUDA-Backend dieselbe Determinismusklasse wie die CPU-Referenz erreichen?
+  relevance: GPU-Beschleunigung darf wissenschaftliche Reproduzierbarkeit nicht implizit verändern; Seed-, RNG-, Scheduling- und Zustandsverträge müssen deshalb explizit prüfbar sein.
+  literature:
+  - SRC-STIMBERG-2019
+  - SRC-BRIAN2-DOCS-2026
+  - SRC-BRIAN2CUDA-2022
+  hypotheses:
+  - H-CUDA-DET-001-A
+  - H-CUDA-DET-001-B
+  - H-CUDA-DET-001-C
+  evidence: []
+  status: open
+  answer:
+    current: null
+    confidence: none
+    limitations: Bestehende Playground-Hardwaretests sind Engineering Verification und werden nicht rückwirkend zu DATA oder EVID.
+  created: '2026-09-28'
+  updated: '2026-09-28'
+
+- id: RQ-CUDA-PAR-001
+  domain: Backend Parity
+  question: Sind CPU- und CUDA-Ausführung für einen präregistrierten rekurrenten SNN-Vertrag auf Ereignis-, Zustands- und Plastizitätsebene semantisch äquivalent?
+  relevance: Erst ein expliziter Cross-Backend-Vertrag erlaubt wissenschaftliche Experimente auf unterschiedlichen Ausführungsbackends ohne stillen Semantikwechsel.
+  literature:
+  - SRC-STIMBERG-2019
+  - SRC-BRIAN2-DOCS-2026
+  - SRC-BRIAN2CUDA-2022
+  hypotheses:
+  - H-CUDA-PAR-001-A
+  - H-CUDA-PAR-001-B
+  - H-CUDA-PAR-001-C
+  evidence: []
+  status: open
+  answer:
+    current: null
+    confidence: none
+    limitations: D1/D2-Verifikation im Playground motiviert die Studie, ersetzt aber keine neue Preregistrierung und keinen Source Freeze.
+  created: '2026-09-28'
+  updated: '2026-09-28'
+
+- id: RQ-CUDA-SCALE-001
+  domain: Computational Scaling
+  question: Wie verändern sich Laufzeit, Speicherbedarf und numerische Stabilität des CUDA-Backends mit wachsender Netzwerkgröße, Kantenanzahl, Delay-Ring und Simulationsdauer?
+  relevance: Beschleunigung ist nur wissenschaftlich nützlich, wenn Skalierung ohne unbeobachtete Semantik- oder Stabilitätsänderung erfolgt.
+  literature:
+  - SRC-BRIAN2CUDA-2022
+  - SRC-BRIAN2GENN-DOCS-2026
+  hypotheses:
+  - H-CUDA-SCALE-001-A
+  - H-CUDA-SCALE-001-B
+  evidence: []
+  status: open
+  answer:
+    current: null
+    confidence: none
+    limitations: Diese Frage testet zunächst Computational Scaling und behauptet keine neue Selbstorganisation oder kritische Dynamik.
+  created: '2026-09-28'
+  updated: '2026-09-28'
+
+- id: RQ-GATE-IR-001
+  domain: Executable Semantics
+  question: Kann die Gate-IR als backendunabhängiger ausführbarer Semantikvertrag für die unterstützten MHRN-Gate-Operationen dienen?
+  relevance: Eine explizite Zwischenrepräsentation könnte Python-Referenz, PTX-Lowering und spätere Backends gegen denselben Vertrag prüfbar machen.
+  literature:
+  - SRC-BRIAN2CUDA-2022
+  hypotheses:
+  - H-GATE-IR-001-A
+  - H-GATE-IR-001-B
+  - H-GATE-IR-001-C
+  evidence: []
+  status: open
+  answer:
+    current: null
+    confidence: none
+    limitations: Gate-IR ist derzeit eine Engineering-IR; formale Verifikation im mathematischen Sinn ist nicht etabliert.
+  created: '2026-09-28'
+  updated: '2026-09-28'
+
+- id: RQ-PAN-SEM-001
+  domain: PAN Semantics
+  question: Welcher minimale, versionierte Zustands- und Updatevertrag ist für PAN-Hyperstate, Ressourcenregulation und strukturelle Signale notwendig, damit eine Ausführung backendneutral fortsetzbar bleibt?
+  relevance: PAN darf nicht gleichzeitig wissenschaftlich umdefiniert und auf einen neuen Backendpfad portiert werden; zuerst muss die Semantik eingefroren werden.
+  literature:
+  - SRC-GERSTNER-2014
+  hypotheses:
+  - H-PAN-SEM-001-A
+  - H-PAN-SEM-001-B
+  evidence: []
+  status: open
+  answer:
+    current: null
+    confidence: none
+    limitations: Health, Energy, Consolidation, Apoptosis und Growth sind nicht als vollständig kanonischer GPU-PAN-Vertrag nachgewiesen.
+  created: '2026-09-28'
+  updated: '2026-09-28'
+
+- id: RQ-PAN-GPU-001
+  domain: PAN Cross-Backend Execution
+  question: Kann ein eingefrorener PAN-Zustandsvertrag auf CPU und CUDA innerhalb präregistrierter Toleranzen äquivalent ausgeführt werden?
+  relevance: Erst nach Semantik-Freeze kann geprüft werden, ob PAN-Hyperstate und Ressourcenmechanismen backendunabhängig reproduzierbar sind.
+  literature:
+  - SRC-BRIAN2CUDA-2022
+  - SRC-GENN-STRUCTPLAST-2026
+  hypotheses:
+  - H-PAN-GPU-001-A
+  - H-PAN-GPU-001-B
+  evidence: []
+  status: open
+  answer:
+    current: null
+    confidence: none
+    limitations: Die derzeitige CUDA-Referenz umfasst rekurrente Membran-/Synapsendynamik und frozen-reward Plastizität, nicht den vollständigen PAN-Hyperstate.
+  created: '2026-09-28'
+  updated: '2026-09-28'
+
+- id: RQ-CUDA-STRUCT-001
+  domain: Structural Plasticity
+  question: Kann strukturelle Mutation an deterministischen Host/GPU-Barrieren durchgeführt werden, ohne Identität, Replay oder Fortsetzbarkeit der CUDA-Ausführung zu verletzen?
+  relevance: Growth, Pruning und Apoptosis verändern Graphstruktur, CSR, Delay-State und Checkpoints und benötigen deshalb einen expliziten Barrieren- und Identitätsvertrag.
+  literature:
+  - SRC-GENN-STRUCTPLAST-2026
+  hypotheses:
+  - H-CUDA-STRUCT-001-A
+  - H-CUDA-STRUCT-001-B
+  evidence: []
+  status: open
+  answer:
+    current: null
+    confidence: none
+    limitations: Die kanonische Self-Organization-Pipeline bleibt Host-seitig maßgeblich; direkte ungoverned GPU-Mutation ist nicht vorausgesetzt.
+  created: '2026-09-28'
+  updated: '2026-09-28'
+
+- id: RQ-CUDA-CL-001
+  domain: Closed-loop Backend Parity
+  question: Bleibt eine Sensor-SNN-Aktor-Umwelt-Reward-Trajektorie zwischen CPU- und CUDA-Netzbackend äquivalent, wenn Umwelt und Boundary-Vertrag eingefroren sind?
+  relevance: D3-Parität muss eine kausale Trajektorienprüfung sein und darf nicht allein durch vorgegebene Action-/Reward-Folgen entstehen.
+  literature: []
+  hypotheses:
+  - H-CUDA-CL-001-A
+  - H-CUDA-CL-001-B
+  - H-CUDA-CL-001-C
+  evidence: []
+  status: open
+  answer:
+    current: null
+    confidence: none
+    limitations: Frozen Action/Reward dient nur als Zwischenkontrolle; freie Closed-loop-Parität bleibt separat zu testen.
+  created: '2026-09-28'
+  updated: '2026-09-28'
+
+- id: RQ-SIM-INTEROP-001
+  domain: Simulator Interoperability
+  question: Kann ein eingeschränkter gemeinsamer Modellvertrag zwischen MHRN und externen Referenzsimulatoren wie Brian 2 reproduzierbar abgebildet und verglichen werden?
+  relevance: Externe Referenzbackends können Modellierungs-, Benchmark- und Replikationslücken schließen, dürfen aber keine stillen Semantikänderungen einführen.
+  literature:
+  - SRC-STIMBERG-2019
+  - SRC-BRIAN2-DOCS-2026
+  - SRC-BRIAN2CUDA-2022
+  - SRC-BRIAN2GENN-DOCS-2026
+  - SRC-BRIAN2LAVA-DOCS-2026
+  hypotheses:
+  - H-SIM-INTEROP-001-A
+  - H-SIM-INTEROP-001-B
+  evidence: []
+  status: open
+  answer:
+    current: null
+    confidence: none
+    limitations: Interoperabilität bedeutet zunächst einen expliziten gemeinsamen Modell-Subset; Brian 2, Brian2CUDA, Brian2GeNN und Brian2Lava werden nicht als identischer nativer Backend-Stack behandelt.
+  created: '2026-09-28'
+  updated: '2026-09-28'
+
+
+- id: RQ-CUDA-PAR-002
+  domain: Cross-Backend Verification Methodology
+  question: Kann ein kanonischer backend-neutraler D1/D2/D3-Paritaetsvertrag mit stabilem Execution Fingerprint spezifizierte Backend-Abweichungen fail-closed erkennen, bevor beschleunigte Ausfuehrungen als wissenschaftlich austauschbar behandelt werden?
+  relevance: Die Frage prueft die Verifikationsmethode selbst und trennt einen technisch konsistenten Paritaetsvertrag von der spaeter separat zu testenden CPU/CUDA-Aequivalenz.
+  literature:
+  - SRC-BRIAN2CUDA-2022
+  hypotheses:
+  - H-CUDA-PAR-002-A
+  - H-CUDA-PAR-002-B
+  evidence: []
+  status: open
+  answer:
+    current: null
+    confidence: none
+    limitations: Wave 3 implementiert Engineering-Vertraege und Unit-Tests. Das erzeugt weder Cross-Backend-DATA noch EVID und beantwortet RQ-CUDA-PAR-001 nicht.
+  created: '2026-09-29'
+  updated: '2026-09-29'
+
+
+- id: RQ-FE-001
+  domain: Frozen Environment Verification
+  question: Kann ein versionierter Frozen-Environment-Vertrag Manifestintegritaet, wiederholbaren Replay und kausale D3-Trajektorienpruefung fail-closed bereitstellen, ohne Engineering-Verifikation mit wissenschaftlicher Evidenz zu verwechseln?
+  relevance: CPU/CUDA-D3-Paritaet ist nur interpretierbar, wenn Umweltzustand, Sensorfolge, Reward-Semantik, RNG-Provenienz und Episodegrenzen explizit eingefroren und reproduzierbar sind.
+  literature: []
+  hypotheses:
+  - H-FE-001-A
+  - H-FE-001-B
+  - H-FE-001-C
+  evidence: []
+  status: open
+  answer:
+    current: null
+    confidence: none
+    limitations: FE-1/FE-2 und ein CPU-Self-Control fuer D3c sind Engineering Verification. Physische CPU-vs-CUDA-D3-Paritaet bleibt separat auszufuehren und erzeugt nicht automatisch DATA oder EVID.
+  created: '2026-09-30'
+  updated: '2026-09-30'
+
+
+- id: RQ-STRUCT-APPROVAL-001
+  domain: Governed Structural Plasticity
+  question: Kann ein versionierter Approval- und Host-Barrieren-Vertrag strukturelle Mutation fail-closed autorisieren, ohne Safety-, Journal-, Identitaets- oder wissenschaftliche Freeze-Grenzen zu umgehen?
+  relevance: Growth, Pruning und Apoptose duerfen nicht allein aus einer Policy-Empfehlung oder GPU-Verfuegbarkeit Mutationserlaubnis ableiten.
+  literature: []
+  hypotheses:
+  - H-STRUCT-APPROVAL-001-A
+  - H-STRUCT-APPROVAL-001-B
+  evidence: []
+  status: open
+  answer:
+    current: null
+    confidence: none
+    limitations: Der aktuelle Descriptor ist Draft/Engineering Governance; Host-Barrieren-Alignment und Human Review sind offen.
+  created: '2026-10-01'
+  updated: '2026-10-01'
+
+- id: RQ-LEARN-SEM-001
+  domain: Cross-Backend Learning Semantics
+  question: Welcher versionierte STDP-, STP-, Eligibility-, Reward- und Delay-Vertrag ist notwendig, damit CPU- und CUDA-Lernen ohne stillen Semantikwechsel verglichen werden koennen?
+  relevance: Aktuelle CPU- und CUDA-Pfade besitzen reale Unterschiede bei STP, Credit Window, Weight Decay, Paarparametern und Synapsenidentitaet.
+  literature:
+  - SRC-GERSTNER-2014
+  hypotheses:
+  - H-LEARN-SEM-001-A
+  - H-LEARN-SEM-001-B
+  - H-LEARN-SEM-001-C
+  evidence: []
+  status: open
+  answer:
+    current: null
+    confidence: none
+    limitations: Wave 7 inventarisiert Semantik; der Vertrag ist nicht eingefroren und erzeugt keine Lern- oder Backend-Evidenz.
+  created: '2026-10-01'
+  updated: '2026-10-01'
+
+- id: RQ-CPU-PAR-001
+  domain: CPU Deterministic Self-Parity
+  question: Erzeugt die kanonische CPU-Ausfuehrung unter identischem Source Freeze, Netzwerkvertrag, Seed, Input und Anfangszustand in gepaarten Wiederholungslaeufen exakt dieselbe Ereignis- und Endzustandssignatur?
+  relevance: Eine prospektive CPU-Self-Parity-Baseline trennt intrinsische Nichtdeterministik des Referenzpfads von spaeteren Cross-Backend-Abweichungen und schafft einen hardwareunabhaengigen wissenschaftlichen Ausgangspunkt.
+  literature: []
+  hypotheses:
+  - H-CPU-PAR-001-A
+  evidence: []
+  status: open
+  answer:
+    current: null
+    confidence: none
+    limitations: Die Studie ist CPU-only. Sie testet weder CUDA-Aequivalenz noch PAN, Lernen, strukturelle Plastizitaet oder kognitive Leistung.
+  created: '2026-10-01'
+  updated: '2026-10-01'

research/registry/sources.acceleration.yaml

@@ -0,0 +1,124 @@
+- source_id: SRC-BRIAN2-DOCS-2026
+  authors:
+  - Brian development team
+  title: Brian 2 documentation, current stable documentation
+  year: 2026
+  publisher: Brian development team
+  source_type: software_documentation
+  url: https://brian2.readthedocs.io/en/latest/
+  verified_on: '2026-09-28'
+  verification_scope: Equations, physical units, multicompartment models, synapses, random-number/reproducibility documentation and current stable feature surface.
+  limitations: Documentation establishes Brian 2 capabilities and stated reproducibility limits, not superiority over MHRN.
+  topic:
+  - snn_simulation
+  - equations
+  - units
+  - multicompartment
+  - reproducibility
+  claims:
+  - Brian 2 supports equation-defined neuron/synapse models, dimensional unit checks and multicompartment SpatialNeuron models.
+  - Brian 2 documents that exact bitwise reproducibility cannot be guaranteed across all generated-code/compiler configurations.
+  brain5d_questions:
+  - RQ-CUDA-DET-001
+  - RQ-CUDA-PAR-001
+  - RQ-SIM-INTEROP-001
+  brain5d_relevance: Current external reference for flexible model specification and reproducibility boundaries.
+
+- source_id: SRC-BRIAN2CUDA-2022
+  authors:
+  - Dennis Alevi
+  - Marcel Stimberg
+  - Henning Sprekeler
+  - Klaus Obermayer
+  - Michael Augustin
+  title: "Brian2CUDA: flexible and efficient simulation of spiking neural network models on GPUs"
+  year: 2022
+  journal: Frontiers in Neuroinformatics
+  doi: 10.3389/fninf.2022.883700
+  source_type: peer_reviewed_article
+  url: https://doi.org/10.3389/fninf.2022.883700
+  verified_on: '2026-09-28'
+  verification_scope: CUDA code-generation backend for Brian 2 and comparative GPU execution context.
+  topic:
+  - cuda
+  - snn_simulation
+  - code_generation
+  - performance
+  claims:
+  - Brian2CUDA provides a CUDA standalone backend generated from Brian 2 model descriptions.
+  brain5d_questions:
+  - RQ-CUDA-DET-001
+  - RQ-CUDA-PAR-001
+  - RQ-CUDA-SCALE-001
+  - RQ-GATE-IR-001
+  - RQ-PAN-GPU-001
+  - RQ-SIM-INTEROP-001
+  brain5d_relevance: Primary peer-reviewed comparison source for GPU code-generation and simulator-backend methodology.
+
+- source_id: SRC-BRIAN2GENN-DOCS-2026
+  authors:
+  - Brian2GeNN development team
+  title: Brian2GeNN documentation
+  year: 2026
+  publisher: Brian2GeNN project
+  source_type: software_documentation
+  url: https://brian2genn.readthedocs.io/en/stable/
+  verified_on: '2026-09-28'
+  verification_scope: External Brian 2 device targeting the GeNN GPU simulator and its supported-feature boundary.
+  limitations: Brian2GeNN is an external extension and does not imply that every Brian 2 feature is supported on GeNN.
+  topic:
+  - gpu
+  - genn
+  - interoperability
+  claims:
+  - Brian2GeNN provides a Brian 2 device that generates and runs models through GeNN, with documented unsupported features.
+  brain5d_questions:
+  - RQ-CUDA-SCALE-001
+  - RQ-SIM-INTEROP-001
+  brain5d_relevance: Reference for external backend interoperability rather than a reason to duplicate GeNN inside MHRN.
+
+- source_id: SRC-BRIAN2LAVA-DOCS-2026
+  authors:
+  - Brian2Lava development team
+  title: Brian2Lava documentation
+  year: 2026
+  publisher: Brian2Lava project
+  source_type: software_documentation
+  url: https://brian2lava.gitlab.io/
+  verified_on: '2026-09-28'
+  verification_scope: Brian 2 to Lava interoperability and current public Loihi 2 access/feature boundary.
+  limitations: Brian2Lava remains in testing; public distributions currently expose CPU models while Loihi 2 model access is restricted.
+  topic:
+  - neuromorphic
+  - lava
+  - loihi2
+  - interoperability
+  claims:
+  - Brian2Lava aims to map Brian 2 models into Lava backends; current public Loihi 2 availability is restricted and flexible mode is not a general public Loihi 2 backend.
+  brain5d_questions:
+  - RQ-SIM-INTEROP-001
+  brain5d_relevance: Supports treating neuromorphic hardware as an optional adapter/interoperability programme, not as an assumed native MHRN feature.
+
+- source_id: SRC-GENN-STRUCTPLAST-2026
+  authors:
+  - James C. Knight
+  - Johanna Senk
+  - Thomas Nowotny
+  title: A flexible framework for structural plasticity in GPU-accelerated sparse spiking neural networks
+  year: 2026
+  journal: Neuromorphic Computing and Engineering
+  doi: 10.1088/2634-4386/ae4535
+  source_type: peer_reviewed_article
+  url: https://doi.org/10.1088/2634-4386/ae4535
+  verified_on: '2026-09-28'
+  verification_scope: GPU-accelerated structural plasticity in sparse SNNs using GeNN.
+  topic:
+  - structural_plasticity
+  - gpu
+  - sparse_snn
+  claims:
+  - Structural plasticity can be implemented in GPU-accelerated sparse SNN workflows under explicit data-structure and update constraints.
+  brain5d_questions:
+  - RQ-PAN-GPU-001
+  - RQ-CUDA-STRUCT-001
+  brain5d_relevance: Contemporary comparison point for MHRN structural-barrier and topology-mutation research.

research/specifications/WAVE7_LEARNING_DIVERGENCES.json

@@ -0,0 +1,46 @@
+{
+  "schema_version": 1,
+  "id": "WAVE7-LEARNING-DIVERGENCES-001",
+  "status": "OPEN_BLOCKERS",
+  "contract_id": "mhrn-learning-synapse-v0.1-draft",
+  "scientific_evidence": false,
+  "cross_backend_learning_equivalence": false,
+  "blockers": [
+    {
+      "id": "EDGE_IDENTITY",
+      "status": "OPEN",
+      "cpu": "stable key currently (pre_id,target_id); parallel edges not canonical",
+      "cuda": "array/edge position can distinguish individual edges",
+      "required_resolution": "define stable versioned edge_id semantics shared by CPU, CUDA, checkpoint and delayed-event state"
+    },
+    {
+      "id": "STP",
+      "status": "OPEN",
+      "cpu": "no canonical STP state/update rule in LearningEngine",
+      "cuda": "deterministic candidate STP release/depletion/recovery exists",
+      "required_resolution": "accept, revise or explicitly exclude one versioned STP contract and implement it on compared backends"
+    },
+    {
+      "id": "REWARD_CREDIT",
+      "status": "OPEN",
+      "cpu": "delayed reward plus continuously decaying eligibility",
+      "cuda": "reference uses a bounded fixed credit window",
+      "required_resolution": "freeze one reward/eligibility timing and credit rule"
+    },
+    {
+      "id": "WEIGHT_DECAY",
+      "status": "OPEN",
+      "cpu": "no unconditional per-tick weight decay in canonical LearningEngine",
+      "cuda": "reference applies per-tick weight decay",
+      "required_resolution": "freeze shared decay semantics or remove decay from the compared contract version"
+    },
+    {
+      "id": "PAIR_DEFAULTS",
+      "status": "OPEN",
+      "cpu": "canonical pair-STDP defaults from LearningEngine/config",
+      "cuda": "reference pair amplitudes/defaults differ",
+      "required_resolution": "freeze identical pair amplitudes, taus, same-tick rule and parameter provenance"
+    }
+  ],
+  "promotion_gate": "all five blockers resolved, contract frozen, implementations aligned, checkpoint continuation state complete, negative controls pass"
+}

research/verification/frozen_environment/FE3_DETERMINISTIC_TARGET_V1.json

@@ -0,0 +1 @@
+{"artifact_type":"MHRN_FROZEN_ENVIRONMENT_MANIFEST","manifest":{"action_schema":{"actions":["left","right","hold"],"actuator_id":"target-actuator","decoder":"two-neuron-spike-choice-v1"},"boundary_frames":[],"contract_id":"mhrn-frozen-environment-v1","environment_config":{"target":2},"environment_id":"deterministic-target-v1","environment_version":"1.0","episode_policy":{"continue_for_parity_after_termination":true,"max_ticks":3,"stop_on_terminated":false},"external_disturbances":[],"initial_world_state":{"position":0,"target":2,"tick":0},"mode":"FE-3","reward_contract":{"kind":"target-equality","otherwise":0.0,"reward_on_target":1.0},"rng":{"algorithm":"none","counter_axes":[],"initial_fingerprint":"deterministic-target:no-runtime-rng:v1","mode":"NONE","state":null,"version":"1"},"schema_version":1,"scientific_evidence":false,"sensor_schedule":[0,1,2]},"manifest_sha256":"e0356fcfafb5b9af37b080754ba00877f60c662243a262a3bc348e310c092e35","schema_version":1,"scientific_evidence":false}

research/verification/pan/PAN_WAVE5B_PREFLIGHT_V1.json

@@ -0,0 +1,61 @@
+{
+  "artifact_type": "MHRN_PAN_WAVE5B_PREFLIGHT",
+  "schema_version": 1,
+  "preflight_id": "mhrn-pan-wave5b-preflight-v1",
+  "scientific_evidence": false,
+  "execution_authorized": false,
+  "integration_claimed": false,
+  "prepared_from_develop": "35decdc720a055bcd0bb35e0d4298e8b1dc2fba6",
+  "contract": {
+    "id": "mhrn-pan-hyperstate-v0.1-draft",
+    "current_status": "DRAFT_NOT_FROZEN",
+    "required_status_for_execution": "FROZEN",
+    "source": "src/homeostasis/pan_contract.py",
+    "review_gate": "PAN_CONTRACT_FREEZE_REVIEW"
+  },
+  "parity": {
+    "id": "mhrn-pan-parity-v0.1-draft",
+    "status": "DRAFT_PREFLIGHT",
+    "source": "src/homeostasis/pan_parity_contract.py",
+    "d2": {
+      "exact_fields": [
+        "pan_alive",
+        "pan_neuron_id"
+      ],
+      "numeric_fields": [
+        "pan_health",
+        "pan_amplitude",
+        "pan_energy",
+        "pan_activity_ema",
+        "pan_consolidation",
+        "pan_information_proxy",
+        "pan_x_hd"
+      ],
+      "abs_tolerance": 1e-12,
+      "fail_closed_nonfinite": true
+    },
+    "d3c": {
+      "required": true,
+      "exact_trajectory": true,
+      "environment_contract": "mhrn-frozen-environment-v1"
+    }
+  },
+  "fe3_manifest": {
+    "path": "research/verification/frozen_environment/FE3_DETERMINISTIC_TARGET_V1.json",
+    "manifest_sha256": "e0356fcfafb5b9af37b080754ba00877f60c662243a262a3bc348e310c092e35"
+  },
+  "required_hardware": {
+    "gpu_identity_contains": "RTX 3060",
+    "acceptance_artifact_glob": "docs/canonical/HARDWARE_ACCEPTANCE_*.json",
+    "requires_passed": true,
+    "requires_full_fe3_accepted": true
+  },
+  "authorization_artifact": "research/verification/pan/PAN_WAVE5B_AUTHORIZATION.json",
+  "next_step": "freeze PAN contract and obtain reviewed physical FE-3 acceptance before explicit Wave-5B execution authorization",
+  "interpretation_boundary": [
+    "preflight readiness is not backend equivalence",
+    "hardware acceptance is engineering verification, not DATA or EVID",
+    "Playground PAN GPU checks do not automatically promote PAN to canonical MHRN",
+    "Wave 5B must remain fail-closed until all gates are satisfied"
+  ]
+}

scripts/brain5d_launcher.py

@@ -30,8 +30,14 @@ from typing import Any
 
 ROOT = Path(__file__).resolve().parents[1]
 
-DEFAULT_HOST = "127.0.0.1"
-DEFAULT_PORT = 8765
+# Read central settings directly from the source file to avoid
+# package import chains (the launcher is run via runpy, not as a package).
+_settings_file = ROOT / "src" / "dashboard" / "network_settings.py"
+_settings_globals: dict[str, object] = {}
+exec(_settings_file.read_text(encoding="utf-8"), _settings_globals)
+DEFAULT_HOST = str(_settings_globals.get("DASHBOARD_HOST", "127.0.0.1"))
+DEFAULT_PORT = int(_settings_globals.get("DASHBOARD_PORT", 8767))
+
 PID_FILE = ROOT / "artifacts" / "brain5d.pid"