Within ~14% of C wall time on one i64 workload, with checked overflow and bounded execution.
A generator proposes.
The compiler disposes.
Swyp is our own programming language. Every program carries a contract, declares its effects from a closed vocabulary and must pass a deterministic judge before it runs. Code from a person, a script or Ilaria is treated the same way: proven, or rejected with a counterexample.
- Usable without a running model
- Closed effect registry
- Native x64 · ARM64 · C11
$ swyp verify checkout-policy --domain enterprisepolicy order.settlement · effects: [ledger.transact, receipt.mint] · timeout 50ms✗ REJECTED undeclared side effect requested unauthorized call to net.fetch: capability not minted by security kernelexit 1 · execution halted, zero side effects recorded $ swyp verify checkout-policy --authorized --domain enterpriseproof: static verification passes all contract bounds✓ PASS verified: contract satisfies safety invariants across all statesexit 0 · signed module minted for execution
How a program earns trust
Nothing runs on confidence.
Source becomes a typed Core IR, is checked against its contract and its declared effects, and only then reaches a backend. Model output has no shortcut through this pipeline.
- 01IntentWhat should exist
- 02ContractInputs, domain, ensures
- 03CandidateProposed by search or a modelrepair
- 04VerificationExhaustive · tested · counterexamplePASS
- 05Pinned sourceSource, IR and contract hashes
- 06Deterministic buildSame input, same artifact
Contracts, not vibes
The contract is the specification.
A contract fixes the input domain, the allowed effects and what must be true of the result. The judge checks a candidate against it — exhaustively when the domain is finite — and answers with a proof or a concrete counterexample. These are production contract specifications.
Every function enforces a formal mathematical contract. The contract strictly defines pre-conditions, post-conditions, and an execution step budget before compilation.
- Input DomainStrictly typed, bounded integer ranges with zero runtime casting
- Effect SurfaceZero ambient I/O, sealed memory references
- PostconditionsFormal equality guarantees & non-negativity bounds
- Budget LimitStrict finite step bounds: halts runaway logic or infinite loops
The Swyp judge evaluates generated code exhaustively against the contract specification. No AI model is consulted to evaluate correctness.
The Ilaria loop, measured
5 of 6 verified. The sixth was refused.
We let a language model write Swyp against contracts and fed every verdict back as a fresh prompt, up to four replies. Five tasks were proven exhaustively on the first reply. One was wrong in every reply — and never got through.
“The failure is the point of the design.”— Swyp verification evaluation
Order InvariantNon-negative total calculationVerified · exhaustive domain checkState BoundaryCryptographic fence checkVerified · lease boundary verifiedCapability LeaseEphemeral token mintingVerified · scoped authorization passesMemory FenceDirect non-aliased slice accessVerified · zero leakage proof verifiedLedger MutationTransactional commit handlerVerified · atomicity verifiedAmbient NetworkUnbrokered socket requestRejected · ambient authority prohibitedLanguage models rarely repair logic from a counterexample on their own. That is exactly why the deterministic judge, not the model, decides.
Effects & capabilities
Declaring an effect grants nothing.
Every side effect comes from a closed registry of eleven operations. A program can say it wants to read a file; only SwypikOS can hand it a scoped, revocable capability to do so — and every brokered call leaves a receipt.
clock.readfs.readfs.writeio.stderrio.stdoutmodel.infernet.connectnet.fetchprocess.execrng.sampletool.call“An effect declaration is not authority. Authority is an opaque SwypikOS capability that guest Swyp code cannot fabricate.”
Code cannot directly access system resources. Every resource interaction is routed through the Swyp capability broker.
Safe, and still fast
Checked i64 arithmetic at near-C speed.
On one i64 workload, Swyp keeps integer overflow checking and bounded execution on and still lands close to optimised C wall time. Strict floating point costs more, and we say so.
The opt-in semantic core provides typed control flow, structured loops, and immutable memory models.
One Mandelbrot run with the explicit ieee64 mode, versus C -O3. The strict finite-f64 default measured ≈ 2.5× C wall time on the same workload.
Deterministic runtime: zero memory allocations on inner arithmetic execution.
One non-isolated workstation, Core AOT lowered to C11 and compiled by GCC; see PERFORMANCE.md. Single-workload results, not a language-wide ranking.
One IR, many targets
From one verified Core to real machines.
x86-64 native
HIR emitted as PE and ELF executables, with runtime parity tests. The published benchmarks use the C11 AOT path, not this one.
ARM64 native
AArch64 code generation under the same parity suite.
C11 AOT
Portable ahead-of-time output for any toolchain with a C11 compiler.
Ternary VM execution
Deterministic virtual machine executing cryptographically signed modules.
Inside Nexus
The language every layer agrees on.
Ilaria proposes typed Swyp plans. Swyp checks their contracts, effects and ownership — with no model in the loop. SwypikOS executes only what was granted, and signs receipts. Even the protocols between our products are generated from .swyp specs, and CI rejects drift.
Roadmap
- Now
Semantic core, contracts, exhaustive judge, effect broker, native backends.
- Next
Self-hosting compiler and richer contract synthesis.
- Later
Tensor / device IR so Ilaria kernels and drivers share one verified IR.
- Vision
Wasm / WIT components: verified Swyp modules anywhere, under SwypikOS capabilities.