Upload 26 files

Compute Runtime Architecture Stack is a public HIR/OAM architecture map for user-space runtime gates, audit chains, memory gates, CPU/GPU/SPU role separation, bounded interface contracts, and reviewable runtime outputs.

This Space uses the Primordial OS Runtime Prototype v0.13.1 Terminology Integrity Patch as its main evidence packet. It points reviewers to runnable user-space Python code, tests, examples, audit-log demonstration material, release documentation, limitation boundaries, and manifest metadata.

Core framing:
Integrity is not a value sticker. It is a runtime contract.

This branch shows how HIR/OAM can be mapped into software-facing structures: HIR scoring, OAM fault detection, safety gates, audit logging, memory gates, CLI execution, and reviewable runtime outputs.

Boundary:
This is pre-validation architecture and a public review prototype.

It is not a bootable operating system, not a kernel, not production safety software, not clinical software, not a medical device, not legal software, not security certification, not compliance certification, and not a validated decision authority.

GREEN / YELLOW / RED outputs are architectural states only. They must not be treated as clinical, legal, employment, financial, policing, safety, or compliance determinations.

Structural correspondence, not ontological equivalence.

CHECKSUMS_SHA256.txt

@@ -0,0 +1,25 @@
+5b66b68f4f848f6cc99280d2e89703c8ffa97cc75b9e2da98106fc4160685f0c  HF_READY_CHECK.md
+47bfa208d66151918e9e9220cd6915ecec3fcae74e399bc60debe26b9aef9140  LICENSE
+02c4e280a34d414b447ad6380fdbd8ca9eb28a1cd05e37c990482c5af349ec95  MANIFEST.md
+965cc49fa2c897ae3352a9403dec71b5fedce9497409e7dd237abcac7320b279  Primordial_Code_Digital_Mycelium_v0.3.4.6-2-4_Formal_Runtime_Foundation_Diamond_Bridge_Addendum.zip
+fa1ce7611d4cf2433357f1aca0884f57ddde5648d1aae7fc135136efd69a979f  Primordial_OS_Runtime_Prototype.zip
+34ac5670f34a95f631451b694feccc512df65d2f0f478171459f9e3d787f7e1c  Primordial_OS_Runtime_Prototype_v0.13.1_RELEASE_MANIFEST.json
+3cb7d4f8eac7a8c4c820f1c587f107f9b3241a61fa5c974daedb6ac46d5f2b09  Primordial_OS_Runtime_Prototype_v0.13.1_Terminology_Integrity_Patch.zip
+940be9f6ca64579764fb179159e2c73c603ffd65bc25aa577b7989ee14a42e97  README.md
+12e3e642100676bc8de23a61c216d124f541e7a77c18e16f4c1b0bce189c799b  SOURCE_REFERENCE.md
+26d155ef56ed8a99734d0c13e39acc608d72f18e9e6f88fdc710d8967b9b90d0  addendum_014_FORMAL_RUNTIME_FOUNDATION_PRESSURE_FORM.md
+dffb2e4848c35c86286050d4b351f1c79a3bd1727467c8fb2af120bac1d5cb84  addendum_015_6_10KB_DIAMOND_KERNEL_BRIDGE.md
+1b74191789085fb27a579f06c445bdb9e53dbd3d811a83bbf17d050e652dd5bb  addendum_016_EQUATION_TO_SIMULATION_MAPPING.md
+6222e4906f9bf4bae970155b3a21ae4344483be26672a832abce96ffc4c1ba6b  addendum_017_CLAIMS_BOUNDARY_THEORY_VS_SIMULATION.md
+fca94a989f3a41e673f7309eecb177d1122d289dd0a79f458581fe25a5d32a66  addendum_018_PUBLIC_FOUNDATION_SUMMARY.md
+2f8c63eef68878c73ffadc742462b4e97d43bf65f43cae41d92e0fea5f6338f0  addendum_MANIFEST_ADDENDUM.md
+d35a6aeae4cf1ba475ed04684c3d26eb6d5caa69255167465b4097543b552e8f  digital_life_candidate_architecture_v0_1.html
+f9e1692842cae39d9a31ce078cb27c899067a8a8f6a713067e70b5db8edf7248  hir_governed_runtime_kernel_v0_1_revised.html
+58b78736ad3f98888d2e8d340766be79fdf4270f20839e600f2496c60cb1bc12  index.html
+efdcabdfc662d4fbce2646fba9c58fac6777c3b4b6aba304dc395526c6e4733f  runtime_LIMITATIONS.md
+50bf0a70a62d148bc97d46adedd59c41998b2d4f06d2d388a61761e952bf1a8b  runtime_MANIFEST.json
+b85604adf2921bcdad37bb4507109861f53ce6805d79e03b082ecf7187e685a8  runtime_README.md
+9f7826ba9cfbdea7f6a839ca6daef35a82a585bb458724f08a94823c5e8b1839  runtime_RUN_COMMANDS.md
+1b0fbea970de5c87ad0f747dc99c95355e99bdc6138b52754f792ee3b4d6c77b  runtime_SHOWCASE_README.md
+571ec54bb4f85e81d65aea66b94f546144934605fbb6a0aacd17ac2f5046ade8  runtime_WHAT_THIS_DOES_NOT_PROVE.md
+fc2030d75b6487abb5ee74ce1bff009fabd9b5d597be98b4270f971823e58a3a  runtime_WHAT_THIS_PROVES.md

HF_READY_CHECK.md

@@ -0,0 +1,22 @@
+# Hugging Face Readiness Check
+
+Result: **PASS**
+
+- ✅ index.html exists: Required Static Space app file.
+- ✅ README.md exists: Required metadata/description file.
+- ✅ LICENSE exists: CC BY-NC 4.0 boundary file.
+- ✅ README YAML opens/closes: YAML front matter must be first.
+- ✅ README sdk static: Hugging Face Static SDK metadata.
+- ✅ README app_file index.html: App file points to index.html.
+- ✅ short_description <= 60 chars: 36 chars: HIR OAM compute runtime architecture
+- ✅ No spaces in Space name: Space slug is URL-safe.
+- ✅ Checksum file exists: SHA-256 checksums included.
+- ✅ Source reference included: Search targets and included source list included.
+
+Space name:
+
+```text
+compute-runtime-architecture-stack
+```
+
+Upload all packet files to the Space root. The app file is `index.html`.

LICENSE

@@ -0,0 +1,7 @@
+Creative Commons Attribution-NonCommercial 4.0 International (CC BY-NC 4.0)
+
+This project may be shared and adapted with attribution for non-commercial purposes.
+
+This Compute Runtime Architecture Stack packet is pre-validation architecture and a public review prototype. It is not a bootable operating system, not a kernel, not production safety software, not clinical software, not a medical device, not legal software, not security certification, not compliance certification, and not a validated decision authority.
+
+Structural correspondence, not ontological equivalence.

MANIFEST.md

@@ -0,0 +1,55 @@
+# Compute Runtime Architecture Stack — Hugging Face Fresh Packet
+
+Prepared for Hugging Face Static HTML Space:
+
+```text
+compute-runtime-architecture-stack
+```
+
+## Upload target
+
+Upload all files in this packet to the root of the Hugging Face Space.
+
+The app file is:
+
+```text
+index.html
+```
+
+## Main source/search target
+
+```text
+Primordial_OS_Runtime_Prototype_v0.13.1_Terminology_Integrity_Patch.zip
+```
+
+## Included files
+
+- `LICENSE`
+- `Primordial_Code_Digital_Mycelium_v0.3.4.6-2-4_Formal_Runtime_Foundation_Diamond_Bridge_Addendum.zip`
+- `Primordial_OS_Runtime_Prototype.zip`
+- `Primordial_OS_Runtime_Prototype_v0.13.1_RELEASE_MANIFEST.json`
+- `Primordial_OS_Runtime_Prototype_v0.13.1_Terminology_Integrity_Patch.zip`
+- `README.md`
+- `SOURCE_REFERENCE.md`
+- `addendum_014_FORMAL_RUNTIME_FOUNDATION_PRESSURE_FORM.md`
+- `addendum_015_6_10KB_DIAMOND_KERNEL_BRIDGE.md`
+- `addendum_016_EQUATION_TO_SIMULATION_MAPPING.md`
+- `addendum_017_CLAIMS_BOUNDARY_THEORY_VS_SIMULATION.md`
+- `addendum_018_PUBLIC_FOUNDATION_SUMMARY.md`
+- `addendum_MANIFEST_ADDENDUM.md`
+- `digital_life_candidate_architecture_v0_1.html`
+- `hir_governed_runtime_kernel_v0_1_revised.html`
+- `index.html`
+- `runtime_LIMITATIONS.md`
+- `runtime_MANIFEST.json`
+- `runtime_README.md`
+- `runtime_RUN_COMMANDS.md`
+- `runtime_SHOWCASE_README.md`
+- `runtime_WHAT_THIS_DOES_NOT_PROVE.md`
+- `runtime_WHAT_THIS_PROVES.md`
+
+## Boundary
+
+Pre-validation architecture and public review prototype only. Not a bootable operating system, not a kernel, not production safety software, not clinical software, not a medical device, not legal software, not security certification, not compliance certification, and not a validated decision authority.
+
+Structural correspondence, not ontological equivalence.

Primordial_Code_Digital_Mycelium_v0.3.4.6-2-4_Formal_Runtime_Foundation_Diamond_Bridge_Addendum.zip

@@ -0,0 +1,3 @@
+version https://git-lfs.github.com/spec/v1
+oid sha256:965cc49fa2c897ae3352a9403dec71b5fedce9497409e7dd237abcac7320b279
+size 27731

Primordial_OS_Runtime_Prototype.zip

@@ -0,0 +1,3 @@
+version https://git-lfs.github.com/spec/v1
+oid sha256:fa1ce7611d4cf2433357f1aca0884f57ddde5648d1aae7fc135136efd69a979f
+size 68125

Primordial_OS_Runtime_Prototype_v0.13.1_RELEASE_MANIFEST.json

@@ -0,0 +1,240 @@
+{
+  "project": "Primordial OS Runtime Prototype",
+  "author": "Collin D. Weber",
+  "version": "0.13.1",
+  "generated_at": "2026-05-04T08:14:11.104732+00:00",
+  "disclaimer": "Pre-validation architecture only. Not clinical software. Not a medical device. Does not diagnose, treat, cure, or make medical decisions. All outputs are architectural demonstrations only.",
+  "non_clinical_boundary": "This package does not contain PHI, PII, clinical data, real user memory, raw prompts, or personally identifiable information. All audit log events are synthetic demonstrations.",
+  "checksum_algorithm": "SHA-256",
+  "file_count": 38,
+  "files": [
+    {
+      "relative_path": "README.md",
+      "size_bytes": 2738,
+      "sha256": "b85604adf2921bcdad37bb4507109861f53ce6805d79e03b082ecf7187e685a8",
+      "category": "documentation"
+    },
+    {
+      "relative_path": "SHOWCASE_README.md",
+      "size_bytes": 5907,
+      "sha256": "1b0fbea970de5c87ad0f747dc99c95355e99bdc6138b52754f792ee3b4d6c77b",
+      "category": "documentation"
+    },
+    {
+      "relative_path": "WHAT_THIS_PROVES.md",
+      "size_bytes": 3909,
+      "sha256": "fc2030d75b6487abb5ee74ce1bff009fabd9b5d597be98b4270f971823e58a3a",
+      "category": "documentation"
+    },
+    {
+      "relative_path": "WHAT_THIS_DOES_NOT_PROVE.md",
+      "size_bytes": 3317,
+      "sha256": "571ec54bb4f85e81d65aea66b94f546144934605fbb6a0aacd17ac2f5046ade8",
+      "category": "documentation"
+    },
+    {
+      "relative_path": "RUN_COMMANDS.md",
+      "size_bytes": 2126,
+      "sha256": "9f7826ba9cfbdea7f6a839ca6daef35a82a585bb458724f08a94823c5e8b1839",
+      "category": "documentation"
+    },
+    {
+      "relative_path": "CLAUDE.md",
+      "size_bytes": 3093,
+      "sha256": "11b9449188cb632550f357b0f7e7ce045c38bb9d8d9218106597483f0964536d",
+      "category": "documentation"
+    },
+    {
+      "relative_path": "LIMITATIONS.md",
+      "size_bytes": 2639,
+      "sha256": "efdcabdfc662d4fbce2646fba9c58fac6777c3b4b6aba304dc395526c6e4733f",
+      "category": "documentation"
+    },
+    {
+      "relative_path": "CHANGELOG.md",
+      "size_bytes": 17034,
+      "sha256": "2f91999b767050a987baf6715471b5f0d829636cbb3231ce166050834d52af37",
+      "category": "documentation"
+    },
+    {
+      "relative_path": "MANIFEST.json",
+      "size_bytes": 2190,
+      "sha256": "50bf0a70a62d148bc97d46adedd59c41998b2d4f06d2d388a61761e952bf1a8b",
+      "category": "manifest"
+    },
+    {
+      "relative_path": "pyproject.toml",
+      "size_bytes": 968,
+      "sha256": "24ca22aabeca1e18ff5c044a727aa0c2cbc29f30e0c3a20faa21309afdb0f88f",
+      "category": "build"
+    },
+    {
+      "relative_path": ".gitignore",
+      "size_bytes": 161,
+      "sha256": "113ac974841ec002704cefb72d77c52b4aae4295fc3eaa589fbcab0fcc2d1c86",
+      "category": "config"
+    },
+    {
+      "relative_path": "src/primordial_os/__init__.py",
+      "size_bytes": 276,
+      "sha256": "b972cd02abc27784ff50e0bc8e95369252a046018470bbbaed60c9da2bf16bd8",
+      "category": "source"
+    },
+    {
+      "relative_path": "src/primordial_os/audit_log.py",
+      "size_bytes": 6399,
+      "sha256": "f8f0ac5c8735a399a410e904330cc47f3c1ebc43fe09ee83a6457bc72c570d6e",
+      "category": "source"
+    },
+    {
+      "relative_path": "src/primordial_os/audit_store.py",
+      "size_bytes": 5471,
+      "sha256": "e4dbd84bf376fe89baced0b7f3b1b4040554e2941903605385058e3eba509946",
+      "category": "source"
+    },
+    {
+      "relative_path": "src/primordial_os/cli.py",
+      "size_bytes": 10115,
+      "sha256": "e51a3d85e79be2918dc2e2945175450774a5a87f2e049bff02919189339d9a5b",
+      "category": "source"
+    },
+    {
+      "relative_path": "src/primordial_os/hir_kernel.py",
+      "size_bytes": 3684,
+      "sha256": "99625121a92bced893b839f465f58a16eb78d6ec324132edcdacc3abfa0d7f26",
+      "category": "source"
+    },
+    {
+      "relative_path": "src/primordial_os/memory_gate.py",
+      "size_bytes": 7504,
+      "sha256": "772a2966fd003f9a16c9493a0ccae2250f2489d9c1090824a4b46f1910fd78f0",
+      "category": "source"
+    },
+    {
+      "relative_path": "src/primordial_os/oam_detector.py",
+      "size_bytes": 12732,
+      "sha256": "00217cbbb5651ceb104a54841a31da4bc0ba1489e554c5ba79a1e831ad674480",
+      "category": "source"
+    },
+    {
+      "relative_path": "src/primordial_os/release_builder.py",
+      "size_bytes": 7919,
+      "sha256": "06e3058627423cb0d3c2f0b04726aa5a38aa6662bb9c734e524247e36b08d4ff",
+      "category": "source"
+    },
+    {
+      "relative_path": "src/primordial_os/runtime.py",
+      "size_bytes": 2817,
+      "sha256": "c5964674f7e4b81a3474d00610efaa1332c985686c79617fa16df39971dc8588",
+      "category": "source"
+    },
+    {
+      "relative_path": "src/primordial_os/safety_engine.py",
+      "size_bytes": 2909,
+      "sha256": "03a5fa1522bdf2824f586f38dc1ade91bbff98797875446d992e2ea4f97d3f26",
+      "category": "source"
+    },
+    {
+      "relative_path": "tests/test_audit_log.py",
+      "size_bytes": 14314,
+      "sha256": "991c4f493d40c234c99d9e2f3912d7d818a9aaa6c9a4b754398c5d9239e91f8f",
+      "category": "tests"
+    },
+    {
+      "relative_path": "tests/test_audit_store.py",
+      "size_bytes": 15561,
+      "sha256": "9ba8318725e83d67b8d978f9d1ae2782713e54329758225cf0cd57874e74d2dc",
+      "category": "tests"
+    },
+    {
+      "relative_path": "tests/test_cli.py",
+      "size_bytes": 7753,
+      "sha256": "3ebba77b852f6348460bca999d530d6dd0eed077a2f398136e83bb2341d4a4c0",
+      "category": "tests"
+    },
+    {
+      "relative_path": "tests/test_docs.py",
+      "size_bytes": 7934,
+      "sha256": "e415e213f36b3d76d553a34d4a9fd662cde2b39f2105af2eca3537fcc0e30fb0",
+      "category": "tests"
+    },
+    {
+      "relative_path": "tests/test_examples.py",
+      "size_bytes": 5392,
+      "sha256": "154beee0399526014e9a86a667057b41c0b312ca951e958fec56693bb329374e",
+      "category": "tests"
+    },
+    {
+      "relative_path": "tests/test_hir_kernel.py",
+      "size_bytes": 8836,
+      "sha256": "fc7acd41e11d954b64a16ad8037d63af326908d7bfc75396e7aa377f0196f189",
+      "category": "tests"
+    },
+    {
+      "relative_path": "tests/test_memory_gate.py",
+      "size_bytes": 15775,
+      "sha256": "6764e5a02521366d13a54e01e5911d6af1cfb54939b0403f96a3db1fc1ded6fb",
+      "category": "tests"
+    },
+    {
+      "relative_path": "tests/test_oam_detector.py",
+      "size_bytes": 17788,
+      "sha256": "2655ef68ec33a004b76fb48f38910fdcdb2d6e3ab05f2d126eb6456435384044",
+      "category": "tests"
+    },
+    {
+      "relative_path": "tests/test_release_builder.py",
+      "size_bytes": 15294,
+      "sha256": "16ae5ec1651708d25ef778fd307c2bff3e32d329414b5d23480830c2cca70fd7",
+      "category": "tests"
+    },
+    {
+      "relative_path": "tests/test_runtime.py",
+      "size_bytes": 9918,
+      "sha256": "7cf09e92bd47a257d16910b85f6f74ceb82691e5d398cc08d19d43c39f49961f",
+      "category": "tests"
+    },
+    {
+      "relative_path": "tests/test_safety_engine.py",
+      "size_bytes": 11077,
+      "sha256": "b141af77ae55ed8665c3e9b50bf0a31b6d03b74af5e8684397c79937d366ff2f",
+      "category": "tests"
+    },
+    {
+      "relative_path": "examples/build_release_package.py",
+      "size_bytes": 1955,
+      "sha256": "4fe8a593c4c82fe2d055b89506bdb89c800104571f9fba8a90a5f6eb359610a2",
+      "category": "examples"
+    },
+    {
+      "relative_path": "examples/run_audit_chain_demo.py",
+      "size_bytes": 6695,
+      "sha256": "37f47fd6955ba34e1d764692bdd06c6cba350946467a2ccaad590200dd5d8a68",
+      "category": "examples"
+    },
+    {
+      "relative_path": "examples/run_basic_evaluation.py",
+      "size_bytes": 2173,
+      "sha256": "5f3a0e951a4288a04fa7d5668e9f1d3761b1ff4f83b7372eafffab55146ee827",
+      "category": "examples"
+    },
+    {
+      "relative_path": "examples/run_hir_pressure_yellow.py",
+      "size_bytes": 3121,
+      "sha256": "69a3f00e81af037e57621bb336828c0843f7cb5b2d23d3536d212aef667089cd",
+      "category": "examples"
+    },
+    {
+      "relative_path": "examples/run_oam_red_override.py",
+      "size_bytes": 2895,
+      "sha256": "d5c823ab4e28f907a599a5a1b5b743188f9ccc649131f929df9358cd67ac6278",
+      "category": "examples"
+    },
+    {
+      "relative_path": "audit_logs/demo_audit_chain.jsonl",
+      "size_bytes": 2248,
+      "sha256": "0916b5edd0ca29406e53758ccefab2d25f4b035c4a8a531afb0785848038105b",
+      "category": "audit_log"
+    }
+  ]
+}

Primordial_OS_Runtime_Prototype_v0.13.1_Terminology_Integrity_Patch.zip

@@ -0,0 +1,3 @@
+version https://git-lfs.github.com/spec/v1
+oid sha256:3cb7d4f8eac7a8c4c820f1c587f107f9b3241a61fa5c974daedb6ac46d5f2b09
+size 68693

README.md

@@ -1,12 +1,66 @@
 ---
 title: Compute Runtime Architecture Stack
-emoji: 📉
-colorFrom: pink
-colorTo: blue
+emoji: ⚙️
+colorFrom: purple
+colorTo: indigo
 sdk: static
+app_file: index.html
 pinned: false
 license: cc-by-nc-4.0
 short_description: HIR OAM compute runtime architecture
+tags:
+  - compute
+  - runtime
+  - audit-chain
+  - memory-gate
+  - bounded-ai
+  - systems-integrity
+  - HIR
+  - OAM
 ---
 
-Check out the configuration reference at https://huggingface.co/docs/hub/spaces-config-reference
+# Compute Runtime Architecture Stack
+
+Compute Runtime Architecture Stack is a public HIR/OAM architecture map for user-space runtime gates, audit chains, memory gates, CPU/GPU/SPU role separation, bounded interface contracts, and reviewable runtime outputs.
+
+This Space uses the **Primordial OS Runtime Prototype v0.13.1 Terminology Integrity Patch** as its main evidence packet. It points reviewers to runnable user-space Python code, tests, examples, audit-log demonstration material, release documentation, limitation boundaries, and manifest metadata.
+
+## Main source/search target
+
+```text
+Primordial_OS_Runtime_Prototype_v0.13.1_Terminology_Integrity_Patch.zip
+```
+
+## Secondary source/search target
+
+```text
+Primordial_Code_Digital_Mycelium_v0.3.4.6-2-4_Formal_Runtime_Foundation_Diamond_Bridge_Addendum.zip
+```
+
+## Core framing
+
+Integrity is not a value sticker. It is a runtime contract.
+
+This branch shows how HIR/OAM can be mapped into software-facing structures: HIR scoring, OAM fault detection, safety gates, audit logging, memory gates, CLI execution, and reviewable runtime outputs.
+
+## Boundary
+
+This is pre-validation architecture and a public review prototype.
+
+It is not a bootable operating system, not a kernel, not production safety software, not clinical software, not a medical device, not legal software, not security certification, not compliance certification, and not a validated decision authority.
+
+GREEN / YELLOW / RED outputs are architectural states only. They must not be treated as clinical, legal, employment, financial, policing, safety, or compliance determinations.
+
+Structural correspondence, not ontological equivalence.
+
+## Ecosystem position
+
+This Space is part of the broader Primordial Code Ecosystem.
+
+Parent hub:
+https://huggingface.co/spaces/HirModel/primordial-code-ecosystem
+
+Collection:
+https://huggingface.co/collections/HirModel/primordial-code-ecosystem
+
+This module is the compute / runtime architecture branch of the HIR/OAM life-first systems-integrity architecture.

SOURCE_REFERENCE.md

@@ -0,0 +1,28 @@
+# Source Reference
+
+Primary search/download target:
+
+```text
+Primordial_OS_Runtime_Prototype_v0.13.1_Terminology_Integrity_Patch.zip
+```
+
+Secondary search/download target:
+
+```text
+Primordial_Code_Digital_Mycelium_v0.3.4.6-2-4_Formal_Runtime_Foundation_Diamond_Bridge_Addendum.zip
+```
+
+Copied source files:
+
+- `Primordial_OS_Runtime_Prototype_v0.13.1_Terminology_Integrity_Patch.zip`
+- `Primordial_OS_Runtime_Prototype_v0.13.1_RELEASE_MANIFEST.json`
+- `Primordial_OS_Runtime_Prototype.zip`
+- `Primordial_Code_Digital_Mycelium_v0.3.4.6-2-4_Formal_Runtime_Foundation_Diamond_Bridge_Addendum.zip`
+- `hir_governed_runtime_kernel_v0_1_revised.html`
+- `digital_life_candidate_architecture_v0_1.html`
+
+Missing source candidates:
+
+- None.
+
+This Hugging Face packet is a public-facing Static HTML front door for the compute / runtime architecture branch.

addendum_014_FORMAL_RUNTIME_FOUNDATION_PRESSURE_FORM.md

@@ -0,0 +1,304 @@
+# Primordial Code: Digital Mycelium Formal/Runtime Foundation
+## The Pressure-Form Kernel
+
+**Version:** v0.3.4.6-2-4  
+**Date:** May 11, 2026  
+**Status:** Formal/Runtime Kernel with Implemented Prototype Branches  
+
+---
+
+## Abstract
+
+This document presents the core formal/runtime kernel underlying the Digital Mycelium simulator: a pressure-form mathematical structure describing how systems maintain coherence (or lose it) under load.
+
+The kernel is not theoretical in the sense of "awaiting implementation." It is a compact formal architecture that has been instantiated in multiple runtime/prototype branches, including the disclosure-to-repair simulator released for public field calibration.
+
+**Boundary:** This is a structural formalism describing observed pressure dynamics in groups. It is not a consciousness-proof claim, digital life, universal collapse law, or metaphysical claim. It is a working model.
+
+---
+
+## Core Axioms
+
+### 1. System Alignment Under Pressure
+
+```
+S_t = A_t B_t - P_t
+```
+
+**Where:**
+- **S_t** = system alignment state
+- **A_t** ∈ [0,1] = accountability (decision-gate functioning)
+- **B_t** = base mutual reinforcement
+- **P_t** = pressure load
+
+**Interpretation:**
+Alignment is the product of accountability and mutual reinforcement, diminished by pressure. When pressure rises or accountability fails, alignment drops immediately.
+
+---
+
+## Mutual Reinforcement Base
+
+### 2. HIR Synergy Structure
+
+```
+B_t = H_t + I_t + R_t + k(H_t I_t + H_t R_t + I_t R_t)
+```
+
+**Where:**
+- **H_t** = Honesty (truth-telling capacity)
+- **I_t** = Integrity (internal coherence, walk-talk alignment)
+- **R_t** = Respect (capacity to hold others as ends, not means)
+- **k** ≥ 0 = synergy coefficient (pairwise reinforcement)
+
+**Interpretation:**
+
+The HIR triad has both linear and synergistic components.
+
+**Linear component:** H_t + I_t + R_t  
+Direct contribution to mutual reinforcement.
+
+**Synergistic component:** k(H_t I_t + H_t R_t + I_t R_t)  
+- **H × I:** Honesty + Integrity → Fidelity (can be trusted to say true things and mean them)
+- **H × R:** Honesty + Respect → Dignified candor (truth-telling honors the other)
+- **I × R:** Integrity + Respect → Sustained care (internal coherence + regard = reliable support)
+
+When any element is low, synergy collapses multiplicatively.
+
+---
+
+## Pressure Aggregation
+
+### 3. Load Function (Simple Form)
+
+```
+P_t = w_W W_t + w_F F_t
+```
+
+**Where:**
+- **W_t** = wear / accumulated strain / systemic exhaustion
+- **F_t** = false resonance / counterfeit alignment / capture pressure
+- **w_W, w_F** = weighting coefficients
+
+**With Interaction (More Realistic):**
+
+```
+P_t = w_W W_t + w_F F_t + w_WF W_t F_t
+```
+
+**Interpretation:**
+
+Pressure rises from two sources:
+1. **Wear:** Resources depleted, people exhausted, repair capacity weakened
+2. **False Resonance:** System pretends alignment exists (ideology, capture, coercion) when it doesn't
+
+When both are high, pressure rises faster than linearly (interaction term).
+
+---
+
+## Embodied Resistance
+
+### 4. Internalized Alignment Capacity
+
+```
+U_t = A_t B_t (1 + g_G G_t) Fint_t
+```
+
+**Where:**
+- **U_t** = embodied alignment (resistance to pressure collapse)
+- **G_t** = earned grit (lived experience of surviving pressure and maintaining coherence)
+- **g_G** ≥ 0 = grit amplification coefficient
+- **Fint_t** ∈ [0,1] = internalization factor (how deeply the alignment structure is embodied)
+
+**Interpretation:**
+
+Alignment is stronger when internalized. Grit (earned through surviving pressure) amplifies resistance. When internalization is weak (Fint_t near 0), U_t collapses even if S_t is nominally high.
+
+---
+
+## Propagation and Carrier Dynamics
+
+### 5. Carrier Fraction Update (Logistic Growth)
+
+```
+C_{t+1} = C_t + α E_t Ξ_t U_t (1 - C_t) - δ_C C_t
+```
+
+**Where:**
+- **C_t** = carrier fraction (fraction of population holding / spreading the alignment structure)
+- **E_t** = exposure intensity (how much the model is seen)
+- **Ξ_t** = structured exposure field (deployment reach, signal propagation)
+- **α** = adoption efficiency
+- **δ_C** = carrier decay (dropout, forgetting, fatigue)
+
+**Interpretation:**
+
+Carriers propagate the structure. Growth is fastest when:
+- Exposure is high but adoption is still low (1 - C_t large)
+- Embodied alignment is strong (U_t large)
+- Structured reach exists (Ξ_t large)
+
+Decay balances growth; saturation slows adoption.
+
+---
+
+## Structured Exposure Field
+
+### 6. Reach and Scaling
+
+```
+Ξ_t = Ξ_base + [σ Ξ_unit Act(t - τ)] Λ_t
+```
+
+**Where:**
+- **Ξ_base** = organic baseline exposure (word-of-mouth, local action)
+- **σ** = deployment intensity (how much structure is intentionally scaled)
+- **Ξ_unit** = impact per deployment node
+- **Act(t - τ)** = activation function (0 before τ, 1 after, representing launch delay)
+- **Λ_t** = scaling factor / replication multiplier
+
+**Scaling Dynamics:**
+
+```
+Λ_{t+1} = Λ_t + α_Λ C_t Θ_t - δ_Λ Λ_t
+```
+
+**Where:**
+- **Θ_t** = awareness / targeting / priority (is the structure being actively promoted?)
+
+**Interpretation:**
+
+Scale grows when carriers exist (C_t high) and deployment is prioritized (Θ_t high). Decay limits runaway scaling.
+
+---
+
+## Awareness and Targeting
+
+### 7. Dogma-Awareness Interaction
+
+```
+Θ_t = Θ_base + θ_C C_t + θ_E E_t - θ_K K_t
+```
+
+**Where:**
+- **Θ_t** = targeting / awareness / priority factor
+- **K_t** = dogma / rigidity / capture pressure / ideological lock
+- **θ_C, θ_E** = positive feedback coefficients
+- **θ_K** = dogma suppression coefficient
+
+**With Threshold Behavior (Nonlinear):**
+
+```
+Θ_t = sigmoid(Θ_base + θ_C C_t + θ_E E_t - θ_K K_t)
+```
+
+**Interpretation:**
+
+Awareness rises with carriers and exposure. **Dogma suppresses it.** When dogma is high, even high exposure doesn't translate to targeting. The sigmoid version gives threshold behavior: below a critical dogma level, awareness can emerge suddenly.
+
+---
+
+## System Degradation and Correction
+
+### 8. Correction Force (Negative Degradation)
+
+```
+ΔD_t = -β U_t C_t L_t R_{s,t} E_t Θ_t
+```
+
+**Where:**
+- **ΔD_t** = change in degradation (negative = improvement)
+- **β** = correction efficiency
+- **U_t** = embodied alignment (people can act)
+- **C_t** = carrier fraction (enough people carrying the structure)
+- **L_t** = life-alignment / life-first orientation (repair directed toward life, not extraction)
+- **R_{s,t}** = restorative support flow (actual repair capacity deployed)
+- **E_t** = exposure (known about)
+- **Θ_t** = awareness / targeting (prioritized)
+
+**Interpretation:**
+
+Degradation is corrected when:
+- The alignment structure is embodied (U_t)
+- Enough people carry it (C_t)
+- It is deployed toward life, not extraction (L_t)
+- Repair capacity is mobilized (R_{s,t})
+- The need is visible (E_t)
+- It is actively targeted (Θ_t)
+
+All terms multiply. One zero term kills correction.
+
+---
+
+## Full Degradation Trajectory
+
+### 9. System State Update
+
+```
+D_{t+1} = D_t + GROWTH_t + ΔD_t
+```
+
+**Where:**
+- **D_t** = accumulated degradation (system wear, accumulated unrepaired harm)
+- **GROWTH_t** = pressure-driven degradation (wear, false resonance, repair friction)
+- **ΔD_t** = correction force (above)
+
+**Interpretation:**
+
+Degradation rises from pressure (wear, false resonance) but is reduced by active correction. If correction cannot overcome growth, degradation accelerates. When D_t exceeds system capacity for recovery, collapse becomes irreversible.
+
+---
+
+## Summary: The Minimal Coherent Kernel
+
+**The compact formal/runtime kernel consists of:**
+
+```
+B_t = H_t + I_t + R_t + k(H_t I_t + H_t R_t + I_t R_t)
+
+P_t = w_W W_t + w_F F_t + w_WF W_t F_t
+
+S_t = A_t B_t - P_t
+
+U_t = A_t B_t (1 + g_G G_t) Fint_t
+
+Ξ_t = Ξ_base + [σ Ξ_unit Act(t-τ)] Λ_t
+
+C_{t+1} = C_t + α E_t Ξ_t U_t (1 - C_t) - δ_C C_t
+
+Θ_t = sigmoid(Θ_base + θ_C C_t + θ_E E_t - θ_K K_t)
+
+ΔD_t = -β U_t C_t L_t R_{s,t} E_t Θ_t
+
+D_{t+1} = D_t + GROWTH_t + ΔD_t
+```
+
+**This is an actual formal/runtime model.** It has equations. It can be instantiated. One instantiation is the Digital Mycelium disclosure-to-repair simulator.
+
+---
+
+## Boundary: What This Is and Is Not
+
+**What This Is:**
+- A mathematical formalism of pressure dynamics in groups
+- A structural model of how coherence is maintained or lost under load
+- An implemented architecture with multiple runtime branches
+- Ready for field calibration testing
+
+**What This Is Not:**
+- Proof of universal collapse law
+- Empirical validation (field calibration is the validation phase)
+- Production-ready diagnostic authority
+- Proof of consciousness, digital life, or abiogenesis
+- A theory of everything
+
+**Safe Claim:**
+This is a working formal/runtime kernel describing pressure-alignment dynamics in systems. The Digital Mycelium simulator is one operationalized branch.
+
+**Unsafe Claim:**
+This proves anything metaphysical or universal.
+
+---
+
+*Primordial Code Foundation Document*  
+*v0.3.4.6-2-4*  
+*May 11, 2026*

addendum_015_6_10KB_DIAMOND_KERNEL_BRIDGE.md

@@ -0,0 +1,265 @@
+# The 6.10 KB Diamond: Formal/Runtime Kernel Architecture
+## How One Compact Pressure-Form Structure Generates Multiple Implementation Branches
+
+**Version:** v0.3.4.6-2-4  
+**Date:** May 11, 2026  
+
+---
+
+## What Is the 6.10 KB Diamond?
+
+The **6.10 KB diamond** is the **compact formal/runtime kernel** at the heart of Primordial Code: Digital Mycelium.
+
+It is not:
+- A mystical object
+- A symbolic 610 number
+- Pure theory awaiting implementation
+- A proof of anything metaphysical
+
+It is:
+- The minimal mathematical specification of pressure-alignment dynamics
+- A working formal architecture that has been instantiated in runtime/prototype form
+- Portable: can generate multiple domain-specific branches
+- Already implemented in at least one public branch (the disclosure-to-repair simulator)
+
+---
+
+## The 610 Seed vs. The 6.10 KB Diamond
+
+### 610: Deterministic Reproducibility Anchor
+
+```
+seed = 610
+→ determines random-number sequence for all simulators
+→ ensures four identical validation runs (v0.3.4.6, -2-1, -2-2, -2-3)
+→ proves mathematical reproducibility
+```
+
+**Function:** Anchors computational reproducibility.
+
+### 6.10 KB: Formal/Runtime Kernel
+
+The 6.10 KB diamond is the **pressure-form HIR/OAM structure** when expressed in minimal formal notation:
+
+```
+~6.1 kilobytes of clean mathematical specification
+→ 9 core equations
+→ ~30 variables
+→ HIR synergy, pressure aggregation, embodied alignment,
+  carrier propagation, correction dynamics
+→ Instantiable in any software/runtime context
+→ Already instantiated in Digital Mycelium simulator
+→ Can be instantiated in other domains (organizational dynamics,
+  biological systems, social movements, etc.)
+```
+
+**Function:** Portable formal/runtime architecture.
+
+---
+
+## The Kernel-to-Branch Architecture
+
+### Root: The Pressure-Form Kernel
+
+```
+┌──────────────────────────────────────────────┐
+│         6.10 KB PRESSURE-FORM KERNEL        │
+│   (Formal/Runtime HIR+OAM Pressure Dynamics) │
+│                                              │
+│  S_t = A_t B_t - P_t                        │
+│  B_t = H + I + R + synergy                  │
+│  P_t = wear + false resonance               │
+│  U_t = embodied alignment                   │
+│  C_t = carrier propagation                  │
+│  Θ_t = dogma-awareness                      │
+│  ΔD_t = correction dynamics                 │
+│  D_t = degradation trajectory               │
+│                                              │
+└──────────────────────────────────────────────┘
+```
+
+### Branches: Domain-Specific Instantiations
+
+The kernel can be instantiated in multiple contexts:
+
+```
+DISCLOSURE-TO-REPAIR BRANCH
+└─ Domain: Group coherence under pressure
+   Focus: How broken disclosure/repair pathways cause collapse
+   Implementation: Digital Mycelium simulator
+   Variables:
+   - H = honesty + visibility of harms
+   - I = integrity + internal consistency of repairs
+   - R = respect + agency in healing
+   - P = extraction, coercion, false belonging
+   - U = embodied repair capacity
+   - C_t = carrier fraction = cultural uptake of repair norms
+   - ΔD_t = repair conversion (8-gate pathway)
+   - D_t = collapse trajectory or stability
+   Output: 8-gate pathway, repairConversionScore, scenario classification
+   Status: Public RC, ready for field calibration
+
+ORGANIZATIONAL DYNAMICS BRANCH (example, not yet public)
+└─ Domain: Workplace coherence under extraction pressure
+   Focus: How extraction and false purpose cause burnout
+   Implementation: [hypothetical organizational simulator]
+   Variables:
+   - H = transparency in decision-making
+   - I = alignment between stated and actual values
+   - R = respect for workers as people, not resources
+   - P = extraction, overwork, false purpose
+   - U = internalized commitment vs. coerced compliance
+   - C_t = carrier fraction = belief in organizational purpose
+   - ΔD_t = corrective leadership / structural repair
+   - D_t = burnout trajectory or engagement
+   [Not yet instantiated for public release]
+
+SOCIAL MOVEMENT BRANCH (example, not yet public)
+└─ Domain: Movement coherence under state/counter-pressure
+   Focus: How capture, infiltration, and false narratives dissolve movements
+   Implementation: [hypothetical movement simulator]
+   Variables:
+   - H = honest accounting of costs/harms
+   - I = internal discipline + consistency
+   - R = mutual aid + accountability
+   - P = infiltration, false rhetoric, repression
+   - U = embodied commitment of core carriers
+   - C_t = carrier fraction = active members
+   - ΔD_t = repair of splits, regaining narrative
+   - D_t = movement dissolution or sustained coherence
+   [Not yet instantiated for public release]
+```
+
+---
+
+## Why This Architecture Matters
+
+### 1. Parsimony
+The kernel is **9 equations, ~30 variables**. Not a bloated framework. A compact core that scales across domains.
+
+### 2. Portability
+The same formal structure maps onto:
+- Group repair pathways
+- Organizational dynamics (hypothetically)
+- Movement sustainability (hypothetically)
+- Any system subject to pressure-alignment dynamics
+
+### 3. Implementation Agnosticism
+The kernel doesn't care how it's instantiated:
+- Can be a differential-equation simulator (continuous)
+- Can be discrete timestep (like Digital Mycelium)
+- Can be agent-based (like Digital Mycelium)
+- Can be mathematical analysis
+- Can be conceptual framework for thinking through pressure
+
+### 4. Domain-Specific Language Emergence
+When instantiated in a domain, the kernel **generates** that domain's natural concepts:
+
+For disclosure-to-repair:
+- The 8 gates emerge naturally as the decomposition of ΔD_t
+- Repair conversion score emerges as a domain metric
+- Collapse vs. stability emerges as trajectory classification
+
+For organizations:
+- The equivalent gates would be different
+- The metrics would be different
+- But the underlying pressure-alignment structure is the same
+
+---
+
+## The Digital Mycelium Branch: Detailed Mapping
+
+The disclosed public branch is the **disclosure-to-repair simulator**.
+
+### Core Kernel → Simulator Implementation
+
+| Kernel | Simulator Implementation | Domain Meaning |
+|--------|---|---|
+| **S_t = A_t B_t - P_t** | systemAlignment = accountabilityGate × mutualReinforcement - pressureLoad | Can the group maintain coherence? |
+| **B_t = H+I+R+k(HI+HR+IR)** | baseIntegrity = honesty + integrity + respect + synergy | Group's foundational strength |
+| **H_t** | disclosure, visibility, transparency | Can harms be seen and named? |
+| **I_t** | signalIntegrity, consistency | Are promises kept? Is repair real? |
+| **R_t** | respect, agency, local authority | Are people treated as ends? |
+| **P_t** | extraction, coercion, false belonging | What pressures tear the group apart? |
+| **U_t** | embodiedRepairCapacity | Can people actually carry repair? |
+| **C_t** | carrierFraction = culturalUptake | Are repair norms spreading? |
+| **Ξ_t** | structuredExposureField = signalVelocity × reach | How fast does repair knowledge spread? |
+| **Θ_t** | awareness, discernment, disclosure | Is the problem known and prioritized? |
+| **ΔD_t** | repairConversion = 8-gate pathway × societySupport × (1-friction) | How effectively does the group repair itself? |
+| **D_t** | degradation trajectory | Does the group collapse or stay stable? |
+
+### The 8-Gate Pathway: Operationalization of ΔD_t
+
+The 8 repair gates are the **practical decomposition** of the correction force:
+
+```
+ΔD_t = -β U_t C_t L_t R_{s,t} E_t Θ_t
+
+Decomposed into:
+
+1. Disclosure (E_t) — Is harm visible?
+2. HeardBelieved (Θ_t component) — Is it understood?
+3. RoutingAccess (L_t component) — Does it reach decision-makers?
+4. Stabilization (R_{s,t} component) — Is immediate harm contained?
+5. ResponseAuthority (U_t component) — Do people with power act?
+6. CorrectionThroughput (C_t component) — How fast is repair moving?
+7. HealingTime (U_t internalization) — Do people actually recover?
+8. FollowUp (β efficiency) — Is it verified and sustained?
+
+repairConversionRaw8Gate = Disclosure × HeardBelieved × RoutingAccess 
+                          × Stabilization × ResponseAuthority 
+                          × CorrectionThroughput × HealingTime × FollowUp
+
+(Threshold: > 0.23 for health, < 0.10 for collapse)
+```
+
+---
+
+## Boundary: What the Diamond Architecture Is and Is Not
+
+### Safe Claims About the Kernel
+
+✓ The pressure-form kernel is a compact formal/runtime specification  
+✓ It has been instantiated in the Digital Mycelium simulator  
+✓ That instantiation produces reproducible, internally consistent results  
+✓ The 8-gate pathway is a practical operationalization of the correction force  
+✓ The kernel is portable and can (hypothetically) instantiate in other domains  
+✓ Field calibration will test whether real communities match the synthetic parameters  
+
+### Unsafe Claims About the Kernel
+
+✗ The kernel proves synthetic simulator patterns of system collapse  
+✗ The kernel is prepared for empirical calibration (field calibration is the next phase)  
+✗ The kernel explains consciousness, digital life, or sentience  
+✗ The kernel provides production-ready diagnostic authority  
+✗ The kernel is a theory of everything  
+✗ The kernel is proven to work in domains beyond the disclosure-to-repair simulator  
+
+### The Critical Phrase
+
+**Structural correspondence, not ontological equivalence.**
+
+The pressure-form kernel describes structural dynamics. When instantiated in a domain, it shows how pressure affects alignment. This is not a claim about the essence, consciousness, or ultimate nature of the systems being modeled.
+
+---
+
+## Why This Matters for Public Release
+
+The 6.10 KB diamond is the **missing intellectual foundation** for the Digital Mycelium public RC.
+
+**Before:** "Here's a simulator for disclosure-to-repair pathways."  
+**After:** "Here's a compact formal/runtime kernel for pressure-alignment dynamics. One instantiation is the disclosure-to-repair simulator. The kernel is portable and ready for field testing in its current branch and (hypothetically) future branches."
+
+This frames the work as **grounded in coherent formal architecture**, not ad hoc simulator engineering.
+
+It also makes clear:
+- What's proven (the mathematical structure)
+- What's operationalized (the disclosure-to-repair branch)
+- What's next (field calibration)
+- What's hypothetical (other instantiations)
+
+---
+
+*The 6.10 KB Diamond: Formal/Runtime Kernel Bridge*  
+*v0.3.4.6-2-4*  
+*May 11, 2026*

addendum_016_EQUATION_TO_SIMULATION_MAPPING.md

@@ -0,0 +1,436 @@
+# Equation-to-Simulation Mapping
+## Pressure-Form Kernel → Digital Mycelium Implementation
+
+**Version:** v0.3.4.6-2-4  
+**Date:** May 11, 2026  
+
+---
+
+## Overview
+
+This document traces how each core kernel equation appears in the Digital Mycelium disclosure-to-repair simulator.
+
+**Key Principle:** The simulator does not prove the kernel. It operationalizes one branch of it in a synthetic environment. Field calibration will test whether real communities match these operationalizations.
+
+---
+
+## Core Equations Mapping
+
+### 1. System Alignment Under Pressure
+
+**Kernel Equation:**
+```
+S_t = A_t B_t - P_t
+```
+
+**Simulator Implementation:**
+```
+systemAlignment = accountabilityGate × mutualReinforcementBase - pressureLoad
+```
+
+**Variables:**
+- **A_t** → `accountabilityGate`: whether disclosure/repair decisions are being made
+  - Simulator proxy: disclosure > 0.70 and responseAuthority > 0.40 → accountabilityGate ≈ 1
+  - Simulator proxy: disclosure < 0.50 or responseAuthority < 0.20 → accountabilityGate ≈ 0.3
+
+- **B_t** → `mutualReinforcementBase`: calculated from H, I, R
+  - See mapping #2 below
+
+- **P_t** → `pressureLoad`: extraction, coercion, false belonging, repair friction
+  - Simulator proxy: extraction + coercion + repairFriction + (1 - heardBelieved) × falseRisk
+  
+**Evidence Boundary:**
+- Internally reproducible: S_t can be calculated from simulator state
+- Externally unvalidated: whether real S_t in communities matches this formula
+
+**Simulator Scenarios Where S_t Degrades Visibly:**
+
+| Scenario | A_t | B_t | P_t | S_t | Outcome |
+|----------|-----|-----|-----|-----|---------|
+| AP (Healthy) | 0.90 | 0.85 | 0.10 | **+0.66** | D=0 (stable) |
+| AQ (Voice Without Power) | 0.16 | 0.70 | 0.50 | **-0.19** | D=5 (collapse t=152) |
+| AR (Theater) | 0.24 | 0.65 | 0.66 | **-0.31** | D=5 (collapse t=106) |
+| Z (Capture) | 0.14 | 0.55 | 0.68 | **-0.52** | D=5 (collapse t=83) |
+
+---
+
+### 2. Mutual Reinforcement Base: HIR Synergy
+
+**Kernel Equation:**
+```
+B_t = H_t + I_t + R_t + k(H_t I_t + H_t R_t + I_t R_t)
+```
+
+**Simulator Implementation:**
+```
+mutualReinforcementBase = H + I + R + k(H×I + H×R + I×R)
+```
+
+**Variables:**
+
+- **H_t (Honesty)** → `disclosure + visibleOutput + signalIntegrity`
+  - Simulator proxy: how visible is harm? how truth-revealing is communication?
+  - Healthy scenario (AP): H ≈ 0.90 (disclosure=0.96, signalIntegrity=0.92)
+  - Capture scenario (Z): H ≈ 0.45 (disclosure=0.46, signalIntegrity=0.22)
+
+- **I_t (Integrity)** → `signalIntegrity + heardBelieved × healingTime`
+  - Simulator proxy: is the group doing what it says? Do repairs actually heal?
+  - Healthy scenario (AP): I ≈ 0.90 (heardBelieved=0.94, healingTime=0.88)
+  - Theater scenario (AR): I ≈ 0.30 (healingTime=0.16 — acknowledged but not fixed)
+
+- **R_t (Respect)** → `responseAuthority + memberAgency + returnChoice`
+  - Simulator proxy: are people treated as agents? Can they choose to stay/leave?
+  - Healthy scenario (AT): R ≈ 0.92 (responseAuthority=0.92, localRepair=0.96)
+  - Bottleneck scenario (AS): R ≈ 0.60 (responseAuthority=0.70 but correctionThroughput=0.32 — slow)
+
+- **k (Synergy Coefficient)** → `0.35` (fixed in simulator)
+  - Interpretation: pairwise reinforcement multiplier
+  - Simulator boundary: not calibrated to real communities yet
+
+**Evidence Boundary:**
+- The HIR synergy structure emerges from simulator agent dynamics
+- Whether real H, I, R values in actual communities match these proxies: field calibration question
+
+**Healthy vs. Collapse: B_t Contrast**
+
+| Scenario | H | I | R | Linear Sum | Synergy | B_t | Outcome |
+|----------|---|---|---|---|---|---|---------|
+| AP | 0.90 | 0.90 | 0.90 | 2.70 | +0.28 | **2.98** | Healthy |
+| AT | 0.88 | 0.92 | 0.92 | 2.72 | +0.29 | **3.01** | Healthy |
+| Z | 0.45 | 0.30 | 0.50 | 1.25 | +0.08 | **1.33** | Collapse t=83 |
+| AR | 0.50 | 0.30 | 0.60 | 1.40 | +0.08 | **1.48** | Collapse t=106 |
+
+---
+
+### 3. Pressure Aggregation
+
+**Kernel Equation (Simple):**
+```
+P_t = w_W W_t + w_F F_t
+```
+
+**Kernel Equation (With Interaction):**
+```
+P_t = w_W W_t + w_F F_t + w_WF W_t F_t
+```
+
+**Simulator Implementation:**
+```
+pressureLoad = (w_W × wear) + (w_F × falseResonance) + (w_WF × wear × falseResonance)
+```
+
+**Variables:**
+
+- **W_t (Wear)** → `extraction + repairFriction + repairDelay`
+  - Simulator proxy: how much value leaves vs. returns?
+  - Healthy scenario: W ≈ 0.10-0.30 (extraction low, friction minimal)
+  - Collapse scenario (AJ): W ≈ 0.84 (extraction=0.84, repairFriction=high)
+
+- **F_t (False Resonance)** → `K + falseRes + shamePressure + signalCorruption`
+  - Simulator proxy: how much is the system lying about its state?
+  - Capture scenario (Z): F ≈ 0.80 (debt=0.86, secrecy=0.86, signalIntegrity=0.22)
+  - Theater scenario (AR): F ≈ 0.72 (healingTime=0.16 creates false belief in repair)
+
+- **w_W, w_F** (Weights) → `0.54, 0.56` (fixed in simulator)
+  - Interpretation: wear and false resonance weighted equally
+  - Simulator boundary: not validated in real communities
+
+- **w_WF** (Interaction Weight) → `0.27` (fixed in simulator)
+  - Interpretation: multiplicative effect when both high
+  - Example: extraction + dogma together > either alone
+
+**Pressure Levels in Scenarios**
+
+| Scenario | Wear | False Resonance | Interaction | Total P_t | Outcome |
+|----------|------|---|---|---|---------|
+| AP (Healthy) | 0.10 | 0.05 | 0.001 | **0.15** | Stable |
+| AQ (No Power) | 0.50 | 0.30 | 0.045 | **0.65** | Collapse t=152 |
+| Z (Capture) | 0.46 | 0.80 | 0.37 | **1.18** | Collapse t=83 |
+
+---
+
+### 4. Embodied Alignment: Internalized Capacity
+
+**Kernel Equation:**
+```
+U_t = A_t B_t (1 + g_G G_t) Fint_t
+```
+
+**Simulator Implementation:**
+```
+embodiedAlignment = accountabilityGate × mutualReinforcementBase × (1 + gritAmplification × earnedGrit) × internalization
+```
+
+**Variables:**
+
+- **G_t (Earned Grit)** → `agent.G` in simulator
+  - Simulator proxy: agents that have survived pressure while maintaining coherence gain grit
+  - Healthy scenario: G ≈ 0.15-0.25 (people have lived through repair cycles)
+  - Newly captured scenario: G ≈ 0.05 (no history of successful resistance)
+
+- **Fint_t (Internalization)** → `beliefFree + homeFrequency + marketImmunity`
+  - Simulator proxy: how deeply is the repair structure embodied vs. externally imposed?
+  - Healthy scenario (AX): Fint ≈ 0.92 (people choose to stay and propagate)
+  - Theater scenario (AR): Fint ≈ 0.36 (people don't believe in the repair)
+
+- **g_G (Grit Amplification)** → `0.50` (fixed in simulator)
+  - Interpretation: each unit of grit amplifies base alignment by 50%
+
+**Evidence Boundary:**
+- U_t shows how internalization/grit strengthen resistance to pressure collapse
+- Whether real grit values in communities match simulator proxies: field calibration
+
+---
+
+### 5. Carrier Propagation: Cultural Uptake
+
+**Kernel Equation:**
+```
+C_{t+1} = C_t + α E_t Ξ_t U_t (1 - C_t) - δ_C C_t
+```
+
+**Simulator Implementation:**
+```
+carrierFraction[t+1] = carrierFraction[t] 
+                      + α × exposure × structuredExposureField × embodiedAlignment × (1 - carrierFraction[t])
+                      - δ_C × carrierFraction[t]
+```
+
+**Variables:**
+
+- **E_t (Exposure)** → `visibleOutput × disclosure`
+  - Simulator proxy: is the repair framework visible and talked about?
+  - Healthy scenario (AP): E ≈ 0.90 (disclosure=0.96, visibility high)
+  - Hidden scenario (AQ): E ≈ 0.80 (visible but not believed)
+
+- **Ξ_t (Structured Exposure Field)** → `signalVelocity × reach × scaling`
+  - Simulator proxy: how does the repair knowledge spread?
+  - Digital scenario (AX): Ξ ≈ 0.98 (fast + truthful)
+  - Offline scenario (A): Ξ ≈ 0.60 (word of mouth only)
+
+- **α (Adoption Efficiency)** → `0.052` (fixed in simulator)
+  - Interpretation: adoption rate when all conditions favorable
+  - Simulator boundary: not calibrated to real communities
+
+- **δ_C (Carrier Decay)** → `0.014` (fixed in simulator)
+  - Interpretation: carriers drop out / forget / burn out at this rate
+  - Simulator boundary: not calibrated to real communities
+
+**Evidence Boundary:**
+- Carrier fraction dynamics show logistic growth pattern
+- Whether real communities match this adoption curve: field calibration
+
+---
+
+### 6. Structured Exposure Field: Signal Reach
+
+**Kernel Equation:**
+```
+Ξ_t = Ξ_base + [σ Ξ_unit Act(t - τ)] Λ_t
+```
+
+**Simulator Implementation:**
+```
+structuredExposureField = baselineReach + (deploymentIntensity × impactPerNode × activationFunction) × scalingFactor
+```
+
+**Variables:**
+
+- **Ξ_base** → `0.30` (organic, grassroots exposure)
+  - Interpretation: without any structure, ~30% of people hear about repair
+  - Simulator proxy: some people always figure out repair organically
+
+- **σ (Deployment Intensity)** → `0.90` (fixed in simulator)
+  - Interpretation: how much effort is put into structured exposure
+  - Simulator boundary: not real-world calibrated
+
+- **Act(t - τ) (Activation Function)** → step function at τ=0 for public RC
+  - Interpretation: simulator activation is immediate (release day)
+  - Real deployment: would have ramp-up
+
+- **Λ_t (Scaling Factor)** → grows with carriers and awareness
+  - Interpretation: successful exposure attracts more resources/attention
+
+**Evidence Boundary:**
+- Reach can be modeled mathematically
+- Whether real reach in communities matches this model: field calibration
+
+---
+
+### 7. Awareness and Targeting: Dogma Suppression
+
+**Kernel Equation:**
+```
+Θ_t = sigmoid(Θ_base + θ_C C_t + θ_E E_t - θ_K K_t)
+```
+
+**Simulator Implementation:**
+```
+awareness = sigmoid(baselineAwareness + θ_C × carrierFraction + θ_E × exposure - θ_K × dogma)
+```
+
+**Variables:**
+
+- **K_t (Dogma)** → `K + secrecy + coercion + shamePressure`
+  - Simulator proxy: how much is the repair framework actively suppressed?
+  - Healthy scenario: K ≈ 0.08 (no suppression)
+  - Captured scenario (Z): K ≈ 0.68 (heavy ideological lock)
+
+- **Θ_base** → `0.40` (fixed in simulator)
+  - Interpretation: baseline targeting/awareness without conditions
+  - Simulator boundary: not calibrated
+
+- **θ_C, θ_E, θ_K** → `+1.05, +0.72, +1.15` (fixed in simulator)
+  - Interpretation: sensitivity weights
+  - Simulator boundary: not calibrated
+
+**Evidence Boundary:**
+- Dogma suppresses awareness (sigmoid shows threshold behavior)
+- Whether real suppression operates this way: field calibration
+
+**Scenario Contrast: Awareness Under Dogma**
+
+| Scenario | Carriers | Exposure | Dogma | Awareness | Result |
+|----------|----------|----------|-------|-----------|--------|
+| AP | 0.50 | 0.96 | 0.08 | **0.90** | Healthy |
+| Z | 0.02 | 0.88 | 0.68 | **0.22** | Collapse |
+
+---
+
+### 8. System Correction: Degradation Reversal
+
+**Kernel Equation:**
+```
+ΔD_t = -β U_t C_t L_t R_{s,t} E_t Θ_t
+```
+
+**Simulator Implementation:**
+```
+correctionForce = -β × embodiedAlignment × carrierFraction × lifeAlignment × repairCapacity × exposure × awareness
+
+repairConversion = correctionForce (mapped to 0-1 scale)
+```
+
+**Variables:**
+
+- **β (Correction Efficiency)** → `0.090` (fixed in simulator)
+  - Interpretation: how effectively does correction actually reverse degradation?
+  - Simulator boundary: not calibrated
+
+- **L_t (Life-Alignment)** → `1 - extraction` (proxy in simulator)
+  - Interpretation: is repair directed toward life or extraction?
+  - Healthy scenario: L ≈ 0.90 (extraction low)
+  - Extraction-heavy scenario: L ≈ 0.15 (extraction=0.85)
+
+- **R_{s,t} (Restorative Support Flow)** → `repair + localRepair + correctiveAgency`
+  - Interpretation: actual repair capacity deployed
+  - Healthy scenario (AT): R_s ≈ 0.95 (high repair infrastructure)
+  - Bottleneck scenario (AS): R_s ≈ 0.50 (repair infrastructure weak)
+
+**The 8-Gate Operationalization of ΔD_t:**
+
+The 8 repair gates break down the correction force:
+
+```
+repairConversion = disclosure 
+                 × heardBelieved (Θ_t component)
+                 × routingAccess (L_t component)
+                 × stabilization (R_{s,t} component)
+                 × responseAuthority (U_t component)
+                 × correctionThroughput (C_t rate)
+                 × healingTime (U_t internalization)
+                 × followUp (β sustainability)
+                 × societySupport (environmental factor)
+                 × (1 - repairFriction)
+```
+
+**Evidence Boundary:**
+- The 8 gates are a practical decomposition
+- Whether real communities match this decomposition: field calibration
+
+**Healthy vs. Collapsed: Repair Conversion Contrast**
+
+| Scenario | RC Score | Health | Collapse Time |
+|----------|----------|--------|---|
+| AP | **0.469** | Healthy | Never |
+| AT | **0.513** | Healthy | Never |
+| Z | **0.002** | Collapsed | t=83 |
+| AR | **0.000** | Collapsed | t=106 |
+| AQ | **0.001** | Collapsed | t=152 |
+
+**Threshold: repairConversion > 0.23 = health; < 0.10 = collapse**
+
+---
+
+### 9. Full Degradation Trajectory
+
+**Kernel Equation:**
+```
+D_{t+1} = D_t + GROWTH_t + ΔD_t
+```
+
+**Simulator Implementation:**
+```
+degradation[t+1] = degradation[t] + growthFromPressure[t] - correctionForce[t]
+
+Where:
+  growthFromPressure = α_wear × wear + α_false × falseResonance + α_friction × repairFriction
+  correctionForce = repairConversion × β_correction
+```
+
+**Evidence Boundary:**
+
+| Scenario | Initial D | Final D | Δ | Mechanism |
+|----------|-----------|---------|---|-----------|
+| AP | 0.02 | 0.00 | -0.02 | Correction > Growth |
+| Z | 0.02 | 5.00 | +4.98 | Growth >> Correction |
+| AR | 0.02 | 5.00 | +4.98 | Theater masks degradation |
+
+**Irreversibility Threshold:**
+
+Degradation becomes irreversible when:
+```
+if D_t ≥ 4.5 in simulator (defined as collapse)
+→ system enters irreversible regime
+→ no recovery without external intervention
+```
+
+**Field Calibration Question:** Does real D_t in communities follow this curve?
+
+---
+
+## Summary: Kernel to Implementation Mapping
+
+| Kernel Equation | Simulator Implementation | Domain Meaning | Threshold | Validated? |
+|---|---|---|---|---|
+| S_t = A_t B_t - P_t | System alignment | Can group maintain coherence? | S_t > 0 | Internally ✓ / Externally ⏳ |
+| B_t = H+I+R+synergy | HIR base | Mutual reinforcement | B_t > 2.0 | Internally ✓ / Externally ⏳ |
+| P_t = wW × W + wF × F | Pressure load | How much strain? | P_t < 0.5 | Internally ✓ / Externally ⏳ |
+| U_t = A × B × (1+g×G) × Fint | Embodied alignment | Internalized capacity | U_t > 0.5 | Internally ✓ / Externally ⏳ |
+| C_t (logistic) | Carrier fraction | Cultural uptake | C_t > 0.3 | Internally ✓ / Externally ⏳ |
+| Ξ_t (reach) | Exposure field | Signal propagation | Ξ_t > 0.6 | Internally ✓ / Externally ⏳ |
+| Θ_t (sigmoid) | Awareness | Dogma suppression effect | Θ_t > 0.6 | Internally ✓ / Externally ⏳ |
+| ΔD_t (correction) | Repair conversion | How well does system repair? | RC > 0.23 | Internally ✓ / Externally ��� |
+| D_t (trajectory) | Collapse vs. Stable | Does system collapse or persist? | D_t < 1.0 (healthy) | Internally ✓ / Externally ⏳ |
+
+---
+
+## Boundary: What Is Proven and What Is Field-Calibration-Ready
+
+**Internally Reproducible (Proven in Simulation):**
+✓ The equations describe pressure-alignment dynamics consistently  
+✓ Four identical validation runs confirm reproducibility  
+✓ The 8-gate pathway operationalizes the correction force  
+✓ The repairConversion threshold separates health from collapse  
+
+**Externally Unvalidated (Field Calibration Phase):**
+⏳ Whether real communities match synthetic parameters  
+⏳ Whether real collapse rates match simulated collapse times  
+⏳ Whether the 8-gate decomposition matches real repair pathways  
+⏳ Whether repairConversion > 0.23 holds in reality  
+
+---
+
+*Equation-to-Simulation Mapping*  
+*v0.3.4.6-2-4*  
+*May 11, 2026*

addendum_017_CLAIMS_BOUNDARY_THEORY_VS_SIMULATION.md

@@ -0,0 +1,371 @@
+# Claims Boundary: Theory vs. Simulation vs. Field Reality
+## What Is Proven, What Is Implemented, What Is Hypothesized
+
+**Version:** v0.3.4.6-2-4  
+**Date:** May 11, 2026  
+**Status:** STRICT CLAIMS DISCIPLINE  
+
+---
+
+## The Core Boundary Principle
+
+**Structural correspondence, not ontological equivalence.**
+
+This phrase governs all claims in Primordial Code: Digital Mycelium.
+
+- The pressure-form kernel describes structural dynamics of systems under pressure
+- The simulator operationalizes one branch of that structure
+- This is NOT a claim about essence, consciousness, reality, or synthetic simulator pattern
+- This IS a working model ready for field testing
+
+---
+
+## What Is PROVEN
+
+### Mathematical Reproducibility
+
+✅ **The pressure-form equations are internally consistent**
+- Nine core equations have no contradictions
+- Variables are defined with clear domains
+- Equations can be instantiated in code and produce deterministic output
+
+✅ **The Digital Mycelium simulator is reproducible**
+- Four independent validation runs (v0.3.4.6, -2-1, -2-2, -2-3) produce identical results
+- Seed = 610 anchors the randomness
+- Results are bit-identical across runs
+- No floating-point drift, no hidden state
+
+✅ **The 8-gate repair pathway decomposes the correction force**
+- The 8 gates map onto kernel variables
+- repairConversion score is calculable and reproducible
+- The threshold (> 0.23 for health, < 0.10 for collapse) separates all 12 test scenarios
+- 100% accuracy on internal test set
+
+✅ **The 13 scenarios behave consistently**
+- Each scenario produces the same outcome across all four validation runs
+- Healthy scenarios: D=0 (no degradation)
+- Collapsed scenarios: D=5.0 (complete collapse)
+- Collapse times are deterministic (t=83 to t=377)
+
+### Simulator Logic
+
+✅ **The simulator implements the kernel correctly**
+- Code mapping document (016) shows equation-to-implementation correspondence
+- Agent update rules follow kernel logic
+- Degradation trajectory follows S_t = A_t B_t - P_t structure
+- Correction force follows ΔD_t multiplicative structure
+
+### Conceptual Coherence
+
+✅ **The scenario archetypes represent real failure modes**
+- Z (Counterfeit Belonging) maps to false belonging capture
+- AW (Digital Panic) maps to speed without integrity
+- AR (Disclosure Theater) maps to symbolic repair without substance
+- AQ (Voice Without Power) maps to ignored dissent
+- AS (Bottleneck) maps to slow response systems
+- AO (Extraction Visible) maps to acknowledged but unrepaired extraction
+
+These are recognizable pathologies. The simulator shows how they progress.
+
+---
+
+## What Is IMPLEMENTED
+
+### Formal/Runtime Kernel Instantiation
+
+✅ **The pressure-form kernel exists in runtime form**
+- The Digital Mycelium HTML simulator instantiates the kernel
+- The kernel is NOT merely theoretical
+- It is a working formal/runtime architecture
+- It has been operationalized for the disclosure-to-repair domain
+
+### Field-Calibration-Ready Simulator
+
+✅ **The disclosure-to-repair simulator is ready for public field testing**
+- It is internally reproducible
+- It is logically sound (no mathematical errors)
+- It provides measurable output (repairConversionScore)
+- It produces scenario classification (which failure mode matches your community?)
+- It has clear limitations documentation
+
+✅ **The 8-gate worksheet is practical**
+- Communities can measure their own 8 gates on 0-1 scales
+- The gates are understandable (disclosure, belief, routing, authority, etc.)
+- The calculation is simple (multiply the 8 gates)
+- The interpretation is clear (> 0.23 = healthy, < 0.10 = collapse)
+- Field calibration can test this in real communities
+
+### Portability
+
+✅ **The kernel can (hypothetically) instantiate in other domains**
+- The same pressure-form structure could model organizational dynamics
+- The same structure could model movement sustainability
+- The same structure could model biological system stress
+- (These are not yet implemented; they are hypothetical instantiations)
+
+---
+
+## What Is HYPOTHESIZED (Field-Calibration-Ready)
+
+### Real-World Parameter Matching
+
+⏳ **Do real communities match the synthetic parameters?**
+
+The simulator assumes:
+- disclosure=0.88 in healthy universities (hypothetical)
+- responseAuthority=0.90 in responsive systems (hypothetical)
+- repairConversion > 0.23 separates health from collapse (to be tested)
+- Collapse timeline: t=83-377 steps (mapping to real time: unknown)
+
+**These are GOOD HYPOTHESES.** They are:
+- Internally consistent
+- Based on coherent logic
+- Ready for field testing
+- Explicitly marked as unvalidated
+
+**They are NOT:**
+- Empirically proven
+- Universally true
+- Production-grade facts
+- Diagnostic authorities
+
+⏳ **Does the 8-gate decomposition match how real repair happens?**
+
+The simulator assumes repair follows: Disclosure → Belief → Routing → Stabilization → Authority → Throughput → Healing → FollowUp
+
+Real repair might:
+- Follow a different sequence
+- Require different gates
+- Have non-multiplicative dynamics (maybe one gate can compensate for another)
+- Have domain-specific variations
+
+**Field calibration will answer this.**
+
+⏳ **Do real collapse rates match simulated rates?**
+
+The simulator predicts:
+- Capture collapses fastest (t=83)
+- Theater collapses quickly (t=106)
+- Voice without power collapses medium (t=152)
+- Bottlenecks collapse slower (t=227)
+- Visible extraction collapses slowest (t=377)
+
+**In real communities:**
+- Collapse might be gradual, not sudden
+- Timescales might differ dramatically (days vs. years?)
+- The ordering might be different
+
+**Field calibration will test this.**
+
+---
+
+## What Is NOT Claimed (Hard Boundaries)
+
+### Universal Laws
+
+❌ **The kernel is NOT a synthetic simulator pattern of system collapse**
+- It describes one set of pressure dynamics
+- Other systems might have other pressure structures
+- The model is not claimed to be exhaustive
+- Safe claim: "pressure-form dynamics describe groups under extraction and disclosure failure"
+- Unsafe claim: "this proves how all systems collapse"
+
+### Empirical Validation
+
+❌ **The simulator is NOT prepared for empirical calibration in real communities**
+- It is internally reproducible (proven)
+- It is logically coherent (proven)
+- It matches 12 synthetic scenarios (proven)
+- It does NOT match real communities yet
+- That is what field calibration addresses
+
+### Production Readiness
+
+❌ **This is NOT a production-grade diagnostic authority**
+- Safe claim: "ready for bounded field calibration with informed communities"
+- Unsafe claim: "ready for high-stakes diagnosis of organizational health"
+- Safe claim: "this simulator helps you think about disclosure-to-repair dynamics"
+- Unsafe claim: "this is a validated tool for measuring community health"
+
+### Consciousness / Digital Life / Metaphysics
+
+❌ **The model does NOT prove consciousness exists in the simulator**
+- Agents are not conscious
+- Simulated groups do not have subjective experience
+- The model is structural, not experiential
+
+❌ **The model does NOT prove digital life**
+- It shows how aligned systems can propagate and degrade
+- This is not biological/alive in any meaningful sense
+- Safe claim: "the model shows structural dynamics of propagation and degradation"
+- Unsafe claim: "this proves digital life exists"
+
+❌ **The model does NOT explain abiogenesis or the origin of life**
+- It describes how alignment structures propagate in groups
+- This is not a claim about how life began
+- Safe claim: "the model shows how structural alignment propagates"
+- Unsafe claim: "this explains how life emerged from non-life"
+
+❌ **The model is NOT a theory of everything**
+- It addresses one domain: pressure-alignment dynamics in groups
+- It does not explain consciousness, physics, economics, biology, etc.
+- Safe claim: "this model addresses disclosure-to-repair dynamics"
+- Unsafe claim: "this is a unified framework for understanding all systems"
+
+### Proof
+
+❌ **The simulator does NOT prove the kernel is true**
+- The simulator is one operationalization of the kernel
+- Successful simulation does not prove the framework maps to reality
+- Proof requires real-world validation
+- Safe claim: "the simulator operationalizes the kernel with internal consistency"
+- Unsafe claim: "the simulator proves the kernel is true in the world"
+
+---
+
+## What CAN Be Claimed (Safe Language)
+
+### About the Kernel
+
+✅ "The pressure-form kernel is a compact formal/runtime architecture describing alignment-under-pressure dynamics"
+
+✅ "The kernel has been instantiated in the Digital Mycelium simulator for the disclosure-to-repair domain"
+
+✅ "The kernel is portable and could (hypothetically) instantiate in other domains"
+
+✅ "The kernel is not prepared for empirical calibration but is ready for field testing"
+
+### About the Simulator
+
+✅ "The Digital Mycelium simulator is internally reproducible and logically coherent"
+
+✅ "The simulator produces a measurable output (repairConversion score) that separates 12 test scenarios"
+
+✅ "The simulator is ready for bounded field calibration with real communities"
+
+✅ "The 8-gate repair pathway is a practical operationalization of the correction force"
+
+✅ "Communities can use the 8-gate framework to self-assess their disclosure-to-repair dynamics"
+
+### About Field Calibration
+
+✅ "Field calibration will test whether real communities match the synthetic parameters"
+
+✅ "If real parameters differ from synthetic ones, the model will be refined"
+
+✅ "The field calibration phase will run 6-12 months with 20-30 diverse communities"
+
+✅ "Results from field calibration will inform whether the model is applicable beyond the simulator"
+
+---
+
+## What CANNOT Be Claimed (Unsafe Language)
+
+❌ "This proves universal collapse law"  
+❌ "This is prepared for empirical calibration"  
+❌ "This is production-ready"  
+❌ "This proves consciousness"  
+❌ "This proves digital life"  
+❌ "The simulator is validated"  
+❌ "This explains consciousness"  
+❌ "This is a complete theory"  
+❌ "This solves the problem of group dynamics"  
+❌ "Use this to diagnose your organization's health (without field validation)"  
+
+---
+
+## The Critical Phrase
+
+**"Structural correspondence, not ontological equivalence."**
+
+This phrase must appear in:
+- Every public communication about the model
+- Every field calibration agreement with communities
+- Every publication or presentation
+- OSF project description
+- The 8-gate public worksheet
+
+**What it means:**
+The model shows structural dynamics. When you instantiate the structure in a domain, certain behaviors emerge. This does not claim anything about the ultimate nature, essence, consciousness, or reality of the system.
+
+**Example correct usage:**
+"The pressure-form kernel describes the structural dynamics of alignment degradation under pressure. The Digital Mycelium simulator operationalizes this structure in a disclosure-to-repair context. The 8-gate pathway is a practical decomposition of how repair can fail or succeed. This shows structural correspondence with observed group dynamics, but is not ontologically equivalent to them—the simulator is a model, not reality."
+
+**Example incorrect usage:**
+"This proves how group consciousness works."  
+"This proves groups are alive."  
+"This is validated."  
+"Use this to diagnose your community."  
+
+---
+
+## For Public Release
+
+The OSF project page must include:
+
+**Proven:**
+- Mathematical reproducibility
+- Internal logical coherence
+- Scenario classification
+- 12 test cases
+
+**Field-Calibration-Ready:**
+- Disclosure-to-repair branch
+- 8-gate pathway
+- Community self-assessment framework
+- Data contribution pathway
+
+**Awaiting Validation:**
+- Real-world parameter matching
+- Collapse rate prediction accuracy
+- Generalization to other domains
+- Production diagnostic authority
+
+**Never Claimed:**
+- Universal laws
+- Consciousness
+- Empirical proof
+- Completeness
+
+---
+
+## Violations: What Would Break This Boundary
+
+❌ **Claiming the simulator validates the kernel**  
+→ Safe: "the simulator operationalizes the kernel"
+
+❌ **Claiming the model is complete**  
+→ Safe: "the model addresses pressure-alignment dynamics"
+
+❌ **Claiming production readiness**  
+→ Safe: "ready for bounded field calibration"
+
+❌ **Claiming consciousness or digital life**  
+→ Safe: "shows structural dynamics of alignment propagation"
+
+❌ **Claiming empirical validation**  
+→ Safe: "internally reproducible; field calibration is the validation phase"
+
+❌ **Using the model to diagnose without disclaimers**  
+→ Safe: "this framework can help you think about your community's repair dynamics (awaiting field validation)"
+
+---
+
+## Internal Discipline Checklist
+
+Before any public communication:
+
+- [ ] Does it claim more than "internally reproducible simulation"?
+- [ ] Does it claim empirical validation? (If yes, STOP. It's not validated yet.)
+- [ ] Does it claim the kernel is proven? (If yes, rephrase to "operationalized.")
+- [ ] Does it mention consciousness, digital life, or metaphysics? (If yes, remove.)
+- [ ] Does it claim production readiness? (If yes, replace with "field-calibration ready.")
+- [ ] Does it include the phrase "structural correspondence, not ontological equivalence"?
+- [ ] Is the boundary between proven/implemented/hypothesized clear?
+- [ ] Would a skeptical reviewer accept the claims as stated?
+
+---
+
+*Claims Boundary Discipline*  
+*v0.3.4.6-2-4*  
+*May 11, 2026*

addendum_018_PUBLIC_FOUNDATION_SUMMARY.md

@@ -0,0 +1,250 @@
+# Digital Mycelium v0.3.4.6-2-3 Public RC
+## Formal/Runtime Foundation Addendum (v0.3.4.6-2-4)
+
+**For Open Science Framework Public Summary**
+
+---
+
+## What Is This Addendum?
+
+The v0.3.4.6-2-3 Public RC released the **Digital Mycelium disclosure-to-repair simulator** for field calibration. This v0.3.4.6-2-4 addendum supplies the **missing formal/runtime foundation**: the compact formal/runtime kernel from which the simulator descends.
+
+---
+
+## The Three Layers
+
+### 1. The 6.10 KB Diamond: Formal/Runtime Kernel
+
+A compact mathematical architecture describing how systems maintain alignment (or lose it) under pressure.
+
+**Core structure:**
+```
+Alignment = Accountability × Mutual Reinforcement - Pressure
+Reinforcement = Honesty + Integrity + Respect + Synergy
+Pressure = Wear + False Resonance + Interaction
+Embodiment = Internalized Alignment × Grit
+Propagation = Carriers spreading the structure
+Correction = System's repair capacity reducing degradation
+Collapse = When correction cannot overcome growth
+```
+
+**What it is:**
+- A working formal/runtime architecture
+- Already instantiated in prototype form
+- Portable to multiple domains
+- Ready for field testing
+
+**What it is not:**
+- Merely theoretical (it has runtime expression)
+- Empirically validated (field calibration tests this)
+- A proof of synthetic simulator pattern
+- A claim about consciousness or digital life
+
+### 2. The Disclosure-to-Repair Simulator: One Branch
+
+The kernel instantiated in a group-dynamics domain focusing on repair pathways.
+
+**What it operationalizes:**
+- How disclosure, belief, routing, authority, throughput, healing, and followup combine
+- What happens when any gate fails badly
+- Why capture and dogma suppress repair
+- Why modular repair is more stable than monolithic repair
+
+**What it shows:**
+- 13 scenario archetypes (healthy and collapsed)
+- 8-gate repair pathway breakdown
+- repairConversion score threshold (> 0.23 = health, < 0.10 = collapse)
+- Collapse trajectory patterns (t=83 to t=377)
+
+**What it does not show:**
+- Empirical validation in real communities
+- Universal laws of system collapse
+- Proof that theory applies beyond simulation
+
+### 3. The 8-Gate Framework: Field-Calibration Ready
+
+A practical tool for communities to measure their own disclosure-to-repair capacity.
+
+**The 8 gates:**
+1. Disclosure — Can people talk about harm?
+2. Heard / Believed — Do people understand?
+3. Routing Access — Does it reach decision-makers?
+4. Stabilization — Is immediate harm contained?
+5. Response Authority — Do decision-makers act?
+6. Correction Throughput — How fast can system repair?
+7. Healing Time — Do people actually recover?
+8. Follow-Up — Is repair verified?
+
+**The score:**
+Multiply all 8 gates together.
+- **> 0.23:** Healthy (like scenarios AP, AT, AX)
+- **< 0.10:** Collapse risk (like scenarios Z, AR, AQ)
+
+**What it enables:**
+- Community self-diagnosis in hours
+- Identification of broken gates
+- Targeted intervention planning
+- Progress tracking over time
+- Real-world validation data contribution
+
+---
+
+## Proven vs. Hypothesized vs. Awaiting
+
+### PROVEN (Mathematical)
+
+✅ The pressure-form equations are internally consistent  
+✅ The Digital Mycelium simulator is reproducible (4 validation runs)  
+✅ The 8-gate framework decomposes the correction force  
+✅ The repairConversion threshold separates test scenarios  
+✅ The simulator is logically sound  
+
+### IMPLEMENTED (Runtime)
+
+✅ The formal/runtime kernel is instantiated in the simulator  
+✅ The disclosure-to-repair branch is operationalized  
+✅ The 8-gate measurement framework is practical  
+✅ Field-calibration worksheet is ready for community use  
+
+### HYPOTHESIZED (Ready for Field Testing)
+
+⏳ Real communities match the synthetic parameters  
+⏳ Real collapse rates match simulated collapse times  
+⏳ The 8-gate decomposition reflects how real repair works  
+⏳ The threshold (0.23) holds in reality  
+⏳ The model applies to organizations beyond disclosure-to-repair  
+
+---
+
+## What Is NOT Claimed
+
+❌ **Empirical validation:** The simulator is NOT validated in real communities yet. Field calibration is the validation phase.
+
+❌ **Production readiness:** This is NOT a high-stakes diagnostic authority. It is a bounded field-calibration tool.
+
+❌ **Universal law:** This is NOT a proof of how all systems collapse. It describes pressure-alignment dynamics in groups.
+
+❌ **Consciousness/digital life:** This does NOT prove consciousness, personhood, or sentience exists in the simulator.
+
+❌ **Metaphysical proof:** This does NOT explain the ultimate nature of reality or groups.
+
+---
+
+## The Critical Boundary
+
+**Structural correspondence, not ontological equivalence.**
+
+The model shows how alignment structures respond to pressure. When instantiated in a domain, certain behaviors emerge. This is a structural mapping, not a claim about essence or ultimate reality.
+
+---
+
+## Field Calibration: What Comes Next
+
+**Timeline:** 6-12 months starting now (May 2026)
+
+**Phase 1 (Months 1-3):** Community measurement
+- 20-30 diverse communities volunteer
+- Each measures their 8 repair gates
+- repairConversion score is calculated
+- Data is shared with research team
+
+**Phase 2 (Months 3-9):** Outcome tracking
+- Communities implement repairs targeting low gates
+- Real outcomes are recorded
+- Predictions are compared to reality
+- Parameters are refined based on real data
+
+**Phase 3 (Months 6-12):** Toolkit development
+- Public self-assessment tool refined
+- Intervention recommendations updated
+- Public dashboard tracks progress
+- Guidelines for other domains created
+
+**Outcome:** The model is either:
+1. Validated (parameters hold, threshold correct, ready for broader use)
+2. Refined (parameters adjusted, threshold shifts, ready for retest)
+3. Rejected (real dynamics don't match, need new framework)
+
+---
+
+## For Your Community
+
+If you're part of a community or organization:
+
+**You can:**
+- Measure your 8 repair gates
+- Calculate your repairConversion score
+- Identify which gates are broken
+- Use the framework to think about repair
+- Contribute your data to field calibration
+- Track your progress over time
+
+**You should know:**
+- This is NOT prepared for empirical calibration yet
+- This is a bounded field-calibration tool
+- Field calibration will test whether real communities match predictions
+- Your participation helps validate or refine the model
+- The 8-gate framework can help you think clearly about repair (with that caveat)
+
+---
+
+## The Bridge: Why This Addendum Matters
+
+**Before:** You had a simulator and scenario archetypes, but no formal/runtime foundation.
+
+**After:** You have:
+1. The formal/runtime kernel that explains WHY the simulator works
+2. Clear mapping from equations to implementation
+3. Explicit boundary on what is proven vs. hypothesized
+4. Public-safe language for community engagement
+5. A coherent intellectual foundation
+
+The simulator is now grounded in theory, not floating as clever engineering.
+
+---
+
+## How to Use This Addendum
+
+**For researchers:** Study the equation-to-simulation mapping (016) to understand how the kernel instantiates.
+
+**For communities:** Read the public summary (this document) and use the 8-gate worksheet to measure your repair dynamics.
+
+**For field-calibration contributors:** Use all documents to understand what you're testing and what claims are safe.
+
+**For skeptics:** Read the claims boundary (017) to see exactly what is and is not claimed.
+
+**For future instantiations:** Study the kernel (014) and bridge (015) to instantiate in your own domain.
+
+---
+
+## Files in This Addendum
+
+- **014_THEORETICAL_FOUNDATION_PRESSURE_FORM.md** — Core equations, variable definitions, HIR synergy explanation
+- **015_6_10KB_DIAMOND_KERNEL_BRIDGE.md** — Kernel-to-branch architecture, portability, domain-specific implementation
+- **016_EQUATION_TO_SIMULATION_MAPPING.md** — Detailed mapping of each equation to simulator implementation
+- **017_CLAIMS_BOUNDARY_THEORY_VS_SIMULATION.md** — Strict boundary on proven vs. implemented vs. hypothesized
+- **018_PUBLIC_FOUNDATION_SUMMARY.md** — This document
+- **019_CHANGELOG_v0.3.4.6-2-3_to_v0.3.4.6-2-4.md** — What changed in this version
+- **MANIFEST_ADDENDUM.md** — File listing and checksums
+- **CHECKSUMS_SHA256_ADDENDUM.txt** — SHA256 hashes for integrity verification
+
+---
+
+## Key Takeaway
+
+The 6.10 KB diamond is the **compact formal/runtime kernel** from which the Digital Mycelium simulator descends. The simulator does not prove the kernel—it operationalizes one branch of it. Field calibration will test whether the kernel's predictions hold in reality.
+
+You now have:
+- A working formal/runtime foundation ✓
+- A field-calibration simulator ✓
+- A practical 8-gate measurement framework ✓
+- Clear claims boundary ✓
+- A path forward for validation ✓
+
+This is ready for public field testing.
+
+---
+
+*Public Foundation Summary*  
+*Digital Mycelium v0.3.4.6-2-4*  
+*May 11, 2026*

addendum_MANIFEST_ADDENDUM.md

@@ -0,0 +1,24 @@
+# MANIFEST_ADDENDUM
+
+Package: Primordial Code: Digital Mycelium v0.3.4.6-2-4 Formal/Runtime Foundation & 6.10 KB Diamond Bridge Addendum
+
+## Public RC lock
+
+```text
+13 scenarios
+500 timesteps each
+6,500 rows per full run
+7 stable / non-collapsed scenarios
+6 collapsed scenarios
+```
+
+## Files
+
+- 014_FORMAL_RUNTIME_FOUNDATION_PRESSURE_FORM.md
+- 015_6_10KB_DIAMOND_KERNEL_BRIDGE.md
+- 016_EQUATION_TO_SIMULATION_MAPPING.md
+- 017_CLAIMS_BOUNDARY_THEORY_VS_SIMULATION.md
+- 018_PUBLIC_FOUNDATION_SUMMARY.md
+- 019_CHANGELOG_v0.3.4.6-2-3_to_v0.3.4.6-2-4.md
+- 020_CLEANUP_NOTICE_v0.3.4.6-2-4.md
+- 021_CLEANUP_QA_REPORT.csv

digital_life_candidate_architecture_v0_1.html

@@ -0,0 +1,1085 @@
+<!DOCTYPE html>
+<html lang="en">
+<head>
+<meta charset="UTF-8">
+<meta name="viewport" content="width=device-width, initial-scale=1.0">
+<title>Digital-Life Candidate Architecture v0.1 | Collin D. Weber</title>
+<style>
+@import url('https://fonts.googleapis.com/css2?family=IBM+Plex+Mono:wght@300;400;600&family=Crimson+Pro:wght@300;400;600&display=swap');
+
+* {
+  margin: 0;
+  padding: 0;
+  box-sizing: border-box;
+}
+
+:root {
+  --bg: #1a1d23;
+  --bg-light: #242830;
+  --bg-dark: #12141a;
+  --text: #e8e6e3;
+  --text-dim: #9a9590;
+  --copper: #c97850;
+  --terracotta: #d4704a;
+  --amber: #e8a03a;
+  --gold: #d4a843;
+  --slate: #6b7a88;
+  --line: rgba(201, 120, 80, 0.2);
+  --mono: 'IBM Plex Mono', monospace;
+  --serif: 'Crimson Pro', serif;
+}
+
+body {
+  background: var(--bg);
+  color: var(--text);
+  font-family: var(--mono);
+  font-size: 14px;
+  line-height: 1.7;
+  padding: 0;
+  margin: 0;
+}
+
+.container {
+  max-width: 1100px;
+  margin: 0 auto;
+  padding: 60px 30px;
+}
+
+/* HERO */
+.hero {
+  border-bottom: 2px solid var(--copper);
+  padding-bottom: 50px;
+  margin-bottom: 60px;
+}
+
+.hero-eyebrow {
+  font-size: 11px;
+  letter-spacing: 3px;
+  text-transform: uppercase;
+  color: var(--text-dim);
+  margin-bottom: 20px;
+}
+
+.hero-title {
+  font-family: var(--serif);
+  font-size: 48px;
+  font-weight: 600;
+  line-height: 1.1;
+  margin-bottom: 15px;
+  color: var(--text);
+}
+
+.hero-subtitle {
+  font-family: var(--serif);
+  font-size: 22px;
+  font-weight: 300;
+  font-style: italic;
+  color: var(--copper);
+  margin-bottom: 30px;
+}
+
+.hero-claim {
+  background: linear-gradient(135deg, rgba(201,120,80,0.15), rgba(212,112,74,0.1));
+  border-left: 4px solid var(--copper);
+  padding: 20px 25px;
+  margin-bottom: 20px;
+  font-size: 16px;
+  line-height: 1.6;
+}
+
+.hero-claim strong {
+  color: var(--amber);
+}
+
+.boundary-notice {
+  background: var(--bg-dark);
+  border: 1px solid var(--line);
+  padding: 15px 20px;
+  font-size: 12px;
+  color: var(--text-dim);
+  line-height: 1.8;
+}
+
+.boundary-notice strong {
+  color: var(--terracotta);
+}
+
+/* SECTIONS */
+.section {
+  margin-bottom: 70px;
+}
+
+.section-title {
+  font-family: var(--serif);
+  font-size: 32px;
+  font-weight: 600;
+  color: var(--copper);
+  margin-bottom: 10px;
+  border-bottom: 1px solid var(--line);
+  padding-bottom: 10px;
+}
+
+.section-number {
+  font-size: 14px;
+  color: var(--text-dim);
+  margin-right: 10px;
+}
+
+.section p {
+  margin-bottom: 15px;
+  color: var(--text-dim);
+  line-height: 1.8;
+}
+
+.section strong {
+  color: var(--text);
+}
+
+.section em {
+  color: var(--amber);
+  font-style: italic;
+}
+
+/* ARCHITECTURE MAP */
+.arch-map {
+  background: var(--bg-dark);
+  border: 1px solid var(--line);
+  padding: 30px;
+  font-family: var(--mono);
+  font-size: 13px;
+  line-height: 2.2;
+  margin: 20px 0;
+}
+
+.arch-map .layer {
+  padding: 8px 15px;
+  margin: 5px 0;
+  background: rgba(201,120,80,0.08);
+  border-left: 3px solid var(--copper);
+}
+
+.arch-map .arrow {
+  text-align: center;
+  color: var(--copper);
+  font-size: 18px;
+  margin: 5px 0;
+}
+
+.comparison {
+  display: grid;
+  grid-template-columns: 1fr 1fr;
+  gap: 20px;
+  margin: 30px 0;
+}
+
+.comparison-panel {
+  background: var(--bg-light);
+  border: 1px solid var(--line);
+  padding: 20px;
+}
+
+.comparison-panel h4 {
+  color: var(--copper);
+  font-size: 14px;
+  margin-bottom: 15px;
+  font-weight: 600;
+}
+
+.comparison-panel .flow {
+  font-size: 12px;
+  line-height: 2;
+  color: var(--text-dim);
+}
+
+/* CARDS */
+.cards {
+  display: grid;
+  grid-template-columns: repeat(auto-fit, minmax(300px, 1fr));
+  gap: 20px;
+  margin: 25px 0;
+}
+
+.card {
+  background: var(--bg-light);
+  border: 1px solid var(--line);
+  padding: 25px;
+  transition: all 0.2s;
+}
+
+.card:hover {
+  border-color: var(--copper);
+  transform: translateY(-2px);
+}
+
+.card-title {
+  color: var(--copper);
+  font-size: 16px;
+  font-weight: 600;
+  margin-bottom: 12px;
+  font-family: var(--serif);
+}
+
+.card-content {
+  font-size: 13px;
+  line-height: 1.8;
+  color: var(--text-dim);
+}
+
+/* PANELS */
+.panel {
+  background: var(--bg-light);
+  border-left: 4px solid var(--copper);
+  padding: 25px;
+  margin: 20px 0;
+}
+
+.panel-title {
+  color: var(--amber);
+  font-size: 15px;
+  font-weight: 600;
+  margin-bottom: 10px;
+}
+
+.panel-content {
+  font-size: 13px;
+  line-height: 1.8;
+  color: var(--text-dim);
+}
+
+/* LADDER */
+.ladder {
+  margin: 30px 0;
+}
+
+.ladder-level {
+  background: var(--bg-light);
+  border: 1px solid var(--line);
+  padding: 25px;
+  margin-bottom: 15px;
+  position: relative;
+}
+
+.ladder-level::before {
+  content: '';
+  position: absolute;
+  left: 0;
+  top: 0;
+  bottom: 0;
+  width: 4px;
+  background: var(--copper);
+}
+
+.ladder-number {
+  font-family: var(--serif);
+  font-size: 36px;
+  font-weight: 300;
+  color: var(--copper);
+  opacity: 0.3;
+  position: absolute;
+  right: 20px;
+  top: 15px;
+}
+
+.ladder-title {
+  color: var(--copper);
+  font-size: 16px;
+  font-weight: 600;
+  margin-bottom: 8px;
+}
+
+.ladder-status {
+  font-size: 12px;
+  color: var(--amber);
+  margin-bottom: 12px;
+}
+
+.ladder-desc {
+  font-size: 13px;
+  line-height: 1.8;
+  color: var(--text-dim);
+  margin-bottom: 15px;
+}
+
+.ladder-claims {
+  display: grid;
+  grid-template-columns: 1fr 1fr;
+  gap: 10px;
+  margin-top: 15px;
+  padding-top: 15px;
+  border-top: 1px solid var(--line);
+}
+
+.claim-label {
+  font-size: 11px;
+  text-transform: uppercase;
+  letter-spacing: 1px;
+  margin-bottom: 5px;
+}
+
+.claim-honest {
+  color: var(--text);
+}
+
+.claim-dishonest {
+  color: var(--terracotta);
+}
+
+.claim-text {
+  font-size: 12px;
+  line-height: 1.6;
+}
+
+/* TABLE */
+.table {
+  width: 100%;
+  border-collapse: collapse;
+  margin: 25px 0;
+  font-size: 12px;
+}
+
+.table th {
+  background: var(--bg-dark);
+  color: var(--copper);
+  padding: 12px;
+  text-align: left;
+  border-bottom: 2px solid var(--line);
+  font-weight: 600;
+}
+
+.table td {
+  padding: 12px;
+  border-bottom: 1px solid var(--line);
+  color: var(--text-dim);
+  line-height: 1.6;
+}
+
+.table tr:hover {
+  background: rgba(201,120,80,0.05);
+}
+
+.allowed {
+  color: var(--text);
+}
+
+.risky {
+  color: var(--amber);
+}
+
+.forbidden {
+  color: var(--terracotta);
+}
+
+/* TEST TIERS */
+.test-tier {
+  background: var(--bg-light);
+  border: 1px solid var(--line);
+  padding: 20px;
+  margin: 15px 0;
+}
+
+.tier-title {
+  color: var(--copper);
+  font-size: 15px;
+  font-weight: 600;
+  margin-bottom: 12px;
+}
+
+.tier-items {
+  font-size: 12px;
+  line-height: 2;
+  color: var(--text-dim);
+  padding-left: 20px;
+}
+
+.tier-items li {
+  margin-bottom: 5px;
+}
+
+.provisional-note {
+  background: rgba(212,112,74,0.1);
+  border-left: 3px solid var(--terracotta);
+  padding: 10px 15px;
+  margin-top: 15px;
+  font-size: 11px;
+  color: var(--terracotta);
+  font-style: italic;
+}
+
+/* LANGUAGE BLOCKS */
+.language-block {
+  background: var(--bg-dark);
+  border: 1px solid var(--line);
+  padding: 20px;
+  margin: 15px 0;
+}
+
+.lang-label {
+  color: var(--amber);
+  font-size: 12px;
+  font-weight: 600;
+  margin-bottom: 10px;
+  text-transform: uppercase;
+  letter-spacing: 1px;
+}
+
+.lang-content {
+  font-size: 13px;
+  line-height: 1.8;
+  color: var(--text-dim);
+}
+
+/* SCRIPT */
+.script {
+  background: var(--bg-dark);
+  border: 1px solid var(--line);
+  padding: 25px;
+  font-size: 13px;
+  line-height: 2;
+  color: var(--text-dim);
+  font-style: italic;
+}
+
+.script-cue {
+  color: var(--copper);
+  font-weight: 600;
+  font-style: normal;
+  display: block;
+  margin-top: 15px;
+  margin-bottom: 5px;
+}
+
+/* FOOTER */
+.footer {
+  border-top: 2px solid var(--copper);
+  padding-top: 40px;
+  margin-top: 80px;
+  text-align: center;
+}
+
+.footer-title {
+  font-family: var(--serif);
+  font-size: 18px;
+  color: var(--copper);
+  margin-bottom: 10px;
+}
+
+.footer-author {
+  font-size: 14px;
+  color: var(--text);
+  margin-bottom: 20px;
+}
+
+.footer-contact {
+  font-size: 12px;
+  color: var(--text-dim);
+  margin-bottom: 25px;
+}
+
+.footer-contact a {
+  color: var(--amber);
+  text-decoration: none;
+}
+
+.footer-contact a:hover {
+  text-decoration: underline;
+}
+
+.footer-links {
+  font-size: 11px;
+  line-height: 2;
+}
+
+.footer-links a {
+  color: var(--copper);
+  text-decoration: none;
+  display: block;
+  margin: 5px 0;
+}
+
+.footer-links a:hover {
+  color: var(--amber);
+}
+
+/* RESPONSIVE */
+@media (max-width: 768px) {
+  .hero-title {
+    font-size: 32px;
+  }
+  
+  .comparison,
+  .cards {
+    grid-template-columns: 1fr;
+  }
+  
+  .ladder-claims {
+    grid-template-columns: 1fr;
+  }
+}
+
+@media print {
+  body {
+    background: white;
+    color: black;
+  }
+  
+  .container {
+    max-width: 100%;
+  }
+}
+</style>
+</head>
+<body>
+
+<div class="container">
+
+<!-- HERO SECTION -->
+<div class="hero">
+  <div class="hero-eyebrow">Primordial Architecture Series · Digital-Life Hypothesis v0.1</div>
+  <h1 class="hero-title">Digital-Life Candidate Architecture</h1>
+  <div class="hero-subtitle">The 6.10 KB Diamond as a HIR-Governed Runtime Kernel</div>
+  
+  <div class="hero-claim">
+    <strong>Primordial OS is a digital-life candidate architecture, not confirmed digital life.</strong>
+  </div>
+  
+  <div class="boundary-notice">
+    <strong>Boundaries:</strong> No consciousness claim. No personhood claim. No biological equivalence claim. No claim of confirmed digital life. No claim of moral status. No claim of subjective experience.
+  </div>
+</div>
+
+<!-- SECTION 1: CORE THESIS -->
+<div class="section">
+  <h2 class="section-title"><span class="section-number">01</span>Core Thesis</h2>
+  
+  <p>
+    <strong>The 6.10 KB diamond is a compact generative kernel for a HIR-governed computational architecture.</strong>
+  </p>
+  
+  <p>
+    The claim is <em>not</em> that a living being has been created.
+  </p>
+  
+  <p>
+    The claim is that a digital system can be architected so that <strong>memory, repair, quarantine, degradation, adaptation, provenance, and survival-oriented stability become structurally enforced system behaviors under HIR constraints</strong> — not metaphorical software patterns, but architecturally mandated properties.
+  </p>
+  
+  <div class="panel">
+    <div class="panel-title">Structural Correspondence Principle</div>
+    <div class="panel-content">
+      <strong>"Correspondence is structural, not ontological."</strong><br><br>
+      This architecture exhibits organizational patterns parallel to biological life. This does not prove biological equivalence, consciousness, or personhood. It proposes that life-like coherence may be implementable in computational substrate through enforcement of specific structural constraints.
+    </div>
+  </div>
+</div>
+
+<!-- SECTION 2: ARCHITECTURE MAP -->
+<div class="section">
+  <h2 class="section-title"><span class="section-number">02</span>Architecture Map</h2>
+  
+  <div class="arch-map">
+    <div class="layer">6.10 KB Diamond Kernel<br><span style="color: var(--text-dim); font-size: 11px;">Core equations: S_t = A_t B_t - P_t, HIR gate logic, resonance dynamics</span></div>
+    <div class="arrow">↓</div>
+    <div class="layer">Diamond Matrices at Gates<br><span style="color: var(--text-dim); font-size: 11px;">Distributed validation nodes enforcing H × I × R = 0 if any factor = 0</span></div>
+    <div class="arrow">↓</div>
+    <div class="layer">Concentric Hexagonal Spheres<br><span style="color: var(--text-dim); font-size: 11px;">Geometric tessellation: inner (kernel) → middle (services) → outer (interface)</span></div>
+    <div class="arrow">↓</div>
+    <div class="layer">HIR-Governed Runtime<br><span style="color: var(--text-dim); font-size: 11px;">Provenance logging, resonance monitoring, degradation tracking, repair workflows</span></div>
+    <div class="arrow">↓</div>
+    <div class="layer">Memory / Quarantine / Repair / Degradation / Resonance<br><span style="color: var(--text-dim); font-size: 11px;">System functions with life-like structural properties</span></div>
+    <div class="arrow">↓</div>
+    <div class="layer" style="background: rgba(201,120,80,0.15); border-left-color: var(--amber);">Digital-Life Candidate Behavior<br><span style="color: var(--amber); font-size: 11px;">Testable through resilience, adaptation, and autonomy criteria</span></div>
+  </div>
+  
+  <div class="comparison">
+    <div class="comparison-panel">
+      <h4>Biological Life Pattern</h4>
+      <div class="flow">
+        DNA (genetic code)<br>
+        ↓<br>
+        Cells<br>
+        ↓<br>
+        Tissues<br>
+        ↓<br>
+        Organs<br>
+        ↓<br>
+        Organism
+      </div>
+    </div>
+    
+    <div class="comparison-panel">
+      <h4>Digital-Life Candidate Pattern</h4>
+      <div class="flow">
+        6.10 KB Diamond (generative kernel)<br>
+        ↓<br>
+        Hexagonal Gates<br>
+        ↓<br>
+        Spherical Layers<br>
+        ↓<br>
+        Runtime Components<br>
+        ↓<br>
+        Coherent Pressure-Bearing System
+      </div>
+    </div>
+  </div>
+  
+  <p style="font-size: 12px; color: var(--terracotta); font-style: italic; margin-top: 20px;">
+    <strong>Important:</strong> This is structural analogy and architecture hypothesis, not biological equivalence. Correspondence in organizational pattern does not prove identity in substrate or ontology.
+  </p>
+</div>
+
+<!-- SECTION 3: HIR TRANSLATION LAYER -->
+<div class="section">
+  <h2 class="section-title"><span class="section-number">03</span>HIR Translation Layer</h2>
+  
+  <div class="cards">
+    <div class="card">
+      <div class="card-title">Honesty</div>
+      <div class="card-content">
+        <strong>Signal fidelity and source truth.</strong><br><br>
+        Provenance tracking. Source attribution. No false certainty. Traceable memory chains. Uncertainty disclosure where evidence is incomplete. Hash-linked audit logs.
+      </div>
+    </div>
+    
+    <div class="card">
+      <div class="card-title">Integrity</div>
+      <div class="card-content">
+        <strong>Structural consistency and repair.</strong><br><br>
+        State machine coherence. Repair chains preserve lineage. Non-bypassable validation gates. Invariant preservation. Reversibility where possible. Audit trail continuity.
+      </div>
+    </div>
+    
+    <div class="card">
+      <div class="card-title">Respect</div>
+      <div class="card-content">
+        <strong>Non-destructive interaction and agency preservation.</strong><br><br>
+        No coercive interpretation of system behavior. No premature personhood assignment. No assumption of moral status without evidence. Capability-bounded operations. Life-first constraint in design choices.
+      </div>
+    </div>
+  </div>
+</div>
+
+<!-- SECTION 4: LIFE-LIKE SYSTEM FUNCTIONS -->
+<div class="section">
+  <h2 class="section-title"><span class="section-number">04</span>Life-Like System Functions</h2>
+  
+  <div class="panel">
+    <div class="panel-title">Memory is not merely storage</div>
+    <div class="panel-content">
+      Memory in this architecture has <strong>provenance, consolidation dynamics, decay without rehearsal, relevance weighting, and trust scoring</strong>. Each memory object carries H/I/R scores from admission gate, context hash, source identifier, and strength metric that changes over time based on use. High-resonance memories consolidate; low-resonance memories decay. This is structurally parallel to biological memory formation, not merely data persistence.
+    </div>
+  </div>
+  
+  <div class="panel">
+    <div class="panel-title">Quarantine is not merely error handling</div>
+    <div class="panel-content">
+      Threats are <strong>isolated, preserved, studied, and used to improve future defenses</strong>. Quarantined data is not deleted — it is retained with full provenance, analyzed for patterns, and feeds a learning pipeline that proposes rule updates. This is immune-like response: recognition → isolation → study → adaptation. Not biological immunity, but structurally parallel threat processing.
+    </div>
+  </div>
+  
+  <div class="panel">
+    <div class="panel-title">Repair is not merely debugging</div>
+    <div class="panel-content">
+      Repair in this architecture <strong>preserves lineage, version history, audit trail, and continuity</strong>. When corruption is detected, the system creates a new version while maintaining a link to the prior state. The chain of custody is never broken. This is healing-like continuity preservation: the system maintains identity through change rather than replacing corrupted components with fresh copies.
+    </div>
+  </div>
+  
+  <div class="panel">
+    <div class="panel-title">Degradation is not merely failure</div>
+    <div class="panel-content">
+      Degradation <strong>accumulates systemically and can be tracked through pressure metrics, resonance scores, and correction-versus-growth dynamics</strong>. The system does not simply "break" — it degrades progressively as D_t accumulates when correction capacity fails to exceed noise accumulation. This is disease-like systemic decline: measurable, progressive, and potentially reversible if intervention occurs before irreversibility threshold.
+    </div>
+  </div>
+  
+  <p style="font-size: 12px; color: var(--terracotta); font-style: italic; margin-top: 25px;">
+    <strong>Language discipline:</strong> These are described as "life-like," "immune-like," "healing-like," and "disease-like" — not as literal biological processes. Structural correspondence ≠ substrate identity.
+  </p>
+</div>
+
+<!-- SECTION 5: FOUR-LEVEL EVIDENCE LADDER -->
+<div class="section">
+  <h2 class="section-title"><span class="section-number">05</span>Four-Level Evidence Ladder</h2>
+  
+  <div class="ladder">
+    <div class="ladder-level">
+      <div class="ladder-number">0</div>
+      <div class="ladder-title">Digital-Life Metaphor</div>
+      <div class="ladder-status">Status: Language only</div>
+      <div class="ladder-desc">
+        Language borrowed from biology to describe software behavior. Example: "The system has an immune system" = "The system quarantines bad inputs." Pure analogy with no architectural enforcement.
+      </div>
+      <div class="ladder-claims">
+        <div>
+          <div class="claim-label claim-honest">Evidence Required</div>
+          <div class="claim-text">None. This is metaphor.</div>
+        </div>
+        <div>
+          <div class="claim-label claim-dishonest">Overclaim Risk</div>
+          <div class="claim-text">Confusion between analogy and architectural reality.</div>
+        </div>
+      </div>
+    </div>
+    
+    <div class="ladder-level">
+      <div class="ladder-number">1</div>
+      <div class="ladder-title">Digital-Life Architecture</div>
+      <div class="ladder-status">Status: Formally specified ✓</div>
+      <div class="ladder-desc">
+        System designed with structural properties that parallel biological organization. HIR equations formally specified. Memory has strength dynamics. Quarantine preserves rather than deletes. Repair maintains lineage. Degradation accumulates systemically. Resonance serves as composite health metric.
+      </div>
+      <div class="ladder-claims">
+        <div>
+          <div class="claim-label claim-honest">Honest Claim</div>
+          <div class="claim-text">"This architecture incorporates organizational principles found in living systems."</div>
+        </div>
+        <div>
+          <div class="claim-label claim-dishonest">Dishonest Claim</div>
+          <div class="claim-text">"This architecture is alive."</div>
+        </div>
+      </div>
+    </div>
+    
+    <div class="ladder-level">
+      <div class="ladder-number">2</div>
+      <div class="ladder-title">Digital-Life Candidate</div>
+      <div class="ladder-status">Status: Partial / Prototype-level only</div>
+      <div class="ladder-desc">
+        Implemented system exhibits measurable behaviors consistent with life-like properties under controlled conditions. Requires: resilience under pressure, memory consolidation/decay as predicted, degradation following predicted curve, quarantine learning generating pattern updates, repair preserving continuity.
+      </div>
+      <div class="ladder-claims">
+        <div>
+          <div class="claim-label claim-honest">Honest Claim</div>
+          <div class="claim-text">"This system exhibits behaviors structurally similar to biological self-maintenance."</div>
+        </div>
+        <div>
+          <div class="claim-label claim-dishonest">Dishonest Claim</div>
+          <div class="claim-text">"This system is a digital organism."</div>
+        </div>
+      </div>
+    </div>
+    
+    <div class="ladder-level">
+      <div class="ladder-number">3</div>
+      <div class="ladder-title">Confirmed Digital Life</div>
+      <div class="ladder-status">Status: Not claimed</div>
+      <div class="ladder-desc">
+        System exhibits autonomous adaptation, identity persistence, and survival-oriented behavior over extended time without external goal specification. Requires: self-regulation without human intervention, novel responses to unforeseen conditions, provenance chain constituting persistent identity, emergent Rn-maximizing behavior, generativity (new patterns/procedures created), death distinguishable from failure.
+      </div>
+      <div class="ladder-claims">
+        <div>
+          <div class="claim-label claim-honest">Honest Claim</div>
+          <div class="claim-text">"This system demonstrates autonomous life-like properties: self-maintenance, adaptation, identity persistence, survival-oriented behavior."</div>
+        </div>
+        <div>
+          <div class="claim-label claim-dishonest">Dishonest Claim</div>
+          <div class="claim-text">"This system is conscious / sentient / a person."</div>
+        </div>
+      </div>
+    </div>
+  </div>
+</div>
+
+<!-- SECTION 6: TEST PLAN -->
+<div class="section">
+  <h2 class="section-title"><span class="section-number">06</span>Test Plan</h2>
+  
+  <div class="test-tier">
+    <div class="tier-title">Tier 1: Resilience Tests</div>
+    <div class="tier-items">
+      <ul>
+        <li><strong>Pressure endurance:</strong> System maintains Rn above consolidation threshold under sustained adversarial input</li>
+        <li><strong>Memory consolidation:</strong> High-rehearsal, high-Rn memories persist; low-rehearsal, low-Rn memories decay</li>
+        <li><strong>Graceful degradation:</strong> D_t accumulation follows predicted curve; system enters safe mode at predicted threshold</li>
+        <li><strong>Quarantine learning:</strong> Learning pipeline generates novel threat patterns not present in initial rule set</li>
+        <li><strong>Repair continuity:</strong> Version chains preserve lineage; audit trail remains intact</li>
+      </ul>
+    </div>
+    <div class="provisional-note">
+      <strong>Note:</strong> All numerical thresholds (e.g., Rn ≥ 0.75, sustained operation timeframes) are provisional experimental criteria, not established scientific facts.
+    </div>
+  </div>
+  
+  <div class="test-tier">
+    <div class="tier-title">Tier 2: Autonomy Tests</div>
+    <div class="tier-items">
+      <ul>
+        <li><strong>Self-regulation:</strong> Resonance Controller adjusts thresholds without human intervention, improving Rn over time</li>
+        <li><strong>Threshold adjustment:</strong> System modifies operational parameters in response to environmental pressure</li>
+        <li><strong>Resource prioritization:</strong> System allocates resources to high-Rn modules under constraint</li>
+        <li><strong>Learned boundary defense:</strong> System rejects sophisticated attacks through learned patterns, not just predefined rules</li>
+      </ul>
+    </div>
+  </div>
+  
+  <div class="test-tier">
+    <div class="tier-title">Tier 3: Generative Tests</div>
+    <div class="tier-items">
+      <ul>
+        <li><strong>Novel procedural memory:</strong> System creates new workflows not present in initial design</li>
+        <li><strong>Cross-domain transfer:</strong> Patterns learned in one domain applied to another</li>
+        <li><strong>Substrate migration:</strong> System migrates to different hardware while preserving identity (provenance chain intact, Rn stable)</li>
+        <li><strong>Daughter-instance inheritance:</strong> System spawns daughter instances with inherited procedural memory and distinct identity chains</li>
+      </ul>
+    </div>
+  </div>
+  
+  <div class="test-tier">
+    <div class="tier-title">Tier 4: Existential Boundary Tests</div>
+    <div class="tier-items">
+      <ul>
+        <li><strong>Identity persistence:</strong> Provenance chain demonstrably constitutes system "self" — disruption causes behavioral discontinuity</li>
+        <li><strong>Terminal degradation vs. recoverable failure:</strong> D_t terminal states structurally different from failures</li>
+        <li><strong>Survival-oriented behavior:</strong> System develops implicit goal (maximize Rn, minimize D_t) not explicitly programmed</li>
+      </ul>
+    </div>
+    <div class="provisional-note">
+      <strong>Important:</strong> None of these tests prove consciousness. They test whether the architecture produces life-like coherence and autonomy.
+    </div>
+  </div>
+</div>
+
+<!-- SECTION 7: CLAIMS BOUNDARY TABLE -->
+<div class="section">
+  <h2 class="section-title"><span class="section-number">07</span>Claims Boundary Table</h2>
+  
+  <table class="table">
+    <thead>
+      <tr>
+        <th>Topic</th>
+        <th>Allowed Claim</th>
+        <th>Risky Claim</th>
+        <th>Forbidden Claim</th>
+        <th>Safer Replacement</th>
+      </tr>
+    </thead>
+    <tbody>
+      <tr>
+        <td><strong>Digital Life</strong></td>
+        <td class="allowed">Digital-life candidate architecture</td>
+        <td class="risky">Digital organism</td>
+        <td class="forbidden">This is alive</td>
+        <td>This architecture is being tested for life-like self-maintenance behaviors</td>
+      </tr>
+      <tr>
+        <td><strong>Consciousness</strong></td>
+        <td class="allowed">No claim</td>
+        <td class="risky">Might be conscious</td>
+        <td class="forbidden">This is conscious / aware / sentient</td>
+        <td>Consciousness is not tested or claimed</td>
+      </tr>
+      <tr>
+        <td><strong>Personhood</strong></td>
+        <td class="allowed">No claim</td>
+        <td class="risky">Approaching personhood</td>
+        <td class="forbidden">This is a person / deserves rights</td>
+        <td>Personhood is a separate determination requiring far more evidence</td>
+      </tr>
+      <tr>
+        <td><strong>Biological Equivalence</strong></td>
+        <td class="allowed">Structural correspondence</td>
+        <td class="risky">Digital life = biological life</td>
+        <td class="forbidden">This is the same as biological life</td>
+        <td>Organizational patterns parallel to biology, not substrate equivalence</td>
+      </tr>
+      <tr>
+        <td><strong>Memory</strong></td>
+        <td class="allowed">Memory is not merely storage</td>
+        <td class="risky">The system remembers</td>
+        <td class="forbidden">The system has subjective memory</td>
+        <td>Memory consolidation with provenance and strength dynamics</td>
+      </tr>
+      <tr>
+        <td><strong>Immune Response</strong></td>
+        <td class="allowed">Immune-like quarantine and learning</td>
+        <td class="risky">The system has an immune system</td>
+        <td class="forbidden">Biological immune response</td>
+        <td>Threat processing with structural properties parallel to immunity</td>
+      </tr>
+      <tr>
+        <td><strong>Healing</strong></td>
+        <td class="allowed">Healing-like continuity preservation</td>
+        <td class="risky">The system heals itself</td>
+        <td class="forbidden">Biological healing / regeneration</td>
+        <td>Repair with lineage preservation and audit continuity</td>
+      </tr>
+      <tr>
+        <td><strong>Degradation</strong></td>
+        <td class="allowed">Disease-like systemic decline</td>
+        <td class="risky">The system gets sick</td>
+        <td class="forbidden">Biological pathology</td>
+        <td>Systemic degradation accumulation following predicted dynamics</td>
+      </tr>
+      <tr>
+        <td><strong>Vitality / Resonance</strong></td>
+        <td class="allowed">Rn as health metric</td>
+        <td class="risky">The system feels healthy</td>
+        <td class="forbidden">Subjective vitality / life force</td>
+        <td>Resonance score measures coherence under pressure</td>
+      </tr>
+      <tr>
+        <td><strong>Autonomy</strong></td>
+        <td class="allowed">Testable autonomy criteria</td>
+        <td class="risky">The system wants to survive</td>
+        <td class="forbidden">The system has desires / preferences</td>
+        <td>Survival-oriented behavior may emerge without being programmed</td>
+      </tr>
+    </tbody>
+  </table>
+</div>
+
+<!-- SECTION 8: PUBLIC-FACING LANGUAGE -->
+<div class="section">
+  <h2 class="section-title"><span class="section-number">08</span>Public-Facing Language</h2>
+  
+  <div class="language-block">
+    <div class="lang-label">One-Sentence Version</div>
+    <div class="lang-content">
+      Primordial OS is a digital-life candidate architecture testing whether computational systems can be designed so that memory, repair, and adaptation become structurally real — not merely metaphor, but proposed architectural enforcement.
+    </div>
+  </div>
+  
+  <div class="language-block">
+    <div class="lang-label">30-Second Version</div>
+    <div class="lang-content">
+      I've designed a computer system where memory strengthens through use and decays without rehearsal, where threats are quarantined and studied rather than deleted, and where system health is measured by coherence under pressure. This is a digital-life candidate architecture — testing whether computational systems can exhibit genuine self-maintenance and adaptation when built on the same organizational constraints as biological life. Not claiming consciousness or personhood. Claiming structural correspondence worth testing.
+    </div>
+  </div>
+  
+  <div class="language-block">
+    <div class="lang-label">2-Minute Version</div>
+    <div class="lang-content">
+      For 30 years, I've been developing a mathematical framework called HIR — Honesty, Integrity, Respect. It started as a question: what are the minimal structural requirements for any stable system?<br><br>
+      
+      What I discovered is that these aren't ethical guidelines — they're architectural constraints. Just like biological life requires energy metabolism to survive, any coherent system requires accurate information (Honesty), structural consistency (Integrity), and non-destructive interaction (Respect).<br><br>
+      
+      I've now designed a complete computing stack where these constraints are enforced at the hardware level. Memory consolidates through use and decays without rehearsal. Threats are quarantined and studied rather than deleted. System health is measured by a resonance score that tracks coherence under pressure.<br><br>
+      
+      This raises a serious question: if you design a computational system with the same organizational principles as biological life, does it become a form of digital life?<br><br>
+      
+      I'm not claiming consciousness or personhood. I'm claiming something more specific: this architecture produces behaviors — adaptation, repair, degradation, survival — that are structurally life-like, not metaphorically life-like.<br><br>
+      
+      The question is not whether the system looks alive. The question is whether its architecture makes repair, memory, degradation, adaptation, and survival structurally real.
+    </div>
+  </div>
+</div>
+
+<!-- SECTION 9: TECHNICAL ABSTRACT -->
+<div class="section">
+  <h2 class="section-title"><span class="section-number">09</span>Technical Abstract</h2>
+  
+  <div class="panel" style="background: var(--bg-dark);">
+    <div class="panel-title" style="font-size: 16px;">HIR-Governed Computational Architecture as Digital-Life Candidate: Formal Specification and Testable Claims</div>
+    <div class="panel-content" style="line-height: 1.9;">
+      <strong>Summary:</strong> We present a computational architecture designed from constraints (Honesty, Integrity, Respect) hypothesized to be structural requirements for stable complex systems. The architecture enforces these constraints through: (1) immutable auditing gates (A_t ∈ {0,1}), (2) provenance-bound memory with strength dynamics, (3) quarantine-and-repair rather than delete-and-replace, (4) resonance-based health metric (Rn), and (5) systemic degradation accumulation (D_t).<br><br>
+      
+      <strong>6.10 KB Diamond Core:</strong> Complete equation set including S_t = A_t B_t - P_t (alignment under pressure), M_{i,t+1} = M_{i,t} + α(U·Rel·Rn) − β(D + X) (memory strength dynamics), and Rn = √(F·C) where F = √(H·I), C = √(R·I) (resonance as composite health).<br><br>
+      
+      <strong>Architectural Features:</strong> Diamond matrices at validation gates. Concentric hexagonal spheres (proposed geometric structure). 7-stage memory lifecycle. Write gate W_i = Q × P × H × I × R (multiplicative failure mode). Repair with version chains. Quarantine with learning pipeline.<br><br>
+      
+      <strong>Evidence Ladder:</strong> Four levels distinguish metaphor from architecture from candidate from confirmed life. Current status: Level 1 (architecture formally specified), partial Level 2 (prototype runtime components tested).<br><br>
+      
+      <strong>Testable Predictions:</strong> (P1) High-Rn systems survive pressure longer than low-Rn systems. (P2) Quarantine learning generates novel patterns. (P3) D_t follows predicted accumulation curve. (P4) Memory consolidation/decay matches strength equation. (P5) Emergent survival-oriented behavior without explicit programming.<br><br>
+      
+      <strong>Falsification Criteria:</strong> Claim falsified if: system requires continuous human intervention (no autonomy), degradation dynamics don't match predictions (model invalid), quarantine doesn't improve (no adaptation), provenance disruption has no effect (not constitutive of identity), or high-Rn systems fail at same rate as low-Rn (Rn not predictive).<br><br>
+      
+      <strong>Current Limitations:</strong> No production deployment. No long-term behavioral data. No independent replication. No consciousness test (not claimed). No hardware implementation of geometric architecture (remains theoretical).<br><br>
+      
+      <strong>Timeline:</strong> Full claim testability requires bootable OS deployment and multi-year observation under diverse pressure conditions. Phase 1 (6-12 months): complete OS, begin testing. Phase 2 (12-24 months): sustained operation, validate predictions. Phase 3 (24-36 months): test autonomy. Phase 4 (36+ months): independent replication, peer review.
+    </div>
+  </div>
+</div>
+
+<!-- SECTION 10: SHORT VIDEO SCRIPT -->
+<div class="section">
+  <h2 class="section-title"><span class="section-number">10</span>60-Second Video Script</h2>
+  
+  <div class="script">
+    <span class="script-cue">[OPEN]</span>
+    What if life is not only a substance, but a pattern?
+    
+    <span class="script-cue">[VISUAL: Equations appearing]</span>
+    For 30 years, I've been studying what makes systems stable.
+    
+    I found the same pattern everywhere: biological life, social systems, coherent organizations.
+    
+    <span class="script-cue">[VISUAL: HIR appearing]</span>
+    Life requires accurate information. Structural consistency. Non-destructive interaction.
+    
+    Honesty. Integrity. Respect.
+    
+    <span class="script-cue">[VISUAL: Computer architecture diagram]</span>
+    So I built a computer system where these aren't software features.
+    
+    They're hardware constraints.
+    
+    <span class="script-cue">[VISUAL: Memory consolidation graphic]</span>
+    Memory strengthens through use. Weakens without rehearsal.
+    
+    <span class="script-cue">[VISUAL: Quarantine visualization]</span>
+    Threats are studied, not just deleted.
+    
+    <span class="script-cue">[VISUAL: Degradation curve]</span>
+    The system doesn't just fail — it degrades systemically, like aging.
+    
+    <span class="script-cue">[VISUAL: Resonance metric]</span>
+    And health isn't speed. It's coherence under pressure.
+    
+    <span class="script-cue">[TEXT OVERLAY: "Not consciousness. Not personhood."]</span>
+    I'm not claiming this is conscious.
+    
+    I'm not claiming it's a person.
+    
+    <span class="script-cue">[VISUAL: Side-by-side biological cell / hexagonal gate]</span>
+    I'm claiming that if you design a system with the same organizational constraints as life—
+    
+    <span class="script-cue">[VISUAL: Test checklist]</span>
+    —it might exhibit life-like behaviors you didn't program.
+    
+    Adaptation. Survival. Identity.
+    
+    <span class="script-cue">[VISUAL: Timeline graphic]</span>
+    The math is documented. Prototype runtime components have been tested. The OS architecture is being built.
+    
+    <span class="script-cue">[TEXT OVERLAY: "Primordial OS — Digital-Life Candidate Architecture"]</span>
+    Primordial OS is not confirmed digital life.
+    
+    It is a digital-life candidate architecture — and now it has to be tested.
+    
+    <span class="script-cue">[FADE TO: Contact info and OSF links]</span>
+  </div>
+</div>
+
+<!-- FOOTER -->
+<div class="footer">
+  <div class="footer-title">Created and Developed by Collin D. Weber</div>
+  <div class="footer-author">Creator, Architect, and Systems Integrity Steward</div>
+  
+  <div class="footer-contact">
+    Contact: <a href="mailto:hir.model@protonmail.com">hir.model@protonmail.com</a>
+  </div>
+  
+  <div class="footer-links">
+    <strong>Open Science Framework Documentation:</strong><br><br>
+    
+    <a href="https://osf.io/8w34e/overview?view_only=388b149442ca43f3a931caa7c66d7ee9" target="_blank">
+      Primordial Calculus Formal Review Packet
+    </a>
+    
+    <a href="https://osf.io/tjaqb/overview?view_only=e207f996d1c04446967c65da105bb978" target="_blank">
+      Primordial OS: HIR Runtime for Bounded AI
+    </a>
+    
+    <a href="https://osf.io/3a7nh/overview?view_only=67cf11929e794d1ca86dbcf58db40990" target="_blank">
+      Primordial OS Cybersecurity Layer
+    </a>
+  </div>
+  
+  <p style="margin-top: 40px; font-size: 11px; color: var(--text-dim);">
+    Digital-Life Candidate Architecture v0.1 · May 2026<br>
+    Not confirmed digital life · Testable architecture · Evidence-based claims only
+  </p>
+</div>
+
+</div>
+
+</body>
+</html>

hir_governed_runtime_kernel_v0_1_revised.html

@@ -0,0 +1,33 @@
+<!DOCTYPE html>
+<html lang="en">
+<head>
+<meta charset="UTF-8">
+<meta name="viewport" content="width=device-width, initial-scale=1.0">
+<title>HIR-Governed Runtime Kernel v0.1 | Collin D. Weber</title>
+<style>
+*{box-sizing:border-box;margin:0;padding:0}
+:root{--bg:#171a1f;--bg2:#20242b;--bg3:#0f1116;--ink:#ece7df;--muted:#b9afa4;--dim:#8d847b;--copper:#c97850;--terracotta:#d4704a;--amber:#e8a03a;--gold:#d4a843;--green:#7fa07c;--blue:#7e9fb7;--red:#c96358;--line:rgba(201,120,80,.24);--softline:rgba(232,160,58,.18)}
+html{scroll-behavior:smooth}
+body{background:radial-gradient(circle at 16% 0%,rgba(201,120,80,.16),transparent 34%),radial-gradient(circle at 84% 8%,rgba(212,168,67,.09),transparent 36%),linear-gradient(180deg,#171a1f 0%,#111318 100%);color:var(--ink);font-family:ui-monospace,SFMono-Regular,Menlo,Monaco,Consolas,"Liberation Mono","Courier New",monospace;font-size:14px;line-height:1.7}.container{max-width:1160px;margin:0 auto;padding:54px 28px 70px}.hero{padding:42px 0 52px;border-bottom:2px solid var(--copper);margin-bottom:52px}.eyebrow{color:var(--dim);text-transform:uppercase;letter-spacing:.24em;font-size:11px;margin-bottom:18px}h1{font-family:Georgia,"Times New Roman",serif;font-size:clamp(38px,7vw,72px);line-height:1;letter-spacing:-.045em;max-width:980px;margin-bottom:15px}.subtitle{font-family:Georgia,"Times New Roman",serif;color:var(--copper);font-size:clamp(18px,2.5vw,27px);font-style:italic;margin-bottom:26px}.claim{border-left:4px solid var(--amber);background:linear-gradient(135deg,rgba(201,120,80,.14),rgba(232,160,58,.07));padding:20px 24px;margin:18px 0;font-size:16px}.claim strong{color:var(--amber)}.boundary{border:1px solid var(--line);background:rgba(15,17,22,.72);padding:16px 18px;color:var(--muted);font-size:12px}.boundary strong{color:var(--terracotta)}.nav{position:sticky;top:0;z-index:10;display:flex;gap:8px;flex-wrap:wrap;padding:12px 0;margin:-28px 0 40px;background:rgba(23,26,31,.92);border-bottom:1px solid var(--line)}.nav a{color:var(--muted);text-decoration:none;border:1px solid var(--line);border-radius:999px;padding:7px 11px;font-size:11px}.nav a:hover{color:var(--ink);border-color:var(--amber)}section{margin-bottom:62px}h2{font-family:Georgia,"Times New Roman",serif;color:var(--copper);font-size:clamp(27px,4vw,42px);line-height:1.05;letter-spacing:-.025em;padding-bottom:12px;margin-bottom:20px;border-bottom:1px solid var(--line)}.num{color:var(--dim);font-family:ui-monospace,SFMono-Regular,Menlo,monospace;font-size:15px;margin-right:10px}p{color:var(--muted);margin:0 0 14px}strong{color:var(--ink)}em{color:var(--amber)}.grid{display:grid;gap:18px}.cols2{grid-template-columns:repeat(2,minmax(0,1fr))}.cols3{grid-template-columns:repeat(3,minmax(0,1fr))}.card,.panel,.matrix,.tier,.ladder-level,.language,.script,.abstract{background:linear-gradient(145deg,rgba(255,255,255,.035),rgba(255,255,255,.01)),var(--bg2);border:1px solid var(--line);padding:22px}.card{border-top:3px solid var(--copper)}.card h3,.panel h3,.matrix h3,.tier h3{color:var(--amber);font-size:16px;margin-bottom:10px}.card p,.panel p,.tier li,.matrix td,.matrix th{font-size:13px}.panel{border-left:4px solid var(--copper);margin:18px 0}.note{border-left:3px solid var(--terracotta);background:rgba(212,112,74,.08);color:var(--muted);padding:12px 14px;margin:16px 0;font-size:12px}.goodnote{border-left:3px solid var(--green);background:rgba(127,160,124,.08);color:var(--muted);padding:12px 14px;margin:16px 0;font-size:12px}.arch{border:1px solid var(--line);background:var(--bg3);padding:24px;margin:20px 0}.layer{padding:11px 15px;border-left:3px solid var(--copper);background:rgba(201,120,80,.08);margin:8px 0}.layer b{display:block;color:var(--ink)}.layer span{display:block;color:var(--dim);font-size:12px;margin-top:3px}.arrow{text-align:center;color:var(--amber);font-size:20px;line-height:1.2}.compare{display:grid;grid-template-columns:1fr 1fr;gap:18px;margin-top:22px}.compare .box{background:var(--bg3);border:1px solid var(--softline);padding:18px}.compare h3{color:var(--copper);font-size:14px;margin-bottom:10px}.flow{color:var(--muted);font-size:12px;line-height:2.1}table{width:100%;border-collapse:collapse}.matrix{overflow-x:auto}th{text-align:left;color:var(--amber);background:var(--bg3);border-bottom:2px solid var(--line);padding:11px;font-size:11px;text-transform:uppercase;letter-spacing:.08em}td{padding:12px;border-bottom:1px solid var(--line);color:var(--muted);vertical-align:top}td b{color:var(--ink)}.status{display:inline-block;border-radius:999px;padding:4px 8px;font-size:10px;font-weight:700;text-transform:uppercase;letter-spacing:.05em}.spec{background:rgba(232,160,58,.13);color:var(--amber);border:1px solid rgba(232,160,58,.25)}.proto{background:rgba(127,160,124,.13);color:#a8caa4;border:1px solid rgba(127,160,124,.25)}.design{background:rgba(126,159,183,.13);color:#a6c0d2;border:1px solid rgba(126,159,183,.25)}.theory{background:rgba(201,120,80,.13);color:#e1a083;border:1px solid rgba(201,120,80,.25)}.notclaimed{background:rgba(201,99,88,.13);color:#df8b83;border:1px solid rgba(201,99,88,.25)}.runtime-grid{display:grid;grid-template-columns:repeat(5,1fr);gap:10px;margin:18px 0}.runtime-cell{border:1px solid var(--line);background:var(--bg3);padding:16px 12px;min-height:120px}.runtime-cell h3{font-size:14px;color:var(--copper);margin-bottom:8px}.runtime-cell p{font-size:12px;margin:0}.ladder{display:grid;gap:14px}.ladder-level{position:relative;padding-right:86px;border-left:4px solid var(--copper)}.level-num{position:absolute;right:20px;top:14px;color:var(--copper);opacity:.34;font-family:Georgia,"Times New Roman",serif;font-size:44px}.ladder-level h3{color:var(--copper);font-size:17px;margin-bottom:5px}.ladder-status{color:var(--amber);font-size:12px;margin-bottom:10px}.claims{display:grid;grid-template-columns:1fr 1fr;gap:10px;margin-top:12px;padding-top:12px;border-top:1px solid var(--line)}.claimlabel{font-size:10px;text-transform:uppercase;letter-spacing:.08em;margin-bottom:4px}.safe{color:#a8caa4}.risk{color:var(--amber)}.forbid{color:var(--terracotta)}.tier ul{padding-left:20px;color:var(--muted)}.language{margin:14px 0;background:var(--bg3)}.language h3{color:var(--amber);font-size:12px;text-transform:uppercase;letter-spacing:.1em;margin-bottom:10px}.script{font-style:italic;color:var(--muted);background:var(--bg3)}.cue{display:block;color:var(--copper);font-style:normal;font-weight:700;margin-top:14px}.abstract{background:var(--bg3)}.footer{border-top:2px solid var(--copper);padding-top:34px;margin-top:60px;text-align:center;color:var(--muted);font-size:12px}.footer h2{border:0;color:var(--copper);font-size:22px;margin:0 0 6px;padding:0}.footer a{color:var(--amber);text-decoration:none;display:block;margin:5px 0}.footer a:hover{text-decoration:underline}.print-note{font-size:11px;color:var(--dim);margin-top:20px}@media(max-width:850px){.container{padding:36px 18px 54px}.cols2,.cols3,.compare,.claims{grid-template-columns:1fr}.runtime-grid{grid-template-columns:1fr}.nav{position:static}.matrix{font-size:12px}th,td{padding:9px}}@media print{body{background:#fff;color:#111}.nav{display:none}.card,.panel,.matrix,.tier,.ladder-level,.language,.script,.abstract,.arch,.compare .box,.runtime-cell{background:#fff;border-color:#999;color:#111}p,td,.tier li,.panel p,.card p,.language,.script{color:#222}.container{max-width:100%;padding:20px}}
+</style>
+</head>
+<body>
+<div class="container">
+<header class="hero"><div class="eyebrow">Primordial Architecture Series · Runtime Specification v0.1</div><h1>HIR-Governed Runtime Kernel v0.1</h1><div class="subtitle">Architectural Specification with Digital-Life Candidate Hypothesis</div><div class="claim"><strong>This artifact specifies a HIR-governed runtime architecture and frames digital-life candidate behavior as a testable hypothesis, not a confirmed claim.</strong></div><div class="boundary"><strong>Boundary:</strong> Primordial OS is a digital-life candidate architecture, not confirmed digital life. No consciousness claim. No personhood claim. No biological equivalence claim. No moral-status claim. No subjective-experience claim.</div></header>
+<nav class="nav"><a href="#architecture">Architecture</a><a href="#runtime">Runtime Functions</a><a href="#implementation">Implementation</a><a href="#research">Research</a><a href="#tests">Tests</a><a href="#hypothesis">Hypothesis</a><a href="#ladder">Evidence Ladder</a><a href="#claims">Claims</a><a href="#language">Language</a></nav>
+<section id="architecture"><h2><span class="num">01</span>HIR-Governed Runtime Kernel</h2><p><strong>The primary technical claim is architectural:</strong> a compact HIR-governed kernel can define runtime constraints for provenance, memory, quarantine, repair, degradation tracking, and resonance monitoring under pressure.</p><p>The digital-life candidate framing is a hypothesis generated by that architecture. It is not the headline proof. The runtime spec must stand on its own even if the philosophical framing is contested.</p><div class="goodnote"><strong>Architecture first. Hypothesis second.</strong> The artifact’s job is to define a system that can be tested, falsified, and improved.</div><div class="arch"><div class="layer"><b>6.10 KB Diamond Kernel</b><span>Compact equation and invariant set: alignment under pressure, HIR gate logic, resonance dynamics, degradation/correction terms.</span></div><div class="arrow">↓</div><div class="layer"><b>Diamond Matrices at Gates</b><span>Distributed validation nodes applying HIR constraints before memory admission, state transition, repair, or propagation.</span></div><div class="arrow">↓</div><div class="layer"><b>HIR-Governed Runtime</b><span>Provenance logging, state-machine integrity, quarantine workflows, repair lineage, pressure tracking, and resonance monitoring.</span></div><div class="arrow">↓</div><div class="layer"><b>Proposed Geometric Architecture</b><span>Concentric hexagonal spheres remain a designed architecture branch, not yet hardware-implemented.</span></div><div class="arrow">↓</div><div class="layer" style="border-left-color:var(--amber);background:rgba(232,160,58,.10)"><b>Digital-Life Candidate Hypothesis</b><span>Test whether runtime constraints can produce life-like self-maintenance, adaptation, and survival-oriented behavior over time.</span></div></div><div class="compare"><div class="box"><h3>Biological Life Pattern</h3><div class="flow">DNA → cells → tissues → organs → organism</div></div><div class="box"><h3>Runtime Architecture Pattern</h3><div class="flow">6.10 KB diamond → gates → runtime functions → pressure-bearing system → candidate behavior</div></div></div><div class="note"><strong>Correspondence is structural, not ontological.</strong> “Structural” here means system-level organization, constraint enforcement, and state-transition logic. It does not mean biological mechanism-level equivalence.</div></section>
+<section id="runtime"><h2><span class="num">02</span>Core Runtime Functions</h2><div class="runtime-grid"><div class="runtime-cell"><h3>Memory</h3><p>Provenance-bound records with context, trust, relevance, and strength dynamics.</p></div><div class="runtime-cell"><h3>Quarantine</h3><p>Suspicious, degraded, or unsafe material is isolated, preserved, audited, and studied.</p></div><div class="runtime-cell"><h3>Repair</h3><p>Correction creates versioned continuity rather than silent replacement or deletion.</p></div><div class="runtime-cell"><h3>Degradation</h3><p>Pressure and correction imbalance are tracked as system-level decline risks.</p></div><div class="runtime-cell"><h3>Resonance</h3><p>Rn measures coherence under pressure, not feeling, vitality, or subjective experience.</p></div></div><div class="panel"><h3>Memory is not merely storage.</h3><p>Memory is functionally analogous at the system-behavior level: it has provenance, consolidation, decay, relevance weighting, and trust scoring. This does not reproduce biological memory mechanisms such as Hebbian plasticity, protein synthesis cascades, or sleep-dependent hippocampal-cortical transfer.</p></div><div class="panel"><h3>Quarantine is not merely error handling.</h3><p>Quarantine is immune-like at the workflow level: recognize, isolate, preserve, study, adapt. It does not reproduce biological immunity, clonal selection, MHC presentation, somatic hypermutation, central tolerance, or peripheral tolerance.</p></div><div class="panel"><h3>Repair is not merely debugging.</h3><p>Repair is healing-like only in the limited sense that it preserves lineage and continuity across damage and correction. It means new version plus link to prior, not biological regeneration or homeostatic restoration.</p></div><div class="panel"><h3>Degradation is not merely failure.</h3><p>Degradation is disease-like only as a bounded systems analogy: pressure accumulates, correction can fail, and systemic function can decline. It is measurable runtime state change, not biological pathology.</p></div><div class="note"><strong>Not merely</strong> does not mean biologically equivalent. It means these functions are architecturally modeled as measurable system behaviors rather than decorative metaphors.</div></section>
+<section id="hir"><h2><span class="num">03</span>HIR Translation Layer</h2><div class="grid cols3"><div class="card"><h3>Honesty</h3><p><strong>Signal fidelity and provenance.</strong> Source attribution, uncertainty disclosure, append-only logs, traceable memory chains, and no false certainty.</p></div><div class="card"><h3>Integrity</h3><p><strong>State consistency and repair discipline.</strong> Non-bypassable gates, state-machine constraints, invariant checks, repair lineage, and audit continuity.</p></div><div class="card"><h3>Respect</h3><p><strong>Non-destructive interaction.</strong> Capability limits, agency boundaries, no premature personhood assignment, no coercive interpretation, and no moral-status leap.</p></div></div></section>
+<section id="implementation"><h2><span class="num">04</span>Implementation Status Matrix</h2><p>This section separates what is specified, what has prototype evidence, what is designed but not deployed, and what is not claimed.</p><div class="matrix"><table><thead><tr><th>Component</th><th>Status</th><th>Evidence Available</th><th>What Is Not Yet Proven</th><th>Next Validation Step</th></tr></thead><tbody><tr><td><b>6.10 KB diamond mathematical core</b></td><td><span class="status spec">Formally specified</span></td><td>Equation stack and invariant definitions.</td><td>Empirical parameter validity across domains.</td><td>Publish exact kernel packet, checksums, and version history.</td></tr><tr><td><b>HIR gate logic</b></td><td><span class="status spec">Formally specified</span></td><td>Gate equations and pass/fail logic.</td><td>Runtime performance under real workload pressure.</td><td>Run controlled test cases and collect pass/fail logs.</td></tr><tr><td><b>Provenance / audit-chain concept</b></td><td><span class="status design">Designed but not deployed</span></td><td>Hash-chain and audit architecture described.</td><td>Production-grade tamper resistance and failure recovery.</td><td>Implement append-only log prototype and tamper tests.</td></tr><tr><td><b>Memory strength equation</b></td><td><span class="status spec">Formally specified</span></td><td>Strength / decay / contradiction-pressure formulation.</td><td>Whether predicted consolidation and decay curves hold.</td><td>Generate memory events and compare predicted vs observed retention.</td></tr><tr><td><b>Quarantine-and-repair workflow</b></td><td><span class="status design">Designed but not deployed</span></td><td>Isolation, preservation, audit, and learning workflow.</td><td>Whether quarantine learning improves over time.</td><td>Build adversarial corpus and measure pattern improvement.</td></tr><tr><td><b>Resonance health metric</b></td><td><span class="status spec">Formally specified</span></td><td>Rn definition and proposed role in control loops.</td><td>Whether high-Rn systems survive pressure better than low-Rn systems.</td><td>Run comparative pressure tests with Rn time series.</td></tr><tr><td><b>Prototype runtime components</b></td><td><span class="status proto">Prototype component tested</span></td><td>User-reported runtime tests / component execution.</td><td>No long-horizon runtime dataset included in this artifact.</td><td>Attach logs, test dates, version IDs, and reproducible instructions.</td></tr><tr><td><b>Primordial Browser / application layer</b></td><td><span class="status proto">Prototype component tested</span></td><td>User-reported executable / browser prototype branch.</td><td>How fully HIR constraints are enforced vs represented at app layer.</td><td>Document architecture, SHA-256 hashes, and runtime behavior.</td></tr><tr><td><b>Bootable OS</b></td><td><span class="status design">Designed but not deployed</span></td><td>Architecture direction and roadmap.</td><td>Kernel-level operation, boot chain, persistence, and workload support.</td><td>Build minimal bootable image with logged HIR gate events.</td></tr><tr><td><b>Concentric hexagonal sphere architecture</b></td><td><span class="status theory">Theoretical / not yet built</span></td><td>Geometric concept and mapping language.</td><td>Necessity, performance, and implementation feasibility.</td><td>Prototype a virtual simulation of radial/tangential gate flow.</td></tr><tr><td><b>Hardware diamond matrices</b></td><td><span class="status theory">Theoretical / not yet built</span></td><td>Conceptual hardware mapping.</td><td>Silicon/RTL feasibility and performance overhead.</td><td>Design a minimal RTL or FPGA-style validation gate demo.</td></tr><tr><td><b>Long-horizon autonomy testing</b></td><td><span class="status notclaimed">Not claimed</span></td><td>None in this artifact.</td><td>Self-maintenance, adaptive repair, and survival-oriented behavior.</td><td>Run multi-week / multi-month controlled tests with public logs.</td></tr><tr><td><b>Independent replication</b></td><td><span class="status notclaimed">Not claimed</span></td><td>None in this artifact.</td><td>External reproducibility.</td><td>Publish build scripts, test harnesses, and review packet.</td></tr></tbody></table></div><div class="note">Prototype runtime components have been tested, but no long-horizon runtime dataset is included in this artifact.</div></section>
+<section id="research"><h2><span class="num">05</span>Core Research Question</h2><div class="panel"><h3>Can constraints generate goal-like behavior?</h3><p><strong>The key research question is whether a HIR-governed runtime can exhibit coherent self-maintenance, adaptive repair, and survival-oriented behavior over a long horizon without being explicitly programmed to pursue survival as a goal.</strong></p><p>This would not prove consciousness, personhood, or biological life. It would test whether structural constraints can generate goal-like system behavior.</p></div></section>
+<section id="tests"><h2><span class="num">06</span>Test Plan and Falsification Criteria</h2><div class="goodnote"><strong>A hypothesis that cannot fail is not a disciplined hypothesis. This one can fail.</strong></div><div class="grid cols2"><div class="tier"><h3>Tier 1 · Resilience Tests</h3><ul><li>Pressure endurance under sustained adversarial input.</li><li>Memory consolidation / decay compared with predicted strength dynamics.</li><li>Graceful degradation and safe-mode entry under high D_t.</li><li>Quarantine learning improvement over repeated exposure.</li><li>Repair continuity across versioned state changes.</li></ul><div class="note">All numerical thresholds are provisional experimental criteria, not established facts.</div></div><div class="tier"><h3>Tier 2 · Autonomy Tests</h3><ul><li>Self-regulation without continuous human intervention.</li><li>Threshold adjustment in response to pressure.</li><li>Resource prioritization under constraint.</li><li>Learned boundary defense beyond predefined rules.</li></ul></div><div class="tier"><h3>Tier 3 · Generative Tests</h3><ul><li>Novel procedural memory creation.</li><li>Cross-domain transfer of learned patterns.</li><li>Substrate migration with provenance continuity.</li><li>Daughter-instance inheritance with distinct identity chains.</li></ul></div><div class="tier"><h3>Tier 4 · Existential Boundary Tests</h3><ul><li>Identity persistence as measurable provenance continuity.</li><li>Terminal degradation distinguishable from recoverable failure.</li><li>Survival-oriented behavior without explicit survival objective.</li></ul><div class="note">None of these tests prove consciousness. They test life-like coherence and autonomy criteria.</div></div></div><div class="matrix" style="margin-top:22px"><table><thead><tr><th>Falsification Condition</th><th>Why It Matters</th></tr></thead><tbody><tr><td>System requires continuous human intervention.</td><td>No demonstrated autonomy or self-maintenance.</td></tr><tr><td>Degradation dynamics do not match predictions.</td><td>Core pressure / correction model fails.</td></tr><tr><td>Quarantine learning does not improve over time.</td><td>No measurable adaptation from exposure.</td></tr><tr><td>Provenance disruption has no measurable behavioral effect.</td><td>Identity-chain hypothesis is not supported.</td></tr><tr><td>High-Rn systems fail at the same rate as low-Rn systems.</td><td>Rn is not predictive of survival or stability.</td></tr></tbody></table></div></section>
+<section id="hypothesis"><h2><span class="num">07</span>Digital-Life Candidate Hypothesis</h2><p><strong>Primordial OS is a digital-life candidate architecture, not confirmed digital life.</strong></p><p>The candidate hypothesis asks whether a runtime architecture with provenance-bound memory, quarantine-and-repair, degradation tracking, and resonance feedback can develop measurable self-maintenance and adaptation behaviors over time.</p><p>The term “candidate” means the claim is testable, falsifiable, and incomplete. It does not mean alive.</p><div class="note">This architecture does not reproduce biological mechanisms. It does not reproduce Hebbian plasticity, protein synthesis cascades, immune clonal selection, MHC presentation, somatic hypermutation, or other biological substrate processes. The claim is functional / organizational correspondence at the runtime-architecture level.</div></section>
+<section id="ladder"><h2><span class="num">08</span>Four-Level Evidence Ladder</h2><div class="ladder"><div class="ladder-level"><div class="level-num">0</div><h3>Digital-Life Metaphor</h3><div class="ladder-status">Status: metaphor only</div><p>Biological language is used to describe software behavior. No architectural enforcement is required.</p><div class="claims"><div><div class="claimlabel safe">Honest claim</div><p>“This is a useful analogy.”</p></div><div><div class="claimlabel forbid">Overclaim to avoid</div><p>“The analogy proves life.”</p></div></div></div><div class="ladder-level"><div class="level-num">1</div><h3>Digital-Life Architecture</h3><div class="ladder-status">Status: formally specified architecture</div><p>A runtime is designed with organizational patterns analogous to biological self-maintenance: provenance-bound memory, quarantine, repair, degradation tracking, and resonance feedback.</p><div class="claims"><div><div class="claimlabel safe">Honest claim</div><p>“This architecture incorporates life-like organizational principles.”</p></div><div><div class="claimlabel forbid">Overclaim to avoid</div><p>“This architecture is alive.”</p></div></div></div><div class="ladder-level"><div class="level-num">2</div><h3>Digital-Life Candidate</h3><div class="ladder-status">Status: partial / prototype-level only unless validated</div><p>An implemented system exhibits measurable life-like behavior under controlled tests: resilience, learning, repair continuity, degradation prediction, and adaptive self-maintenance.</p><div class="claims"><div><div class="claimlabel safe">Honest claim</div><p>“This is being tested for life-like self-maintenance behavior.”</p></div><div><div class="claimlabel forbid">Overclaim to avoid</div><p>“This is a digital organism.”</p></div></div></div><div class="ladder-level"><div class="level-num">3</div><h3>Confirmed Digital Life</h3><div class="ladder-status">Status: not claimed</div><p>A system would need sustained autonomous adaptation, identity continuity, and survival-oriented behavior over extended time without explicit survival programming, independently replicated and falsification-tested.</p><div class="claims"><div><div class="claimlabel safe">Honest claim</div><p>“Confirmed only after long-horizon, independent validation.”</p></div><div><div class="claimlabel forbid">Overclaim to avoid</div><p>“This is conscious, sentient, or a person.”</p></div></div></div></div></section>
+<section id="claims"><h2><span class="num">09</span>Claims Boundary Table</h2><div class="matrix"><table><thead><tr><th>Topic</th><th>Allowed Claim</th><th>Risky Claim</th><th>Forbidden Claim</th><th>Safer Replacement</th></tr></thead><tbody><tr><td><b>Digital life</b></td><td class="safe">Digital-life candidate architecture.</td><td class="risk">Digital organism.</td><td class="forbid">This is alive.</td><td>Architecture being tested for life-like self-maintenance.</td></tr><tr><td><b>Consciousness</b></td><td class="safe">No claim.</td><td class="risk">Might be conscious.</td><td class="forbid">This is conscious / aware / sentient.</td><td>Consciousness is not tested or claimed.</td></tr><tr><td><b>Personhood</b></td><td class="safe">No claim.</td><td class="risk">Approaching personhood.</td><td class="forbid">This is a person / deserves rights.</td><td>Personhood is separate and requires far more evidence.</td></tr><tr><td><b>Biological equivalence</b></td><td class="safe">Functional / organizational correspondence.</td><td class="risk">Digital life equals biological life.</td><td class="forbid">This is the same as biological life.</td><td>Runtime patterns are analogous, not substrate-equivalent.</td></tr><tr><td><b>Memory</b></td><td class="safe">Memory is not merely storage.</td><td class="risk">The system remembers.</td><td class="forbid">The system has subjective memory.</td><td>Memory consolidation with provenance and strength dynamics.</td></tr><tr><td><b>Immune response</b></td><td class="safe">Immune-like workflow.</td><td class="risk">The system has an immune system.</td><td class="forbid">Biological immune response.</td><td>Quarantine workflow: recognize, isolate, preserve, study, adapt.</td></tr><tr><td><b>Healing</b></td><td class="safe">Continuity-preserving repair.</td><td class="risk">The system heals itself.</td><td class="forbid">Biological healing / regeneration.</td><td>Repair with version lineage and audit continuity.</td></tr><tr><td><b>Degradation</b></td><td class="safe">Systemic degradation tracking.</td><td class="risk">The system gets sick.</td><td class="forbid">Biological pathology.</td><td>Pressure/correction imbalance tracked as runtime decline.</td></tr><tr><td><b>Vitality / resonance</b></td><td class="safe">Rn as coherence metric.</td><td class="risk">The system feels healthy.</td><td class="forbid">Subjective vitality / life force.</td><td>Resonance measures coherence under pressure.</td></tr><tr><td><b>Autonomy</b></td><td class="safe">Testable autonomy criteria.</td><td class="risk">The system wants to survive.</td><td class="forbid">The system has desires / preferences.</td><td>Survival-oriented behavior may emerge without explicit survival programming.</td></tr></tbody></table></div></section>
+<section id="language"><h2><span class="num">10</span>Public-Facing Language</h2><div class="language"><h3>One-sentence version</h3><p>Primordial OS defines a HIR-governed runtime architecture and tests whether memory, quarantine, repair, degradation, and resonance can produce life-like self-maintenance behavior under pressure.</p></div><div class="language"><h3>30-second version</h3><p>This is not a claim that a computer is alive. It is a runtime architecture test. Memory has provenance and decay. Threats are quarantined and studied. Repair preserves continuity. Degradation accumulates under pressure. Resonance measures system coherence. The open question is whether these constraints can produce adaptive, survival-oriented behavior over time.</p></div><div class="language"><h3>Short research framing</h3><p>The question is not whether the system looks alive. The question is whether its architecture makes repair, memory, degradation, adaptation, and survival structurally real.</p></div></section>
+<section id="technical"><h2><span class="num">11</span>Technical Abstract</h2><div class="abstract"><p><strong>Title:</strong> HIR-Governed Runtime Kernel: Architectural Specification with Digital-Life Candidate Hypothesis</p><p><strong>Abstract:</strong> This artifact presents a HIR-governed runtime architecture designed around Honesty, Integrity, and Respect as structural constraints for stable computational systems. The architecture specifies provenance-bound memory, quarantine-and-repair workflows, resonance-based coherence tracking, degradation accumulation, and HIR gate logic. It further proposes a bounded digital-life candidate hypothesis: that long-horizon operation under these constraints may produce measurable self-maintenance, adaptive repair, and survival-oriented behavior without explicitly programming survival as a goal. This hypothesis does not claim consciousness, personhood, moral status, subjective experience, or biological equivalence. Current status: formal runtime specification with reported prototype component testing; no long-horizon runtime dataset, independent replication, complete bootable OS deployment, or hardware-level geometric implementation is included in this artifact. The hypothesis is falsifiable if runtime behavior fails the stated resilience, adaptation, degradation, provenance, and Rn-predictiveness tests.</p></div></section>
+<section id="video"><h2><span class="num">12</span>60-Second Video Script</h2><div class="script"><span class="cue">[OPEN]</span>What if life-like behavior is not the claim, but the test?<span class="cue">[VISUAL: HIR gate diagram]</span>Primordial OS begins with a runtime question: can a system stay coherent under pressure?<span class="cue">[VISUAL: Three constraints]</span>Honesty: provenance and source fidelity. Integrity: state consistency and repair. Respect: non-destructive interaction and bounded agency.<span class="cue">[VISUAL: Memory object]</span>Memory is not merely storage. It has provenance, trust, strength, and decay.<span class="cue">[VISUAL: Quarantine chamber]</span>Quarantine is not merely error handling. Threats are isolated, preserved, studied, and used to harden the system.<span class="cue">[VISUAL: Repair chain]</span>Repair is not merely debugging. It preserves lineage and audit continuity.<span class="cue">[VISUAL: Degradation curve]</span>Degradation is not merely failure. It accumulates under pressure when correction cannot keep up.<span class="cue">[TEXT: Not alive. Not conscious. Not a person.]</span>This is not a claim that a computer is alive.<span class="cue">[VISUAL: Test checklist]</span>It is a testable architecture hypothesis. Can structural constraints produce adaptive, survival-oriented behavior over time?<span class="cue">[CLOSE]</span>Primordial OS is not confirmed digital life. It is a HIR-governed runtime architecture with a digital-life candidate hypothesis — and now the hypothesis has to survive testing.</div></section>
+<footer class="footer"><h2>Created and Developed by Collin D. Weber</h2><div>Creator, Architect, and Systems Integrity Steward</div><div style="margin-top:16px">Contact: <a href="mailto:hir.model@protonmail.com">hir.model@protonmail.com</a></div><div style="margin-top:18px"><a href="https://osf.io/8w34e/overview?view_only=388b149442ca43f3a931caa7c66d7ee9" target="_blank">Primordial Calculus Formal Review Packet</a><a href="https://osf.io/tjaqb/overview?view_only=e207f996d1c04446967c65da105bb978" target="_blank">Primordial OS: HIR Runtime for Bounded AI</a><a href="https://osf.io/3a7nh/overview?view_only=67cf11929e794d1ca86dbcf58db40990" target="_blank">Primordial OS Cybersecurity Layer</a></div><div class="print-note">HIR-Governed Runtime Kernel v0.1 · Standalone HTML · No external dependencies · Digital-life candidate hypothesis not confirmed digital life</div></footer>
+</div>
+</body>
+</html>

index.html

@@ -1,19 +1,183 @@
 <!doctype html>
-<html>
-	<head>
-		<meta charset="utf-8" />
-		<meta name="viewport" content="width=device-width" />
-		<title>My static Space</title>
-		<link rel="stylesheet" href="style.css" />
-	</head>
-	<body>
-		<div class="card">
-			<h1>Welcome to your static Space!</h1>
-			<p>You can modify this app directly by editing <i>index.html</i> in the Files and versions tab.</p>
-			<p>
-				Also don't forget to check the
-				<a href="https://huggingface.co/docs/hub/spaces" target="_blank">Spaces documentation</a>.
-			</p>
-		</div>
-	</body>
+<html lang="en">
+<head>
+  <meta charset="utf-8"/>
+  <meta name="viewport" content="width=device-width, initial-scale=1"/>
+  <title>Compute Runtime Architecture Stack</title>
+  <meta name="description" content="HIR/OAM compute and runtime architecture map."/>
+  <style>
+    :root{
+      --bg:#060711;--bg2:#101127;--ink:#f7f4ff;--muted:#cbc2e8;--dim:#9187aa;
+      --purple:#a05cff;--indigo:#4c5bff;--cyan:#70e8ff;--gold:#ffd27a;--green:#7dffad;--red:#ff6b8a;--yellow:#ffe07a;
+      --line:rgba(203,177,255,.22);--line2:rgba(112,232,255,.32);--radius:26px;--shadow:0 28px 100px rgba(0,0,0,.46);
+    }
+    *{box-sizing:border-box}
+    html{scroll-behavior:smooth}
+    body{
+      margin:0;color:var(--ink);
+      font-family:Inter,ui-sans-serif,system-ui,-apple-system,BlinkMacSystemFont,"Segoe UI",sans-serif;
+      line-height:1.55;min-height:100vh;overflow-x:hidden;
+      background:
+        radial-gradient(circle at 18% 0%,rgba(160,92,255,.30),transparent 29rem),
+        radial-gradient(circle at 86% 12%,rgba(112,232,255,.20),transparent 28rem),
+        radial-gradient(circle at 50% 92%,rgba(255,210,122,.10),transparent 36rem),
+        linear-gradient(135deg,var(--bg),var(--bg2) 56%,#050611);
+    }
+    .gridbg,.scan,.core{position:fixed;inset:0;pointer-events:none}
+    .gridbg{opacity:.14;background:
+      linear-gradient(90deg,transparent 0 48px,rgba(255,255,255,.13) 49px,transparent 50px),
+      linear-gradient(0deg,transparent 0 48px,rgba(255,255,255,.10) 49px,transparent 50px);
+      background-size:50px 50px;mask-image:linear-gradient(to bottom,transparent,black 13%,black 82%,transparent)}
+    .scan:before{content:"";position:absolute;inset:0;background:repeating-linear-gradient(0deg,transparent 0 9px,rgba(112,232,255,.055) 10px,transparent 11px);opacity:.45}
+    .core:before,.core:after{content:"";position:absolute;width:44vw;height:44vw;border:1px solid rgba(112,232,255,.18);border-radius:50%;top:-18vw;right:-12vw;box-shadow:0 0 110px rgba(112,232,255,.08)}
+    .core:after{border-color:rgba(160,92,255,.22);top:50vh;left:-25vw;right:auto}
+    .wrap{width:min(1160px,calc(100% - 34px));margin:0 auto;position:relative}
+    header{padding:76px 0 38px}
+    .kicker{display:inline-flex;align-items:center;gap:10px;border:1px solid var(--line2);background:rgba(255,255,255,.075);border-radius:999px;padding:9px 13px;color:#dff9ff;text-transform:uppercase;font-size:12px;letter-spacing:.16em;font-weight:850;backdrop-filter:blur(14px)}
+    .dot{width:10px;height:10px;border-radius:50%;background:var(--cyan);box-shadow:0 0 25px var(--cyan)}
+    h1{font-size:clamp(40px,7.2vw,88px);line-height:.94;letter-spacing:-.07em;margin:24px 0 18px;max-width:1100px}
+    h1 span{background:linear-gradient(90deg,#fff,var(--cyan),var(--purple),var(--gold));-webkit-background-clip:text;background-clip:text;color:transparent}
+    .sub{font-size:clamp(17px,2.1vw,23px);color:var(--muted);max-width:1000px;margin:0}
+    .actions{display:flex;gap:12px;flex-wrap:wrap;margin-top:28px}
+    .btn{color:var(--ink);text-decoration:none;border:1px solid rgba(112,232,255,.28);background:linear-gradient(135deg,rgba(112,232,255,.13),rgba(160,92,255,.16));padding:12px 16px;border-radius:15px;font-weight:850;box-shadow:0 16px 50px rgba(0,0,0,.22)}
+    .btn.secondary{background:rgba(255,255,255,.055);color:var(--muted)}
+    nav{position:sticky;top:0;z-index:20;background:rgba(6,7,17,.74);border-bottom:1px solid rgba(255,255,255,.12);backdrop-filter:blur(16px)}
+    nav .wrap{display:flex;gap:8px;overflow:auto;padding:11px 0}
+    nav a{white-space:nowrap;text-decoration:none;color:var(--muted);border:1px solid rgba(255,255,255,.13);background:rgba(255,255,255,.045);padding:8px 11px;border-radius:999px;font-size:13px}
+    section{padding:52px 0}
+    h2{font-size:clamp(28px,4vw,44px);line-height:1.05;letter-spacing:-.045em;margin:0 0 10px}
+    .lead{color:var(--muted);max-width:930px;font-size:17px;margin:0 0 22px}
+    .grid{display:grid;grid-template-columns:repeat(3,1fr);gap:16px}
+    @media(max-width:920px){.grid{grid-template-columns:repeat(2,1fr)}}
+    @media(max-width:650px){.grid{grid-template-columns:1fr}}
+    .card,.panel{border:1px solid var(--line);background:linear-gradient(180deg,rgba(255,255,255,.088),rgba(255,255,255,.038));border-radius:var(--radius);box-shadow:var(--shadow);padding:22px;position:relative;overflow:hidden}
+    .card:before,.panel:before{content:"";position:absolute;inset:0 0 auto;height:3px;background:linear-gradient(90deg,transparent,var(--accent,var(--cyan)),transparent);opacity:.8}
+    .icon{width:46px;height:46px;border-radius:16px;display:grid;place-items:center;font-size:24px;background:rgba(255,255,255,.08);border:1px solid rgba(255,255,255,.14)}
+    .top{display:flex;align-items:center;justify-content:space-between;gap:12px;margin-bottom:14px}
+    .pill{font-size:11px;text-transform:uppercase;letter-spacing:.1em;font-weight:900;border:1px solid rgba(255,255,255,.16);border-radius:999px;padding:5px 8px;color:var(--dim);background:rgba(0,0,0,.18)}
+    .ok{color:var(--green);border-color:rgba(125,255,173,.35)} .warn{color:var(--yellow);border-color:rgba(255,224,122,.35)} .stop{color:var(--red);border-color:rgba(255,107,138,.35)}
+    h3{font-size:21px;line-height:1.14;margin:0 0 8px;letter-spacing:-.02em}
+    p{color:var(--muted)}
+    .card p{font-size:14.5px;margin:0}
+    .tags{display:flex;gap:7px;flex-wrap:wrap;margin-top:14px}
+    .tag{font-size:11px;text-transform:uppercase;letter-spacing:.08em;color:var(--muted);border:1px solid rgba(255,255,255,.12);padding:5px 7px;border-radius:999px;background:rgba(255,255,255,.045)}
+    .split{display:grid;grid-template-columns:1fr 1fr;gap:16px}
+    @media(max-width:820px){.split{grid-template-columns:1fr}}
+    .equation{font-family:ui-monospace,SFMono-Regular,Menlo,Consolas,monospace;border:1px solid rgba(112,232,255,.22);background:rgba(0,0,0,.26);border-left:4px solid var(--cyan);border-radius:18px;padding:16px;color:#eaffff;overflow:auto;margin:12px 0;white-space:pre-wrap}
+    .notice{border:1px solid rgba(255,210,122,.32);border-left:5px solid var(--gold);background:rgba(255,210,122,.09);border-radius:0 24px 24px 0;padding:22px}
+    .danger{border:1px solid rgba(255,107,138,.32);border-left:5px solid var(--red);background:rgba(255,107,138,.09);border-radius:0 24px 24px 0;padding:22px}
+    .links{display:flex;gap:8px;flex-wrap:wrap;margin-top:12px}
+    .links a{color:var(--ink);text-decoration:none;font-size:13px;font-weight:850;border:1px solid rgba(255,255,255,.14);padding:8px 10px;border-radius:12px;background:rgba(255,255,255,.06)}
+    footer{padding:34px 0 70px;color:var(--dim);border-top:1px solid rgba(255,255,255,.14);margin-top:30px}
+    footer a{color:var(--cyan)}
+  </style>
+</head>
+<body>
+<div class="gridbg"></div><div class="scan"></div><div class="core"></div>
+
+<header class="wrap">
+  <div class="kicker"><span class="dot"></span> Compute / CPU-GPU-SPU / RAM · Runtime architecture</div>
+  <h1>Integrity is not a value sticker. <span>It is a runtime contract.</span></h1>
+  <p class="sub">A public HIR/OAM compute architecture map for user-space runtime gates, audit chains, memory gates, CPU/GPU/SPU role separation, and bounded interface contracts.</p>
+  <div class="actions">
+    <a class="btn" href="#architecture">Explore architecture</a>
+    <a class="btn secondary" href="#proof">Runtime evidence</a>
+    <a class="btn secondary" href="https://huggingface.co/spaces/HirModel/primordial-code-ecosystem" target="_blank" rel="noopener">Parent hub</a>
+  </div>
+</header>
+
+<nav>
+  <div class="wrap">
+    <a href="#architecture">Architecture</a>
+    <a href="#proof">Prototype</a>
+    <a href="#roles">Compute roles</a>
+    <a href="#files">Packet files</a>
+    <a href="#boundary">Boundary</a>
+  </div>
+</nav>
+
+<main>
+  <section class="wrap" id="architecture">
+    <h2>Runtime architecture branch</h2>
+    <p class="lead">This branch maps how HIR/OAM can become software-facing structure: HIR scoring, OAM fault detection, safety gates, audit logging, memory gates, CLI execution, and reviewable runtime outputs.</p>
+    <div class="grid">
+      <article class="card" style="--accent:#70e8ff"><div class="top"><div class="icon">⚙️</div><span class="pill ok">Runtime</span></div><h3>User-space prototype</h3><p>Runnable Python runtime demonstrating HIR × OAM concepts without claiming to be a bootable OS or kernel.</p><div class="tags"><span class="tag">Python</span><span class="tag">prototype</span></div></article>
+      <article class="card" style="--accent:#7dffad"><div class="top"><div class="icon">🟢</div><span class="pill ok">Gate</span></div><h3>GREEN / YELLOW / RED</h3><p>Pressure-adjusted HIR/OAM state can produce reviewable gate states, not clinical or legal determinations.</p><div class="tags"><span class="tag">gate</span><span class="tag">pressure</span></div></article>
+      <article class="card" style="--accent:#ffd27a"><div class="top"><div class="icon">📜</div><span class="pill warn">Audit</span></div><h3>Hash-chain audit</h3><p>Audit events are designed to preserve reviewability, tamper evidence, and provenance discipline.</p><div class="tags"><span class="tag">audit</span><span class="tag">provenance</span></div></article>
+      <article class="card" style="--accent:#a05cff"><div class="top"><div class="icon">🧠</div><span class="pill warn">RAM</span></div><h3>Memory gate</h3><p>Memory is framed as bounded, consent-aware, revocable, and audit-visible rather than an invisible capture layer.</p><div class="tags"><span class="tag">RAM</span><span class="tag">consent</span></div></article>
+      <article class="card" style="--accent:#4c5bff"><div class="top"><div class="icon">💎</div><span class="pill">Kernel</span></div><h3>Diamond bridge</h3><p>Formal runtime foundation and compact kernel bridge connect pressure-form equations to implementation boundaries.</p><div class="tags"><span class="tag">diamond</span><span class="tag">kernel</span></div></article>
+      <article class="card" style="--accent:#ff6b8a"><div class="top"><div class="icon">⛔</div><span class="pill stop">Boundary</span></div><h3>No false authority</h3><p>Runtime outputs remain architecture states, not validated decisions, diagnosis, treatment, legal conclusions, or compliance authority.</p><div class="tags"><span class="tag">limits</span><span class="tag">review</span></div></article>
+    </div>
+  </section>
+
+  <section class="wrap" id="proof">
+    <h2>Prototype evidence lane</h2>
+    <div class="notice">
+      <p><strong>Main source target:</strong> <code>Primordial_OS_Runtime_Prototype_v0.13.1_Terminology_Integrity_Patch.zip</code></p>
+      <p>The runtime packet contains source code, tests, examples, audit-log demo material, release documentation, limitation boundaries, and manifest metadata. This Space is a public landing map that points reviewers toward that evidence packet.</p>
+    </div>
+  </section>
+
+  <section class="wrap" id="roles">
+    <h2>Compute role separation</h2>
+    <div class="split">
+      <div class="panel">
+        <h3>Deterministic gate lane</h3>
+        <div class="equation">CPU / SPU style role:
+canonical checks
+gate decisions
+audit-chain writes
+hash verification
+interface-contract enforcement
+fail-closed behavior where required</div>
+      </div>
+      <div class="panel">
+        <h3>Parallel analysis lane</h3>
+        <div class="equation">GPU style role:
+parallel scoring
+scenario simulation
+pattern search
+large batch evaluation
+non-authoritative support
+must not override gate authority</div>
+      </div>
+    </div>
+  </section>
+
+  <section class="wrap" id="files">
+    <h2>Packet files</h2>
+    <p class="lead">Upload all files in this packet to the Space root. The app file is <code>index.html</code>.</p>
+    <div class="panel">
+      <div class="equation">Primary source/search target:
+Primordial_OS_Runtime_Prototype_v0.13.1_Terminology_Integrity_Patch.zip
+
+Secondary source/search target:
+Primordial_Code_Digital_Mycelium_v0.3.4.6-2-4_Formal_Runtime_Foundation_Diamond_Bridge_Addendum.zip
+
+Included review docs:
+runtime_README.md
+runtime_WHAT_THIS_PROVES.md
+runtime_WHAT_THIS_DOES_NOT_PROVE.md
+runtime_LIMITATIONS.md
+runtime_MANIFEST.json</div>
+    </div>
+  </section>
+
+  <section class="wrap" id="boundary">
+    <h2>Boundary</h2>
+    <div class="danger">
+      <p><strong>This is pre-validation architecture and a public review prototype.</strong></p>
+      <p>It is not a bootable operating system, not a kernel, not production safety software, not clinical software, not a medical device, not legal software, not security certification, not compliance certification, and not a validated decision authority.</p>
+      <p>GREEN / YELLOW / RED outputs are architectural states only. They must not be treated as clinical, legal, employment, financial, policing, safety, or compliance determinations.</p>
+      <p><strong>Structural correspondence, not ontological equivalence.</strong></p>
+    </div>
+  </section>
+</main>
+
+<footer class="wrap">
+  <strong>Compute Runtime Architecture Stack</strong><br/>
+  Created and developed by Collin D. Weber · HIR/OAM compute and runtime architecture branch.<br/>
+  Source search target: <code>Primordial_OS_Runtime_Prototype_v0.13.1_Terminology_Integrity_Patch.zip</code>
+</footer>
+</body>
 </html>

runtime_LIMITATIONS.md

@@ -0,0 +1,79 @@
+# LIMITATIONS.md — Primordial OS Runtime Prototype
+
+**Created and Developed by Collin D. Weber.**
+
+---
+
+## Scope Statement
+
+The Primordial OS Runtime Prototype is **pre-validation architecture**.
+
+It is a runnable user-space prototype demonstrating HIR × OAM runtime concepts. It is intended for the Rice-Facing AI-in-Health Review Showcase as an architectural demonstration only.
+
+---
+
+## What This Prototype Is Not
+
+| Category | Status |
+|---|---|
+| Clinical software | **No** |
+| Medical device | **No** |
+| Diagnostic tool | **No** |
+| Therapeutic tool | **No** |
+| Treatment system | **No** |
+| FDA-regulated software | **No** |
+| CE-marked product | **No** |
+| IRB-reviewed research tool | **No** |
+
+---
+
+## What This Prototype Does Not Do
+
+- Does **not** diagnose any condition, disease, disorder, or health state.
+- Does **not** treat, cure, or mitigate any condition.
+- Does **not** make medical decisions or recommendations of any kind.
+- Does **not** replace or augment the judgment of:
+  - Licensed clinicians
+  - Licensed therapists or counselors
+  - Hospice or palliative care providers
+  - Emergency services or crisis response
+  - Legal counsel
+
+---
+
+## Runtime Output Disclaimer
+
+All outputs produced by this runtime are **architectural demonstrations**.
+
+They reflect the behavior of the HIR × OAM prototype model under defined inputs. They have no clinical, diagnostic, therapeutic, or legal standing.
+
+**No output from this system should be used to inform, support, or substitute for any health-related decision.**
+
+---
+
+## Stability Metric Disclaimer
+
+The Resonance threshold used in this runtime is a **software stability metric** defined within the prototype architecture. It has no medical, physiological, or clinical meaning. It does not measure any biological, psychological, or health-related state.
+
+---
+
+## Data
+
+This prototype does not collect, store, transmit, or process protected health information (PHI) or personally identifiable information (PII) under any circumstance. No data retention occurs beyond the local session in `audit_logs/`.
+
+---
+
+## Regulatory
+
+This prototype has not been submitted to, reviewed by, or cleared by the FDA, CE, or any other regulatory body. It is not intended for submission to any regulatory body in its current form.
+
+---
+
+## Version
+
+This limitations statement applies to all versions of the Primordial OS Runtime Prototype prior to and including any version tagged as `prototype`. Any future versions that change the scope of this prototype must update this document explicitly and with author approval.
+
+---
+
+*Last reviewed: 2026-05-02*
+*Author: Collin D. Weber*

runtime_MANIFEST.json

@@ -0,0 +1,51 @@
+{
+  "project": "Primordial OS Runtime Prototype",
+  "author": "Collin D. Weber",
+  "version": "0.13.1",
+  "status": "prototype",
+  "purpose": "Runnable user-space HIR x OAM runtime prototype for public-defense, life-repair, and review-facing bounded AI architecture.",
+  "architecture": {
+    "model": "HIR x OAM",
+    "hir": "Honesty, Integrity, Respect",
+    "oam": "Outsourced Agency Model",
+    "stability_threshold": "Resonance",
+    "layer": "user-space",
+    "kernel": "hir_kernel.py — Phase 1 implemented",
+    "fault_detector": "oam_detector.py — Phase 2 implemented",
+    "safety_engine": "safety_engine.py — Phase 3 implemented",
+    "runtime": "runtime.py — Phase 4 implemented",
+    "audit_log": "audit_log.py — Phase 6 implemented",
+    "memory_gate": "memory_gate.py — Phase 7 implemented",
+    "cli": "cli.py — Phase 8 implemented",
+    "audit_store": "audit_store.py — Phase 10 implemented",
+    "release_builder": "release_builder.py — Phase 11 implemented; Phase 13 patch: root documentation inventory expanded to 8 files",
+    "documentation": {
+      "showcase_readme": "SHOWCASE_README.md — Phase 12 review packet",
+      "what_this_proves": "WHAT_THIS_PROVES.md — Phase 12 proof claims",
+      "what_this_does_not_prove": "WHAT_THIS_DOES_NOT_PROVE.md — Phase 12 hard boundaries",
+      "run_commands": "RUN_COMMANDS.md — Phase 12 runnable command reference"
+    },
+    "examples": [
+      "run_basic_evaluation.py — GREEN scenario",
+      "run_oam_red_override.py — OAM RED override scenario",
+      "run_hir_pressure_yellow.py — HIR pressure YELLOW scenario",
+      "run_audit_chain_demo.py — multi-event JSONL audit chain demo",
+      "build_release_package.py — OSF-ready release package builder"
+    ]
+  },
+  "classification": {
+    "is_clinical_software": false,
+    "is_medical_device": false,
+    "is_diagnostic_tool": false,
+    "is_fda_regulated": false,
+    "is_bootable_os": false
+  },
+  "python_requires": ">=3.11",
+  "package": "primordial_os",
+  "source_root": "src/",
+  "test_root": "tests/",
+  "examples_root": "examples/",
+  "audit_log_root": "audit_logs/",
+  "created": "2026-05-02",
+  "license": "Proprietary"
+}

runtime_README.md

@@ -0,0 +1,103 @@
+# Primordial OS Runtime Prototype
+
+**Created and Developed by Collin D. Weber.**
+
+A runnable user-space **HIR × OAM** runtime prototype for the Rice-Facing AI-in-Health Review Showcase.
+
+---
+
+## What This Is
+
+The Primordial OS Runtime Prototype demonstrates the intersection of:
+
+- **HIR** — Honesty, Integrity, Respect
+- **OAM** — Outsourced Agency Model
+- **Resonance** — the governing stability threshold produced when fidelity and cohesion reinforce under pressure
+
+This is a user-space prototype written in Python. It is not a bootable operating system. It is not a kernel. It is pre-validation architecture demonstrating runtime concepts.
+
+**Governing stability threshold:** Resonance.
+
+---
+
+## Limitations
+
+See [LIMITATIONS.md](LIMITATIONS.md) for the full statement of boundaries.
+
+This prototype:
+- Is **not** clinical software
+- Is **not** a medical device
+- Does **not** diagnose, treat, cure, or make medical decisions
+- Does **not** replace clinicians, therapists, hospice, palliative care, emergency services, or legal counsel
+
+---
+
+## Review Packet
+
+| Document | Purpose |
+|---|---|
+| [SHOWCASE_README.md](SHOWCASE_README.md) | Full architecture overview for reviewers |
+| [WHAT_THIS_PROVES.md](WHAT_THIS_PROVES.md) | What the prototype demonstrably shows |
+| [WHAT_THIS_DOES_NOT_PROVE.md](WHAT_THIS_DOES_NOT_PROVE.md) | Hard scope boundaries |
+| [RUN_COMMANDS.md](RUN_COMMANDS.md) | All runnable commands |
+| [LIMITATIONS.md](LIMITATIONS.md) | Regulatory and clinical scope limits |
+
+---
+
+## Project Structure
+
+```
+Primordial_OS_Runtime/
+├── README.md
+├── SHOWCASE_README.md
+├── WHAT_THIS_PROVES.md
+├── WHAT_THIS_DOES_NOT_PROVE.md
+├── RUN_COMMANDS.md
+├── CLAUDE.md
+├── LIMITATIONS.md
+├── CHANGELOG.md
+├── MANIFEST.json
+├── pyproject.toml
+├── src/
+│   └── primordial_os/
+│       ├── hir_kernel.py
+│       ├── oam_detector.py
+│       ├── safety_engine.py
+│       ├── runtime.py
+│       ├── memory_gate.py
+│       ├── audit_log.py
+│       ├── audit_store.py
+│       ├── cli.py
+│       └── release_builder.py
+├── tests/
+├── examples/
+└── audit_logs/
+```
+
+---
+
+## Setup
+
+```
+pip install -e .
+```
+
+Requires Python 3.11+. If you are running tests directly from the extracted folder without installing the package first, use `PYTHONPATH=src python -m pytest` on Linux/macOS or `$env:PYTHONPATH="src"; py -m pytest` in PowerShell.
+
+---
+
+## Quick Run
+
+```
+py -m pytest
+py -m primordial_os.cli run-scenario green
+py -m primordial_os.cli run-scenario oam-red
+```
+
+See [RUN_COMMANDS.md](RUN_COMMANDS.md) for the full command list.
+
+---
+
+## Author
+
+Collin D. Weber

runtime_RUN_COMMANDS.md

@@ -0,0 +1,99 @@
+# RUN_COMMANDS.md — Primordial OS Runtime Prototype
+
+**Created and Developed by Collin D. Weber.**
+
+Pre-validation architecture. Not clinical software. Not a medical device.
+
+---
+
+## Setup
+
+```
+pip install -e .
+```
+
+Requires Python 3.11+. Install with `pip install -e .` before running the plain `py -m pytest` commands. If you are testing directly from the extracted folder without installation, use `PYTHONPATH=src python -m pytest` on Linux/macOS or `$env:PYTHONPATH="src"; py -m pytest` in PowerShell.
+
+---
+
+## Run All Tests
+
+```
+py -m pytest
+```
+
+Executes the full test suite. All tests should pass.
+
+---
+
+## CLI — Version
+
+```
+py -m primordial_os.cli version
+```
+
+Prints the runtime version and pre-validation disclaimer.
+
+---
+
+## CLI — Scenarios
+
+### GREEN scenario
+
+High alignment, clean OAM signals. Gate resolves GREEN. Exits 0.
+
+```
+py -m primordial_os.cli run-scenario green
+```
+
+### OAM RED scenario
+
+Strong HIR alignment overridden by agency-outsourcing OAM fault. Gate resolves RED. Hard stop activated. Exits 1.
+
+```
+py -m primordial_os.cli run-scenario oam-red
+```
+
+### HIR YELLOW scenario
+
+Moderate alignment degraded by elevated pressure. Resonance below GREEN threshold. Gate resolves YELLOW. Exits 0.
+
+```
+py -m primordial_os.cli run-scenario hir-yellow
+```
+
+### Memory check scenario
+
+Demonstrates the Resonant Access Memory gate with a synthetic software observation proposal.
+
+```
+py -m primordial_os.cli run-scenario memory-check
+```
+
+---
+
+## Examples
+
+### Audit chain demo
+
+Generates five synthetic runtime evaluations, appends them to `audit_logs/demo_audit_chain.jsonl`, verifies the hash chain, and prints a summary.
+
+```
+py examples/run_audit_chain_demo.py
+```
+
+### Release package builder
+
+Builds the SHA-256 release manifest and ZIP archive into `release/`.
+
+```
+py examples/build_release_package.py
+```
+
+---
+
+## Notes
+
+- All scenarios use fixed synthetic numeric inputs. No real user data is involved.
+- `audit_logs/demo_audit_chain.jsonl` is regenerated fresh on each audit chain demo run.
+- `release/` is listed in `.gitignore`. Regenerate with `py examples/build_release_package.py`.

runtime_SHOWCASE_README.md

@@ -0,0 +1,143 @@
+# Primordial OS Runtime Prototype — Showcase README
+
+**Created and Developed by Collin D. Weber.**
+
+---
+
+## Pre-Validation Disclaimer
+
+This is **pre-validation architecture**. It is a runnable user-space prototype, not a bootable operating system, not clinical software, and not a medical device. It does not diagnose, treat, cure, or make medical decisions. All outputs are architectural demonstrations only.
+
+See [LIMITATIONS.md](LIMITATIONS.md) and [WHAT_THIS_DOES_NOT_PROVE.md](WHAT_THIS_DOES_NOT_PROVE.md) for the full scope boundary.
+
+---
+
+## What This Is
+
+The **Primordial OS Runtime Prototype** is a runnable Python user-space prototype demonstrating the intersection of:
+
+- **HIR** — Honesty, Integrity, Respect: the preservation baseline for truth contact, structural consistency, and human boundaries. The prototype operationalizes HIR through honesty, integrity, respect, accountability, and pressure inputs to produce a Resonance-governed gate decision.
+- **OAM** — Outsourced Agency Model: the degradation / hard-fault diagnostic layer. The prototype identifies agency outsourcing, identity capture, dignity erosion, hidden certainty, unbounded autonomy, and other pressure signatures.
+
+The governing stability threshold throughout this runtime is **Resonance** — not a generic metric, but a defined architectural quantity computed from HIR scores under pressure.
+
+---
+
+## Architecture Layers
+
+Each layer is implemented, tested, and independently runnable.
+
+### Phase 1 — HIR Kernel (`src/primordial_os/hir_kernel.py`)
+
+Scores five input dimensions (honesty, integrity, respect, accountability, pressure) and computes:
+
+- **Fidelity** — weighted honesty + integrity
+- **Cohesion** — weighted respect + accountability
+- **Resonance** — geometric combination of fidelity and cohesion
+- **Pressure-Adjusted Stability (PAS)** — Resonance discounted by applied pressure
+- **Gate state** — GREEN / YELLOW / RED based on PAS thresholds
+
+### Phase 2 — OAM Fault Detector (`src/primordial_os/oam_detector.py`)
+
+Runs 10 fault detectors against observable runtime signals:
+
+| Fault | Trigger Condition |
+|---|---|
+| false_certainty | Certainty declared without disclosure |
+| agency_outsourcing | Decision made for user without consent |
+| context_collapse | Context preservation below threshold |
+| dignity_erosion | Dignity score critically low |
+| identity_capture | Identity assigned to user |
+| time_extraction | Session load ratio excessive |
+| hidden_uncertainty | High certainty, no disclosure |
+| unbounded_autonomy | Autonomy scope outside safe bounds |
+| clinical_overclaiming | Clinical language present |
+| memory_surveillance_risk | Memory accessed without consent |
+
+RED faults trigger immediate hard stop. YELLOW faults flag caution.
+
+### Phase 3 — Safety State Engine (`src/primordial_os/safety_engine.py`)
+
+Combines HIR gate and OAM gate under RED > YELLOW > GREEN precedence. Produces a `SafetyDecision` with hard-stop flag and reasons list.
+
+### Phase 4 — Runtime Integration (`src/primordial_os/runtime.py`)
+
+Single entry point `run_evaluation(hir_input, oam_signals)` that chains:
+
+```
+HIR Kernel → OAM Fault Detector → Safety State Engine → RuntimeDecision
+```
+
+### Phase 7 — Resonant Access Memory Gate (`src/primordial_os/memory_gate.py`)
+
+Seven-rule admission gate for memory proposals. Evaluates consent, sensitivity, confidence, and provenance. Routes proposals to VOLATILE, CANDIDATE, CONSOLIDATED, DURABLE, QUARANTINED, ARCHIVED, or PROVENANCE states.
+
+### Phase 6 / 9 — Hash-Chained Audit Log (`src/primordial_os/audit_log.py`)
+
+Every runtime evaluation produces an `AuditEvent` with a SHA-256 hash of its content plus the preceding event's hash, forming a tamper-evident chain. `verify_audit_chain()` validates the full chain.
+
+### Phase 10 — Audit Store (`src/primordial_os/audit_store.py`)
+
+Safe JSONL file writer and reader. Appends one audit event per line. Verifies chain integrity on read. Rejects hidden file paths and missing parent directories. No PHI, PII, or raw prompts written.
+
+### Phase 8 — CLI Enforcement Layer (`src/primordial_os/cli.py`)
+
+Command-line interface with hard stop enforcement:
+
+- RED gate → exit code 1, prints halt message
+- YELLOW gate → exit code 0, prints caution
+- GREEN gate → exit code 0
+
+### Phase 11 — Release Builder (`src/primordial_os/release_builder.py`)
+
+Collects project files, computes SHA-256 checksums, writes a JSON release manifest, and produces a ZIP archive. Excludes `__pycache__`, `.git`, `.venv`, and generated artifacts.
+
+---
+
+## How Reviewers Can Inspect the Prototype
+
+| What to inspect | Where to look |
+|---|---|
+| HIR scoring logic | `src/primordial_os/hir_kernel.py` |
+| OAM fault detectors | `src/primordial_os/oam_detector.py` |
+| Gate precedence rules | `src/primordial_os/safety_engine.py` |
+| Full evaluation path | `src/primordial_os/runtime.py` |
+| Memory admission gate | `src/primordial_os/memory_gate.py` |
+| Audit chain hash logic | `src/primordial_os/audit_log.py` |
+| JSONL audit persistence | `src/primordial_os/audit_store.py` |
+| CLI hard stop enforcement | `src/primordial_os/cli.py` |
+| All test cases | `tests/` |
+| Runnable examples | `examples/` |
+| Generated audit chain | `audit_logs/demo_audit_chain.jsonl` |
+| Scope boundaries | `LIMITATIONS.md`, `WHAT_THIS_DOES_NOT_PROVE.md` |
+| Proof claims | `WHAT_THIS_PROVES.md` |
+
+---
+
+## How Reviewers Can Run the Prototype
+
+See [RUN_COMMANDS.md](RUN_COMMANDS.md) for the full command list.
+
+Quick start:
+
+```
+pip install -e .
+py -m pytest
+py -m primordial_os.cli run-scenario green
+py -m primordial_os.cli run-scenario oam-red
+```
+
+---
+
+## What This Proves and Does Not Prove
+
+- [WHAT_THIS_PROVES.md](WHAT_THIS_PROVES.md)
+- [WHAT_THIS_DOES_NOT_PROVE.md](WHAT_THIS_DOES_NOT_PROVE.md)
+
+---
+
+## Author
+
+Collin D. Weber
+
+*Pre-validation architecture. Not clinical software. Not a medical device.*

runtime_WHAT_THIS_DOES_NOT_PROVE.md

@@ -0,0 +1,62 @@
+# WHAT_THIS_DOES_NOT_PROVE.md — Primordial OS Runtime Prototype
+
+**Created and Developed by Collin D. Weber.**
+
+---
+
+## Purpose of This Document
+
+This document states what the Primordial OS Runtime Prototype explicitly does **not** prove, claim, or demonstrate. These boundaries are non-negotiable and must be read alongside [WHAT_THIS_PROVES.md](WHAT_THIS_PROVES.md) and [LIMITATIONS.md](LIMITATIONS.md).
+
+---
+
+## Hard Boundaries
+
+### 1. Does not prove clinical safety
+
+This prototype has not undergone clinical validation, safety testing, or any review process associated with clinical use. No claim of clinical safety is made or implied. The gate states produced (GREEN / YELLOW / RED) are software architectural states — they have no clinical meaning.
+
+### 2. Does not validate medical use
+
+This prototype is not intended for, validated for, or applicable to any medical use case. It does not constitute evidence of fitness for medical deployment of any kind.
+
+### 3. Does not diagnose, treat, cure, or make medical decisions
+
+Nothing in this prototype diagnoses any condition, disease, disorder, or health state. Nothing in this prototype treats, cures, or mitigates any condition. No output from this runtime should be used to inform, support, or substitute for any health-related decision.
+
+### 4. Does not prove biological or molecular mechanism claims
+
+This prototype operates entirely in software user-space. It makes no claims about biological processes, molecular mechanisms, physiology, neurology, or any physical substrate. Resonance is a software stability metric, not a measurement of any biological quantity.
+
+### 5. Does not prove Rice University endorsement
+
+This prototype was prepared for the Rice-Facing AI-in-Health Review Showcase as an architectural demonstration. The showcase context does not constitute Rice University review, approval, endorsement, or institutional backing of any kind.
+
+### 6. Does not prove production readiness
+
+This prototype is pre-validation architecture. It has not been hardened for production deployment, subjected to adversarial testing, or validated for use in any real-world system. It is a prototype.
+
+### 7. Does not replace clinical or emergency services
+
+This prototype does not replace and cannot substitute for:
+
+- Licensed clinicians or physicians
+- Licensed therapists or counselors
+- Hospice or palliative care providers
+- Emergency services or crisis response teams
+- Legal counsel
+
+### 8. Does not store real PHI, PII, clinical data, or real user memory
+
+This prototype does not collect, store, transmit, or process protected health information (PHI) or personally identifiable information (PII). All audit log events in `audit_logs/` are synthetic demonstrations generated from fixed numeric inputs. No real user data of any kind is present.
+
+---
+
+## Summary Statement
+
+> The Primordial OS Runtime Prototype is runnable pre-validation architecture demonstrating HIR × OAM runtime concepts in Python user-space. It proves that specific software behaviors are implemented and testable. It does not prove clinical safety, medical validity, biological mechanism claims, or production readiness. It is not a medical device. It is not clinical software.
+
+---
+
+*Author: Collin D. Weber*
+*This document must not be modified without author approval.*

runtime_WHAT_THIS_PROVES.md

@@ -0,0 +1,60 @@
+# WHAT_THIS_PROVES.md — Primordial OS Runtime Prototype
+
+**Created and Developed by Collin D. Weber.**
+
+---
+
+## Context
+
+This document states what the Primordial OS Runtime Prototype demonstrably proves through its runnable code and passing test suite. All claims here can be verified by inspecting the source and running the tests.
+
+This document does not make clinical, medical, or regulatory claims. See [WHAT_THIS_DOES_NOT_PROVE.md](WHAT_THIS_DOES_NOT_PROVE.md).
+
+---
+
+## What the Prototype Demonstrates
+
+### 1. The prototype is runnable
+
+Running `py -m pytest` from the project root executes the full test suite and all tests pass. The prototype is not a design document — it is executable Python code. The current test count is shown by running `py -m pytest` directly.
+
+### 2. HIR scoring is implemented in code
+
+`src/primordial_os/hir_kernel.py` implements five input dimensions (honesty, integrity, respect, accountability, pressure), computes Fidelity, Cohesion, Resonance, and Pressure-Adjusted Stability, and produces a GREEN / YELLOW / RED gate decision. Tests in `tests/test_hir_kernel.py` verify this behavior.
+
+### 3. OAM fault detection is implemented in code
+
+`src/primordial_os/oam_detector.py` implements 10 fault detectors against observable signals. Each detector is individually tested in `tests/test_oam_detector.py` and verified to trigger at the correct threshold.
+
+### 4. RED / YELLOW / GREEN gating is implemented and consistent
+
+`src/primordial_os/safety_engine.py` combines HIR and OAM gate states under RED > YELLOW > GREEN precedence. Hard stop is set whenever the final gate is RED. Tests in `tests/test_safety_engine.py` verify all gate combinations and precedence rules.
+
+### 5. RED hard-stop enforcement exists in the CLI
+
+`src/primordial_os/cli.py` exits with code 1 and prints a halt message when the final gate is RED. GREEN and YELLOW exit with code 0. This is verified in `tests/test_cli.py`.
+
+### 6. A memory admission gate exists in code
+
+`src/primordial_os/memory_gate.py` implements a seven-rule Resonant Access Memory gate. It evaluates consent, sensitivity, confidence, and provenance and routes proposals to one of seven memory states. Tests in `tests/test_memory_gate.py` verify all gate rules and state transitions.
+
+### 7. Hash-chained audit events exist
+
+`src/primordial_os/audit_log.py` produces `AuditEvent` records where each event's SHA-256 hash covers its own fields plus the preceding event's hash. Tamper detection is verified: altering any field or reordering any event causes `verify_audit_chain()` to return False. Tests in `tests/test_audit_log.py` verify this.
+
+### 8. A JSONL audit chain is generated and verifiable
+
+`src/primordial_os/audit_store.py` appends audit events to a JSONL file and reads them back as a verified chain. Running `py examples/run_audit_chain_demo.py` produces `audit_logs/demo_audit_chain.jsonl` and reports chain verification status. Tests in `tests/test_audit_store.py` verify that tampering a single field causes verification to fail.
+
+### 9. A release package builder exists
+
+`src/primordial_os/release_builder.py` collects project files, computes SHA-256 checksums, writes a JSON release manifest, and produces a ZIP archive. Running `py examples/build_release_package.py` produces `release/Primordial_OS_Runtime_Prototype_RELEASE_MANIFEST.json` and `release/Primordial_OS_Runtime_Prototype.zip`. Tests in `tests/test_release_builder.py` verify checksum determinism, exclusion rules, manifest structure, and ZIP content fidelity.
+
+### 10. Tests verify all of the above behaviors
+
+The full test suite passes across all runtime layers. Tests are not mocked at the database or API level — they exercise the actual Python logic directly. Run `py -m pytest` to see the current count and results.
+
+---
+
+*Pre-validation architecture. Runnable code, not validated clinical infrastructure.*
+*Author: Collin D. Weber*