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. Thesqrt_proxyfunction in the RTL requires replacement with a proper LUT or integer sqrt before FPGA synthesis (noted inrtl/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.