| # 003 — CANONICAL BOUNDARIES |
| ## What Is Established vs. What Is Forward-Looking |
| **Primordial Compute Stack v0.1 — Collin D. Weber** |
|
|
| --- |
|
|
| ## Purpose of This Document |
|
|
| This document draws a precise line between what is canonical, what is specified, what is |
| architecturally derived, and what is provisional. It does not promote any layer or document |
| to a status it has not earned. It does not simplify complexity in order to make the stack |
| appear more complete than it is. |
|
|
| This is the boundary record for v0.1. |
|
|
| --- |
|
|
| ## Classification Definitions |
|
|
| **CANONICAL SOURCE LAW** |
| Original framework documents from which all other materials are derived. |
| These define the variable symbols, equation forms, axioms, and governing rule-set. |
| Nothing in this bundle supersedes them. |
|
|
| **RUNNABLE PROTOTYPE** |
| Python code that has been executed, tested, and verified to route correctly. |
| The software exists, runs, and produces auditable output. |
| "Runnable" does not mean production-ready, security-certified, or formally verified. |
|
|
| **HARDWARE SPECIFICATION** |
| Architecture documented at the RTL level with register maps, instruction sets, and |
| SystemVerilog scaffold. The computation is architecturally defined and internally consistent. |
| The hardware does not physically exist. No FPGA synthesis has been performed. |
|
|
| **ARCHITECTURAL MAPPING** |
| A translation of an existing specification onto a different compute model, |
| derived through structural analysis of source materials. |
| An architectural mapping is a reasoned diagram, not an implementation. |
|
|
| **PROVISIONAL SPECIFICATION** |
| A forward-looking architectural proposal with defined equations, schemas, and invariants. |
| The proposal is internally consistent and grounded in the upstream canonical framework. |
| No running code, hardware, or simulation validates it yet. |
|
|
| **INTEGRATION SCAFFOLDING** |
| Bundle-level documentation created to connect the above layers. |
| Does not originate in the canonical framework. Does not claim canonical status. |
|
|
| --- |
|
|
| ## Per-Artifact Classification |
|
|
| ### Canonical Source Law |
|
|
| | File | Classification | Notes | |
| |------|---------------|-------| |
| | `docs_canonical/HIR_Architecture_Specification_v1.0_Collin_D_Weber.md` | **CANONICAL SOURCE LAW** | Variable Sheet v2 derivation. Defines H, I, R, F, C, Rn, P, G, B, S, U. Equation forms are upstream authority. | |
| | `docs_canonical/Primordial_OS_Baseline_Instruction_Set_v1.0_Collin_D_Weber.md` | **CANONICAL SOURCE LAW** | Defines HIR/OAM boundary, §3 kernel statement, §9 gate definitions, §11 equation stack, §12 operating loop, §13 permission states, §14 audit requirements, §18 failure modes, §19 repair protocol. | |
| | `docs_canonical/README_OSF.md` | **CANONICAL SOURCE LAW** | Primary release statement. Defines what the prototype is and is not. Limitations language authoritative. | |
|
|
| These three documents are the upstream law. The HIR Architecture Specification and Baseline |
| Instruction Set define every equation used in every layer of the stack. They are cited, not modified. |
|
|
| --- |
|
|
| ### Runnable Prototypes |
|
|
| | File | Classification | Verification Evidence | |
| |------|---------------|----------------------| |
| | `source_packages/Primordial_OS_HIR_Runtime_Prototype_v0_1_Collin_D_Weber_OSF.zip` (inner runtime) | **RUNNABLE PROTOTYPE** | SHA-256: `85b9fdf9...` · 24/24 tests pass · GREEN/YELLOW/RED routing confirmed · audit chain intact · 7 demo scenarios verified | |
| | `source_packages/Primordial_CyberSec_Suite_v0_1_Collin_D_Weber.zip` | **RUNNABLE PROTOTYPE** | Windows/Linux/macOS collectors · HIR bridge · triage rules · test suite included | |
|
|
| What "runnable" means: the code can be extracted and executed. The OS Runtime has a documented |
| verification summary (in `README_OSF.md`) that lists exact test counts and scenario outcomes. |
| What "runnable" does not mean: production-ready, security-certified, adversarially tested, |
| or formally verified. The LIMITATIONS.md inside each package is authoritative on this point. |
|
|
| --- |
|
|
| ### Hardware Specification |
|
|
| | File | Classification | Notes | |
| |------|---------------|-------| |
| | `source_packages/Primordial_HIR_SPU_Architecture_v0_1_Collin_D_Weber.zip` | **HARDWARE SPECIFICATION** | RTL scaffold (not synthesized). Architecture internally consistent. FPGA path defined; not executed. | |
|
|
| Contents of note: |
| - `rtl/hir_spu_top.sv` — SystemVerilog scaffold. Architecture-verified. Not manufacturing-verified. |
| The `sqrt_proxy` function in the RTL requires replacement with a proper LUT or integer sqrt |
| before FPGA synthesis (noted in `rtl/README_RTL.md`). |
| - `specs/SAFETY_INVARIANTS.md` — 8 hard invariants specified as silicon-level constraints. |
| These are intended constraints; their enforcement depends on correct RTL implementation. |
| - `sim/test_vectors.json` — simulation test vectors. These are input/expected-output pairs. |
| No simulation has been run against them in this session. |
|
|
| The architecture is real. The chip is not. |
|
|
| --- |
|
|
| ### Architectural Mappings |
|
|
| | File | Classification | Derivation Source | |
| |------|---------------|-------------------| |
| | `architecture_maps/Primordial_HIR_SPU_CPU_Map.html` | **ARCHITECTURAL MAPPING** | Derived from: `ARCHITECTURE_HIR_SPU_v0.1.md`, `REGISTER_MAP.md`, `INSTRUCTION_SET.md`, `hir_spu_top.sv`, `HIR_SPU_PIPELINE.txt`, `SAFETY_INVARIANTS.md`, `PACKET_SCHEMAS.json` | |
| | `architecture_maps/Primordial_HIR_SPU_GPU_Map.html` | **ARCHITECTURAL MAPPING** | Derived from: RTL `always_comb` block analysis, `equations.py`, `diamond.py`, `config.py`. Parallel gate independence verified structurally in source. No GPU code written. | |
| | `architecture_maps/Primordial_RAM_Architecture_v0_1.html` | **ARCHITECTURAL MAPPING + PROVISIONAL** | Derived from: canonical equation stack, `audit/log.py` schema, `KernelState`, `AuditRecord`. Extends these into a memory architecture proposal. Clearly provisional. | |
|
|
| The CPU and GPU maps are faithful visualizations of existing specifications and their structural |
| properties. They are architecture diagrams, not software or hardware. The GPU map in particular |
| is a structural analysis result: the independence of H, I, R gates and the P field is a property |
| that exists in the RTL source; the GPU warp mapping is a reasoned interpretation of that |
| property, not a novel claim. |
|
|
| --- |
|
|
| ### Provisional Specifications |
|
|
| | File | Classification | Notes | |
| |------|---------------|-------| |
| | `architecture_maps/Primordial_RAM_Architecture_v0_1.html` | **PROVISIONAL SPECIFICATION** | Equations defined. Schema defined. Safety invariants defined. No prototype, no running code, no simulation. | |
| | `osf_documents/Primordial_RAM_Architecture_v0_1_Collin_D_Weber.docx` | **PROVISIONAL SPECIFICATION** | OSF-format document for the RAM layer. Authorship: Collin D. Weber. Status: proposal. | |
|
|
| The RAM architecture is internally consistent with the upstream canonical framework. The Write Gate |
| equation (`W_i = Q × P × H × I × R`) is a natural extension of the HIR gate structure. The Memory |
| Strength and Recall Score equations are grounded in the Primordial Calculus variable set. |
|
|
| However: none of this has been run. The equations have not been computationally validated. |
| The schema has not been implemented. The lifecycle FSM has not been coded. The safety invariants |
| have not been tested. |
|
|
| **The RAM layer is the correctly-specified next step, not a completed layer.** |
|
|
| --- |
|
|
| ### Integration Scaffolding |
|
|
| | File | Classification | Notes | |
| |------|---------------|-------| |
| | `000_READ_ME_FIRST.md` | **INTEGRATION SCAFFOLDING** | Bundle entry point | |
| | `001_STACK_OVERVIEW.md` | **INTEGRATION SCAFFOLDING** | Layer-by-layer summary | |
| | `002_INTEGRATION_SPEC.md` | **INTEGRATION SCAFFOLDING** | Inter-layer interface definitions | |
| | `003_CANONICAL_BOUNDARIES.md` | **INTEGRATION SCAFFOLDING** | This document | |
| | `004_MANIFEST.md` | **INTEGRATION SCAFFOLDING** | File inventory | |
| | `005_SHA256_CHECKSUMS.sha256` | **INTEGRATION SCAFFOLDING** | Bundle integrity verification | |
|
|
| The integration scaffolding documents are not part of the canonical Primordial Calculus framework. |
| They are not authored as framework documents and should not be cited as such. |
| They are bundle-level connective tissue, authored to support navigation and integration review. |
|
|
| --- |
|
|
| ## What Has Not Been Claimed |
|
|
| For the avoidance of ambiguity, the following have not been claimed anywhere in this bundle: |
|
|
| - That the HIR-SPU hardware exists in physical form. |
| - That the GPU implementation exists in any form beyond an architectural diagram. |
| - That the RAM memory architecture has been prototyped or verified. |
| - That the running test suite constitutes formal verification of the framework's correctness. |
| - That the CyberSec Suite is a production security tool. |
| - That the canonical equations have been validated against the 300-year simulation referenced |
| in the framework documentation. |
| - That any component in this bundle is ready for production deployment. |
|
|
| The stack is real work at early prototype / specification stage. |
| The boundary between what runs and what is proposed is kept explicit throughout. |
|
|
| --- |
|
|
| ## Authorship Continuity |
|
|
| All component artifacts carry original authorship: **Created and Developed by Collin D. Weber.** |
| This bundle does not modify that attribution. The integration scaffolding documents (000–005) are |
| bundle-level, not framework-level, and do not carry framework authorship claims. |
|
|
