Documentation

Introduction

Why the platform exists — a large, fragmented, fast-moving landscape of implementations that AI is now expanding — and the chain that answers it, from a named computation to a valid, measured, comparable result.

The computational stack

Kernels sit at five layers of abstraction, from a mathematical primitive to a privacy-preserving application, and record which lower-level computations they depend on.

Kernels

A named computational problem, stated apart from anything that realises it — and the graph problems form between themselves.

Specifications

One precise statement of a kernel — what it settles, how it is addressed, and why a published version never changes.

Implementations

One answer to a specification — what it declares, what makes it runnable, and how coverage decides who it is compared with.

The performance map

Every valid evaluation adds a measured observation; together they map which implementation wins for a given point, hardware and set of constraints — there need not be one global winner.

Challenges

A public call to build or improve an implementation — with a deadline, a metric, and submissions judged like everything else.

The committee

Who decides what on the platform — how a kernel is approved, a specification signed off, and a dispute resolved.

Overview

What the language is for, and the shortest complete example of it.

Declarations

Kernels and specifications as they are written — parameters, arguments, results, and the one suffix an added argument may carry.

Types

The closed set of scalar types, value-parameter types, tensors and their dimensions, and the semantics of secret<T>.

Refinement

The one-way relation between a kernel and its specifications — what may be narrowed, what may be added, and what may never change.

Diagnostics

What the tools refuse and how they say it — coded errors with a place and a next step, and the vocabulary a form can ask for.

Grammar

The notation formally, for anyone writing a tool against it.

Points, cases, verdicts

What it takes for a specification to be measurable, and the formal vocabulary of judging — point, case, sample, verdicts, coverage.

The testing bundle

The set of components a specification is tested with — which are required, what state each can be in, and when the specification accepts submissions.

Component reference

The contract of each authored component — signatures, determinism requirements, and the checks that gate acceptance.

The bundle protocol

The command-line and on-disk contract between a bundle, a solution and a runner — commands, directory layout, file format, exit codes.

The execution layer

How a submission becomes a number — submissions, jobs, runners, containers, the timing window, and the invariants that keep the numbers honest.

Runners and images

The machines that measure and the environments they measure in — capabilities, admission, liveness, and why an image is pinned by digest.

Encrypted solutions

The contract an FHE implementation is measured under — four functions, the envelope that holds the keys, the declared parameters, and what of it is scored.

Comparability and standings

The one rule that lets two numbers sit in one table — and how standings, the compare views and the catalogue apply it.

Install and set up

Two commands on the path, an offline doctor, tokens and profiles, and the exit codes CI can rely on.

Writing a testing bundle

Scaffold the bundle, check its components statically, run them in a sandboxed process, and submit.

Scaffolding an implementation

Generate a skeleton in Python, C++ or Rust, implement init/run/free, test locally against the bundle, submit a commit.

The fherma-lang tool

The language on its own — parse a declaration, emit a scaffold, print the vocabularies — with no platform involved.