Skip to content

Understand the foundations

Clear foundations.
Shared understanding.

A shared reference for the toolchain we want to build: its proposed structure, the requirements behind independence, and the questions we need to answer together.

Planning documentation · No toolchain release yet

01 / Getting started

Read this first.

low-level.eu is an early-stage initiative for a low-level toolchain fully developed in the European Union and independently buildable without sources or services outside the EU. These documents describe the intended direction, not an available product.

There is no toolchain to install yet.

Languages, target architectures, licensing, governance, and a bootstrap strategy have not been selected. Installation instructions, API references, and release downloads will only be appropriate once implementations exist.

02 / Proposed architecture

From source to execution.

The initial scope connects a small set of essential tools. The pipeline below is conceptual: a compiler may produce object code directly, and runtime support is linked or loaded according to the chosen platform.

SOURCE → COMPILER → ASSEMBLER → LINKER → EXECUTABLE

Build tools coordinate the pipeline.
Runtimes and core libraries support execution.

Proposed components, their inputs and outputs, and their responsibilities.
ComponentInput → outputResponsibility
CompilerSource codeto Assembly or object codeParse, check, and translate a selected language into instructions for the chosen target.
AssemblerAssemblyto Object filesEncode instructions and record symbols and relocations in a documented object format.
LinkerObjects and librariesto ExecutableResolve symbols, apply relocations, and produce a binary compatible with the target platform.
Build toolsSources and build descriptionto Build artifacts and recordsCoordinate the pipeline with explicit inputs, dependencies, and reproducible settings.
Runtime & core librariesPlatform and language interfacesto Execution supportProvide startup routines and the minimal support required by compiled programs.

A complete operating system and hardware sovereignty are outside the initial proposed scope. Host-system dependencies still need to be identified and documented.

03 / Independence requirements

Make independence explicit.

These are proposed requirements, not certifications or achieved properties. Each needs a concrete policy and evidence before a release can claim compliance.

Development and stewardship
Core tools should be fully developed and maintained in the EU. Governance, maintenance responsibilities, and source-provenance rules must be defined openly.
Complete source availability
Account for every required source, including generated code, build tools, runtime libraries, and bootstrap compilers. A repository mirror alone does not demonstrate independent development or maintenance.
EU-operated infrastructure
Source archives, build infrastructure, release signing, and distribution should remain operable under EU-based stewardship, without mandatory external services.
Disconnected operation
A clean build should work with network access disabled once the documented inputs have been obtained from EU-maintained archives. No hidden downloads or remote APIs should be needed.

Open standards and global research remain valuable. Reusing existing code would require a transparent provenance policy consistent with the EU-development goal; it must not be silently treated as EU-developed code.

04 / Verification checklist

Evidence before claims.

Use this checklist when proposing a component or designing a future release process. It is guidance for planned work, not a record of completed checks.

  1. Record the complete input set

    List source revisions, dependency versions, licenses, provenance, generated inputs, and the required host environment.

  2. Document the bootstrap chain

    Explain which tools build the first compiler and how each stage is obtained and verified. State any remaining trust assumptions.

  3. Build with the network disabled

    Use only the documented inputs. Record the commands, environment variables, configuration, and resulting artifacts.

  4. Repeat in a separate environment

    Have an independently operated EU-based environment build the same inputs. Compare artifact hashes and investigate differences.

  5. Publish evidence and limitations

    Make the dependency inventory, build instructions, verification results, and unresolved external dependencies inspectable.

Reproducibility alone does not prove security or EU provenance. Source review, testing, dependency auditing, and governance are separate responsibilities.

05 / Contributing

Start with a focused proposal.

Developers, researchers, and organisations can help define the foundations. A useful proposal should explain:

  • The problem and the smallest useful outcome.
  • Your relevant expertise and the component or research area involved.
  • Dependencies, source provenance, and bootstrap assumptions.
  • How someone else could reproduce or verify the result.
  • A first milestone, open questions, and maintenance considerations.
Prepare a proposal

The proposal builder downloads a Markdown draft locally. It does not submit or store your information on a server. A public contribution channel has not yet been established.

06 / Website development

Working on this website.

The website uses Nuxt 4, Vue 3, and Tailwind CSS. Its internationally developed dependencies are separate from the proposed toolchain’s EU-only development goal.

Run the website locally

With a copy of the website repository and a Node.js version supported by Nuxt 4, run these commands from the project directory:

npm ci
npm run dev

The development server normally starts at http://localhost:3000; check the terminal for the actual address.

Build and preview

npm run build
npm run preview

For static hosting, run npm run generate and deploy .output/public.

Project structure

  • app/pages/ — file-based routes, including this documentation page.
  • app/layouts/default.vue — shared navigation and footer.
  • app/components/ — reusable UI and local SVG artwork.
  • tailwind.config.ts — theme colours, typography, and container sizing.

Use Tailwind utility classes and existing shared components when extending the site. No custom stylesheet is required.

07 / Glossary

A common vocabulary.

Toolchain
A connected set of tools used to turn source code into executable software.
Bootstrap
The process of building a toolchain from an initial set of existing tools. That initial set is part of the trust and dependency chain.
Reproducible build
A build in which the same source, documented environment, and instructions produce byte-for-byte identical artifacts.
Source provenance
A record of where code comes from, how it was produced, and who maintains it. Availability of source code alone does not establish its provenance.
ABI
An application binary interface: the conventions that let compiled components interact, including calling conventions and data layout.
Digital sovereignty
The practical ability to govern, understand, maintain, and operate essential digital systems without being dependent on external control.

Documentation is a shared foundation

Good questions move us forward.

Turn a technical question or a small experiment into a concrete contribution.

Prepare a contribution