Skip to content

The form that was verified is the form that runs: native machine code, no garbage collector.

  1. 001Scope-Forge lowers a policy into Pancake, the low-level language of the formally verified CakeML toolchain, which compiles it to native code.verified back endSource: CakeML toolchain
  2. 002The policy runs as native machine code with no garbage collector; the policy that was proved is the policy that runs.native, no collectorSource: Scope-Forge compiler
  3. 003Everything already decided at compile time is removed, so the running system executes only the checks that remain.minimal runtime workSource: Scope-Forge compiler
  4. 004Compiled policies integrate with existing applications and specialized systems through a dedicated Scope-Forge code generator.integrationSource: Scope-Forge compiler

01Lowering

A verified path to native machine code

The policy that was proved is the policy that runs. Scope-Forge lowers the policy into Pancake once, and the CakeML toolchain, a compiler whose correctness is itself machine-checked, takes it to native machine code for ARMv7, ARMv8, x86-64, RISC-V and MIPS-64, and for Silver, the instruction set of a processor whose own design is formally verified. A verified front end, a verified compiler, and a verified back end: what you see is what you run. Every verified system trusts its toolchain. Scope-Forge's trusted base is small, and every item on it is listed.

02Reach

From the data center to the field

The same compiled policy runs wherever the decision is made, and compiled policies integrate with existing applications and specialized systems through a dedicated Scope-Forge code generator.

  • Data center servers
  • Existing applications
  • Specialized systems
  • Low-power field equipment

03Collector

No garbage collector

The compiled policy runs with no garbage collector: small, fast, predictable enforcement, from data center servers to small, low-power field equipment.

No garbage collector: small, fast, predictable enforcement.

Predictable by construction

04Compile time

Most logic resolved at compile time

Everything already decided at compile time is removed, so the running system executes only the checks that remain, and text checks run in a single pass over the input. The clearance band, the mission window, and the subset relation below are settled before the policy ever runs; what runs is the membership check on the live request. A policy that breaks a stated rule does not build.

mission-operator.sf

Operator requires {
    station: str where in ("A".."Z")+ ++ ("0".."9")+
    clearance: num where in 1..5
    action: str where in "read" || "task" || "release"
}

MissionOperator requires Operator && {
    clearance: num where in 3..4
    mission_window: num where in 1400..2200
    action: str where in "read" || "task"
}

accepted: 2 declarations, 0 contradictions

MissionOperator is a subset of Operator

Base operator access, narrowed to a clearance band and a mission window.

The compiler is machine-checked with Verus for every possible input, and the back end is the formally verified CakeML compiler: a verified compiler from source to machine code.

What you see is what you run

From the data center to the tactical edge: verified policy in native code.