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 yet01 / 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.
| Component | Input → output | Responsibility |
|---|---|---|
| Compiler | Source codeto Assembly or object code | Parse, check, and translate a selected language into instructions for the chosen target. |
| Assembler | Assemblyto Object files | Encode instructions and record symbols and relocations in a documented object format. |
| Linker | Objects and librariesto Executable | Resolve symbols, apply relocations, and produce a binary compatible with the target platform. |
| Build tools | Sources and build descriptionto Build artifacts and records | Coordinate the pipeline with explicit inputs, dependencies, and reproducible settings. |
| Runtime & core libraries | Platform and language interfacesto Execution support | Provide 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.
Record the complete input set
List source revisions, dependency versions, licenses, provenance, generated inputs, and the required host environment.
Document the bootstrap chain
Explain which tools build the first compiler and how each stage is obtained and verified. State any remaining trust assumptions.
Build with the network disabled
Use only the documented inputs. Record the commands, environment variables, configuration, and resulting artifacts.
Repeat in a separate environment
Have an independently operated EU-based environment build the same inputs. Compare artifact hashes and investigate differences.
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.
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 devThe development server normally starts at http://localhost:3000; check the terminal for the actual address.
Build and preview
npm run build
npm run previewFor 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.