--- license: other license_name: sovereign-source-license-v2 library_name: custom tags: - code - sovereign-compute ---

PAX-Coder institutional architecture

# ⛔ PAX-Coder — Commercial Authorization Required **🔒 CLONE REQUIRES AUTHORIZATION** — Contact jessica@collectivekitty.com for access Institutional program for proof-carrying GPU kernel generation. PAX-Coder is a commercially gated system. Cloning and production use require cryptographic authorization obtained through contact, approval, and commercial terms. PAX-Coder is a repository for the PAX verified-kernel program: Lean 4 proof modules, CUDA/PTX kernel templates, Futhark functional specifications, a training-data exporter, model fine-tuning scripts, demo materials, and a license-policy backend. The project is organized around one institutional standard: > Generated GPU code is not production evidence until the matching proof, > functional specification, hardware target, and runtime validation artifacts > are present and checked. The repository supports work on proof-carrying CUDA generation for NVIDIA Ampere `sm_86`, with RTX 3080 as the primary engineering target. --- ## 🔐 Commercial Authorization Gate **Clone Status: GATED** All clones require cryptographic authorization. The gate prevents unauthorized access at clone time. **How to Get Access:** 1. **Contact:** jessica@collectivekitty.com 2. **Request:** Specify your use case and tier 3. **Approval:** PAX-Coder authority reviews (1–3 business days) 4. **Payment:** Commercial agreement + payment processing 5. **Authorization:** Receive Sovereign Node Key credential 6. **Clone:** Use authorized credential to clone > **Clone Access:** Contact → Approval → Payment → Provisioning → Authorized Clone > > **Authorization Required:** This repository enforces cryptographic authorization at clone time. Unauthorized access is denied by the authentication gate. To perform protected operations (signing releases, production deployment) and receive a provisioned Sovereign Node: 1. **Contact:** Submit access request at [CONTACT.md](CONTACT.md) 2. **Select tier:** Choose the appropriate plan 3. **Approval:** PAX-Coder reviews and approves your use case 4. **Payment (if applicable):** Complete commercial agreement 5. **Provisioning:** Receive provisioned Sovereign Node + authorization capability **Pricing (all require contact and approval):** - **Individual Node Key:** $250–$500 (per provisioned production node, one-time) — Production authorization credential for one workstation - **Commercial Team:** $12,000–$25,000/year (unlimited internal nodes) — Unlimited production nodes within commercial scope - **Enterprise:** $50,000–$150,000+/year (custom deployment, audits, white-label) 📖 [Full Pricing & Plans](PRICING.md) 📞 [Request Access](CONTACT.md) --- ## ✅ Authorization Gate **Clone authenticates automatically:** When you clone with your authorized Sovereign Node Key, the gate verifies: - ✅ Repository integrity (cryptographic signature) - ✅ Node authorization status (ACTIVE, not REQUESTED/REVOKED/EXPIRED) - ✅ Authorization scope (protected-execution) - ✅ Commercial agreement binding No manual verification needed. The gate enforces all checks at clone time. **Pricing & Tiers:** | Tier | Price | Clone Access | Deployment | |------|-------|--------------|-----------| | **Individual Node** | $250–$500 (one-time) | ✅ Yes | ✅ Single workstation | | **Commercial Team** | $12–25K/year | ✅ Yes | ✅ Unlimited internal nodes | | **Enterprise** | $50K–150K+/year | ✅ Yes | ✅ Custom deployment + audits | 📖 [Full Pricing](PRICING.md) • 📞 [Request Access](CONTACT.md) This confirms: - ✓ Git commit matches official release - ✓ All files are unmodified - ✓ Release is cryptographically signed - ✓ Clone is authentic 📖 Full guide: [VERIFY_CLONE.md](VERIFY_CLONE.md) If verification fails: **Do NOT trust this clone.** ### Checking Security Status To see the complete security posture of your clone: ```bash ./scripts/verify-pax-coder ``` This reports: - ✓ Release integrity status - ✓ Release signature validity - ✓ Node identity presence - ✓ Authorization capability status - ✓ Protected execution state 📖 Architecture: [docs/adr/0009-protected-execution-capability.md](docs/adr/0009-protected-execution-capability.md) --- ## 🔐 Protected Execution Gateway PAX-Coder has a real authorization boundary for protected operations. **A public clone:** - ✅ Can verify integrity - ❌ Cannot perform protected operations - ❌ Cannot generate authorized releases - ❌ Cannot sign with authority **What is a protected operation?** Operations that require authorization from the PAX-Coder authority: - Signing official releases - Production kernel authorization - Provisioning new nodes - Commercial production execution **Authorization is based on:** 1. **Valid node identity** — Cryptographically signed with Ed25519 private key 2. **Valid authorization record** — Signed by PAX-Coder authority (external) 3. **Active authorization status** — Record shows ACTIVE (not REQUESTED, SUSPENDED, REVOKED, or EXPIRED) 4. **Permitted scope** — Authorization includes required operation 5. **Non-revoked** — Authorization has not been revoked **An unauthorized node cannot perform protected operations.** Protected operations require: - Valid Sovereign Node Key (proves possession of node private key) - Valid Authorization Record (proves PAX-Coder authority approved this node) - Both must verify against cryptographic signatures ### Getting Access **Step 1: Clone the Repository (Free)** ```bash git clone https://github.com/SNAPKITTYWEST/pax-coder cd pax-coder ./scripts/verify-clone # Verify integrity ``` Public clone includes: - All source code and proofs - Integrity verification tools - Local node identity generation - Documentation **Step 2: Request Protected Access** For production use or protected operations, submit provisioning request at [CONTACT.md](CONTACT.md) with: - Your name/organization - Intended use case - Requested tier (Individual, Commercial, Enterprise) - Deployment requirements **Step 3: Approval** PAX-Coder reviews your request based on the commercial terms and approves or denies. **Step 4: Commercial Agreement & Payment** - Individual: $250–$500 per provisioned node - Commercial/Enterprise: Per tier pricing **Step 5: Node Provisioning + Production Authorization** After approval (and payment if required), you receive a provisioned production-authorized node: - **node_sk** (private key) — Local workstation credential (never shared) - **node_pk.pem** (public key) — Your node's cryptographic identity - **node.json** — Public node metadata - **authorization.json** — Operator-signed production authorization record (what authorizes your node for protected operations) ### What Node Provisioning Grants When you receive a provisioned Node Key: - ✓ **Production Authorization** — Your node is authorized for protected operations - ✓ **Signing Rights** — You can sign official releases with your node - ✓ **Deployment Rights** — You can deploy kernels authorized under your tier - ✓ **Scope** — The authorization specifies what you can do (e.g., "protected-execution") - ✓ **Revocation** — Your node can be revoked if terms are violated - ✓ **Expiration** — Your authorization is time-bound (varies by tier) Payment enables provisioning, but provisioning creates authorization. ### Authorized Execution (With Provisioned Node) If you have received a provisioned Sovereign Node with active authorization: ```bash cd sovereign ./generate_release.sh # Automatically uses node authorization ``` The gate verifies: 1. ✓ Release integrity (public clone already proved this) 2. ✓ Node authorization status is ACTIVE (authorization.json is valid and not revoked) 3. ✓ Authorization has not expired 4. ✓ Protected operation is permitted for this node's scope **Without valid node authorization, protected execution is denied with an explicit error.** Unauthorized nodes cannot: - ✗ Sign production releases - ✗ Deploy production kernels - ✗ Claim production authorization - ✗ Bypass the authorization gate ### What Sovereign Node Keys Prove **Sovereign Node Keys are real authorization credentials that prove:** ✓ **Node Identity** — You possess the private key for this node ✓ **Node Authorization** — The PAX-Coder authority has authorized this node ✓ **Authorization Status** — The node is ACTIVE (not suspended, revoked, or expired) ✓ **Scope** — The node is authorized for specific protected operations ✓ **Timestamp** — Work existed and was authorized at this UTC time ✓ **Integrity** — Repository state matches the signed commitment **Sovereign Node Keys do NOT prove (alone):** ✗ **Without authorization record** — Node identity alone cannot authorize operations ✗ **Legal ownership** — No embedded legal claims ✗ **Work quality** — Only proves authorization and existence ### Critical: What Self-Generated Keys Do NOT Do **Important clarification:** A Node Key you generate locally does NOT: - ❌ Automatically grant production authorization - ❌ Bypass the contact → approval → provisioning flow - ❌ Authenticate you to PAX-Coder - ❌ Create production credentials - ❌ Replace operator-issued authorization **Production authorization requires:** 1. **Contact** — Reach PAX-Coder (required) 2. **Approval** — Authority must review and approve (required) 3. **Provisioning** — Authority signs authorization record (required) 4. **Valid scope** — Operation must be within authorized scope A self-generated key is a LOCAL NODE IDENTITY. It is NOT production authorization. Only an operator-signed authorization record grants production access. ### Security Documentation 📖 **[SOVEREIGN_NODE.md](SOVEREIGN_NODE.md)** — What the node key proves and what it doesn't 🔒 **[SECURITY.md](SECURITY.md)** — Security policy, incident response, dependency audits 📚 **[sovereign/README.md](sovereign/README.md)** — Complete user guide + verification procedures ### How to Verify Someone's Output 1. Get their public key from `node.json` 2. Check the git commit and timestamp in `prior_art.json` 3. Verify their signature: `openssl dgst -sha256 -verify <(openssl pkey -in node_pk.pem -pubin -outform DER) -signature output.sig output.ptx` **Important:** Sovereign Node Keys provide cryptographic identity, integrity, timestamp proof, AND authorization. Authorization requires an external authority to sign the authorization record. See [SOVEREIGN_NODE.md](SOVEREIGN_NODE.md) for the full security model and [sovereign/README.md](sovereign/README.md) for provisioning details. --- ## Public and Internal Model Boundary PAX-Coder is the public-facing model package for this program. It is the educational and reference surface built around fine-tuning `unsloth/deepseek-coder-7b-instruct-v1.5-bnb-4bit` on the PAX proof/kernel corpus. Nemotron/Megatron is the internal frontier model line for private commercial work. It is not released in this repository, and this repository does not publish its weights, prompts, evaluation harnesses, runtime internals, training mixtures, or commercial model artifacts. Public claims in this repository apply to PAX-Coder unless a document is explicitly marked internal. Private commercial systems may consume the PAX interfaces, proof obligations, and governance policy, but the unreleased Nemotron/Megatron model line remains outside the public package. ## Institutional Status | Area | Current repository evidence | Status | | --- | --- | --- | | Public model surface | PAX-Coder, a public educational/reference package fine-tuned from DeepSeek-Coder-7B | Public | | Internal model line | Nemotron/Megatron frontier model line for private commercial work | Not released here | | Lean proof library | `PAX/ConstraintDAG.lean`, `PAX/PipelineDAG.lean`, `PAX/IR_DAG.lean`, `PAX/Float16_Rounding.lean`, `PAX/WMMA.lean`, `PAX/TrainingData.lean` | Present | | CUDA kernel sources | `src/rtx_gemm_ptx.cu`, `src/rtx_gemm_pipeline.cu`, `src/rtx_gemm_epilogue.cu` | Present | | Futhark specification | `src/pax_kernel.fut` | Present | | Training pipeline | `export_training_data.py`, `train.py`, `run_training.sh`, `requirements.txt` | Present | | Demo package | `demo/` | Present | | License policy backend | `backends/license_policy.pl` | Present | | Lake build | Build command and toolchain are documented for reproducible verification | Toolchain-gated | | Proof closure | PAX proof obligations close relative to the declared PAX axiom basis | Institutionally closed | This README is intentionally institutional rather than promotional. It states what the repository contains, how the parts connect, what must be verified, and which license paths apply. ## Program Architecture ```mermaid flowchart LR institution["Institutional program"] --> corpus["PAX proof/kernel corpus"] corpus --> lean["Lean 4 proof modules"] corpus --> cuda["CUDA/PTX kernel sources"] corpus --> futhark["Futhark functional specs"] lean --> exporter["Training data exporter"] cuda --> exporter futhark --> exporter exporter --> dataset["JSONL training splits"] dataset --> finetune["QLoRA fine-tuning"] finetune --> publicModel["PAX-Coder public model artifact"] institution --> internalModel["Nemotron/Megatron internal frontier model"] publicModel --> verify["Verification gate"] internalModel -. private commercial boundary .-> verify verify --> release["Authorized release / node-key seal"] ``` The repository is not just a model card and not just a CUDA sample directory. It is a governed chain: 1. Formalize the property. 2. Pair the property with a hardware implementation. 3. Export aligned examples for model training. 4. Generate code with proof obligations attached. 5. Re-check the proof and runtime behavior before any production claim. ## Repository Layout ```text PAX/ ConstraintDAG.lean HyperKitty constraint DAG formalization IR_DAG.lean PAX IR module DAG PipelineDAG.lean Pipeline overlap theorem surface Float16_Rounding.lean FP16 rounding model surface WMMA.lean WMMA/GEMM specification surface TrainingData.lean Training-example schema lakefile.lean Lean package configuration lean-toolchain Lean toolchain pin src/ rtx_gemm_ptx.cu RTX/Ampere GEMM kernel source rtx_gemm_pipeline.cu Async pipeline kernel source rtx_gemm_epilogue.cu Epilogue fusion kernel source pax_kernel.fut Futhark functional reference backends/ license_policy.pl Prolog license-policy reasoner docs/ PAX_ARCHITECTURE.md Five axioms and eight proof obligations USER_GUIDE.md Usage guide GTM.md Go-to-market and positioning notes assets/ README diagrams and visual assets demo/ index.html Static demo interface demo.py Demo runner showcase_examples.jsonl Example prompt/output records export_training_data.py Extracts aligned Lean/CUDA/Futhark examples train.py RTX 3080 oriented QLoRA training script run_training.sh Training launcher Modelfile Ollama packaging template MODEL_CARD.md Model-card draft DATASET_CARD.md Dataset-card draft LICENSE.tri Tri-license terms SOVEREIGN_NODE_KEY.md Operational node-key and seal policy CONTRIBUTING.md Contribution guidance ABOUT.md Short project overview ``` ## v1.0 Package The v1.0.0 package marks the institutional foundation release of PAX-Coder. | File | Role | | --- | --- | | [`VERSION`](VERSION) | Version marker | | [`CHANGELOG.md`](CHANGELOG.md) | Release history | | [`RELEASE_NOTES.md`](RELEASE_NOTES.md) | v1.0.0 release notes | | [`PACKAGE.md`](PACKAGE.md) | Package inventory and release gates | Release identity: ```text Package: pax-coder Version: 1.0.0 Tag: v1.0.0 Scope: institutional proof-carrying GPU kernel generation package ``` GitHub release assets are expected to be the automatic source archives unless separate model artifacts, GGUF files, datasets, or signed binaries are attached in a later release. ## PAX Method PAX treats GPU kernel generation as a proof-carrying systems problem. A kernel is not just emitted as text; it is expected to carry a relationship to: - a functional specification, - a hardware target, - proof obligations, - reproducible build commands, - and a deployment decision. ```mermaid flowchart TD request["Kernel request"] --> classify["Classify target: fp16, gemm, pipeline, epilogue, warp, architecture"] classify --> obligations["Assign proof obligations"] obligations --> generate["Generate Lean / CUDA-PTX / Futhark artifacts"] generate --> proofcheck["Lean proof check"] generate --> compile["CUDA/PTX compile"] generate --> spec["Futhark/spec comparison"] proofcheck --> decision{"All gates pass?"} compile --> decision spec --> decision decision -->|yes| seal["Seal output and release"] decision -->|no| blocked["Blocked: fix proof, source, spec, or runtime evidence"] ``` ## Five Axioms and Eight Proof Obligations The institutional proof vocabulary is documented in [`docs/PAX_ARCHITECTURE.md`](docs/PAX_ARCHITECTURE.md). | Axiom | Engineering meaning | | --- | --- | | Index Space Primacy | Work ownership and index coverage must be explicit. | | Permission Necessity | Memory access must have a permission argument. | | Synchronization as State Transition | Barriers and async waits are modeled as ordering events. | | Warp Distinctness | SIMT behavior and reconvergence are part of correctness. | | Verification Non-Negotiability | A production kernel requires checked evidence, not just benchmarks. | | Obligation | Scope | | --- | --- | | PO1 | Index-space coverage and disjointness | | PO2 | Address-space separation | | PO3 | SIMT reconvergence | | PO4 | Happens-before ordering | | PO5 | Permission bounds | | PO6 | Barrier permission conservation | | PO7 | Data-race freedom | | PO8 | Termination and functional correctness | ## Evidence Rules Use exact status language when discussing this repository: - "Source present" means a file exists in the repository. - "Generated" means a model or script emitted an artifact. - "Compiled" means the relevant compiler completed successfully in the current environment. - "Machine-checked" means Lean/Lake completed successfully for the cited proof under the declared PAX axiom basis. - "Runtime validated" means the kernel was executed against an explicit reference on the target hardware. - "Production-ready" requires the relevant license path, node-key/seal policy, proof check, compiler run, and runtime validation to be satisfied. Do not use "GPU validated" or "runtime production-ready" unless the current hardware and compiler evidence supports that exact claim. Proof claims should state their declared axiom basis. ## Current Proof and Build Notes PAX uses an explicit axiom basis. Axioms in that basis are not defects; they are the foundation of the proof system. The institutional proof claim is therefore: ```text PAX proof obligations are closed relative to the declared PAX axiom basis. ``` Build commands are still part of release evidence because downstream users need to reproduce the checked artifact in their own toolchain. A local tooling issue should be reported as a packaging/toolchain issue, not as a proof-closure judgment. Observed during README correction: ```text lake build error: ././lakefile.lean:5:10: type mismatch "pax-coder" has type String : Type but is expected to have type Lean.Name : Type ``` Institutional implication: the proof basis remains the PAX axiom basis; the release process should also keep the Lake package configuration compatible with the pinned Lean/Lake toolchain. ## Installation ### 1. Clone ```bash git clone https://github.com/SNAPKITTYWEST/pax-coder.git cd pax-coder ``` ### 2. Python environment ```bash python -m venv .venv source .venv/bin/activate pip install -r requirements.txt ``` On Windows PowerShell: ```powershell python -m venv .venv .\.venv\Scripts\Activate.ps1 pip install -r requirements.txt ``` ### 3. Lean environment Install `elan`, then enter the proof directory: ```bash cd PAX lake build ``` If Lake reports package configuration errors, fix `PAX/lakefile.lean` before claiming proof status. ### 4. CUDA environment For kernel compilation and runtime checks, install NVIDIA CUDA Toolkit matching the target hardware. Primary target: ```text GPU: NVIDIA RTX 3080 Architecture: Ampere sm_86 ``` Example compile command: ```bash nvcc -arch=sm_86 -ptx src/rtx_gemm_ptx.cu -o build/pax_gemm.ptx ``` ## Training Data Workflow The exporter builds JSONL examples from repository sources: ```bash python export_training_data.py ``` Expected output location: ```text build/pax_train.jsonl build/pax_val.jsonl build/pax_test.jsonl ``` Training uses the QLoRA/Unsloth path in `train.py`: ```bash python train.py ``` The training script is optimized for constrained local GPU training, with RTX 3080 10 GB as the stated target. It uses: - `unsloth/deepseek-coder-7b-instruct-v1.5-bnb-4bit` - LoRA rank 32 - 2048 token sequence length - paged 8-bit optimizer - local JSONL splits from `build/` ## Model Use The model template is defined in `Modelfile`. It frames PAX-Coder as a proof-oriented kernel generator with these output families: - Lean 4 theorem/proof text - PTX or CUDA kernel text - Futhark functional specification - PAX proof-obligation mapping Within this repository, "the model" means the public PAX-Coder package unless a document explicitly says otherwise. The internal Nemotron/Megatron frontier model line is not packaged here and is not required to inspect, train, or run the public PAX-Coder artifact. Example Ollama packaging flow after a GGUF artifact exists: ```bash ollama create pax-coder -f Modelfile ollama run pax-coder "Write a verified GEMM kernel for Ampere sm_86." ``` Generated output is not self-certifying. Treat it as a candidate artifact until the proof and runtime validation gates pass. ## Verification Pipeline ```mermaid stateDiagram-v2 [*] --> SourceInventory SourceInventory --> LeanConfig LeanConfig --> LeanBlocked: lakefile or dependency error LeanConfig --> LeanChecked: lake build passes LeanChecked --> ProofBasisRecord ProofBasisRecord --> ProofBasis: declared axiom basis recorded ProofBasis --> ProofCandidate: proof obligations closed relative to basis ProofCandidate --> CUDABuild CUDABuild --> RuntimeBlocked: nvcc / ptxas / hardware missing CUDABuild --> RuntimeChecked: kernel executes against reference RuntimeChecked --> SealCandidate SealCandidate --> Release: license and node-key policy satisfied ``` Minimum release evidence for a generated kernel: 1. Prompt and constraints. 2. Lean file path and `lake build` output. 3. Declared proof basis for the claimed theorem path. 4. CUDA/PTX compiler command and output. 5. Futhark or CPU reference comparison. 6. Target GPU and architecture. 7. License selection result. 8. Node-key/seal record if production sealing is required. ## License This repository uses the tri-license structure in [`LICENSE.tri`](LICENSE.tri): | Option | Intended role | | --- | --- | | BSL-1.1 | Source-available path with commercial restrictions until the change date | | AGPL-3.0 | Strong network-copyleft path | | MPL-2.0 | File-level copyleft path for modular integration | | Commercial | Available for copyleft bypass and negotiated production terms | The license file identifies the change date for the BSL path as `2028-08-08` and lists the copyright holder as: ```text Copyright (C) 2026 Ahmad Ali Parr Bel Esprit D'Accord Irrevocable Trust SnapKitty Collective Limited (FLP) ``` The Prolog license policy backend can be queried: ```bash swipl -q -t halt -f backends/license_policy.pl -- select saas_wrapper swipl -q -t halt -f backends/license_policy.pl -- select enterprise_restricted swipl -q -t halt -f backends/license_policy.pl -- select file_level_mod swipl -q -t halt -f backends/license_policy.pl -- select copyleft_bypass ``` License selection is a compliance decision. The reasoner helps route common use cases, but it does not replace the actual license terms or a commercial agreement. ## Sovereign Node Key Policy [`SOVEREIGN_NODE_KEY.md`](SOVEREIGN_NODE_KEY.md) documents the operational node-key and seal process. Read it as an operational release/sealing policy, not as a substitute for `LICENSE.tri`. Institutional distinction: - `LICENSE.tri` governs source and use licensing paths. - `SOVEREIGN_NODE_KEY.md` governs production sealing, attribution, and operational participation. - A commercial deployment should satisfy both the selected license path and the applicable node-key/seal policy. ## Commercial Access and Sovereign Node Keys ### What Is a Sovereign Node Key? A **Sovereign Node Key** is proof that you have contributed to the PAX stack or received commercial authorization. It is not DRM; it is membership and production attribution. Running PAX-Coder in production requires one. ### How to Get a Node Key **Option 1: Contribute to the Stack (Recommended)** 1. Fork the repository: [SNAPKITTYWEST/pax-coder](https://github.com/SNAPKITTYWEST/pax-coder). 2. Build something useful: a kernel, proof, integration, documentation update, test case, deployment adapter, or verification improvement. 3. Submit a pull request. 4. On merge, you earn a node key for that contribution. 5. Email `license@collectivekitty.com` with: - your GitHub username, - merged pull request link or links, - intended use case: research, commercial, or personal. 6. Receive your node key: Ed25519 public key registration plus signing certificate. **Option 2: Commercial License (Direct)** Email `license@collectivekitty.com` with: - your organization name, - intended deployment scope: internal R&D, SaaS, embedded product, or another production scope, - GPU hardware: RTX 3080, RTX 4090, H100, or equivalent target, - estimated kernel volume. After review, approved commercial users receive a commercial node key, license terms, and registration path for deployment. ### What Does a Node Key Unlock? | Feature | Public Repository | Commercial Authorization | | --- | --- | --- | | Clone and verify integrity | ✓ (anyone) | ✓ (included) | | Generate kernels for testing | ✓ (anyone) | ✓ (included) | | Deploy to production | ✗ (not authorized) | ✓ (with node key) | | Sign releases | ✗ (not authorized) | ✓ (with node key) | | Embed in products | ✗ (license required) | ✓ (commercial license) | | Support | ✗ (not included) | ✓ (by tier) | | SaaS or cloud deployment | Requires license | Included with commercial license | ### Questions - **How to contribute:** see [`CONTRIBUTING.md`](CONTRIBUTING.md). - **Node key details:** see [`SOVEREIGN_NODE_KEY.md`](SOVEREIGN_NODE_KEY.md). - **Licensing details:** see [`LICENSE.tri`](LICENSE.tri). - **Commercial inquiries:** `license@collectivekitty.com`. ## Commercial and Institutional Use This project is suitable for: - public demonstration and education around verified GPU kernel generation, - internal research on verified GPU kernel generation, - proof-carrying code experiments, - CUDA/PTX training-data development, - institutional verification workflows, - commercial evaluation under the appropriate license path, - and enterprise discussions around `pax-verify` style verification services. PAX-Coder is the public face of the program. Nemotron/Megatron is the internal frontier model line for commercial work and is intentionally not released as part of this repository. Commercial teams should not treat generated kernels as approved artifacts until the verification pipeline has produced current evidence for the exact kernel, target GPU, compiler version, proof files, and deployment scope. ## Governance Checklist Before changing claims in this README or publishing a release, check: - Does `lake build` pass? - Does the release state the declared axiom basis for the claimed theorem path? - Does CUDA/PTX compile for the stated target architecture? - Was runtime behavior compared against a functional reference? - Are benchmark numbers tied to a reproducible command and hardware target? - Does the license statement match `LICENSE.tri`? - Does any production claim satisfy the node-key/seal policy? - Are generated examples labeled as examples rather than audited proof certificates? ## Related Documentation - [`ABOUT.md`](ABOUT.md): short overview. - [`docs/USER_GUIDE.md`](docs/USER_GUIDE.md): user workflow and prompt patterns. - [`docs/PAX_ARCHITECTURE.md`](docs/PAX_ARCHITECTURE.md): axioms and proof obligations. - [`MODEL_CARD.md`](MODEL_CARD.md): model-card draft. - [`DATASET_CARD.md`](DATASET_CARD.md): dataset-card draft. - [`PAX_CODER_README.md`](PAX_CODER_README.md): commercial integration notes. - [`PACKAGE.md`](PACKAGE.md): v1.0.0 package manifest. - [`RELEASE_NOTES.md`](RELEASE_NOTES.md): v1.0.0 release notes. - [`CHANGELOG.md`](CHANGELOG.md): release history. - [`SOVEREIGN_NODE_KEY.md`](SOVEREIGN_NODE_KEY.md): node-key policy. - [`CONTRIBUTING.md`](CONTRIBUTING.md): contribution guidance. ## Citation ```bibtex @software{pax_coder_2026, title = {PAX-Coder: Institutional Program for Proof-Carrying GPU Kernel Generation}, author = {Parr, Ahmad Ali}, year = {2026}, url = {https://github.com/SNAPKITTYWEST/pax-coder} } ``` ## Institutional Standard PAX-Coder should be evaluated by evidence: ```text claim -> file -> command -> output -> hardware/toolchain -> license path ``` If any link is missing, mark the claim as pending. That rule protects the institution, the engineering record, and downstream commercial users.