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 plus the first Orange 2026 syntax slice: source locations, deterministic lexing, a bounded parser for one deliberately small module/function grammar, structured diagnostics, and the orangec command-line boundary. There is no type checker, name resolver, evaluator, code generator, standard library, proof checker, or verified cryptographic implementation yet.

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

• 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
• Solo-development process
• Edition 2026 parser proposal
• Compiler status and usage

Repository and compiler foundation

The repository carries the permanent policy and evidence architecture created during Gate 0 and the first two production-lineage compiler slices:

• 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:

make check

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.