Orange

Orange is a language and toolchain for specifying, implementing, and verifying cryptography.

The goal is a production system in which a cryptographic engineer can write a mathematical specification, connect it to an efficient implementation, state the exact assurance claims that matter, and ship native artifacts together with machine-readable evidence, including independently checkable proofs and certificates where the claim kind permits them.

Orange is now in solo, pre-alpha compiler development. The repository contains the Rust compiler foundation, the accepted Orange 2026 parser slice, and an accepted S3a typed-literal semantic slice. orangec check performs bounded lexical, syntactic, and semantic validation; typed spec literals with exact Int or Word[8] types lower to a deterministic, noncanonical Typed Reference Core; and orangec eval FILE prints those closed values in source order.

The S3a slice has separate spec and impl name namespaces, but only typed specifications acquire values. It defines no parameters, operators, calls, typed implementations, refinement, proof system, canonical Core encoding, code generation, ABI, standard library, package or release behavior, or verified cryptographic implementation. D-003 and D-004 remain unresolved and unratified, and later S3 semantic work is incomplete.

The accepted S3a implementation and normative documentation were merged by PR #9 as commit 6c0bd3021cf2df603e08808e4660724ca1e2b2a5. That repository fact is implementation evidence, not a stable compatibility or assurance claim.

Implemented behavior is solo-authored and solo-reviewed. It is not independently reviewed, formally verified, production-ready, or a cryptographic assurance claim.

Directed commitments

• Deliver the complete language and toolchain, not a disposable prototype.
• Build incrementally through tested components of the final production architecture; do not plan a prototype-to-rewrite phase.
• Operate as a solo project without making development depend on unavailable contributors, reviewers, auditors, laboratories, or partner organizations.
• Separate implementation progress from assurance claims: missing external evidence is disclosed and limits claims, not unrelated development.

Architecture direction

The current planning documents recommend the following. Individual choices are ratified incrementally before the component or claim that depends on them.

• One language with distinct semantic strata for mathematical specifications, executable implementations, leakage-aware low-level code, probabilistic games, and proofs.
• Explicit claim reports instead of a generic verified label.
• Machine-readable, content-addressed evidence; proof and compilation evidence is independently checkable, and thick release bundles replay offline.
• A small, published trusted computing base for every kind of claim.
• Production native code, a stable C ABI, deterministic builds, and signed release provenance.

Plan

• The Orange Book, the living reader guide by Chase Bryan
• Project charter
• Research and landscape analysis
• End-state architecture
• Assurance and security model
• Dependency-ordered roadmap
• Gate 0 feature traceability
• Proposed Orange 1.0 user journeys
• D-006 proof-foundation decision suite
• Decision register
• Normative Orange 2026 lexical and grammar specification
• Normative Orange 2026 typed-literal semantics
• Solo-development process
• Edition 2026 parser proposal
• Accepted typed-literal semantics OEP
• Compiler status and usage

Repository and compiler foundation

The repository carries the permanent policy and evidence architecture created during Gate 0, the first two completed production-lineage compiler slices, and the accepted S3a typed-literal slice. The larger S3 semantic milestone remains incomplete:

• governance, contribution boundary, and the OEP and ADR processes;
• security reporting, support, the living threat model, and the honest OSPS evidence matrix, backed by the secrets and incident playbook;
• dependency and release policy, with an honest CI dependency inventory;
• the Gate 0 reproducibility contract, provisional evidence schemas, and positive/adversarial conformance fixtures; and
• the machine-readable repository policy, pinned CI, dependency review, CodeQL default-setup record, and GitHub control runbook; and
• the owner-designated official Orange emblem, wordmark, and lockup assets, preserved with a digest manifest and explicit rights boundary.

Run the deterministic repository and compiler checks with:

scripts/ci/check-repository

Passing this check demonstrates the scoped repository invariants, fixture expectations, and tested compiler behavior only. It does not prove language or compiler soundness, cryptographic correctness, a security certification, OSPS conformance, independent review, or release readiness.

The repository has no selected outbound license under D-018 and does not accept third-party pull requests for merge yet. Security reports must use the private path in SECURITY.md, never a public issue.

The name Orange is a working project name until the naming and trademark gate in the decision register is closed. Existing software and an earlier systems language already use the name.