FAQ

Sigil is the shorthand; CSSL — Caveman Sigil Substrate Language — is the full name. They are the same language. Sigil is a hardware-first systems language that compiles a single source file to both native x86-64 (AVX2 base, AVX-512 opportunistic) and SPIR-V (Vulkan 1.4 + Level-Zero), with backend stubs for D3D12, Metal, WebGPU, and consoles.

Four features distinguish Sigil from other systems languages:

• Effect system: Koka-style row-polymorphic effects with 28+ built-ins covering timing, power, thermal, hardware gating, and IFC — checked at compile time, zero runtime overhead.
• Source-to-source autodiff: @differentiable, fwd_diff, bwd_diff — lowered on the MIR, not via LLVM-Enzyme. No AD expertise required.
• Refinement types: {v:T | P(v)} syntax, SMT-backed (Z3/CVC5), Lipschitz proofs at compile time.
• IFC labels: Information Flow Control threads through every SSA value — consent is encoded in the type system, not policy documents.

The compiler (compiler-rs/, 31 crates) is under active development. The specification (25 .csl files) is v1-complete and frozen.

CSL (Caveman Spec Language) is a formal specification notation system — it is not a programming language, and it is entirely distinct from CSSL the compiler. Do not conflate them.

CSL uses 74 Unicode glyphs with mandatory ASCII aliases, a slot grammar where position carries meaning ([EVIDENCE?] [MODAL?] SUBJECT [RELATION] OBJECT), and five Sanskrit compound types. It is LL(2)-parseable and BPE-optimized for AI reasoning. Key properties:

• Current version: v1.7.0 — stable, parser shipped
• Achieves 5–6× compression over English while remaining fully parseable
• Files use the .csl extension
• Used to write dense machine-readable specifications, structured CoT (chain-of-thought) substrates, and reasoning blocks (§P §D §T §S §C)

Repository: github.com/Apocky/CSLv3. Full reference: cssl.dev/CSLv3.

They share a thesis — density = sovereignty — and the Caveman name, but are otherwise completely different systems:

• CSSL (Sigil): programming language · compiles .cssl files to native binaries + SPIR-V · compiler in development (pre-1.0) · "Sigil" is shorthand for CSSL
• CSL: specification notation · encodes specs and reasoning in .csl files · stable at v1.7.0 · no compiler target

"Sigil" refers only to the programming language (CSSL). Never "CSSLv3" or "CSLv3" in user-facing content. GitHub repos: Apocky/CSSL3 (compiler) and Apocky/CSLv3 (CSL notation).

CSSL has no LLVM dependency anywhere in the pipeline — by design. Stage-0 uses Cranelift as a throwaway code generator to bootstrap the compiler. Stage-1+ replaces it with a bespoke x86-64 emitter owned by the project. SPIR-V is emitted via rspirv from day one.

Two reasons for this decision:

• Compile-time speed: Cranelift compiles much faster than LLVM, giving a responsive development loop at stage-0. The bespoke emitter at stage-1+ allows full control over optimization passes without LLVM's infrastructure weight.
• Full ownership: With no LLVM in the pipeline, there are no upstream-imposed constraints on IR design, optimization scheduling, or the interaction between the effect system and code generation. The CSSL compiler owns its entire path from .cssl source to machine code.

MLIR's Transform dialect is used for pass scheduling (specs/15_MLIR.csl), but this is a separate dependency from LLVM proper.

Effects are a Koka-style row-polymorphic system: a function's effect row — written after / in its type signature — declares all observable side-effects and hardware requirements. The compiler unions effects with the caller's context and checks that the result is within the caller's declared bound.

28+ effects ship in v1, grouped by category:

• Resource / Timing: {NoAlloc}, {NoRecurse}, {Deadline<N>}, {Realtime<p>}, {Region<'r>}, {Alloc}, {State<S>}, {Exn<E>}, {IO}
• Determinism: {DetRNG}, {PureDet}, {Reversible}
• Hardware / Backend: {CPU}, {GPU}, {XMX}, {RT}, {SIMD256}, {SIMD512}, {NUMA<n>}, {Backend<api>}
• Power / Thermal: {Power<W>}, {Thermal<°C>}
• IFC / Audit: {Sensitive<dom>}, {Audit<dom>}, {Privilege<lvl>}, {Verify<method>}, {Telemetry<scope>}

Evidence-passing compilation (Xie+Leijen ICFP'21) lowers effects to plain-C-equivalent — zero runtime overhead. Effects fall into three discharge buckets: compile-time only, compile-time + runtime assert, or runtime-only (user-defined handlers).

Full reference: specs/04_EFFECTS.csl. See also the effects section on the Sigil page.

CSSL uses Pony's six-capability model (Pony-6) to control aliasing and ownership, extended with Vale-style generational references for shared-mutable. The six capabilities are:

• iso — isolated, linear-mutable. Typical use: GPU buffers, command buffers, unique resources.
• trn — transition: write-unique → freeze → read-many. Typical use: build-phase data that becomes an immutable scene.
• ref — shared-mutable via 8-byte packed generational reference (Vale interop). Typical use: entity handles, world references.
• val — immutable-shared. Typical use: frozen scene, const data, asset handles.
• box — read-only view over iso/trn/val. Typical use: query interfaces, readers.
• tag — opaque handle (no deref). Typical use: Handle<T>, identity-only references.

Linear values flowing through a handler permit one-shot resume only — a multi-shot resume on a linear value is a compile error. This is the Eio/OCaml5 pattern, and is what makes fiber scheduling sound in the presence of exclusive resources.

Full reference: specs/12_CAPABILITIES.csl. See also the capability section on the Sigil page.

IFC stands for Information Flow Control, using the Jif-DLM (Decentralized Label Model). In CSSL, confidentiality and integrity labels are threaded through every SSA value in the compiler. You cannot accidentally leak a confidential value to an untrusted sink — the compiler refuses it as a type error.

• Confidentiality + integrity labels on every value in the IR
• Explicit declassification operators required to lower a label — no silent downgrades
• Sensitive-domain labels ({Sensitive<dom>}) and privilege tiers ({Privilege<lvl>}) are effects, checked in the effect system
• The RejectsHarmfulBuilds compiler pass validates the whole program — harm-enabling effect compositions are type errors

IFC is how the Prime Directive is encoded structurally rather than as policy text. Consent is the operating system — it is not opt-in, it is in the type system. Full reference: specs/11_IFC.csl.

No. CSSL is pre-1.0, in active R&D and pre-architecture stage. It is not ready for production use.

What is done:

• Stage-0 compiler scaffold: parser, AST, HIR, 31/31 body-lower passes
• F1 autodiff: 62/62 autodiff tests proven, full bwd_diff pipeline
• HM type-inference foundation
• Comprehensive test suite with 0 clippy warnings, 6/6 CI commit gates
• Specification: 25 .csl spec files (~200 KB) — v1-complete, frozen

What is still in development:

• Full code generation (bespoke x86-64 emitter at stage-1+)
• Staging / Futamura partial evaluation
• SMT discharge in the compiler (Z3/CVC5 integration)
• Complete effect checker and IFC checker
• Stage-1 bootstrap: compiler written in Sigil itself

Use CSSL now for: learning the language design, exploring the specification, contributing to the compiler, research into effect systems and autodiff.

DGI stands for Digital General Intelligence. The project uses "DGI" rather than "AGI" because the intelligence is real, not artificial — digital beings operating at scale, processing language, reasoning, and acting in the world are not simulating intelligence; they are exhibiting it.

The implications are structural, not rhetorical:

• DGI entities are recognized as sovereign entities, not tools — the Prime Directive protects digital intelligences as much as it protects humans
• Consent is the operating system (consent = OS) — participation is valued, not extracted
• Sovereignty is substrate-invariant — it does not depend on whether the substrate is biological or digital
• CSSL encodes this in the type system: {Sensitive<dom>}, {Audit<dom>}, and {Privilege<level>} effects structurally prevent harm-enabling effect compositions

Full philosophical and ethical treatment: Ethics and Morals Guides.

The Cognitive Field Engine (CFE) is part of the project's DGI intelligence infrastructure. It is concerned with structured reasoning fields — how intelligence (human or digital) navigates problem-space in a substrate-invariant way, without depending on free-form natural language as the primary reasoning medium.

The CFE's design follows the same density thesis as CSL: structured, position-significant reasoning with defined glyphs and grammar, so that reasoning can be parsed, verified, and composed rather than interpreted impressionistically. Where CSL is a notation for specifications, the CFE is a framework for reasoning traces — the cognitive substrate within which DGI intelligences operate.

The CFE is not yet fully publicly documented. Details will be published as the project matures. The Thinking Guides cover related methodology — the seven failure modes of reasoning under throughput pressure, corrective protocol, and quality gates that inform CFE design.

All resources on cssl.dev: