C-Kernel-Engine spans model mathematics, generated C, numerical contracts, SIMD kernels, Linux profiling, multimodal execution, and future distributed CPU systems. You do not need to understand all of it before contributing. Begin with one bounded problem whose result another engineer can reproduce.
Current work may involve Qwen3-VL long-context divergence, BF16 reduction semantics, AVX2/AVX-512/AMX dispatch, compiler ownership, or multimodal parity. Those are Level-5 problems. A distribution fix, profiler adapter, benchmark artifact, documentation correction, or independent numerical fixture is a complete and useful contribution.
Improve setup instructions, repair one distribution-specific failure, clarify a command, or make an existing workflow reproducible on a named machine.
Environment details, failing command, corrected command or patch, and proof the documented path now succeeds.
Add a repeatable perf, FlameGraph, flamegraph-rs, VTune, Advisor, cache, assembly, or power-measurement lane without breaking existing platforms.
Exact command, CPU and compiler metadata, workload, raw artifact, interpretation, and known sources of measurement noise.
Exercise one operation or canonical tensor boundary against PyTorch, llama.cpp, SciPy, a finite-difference gradient, or another independent implementation.
Deterministic fixture, independent oracle, tolerance and dtype policy, failure reproduction, and regression test.
Implement or tune one C kernel, SIMD route, memory layout, fusion, quantized path, or thread-pool boundary.
Parity first, supported-ISA detection, before/after benchmark, profiler attribution, fallback behavior, and no unsupported performance claim.
Change circuit semantics, lowering, kernel binding, generated runtime ownership, numerical X-ray attribution, multimodal stitching, or multi-node execution.
Written contract, cross-layer tests, generated-C inspection, architecture regression coverage, migration impact, and end-to-end evidence.
Build one known model on Arch, CachyOS, Fedora, Debian, or another Linux environment. Preserve Ubuntu behavior while adding explicit commands for the platform's profiler package and interface.
Concrete example: detect or document flamegraph-rs on Arch/CachyOS instead of assuming the Perl FlameGraph command line, then capture the resulting SVG and baseline metadata.
Run one supported model with a fixed prompt and thread count. Record CPU topology, ISA flags, compiler, CKE commit, model hash, command, prompt-eval rate, decode rate, RSS, and profiler output.
The contribution is the reproducible evidence package, not a context-free tokens-per-second number.
Choose RMSNorm, RoPE, quantized dot product, softmax, Conv1D, attention, or another bounded operation. Compare CKE against an independent oracle using deterministic tensors and an explicit precision policy.
Do not begin with complete model generation unless the smaller boundary already passes.
Reproduce a public guide from a clean checkout. Correct stale paths, unsupported assumptions, missing dependencies, or unclear evidence labels. Link every claim to the current implementation or test.
Documentation-only changes still need reproduction evidence.
Follow the quickstart and record your machine, OS, CPU, compiler, and commit.
Use an existing issue or open a focused issue describing one observable failure or missing path.
Capture the failing and passing commands before broadening the change.
Share direction early. Do not wait until a large rewrite is complete.
Attach tests, artifacts, limits, and the exact claim the change supports.
If you are already in the CKE Discord: introduce yourself with your operating system, CPU, compiler, the CKE path you successfully ran, and one contribution level that interests you. Link a focused GitHub issue or draft PR so technical decisions remain searchable outside chat.
If you need an invite: open a short onboarding issue in the CKE repository. The public repository remains the durable source for scope, commands, patches, evidence, and review; Discord is for coordination and questions, not the only copy of a technical decision.
Good first message: "I built commit <sha> on <OS> with <CPU/compiler>. I want to work at Level 2 on the Arch/CachyOS flamegraph-rs path. Here is my baseline command and draft issue."
| Include | Why it matters |
|---|---|
| Problem and bounded scope | Reviewers can tell what changed and what deliberately did not. |
| Hardware, OS, compiler, model, and commit | CPU behavior and performance claims are environment-dependent. |
| Exact reproduction commands | Another contributor can rerun the result without reconstructing your shell history. |
| Independent correctness evidence | An implementation must not validate only against itself. |
| Before/after artifacts for performance work | Optimization requires attribution, not intuition or CPU utilization alone. |
| Known limits and unsupported cases | A narrow validated path must not become a broad accidental claim. |
| Focused commit history | Intent remains inspectable and unrelated changes do not hide in the patch. |
Enable the repository hooks after cloning:
./scripts/setup-hooks.sh
git config core.hooksPathThe configured path should be .githooks. Run the tests relevant to your changed boundary and report exactly what ran. Do not claim the complete engine passed if you ran only a scoped test.
make
make test
# Examples of focused Python gates
python3 -m pytest tests/test_v8_attention_contracts.py
python3 -m pytest tests/test_v8_numerical_execution_contracts.pyAI tools may help inspect code, propose tests, or draft a patch. The human contributor remains accountable for every equation, hardware assumption, generated artifact, claim, and line submitted, and represents that they have the right to submit the material for project review. AI providers are not listed as contributors merely because their tools were used. Correct-looking code without independent evidence is not a completed contribution.
A contribution is the engineering act of finding a bounded problem, reproducing it, submitting a correction with evidence, and passing review. Recognition records who performed that work. Copyright concerns legal rights in original expression. A software licence states what permissions a rights holder grants to users. Merging one pull request does not collapse those four concepts into one.
The person found or clarified a real boundary, produced reproducible evidence, and submitted a reviewed improvement. This can be meaningful even when the final patch is small.
Git commits, pull requests, CONTRIBUTORS.md, .mailmap, and release notes preserve who did the work. Recognition survives later refactoring.
Copyright, where it exists, concerns original human expression. CKE currently has no CLA or DCO, so a merge is not documented as an automatic copyright assignment.
A root licence grants reuse permissions for the project. Dependency licences apply to those dependencies only; they do not automatically license CKE's original code.
CKE does not currently publish a root LICENSE file. Repository visibility is not the same as an open-source licence. Until explicit terms are adopted, do not infer a general grant to copy, modify, redistribute, sublicense, or sell CKE code from the licences of llama.cpp, PyTorch, or any other included project.
Read LICENSING.md for the current boundary and the governance steps required before a stable licensed release.
CKE recognizes the person who found the problem, established the reproduction, and submitted the reviewed correction. Recognition is not measured only by line count, and replacing those lines later does not erase the original engineering contribution.
.mailmap consolidates known identities for accurate shortlogs without rewriting published history.Quickstart, architecture, IR pipeline, and v8 runbook.
Profiling guide, kernel tuning methodology, and SIMD architecture.
PyTorch parity, divergence harness, and numerical contracts.
Issues, draft pull requests, and the current test report.