Schema–Segment Composition Computing System

SSCCS is a geometric computing model: a computation is an observation over a coordinate space, not a sequence of instructions. That space is composed of immutable Segments, a Scheme, and the dynamic Fields that bound the admissible set. Parallelism and verifiability follow from that structure rather than from added mechanisms, and near-linear scalability and energy efficiency follow with them. State is the result of projection, and time is one coordinate among many.

The SSCCS Initiative develops the model, guided by its operational direction and philosophy. It reaches current silicon through open stacks that run the full pipeline, from formal specifications through the software toolchain, a compiler and a runtime, to the open hardware architecture. Those stacks rest on three shared layers: synTagma, neXus, and kineTics.

The brief

Current work

SSCCS is an entirely new computing model and a hardware architecture, so the research is ongoing. What runs today is the infrastructure stack, on the silicon and the computing models in use now, and each layer that runs tests another part of the model against a working system. The work also runs in the other direction. Products, and the infrastructure elements that support them, are implemented and composed first, and what they require is what moves the model forward.

Field composition algebra
The current focus of the core team. Constraint sets have to compose while observation determinism is preserved, so that a composed Field can be reasoned about with the same guarantees as its parts.
Compiler pipeline
The core compiler and runtime are under active development, with work on compiler pipeline hardening and on hardware mapping, including the decode path that replaces a hash unit with combinational logic.
Domain instantiations
The model is carried into the field by projects held by separate entities, which the foundation supplies with the open-source technology and works alongside. The commercial ones among them stand on their own, so the stack does not depend on a single source of support.
Hardware validation
Phased prototyping from software emulation to FPGA deployment, with a parallel track for radiation-tolerant platforms. See hardware validation.
Strategic partnerships
Work with infrastructure leaders to extend the reach of agentic research environments, and contribution to established open-source projects, whose requirements come back into the research as constraints the model has to meet. There is a standing invitation to institutions that want to validate the model against their own workloads.

The work notes carry the measurements behind each of these as they are taken.

Projects

The stack is independent projects on the same substrate. Each one solves its own problem and strengthens the primitives for all.

SSCCS is a paradigm, not a single implementation. The directory of all of them is at docs.ssccs.org/projects.

Application domains

The model is developed against the domains where the cost of moving data has stopped being affordable. What each domain contributes in return is a constraint that the primitives have to satisfy in the field, not only in a specification.

Space systems
Radiation tolerance follows from structural reproducibility. After an upset, the system re-observes the same immutable Scheme and returns to the same configuration, without redundant hardware. Read the note.
Embedded and edge systems
A no-allocator coordinate space fits OS-less microcontrollers and radiation-tolerant hardware, and replaces hash units with combinational decoders.
AI inference
Model weights stay in place and computation moves to them, which addresses the memory-bandwidth bottleneck behind inference latency and energy cost.
Swarm robotics
Agents observe a shared Scheme locally, so a fleet holds one configuration without runtime coordination traffic.
Climate and scientific computing
Dependency grids become adjacency relations compiled into memory, so each timestep is a parallel observation rather than a data movement.
Scientific data infrastructure
Coordinate indexing replaces hash lookup in large datasets, collapsing read-request bottlenecks from hours to seconds. Read the note.

Engagements

SSCCS welcomes partnerships from academia, industry, and public institutions worldwide, in any nation with aligned public-interest programmes. Collaboration is selective: engineering depth and long-term commitment matter more than reach. Opportunities include research collaboration, software toolchain development, and joint hardware validation. Representative engagements:

For the full list of current engagements, see Current Engagements.

Sponsorship

SSCCS is independent and open source, committed to public-good infrastructure. The official sponsorship charter on GitHub Sponsors describes the funded work: open-source releases, documentation that stays free to read, and research into energy-efficient, verifiable computing.

The brief

The model, the architecture, and the design principles.

The model

The ontology has six members, and each of them is a region of a coordinate space rather than a step in a sequence.

Segment S = (c, id)
Immutable. Sits on the coordinate space and carries its identity from the coordinate rather than from a hash.
Scheme Σ = (A, R, L, O)
The static structure that binds Segments into a layout. It is compiled, and it is not interpreted at run time.
Field F = (C, T)
Raises a constraint potential over the coordinate space. The admissible set A(Σ, F) is the region where C holds.
Observation Ω
Applies the Field to the Scheme and produces one projection per admissible Segment. No data is moved: the layout already places each Segment at its address.
Projection P = Ω(Σ, F)
Computed per observation, and not stored. A projection is defined by the Scheme, the Field, and the Field version it resolved against.
Data D = I(P)
What a projection yields where it is recorded. The state of a system is the Data its observations have written.

The opening scene draws all six at once. The axioms state them formally, and the whitepaper derives the stack from them.

Architecture

SSCCS is developed as a software-first system: a compiler toolchain, a runtime, and an open binary format, with the hardware architecture specified alongside them and derived from the same structure. The layers below are the ones that carry the model from a specification to a running substrate.

Lowering chain
A structural description is compiled through a layered lowering chain onto hardware-specific backends. Each layer refines the description while the invariants of the model are preserved, and the structural document itself is what reaches execution, embedded rather than interpreted at run time.
Hardware abstraction
A target-agnostic hardware abstraction layer keeps the ontological core independent of the execution substrate. The same Scheme projects onto a CPU, an FPGA, or a processor-in-memory architecture without rewrites.
Binary format
The compiled artefact is an open binary format. The structural description and the executable are one document, so a deployment carries its own specification.
Reference implementation
A Rust reference implementation validates all core primitives under continuous integration. The same primitives are proven in parallel across RTL, RISC-V assembly, and current-language work in the proof-of-concept tree, before the reference compiler and runtime take their final shape.

Design principles

The model is designed around five properties. Each of them follows from the structure rather than from a feature added later, and each is a claim the implementation is expected to bear out.

Energy and data movement
Data movement dominates the energy cost of modern computing, and most of it exists to carry operands to a fixed execution point. The model keeps the structure stationary and moves no data during observation, so computation is not paid for twice, once in arithmetic and once in transport.
Parallelism
Parallelism is inherent to the structure rather than added to it. Independent sub-graphs within a Scheme are observed concurrently, and no locks or synchronisation are needed because there is no shared mutable state for them to guard.
Compilation
Structural descriptions are compiled into the hardware substrate at build time. There is no runtime interpretation: the structural document is embedded into execution itself, and the artefact and the specification remain the same object.
Security and auditability
Security and auditability follow from the structure rather than from added features. Immutable Segments carry cryptographic identity by design, independent sub-graphs share no mutable state and are observed without synchronisation, and every observation is deterministic and traceable from blueprint to result.
Digital sovereignty
Digital sovereignty is a design property. Policy sandboxes are enforced at the binary level, so an organisation or an individual keeps control of its computational environment, free of proprietary lock-in.