Contribute to Dweve AI Infrastructure

Choose the audience that matches your question

The page contains three selectable readings of the same subject.

Full-time roles across engineering and product. Remote-first within the EU.

Ask which project route, licence, and contribution terms apply before you send work.

Release notes, deep dives, and honest postmortems from the team.

API references, integration guides, and architecture documentation.

Dweve’s technical foundations, from Numerus and BitWeave to Lattice and AION. Check each project’s access route before you begin.

Once a project has published, follow its repository instructions to propose a pull request. Before that, the project page carries its round and the terms explain the review route. You can ask about it at any point.

Accepted changes are merged according to the project policy.

Run the CI checks that the project documents for this change.

Address the feedback and follow the project's approval rules.

Open a pull request when the project accepts one, reference the issue if required, and complete its template.

Run the tests and quality checks documented by the project before opening a pull request.

Sign commits and follow the commit format only when the project requires it.

Create a branch according to the project's naming instructions.

If the project is public and accepts changes, create a fork as its instructions describe.

Each step has a clear expectation. Use the quality checks the project documents.

Public projects may use a GitHub fork-and-pull workflow. Check each project's instructions for branch names, commit signing, issue references, review steps and response expectations.

Access, branch, review, merge. Each project documents its route.

Follow the project's documentation requirements for public APIs, examples and longer guides. Add enough context for another contributor to understand and check the change.

For performance-sensitive changes, include benchmark context when the project asks for it. Record the method, baseline, hardware and observed result so a reviewer can interpret the claim.

Add tests appropriate to the change and follow the project's checks for unit, integration, property-based or fuzz testing. Describe any coverage or environment limits that affect the review.

Quality gates documented for the project and the change.

A contribution should carry evidence that matches its change. Follow the project's documented tests, benchmark expectations and documentation requirements; they vary by project and access route.

Use the testing, benchmark and documentation checks the project requires.

For native development, use the system dependencies and platforms documented by the project. Some projects provide BUILD.md instructions; check them before you start.

Where a project provides a container workflow, follow its Docker or Podman instructions and use the image and commands it documents. Do not assume the container matches CI without checking the project record.

If the project uses Rust, install the toolchain and components named in its build instructions. Requirements such as rustfmt, clippy, miri or an MSRV are project-specific.

Ways to prepare a development environment. Check the project instructions for the supported path.

Toolchain, containers, and native setup.

The standard path depends on the project. Read its access and build instructions, prepare the documented environment, run the checks that apply, and use the stated review route.

Many Dweve projects use Rust, but toolchains, minimum versions, containers and integration targets are project-specific. Use the current project documentation as the source of truth.

Rust toolchain, Docker and local setup where documented.

Rust toolchain, formatting, and lint checks

Dweve maintains fourteen technical foundations spanning maths, parsing, retrieval, policy, simulation and runtime verification. HEDL is public on GitHub; the rest publish in fortnightly rounds from 1 September 2026, two at a time to begin with. Start with each project licence and stated route before sending work.

Browse the foundation pages. HEDL is public now, AION and Knot publish on 1 September 2026, and every other page names the round it is in. The project route explains how to ask for help.

Accepted contributions may be credited in release notes or a contributor record when the project keeps one. Check the project terms for any recognition or other benefit.

Contributor sessions may be announced when a project schedules them. Check the project page or contact Dweve for current participation options; location, timing and support depend on the event.

You can ask for contribution guidance through the project or contact route. Whether a maintainer can review a first change, which language is available and how quickly someone responds depend on the project and current capacity.

Project guidance, community sessions and contribution records depend on the route you choose.

Contribution can feel intimidating. Start with a concrete question, report, documentation change or test. Where a repository exposes issue templates or an entry point, use it; otherwise request the current route through Dweve. Support and response time depend on the project.

Review practices depend on the project. Read its contribution terms to see who can review a change, which checks apply, how security concerns are handled and whether the discussion is public.

Check the licence and source-access terms for each project before integrating or sending work. If they are not stated, contact Dweve before use.

Contribution terms vary by project. Check the repository or contact route for the applicable licence, review conditions and any agreement requested before submission.

Contribution terms, licence and review vary by project.

Contribution needs clear terms. Dweve describes the current access, licence and review route for each project. Repositories publish in fortnightly rounds from 1 September 2026, so check the project record before you commit time or submit work.

Clear terms. Documented route. Shared responsibility.

Interface design, accessibility audits, iconography and brand assets. Designers can propose work for Fabric, the documentation site and project surfaces. Follow the available brand and accessibility guidance, and ask before reusing files or tokens.

Manual testing, automated test expansion, fuzz testing, and benchmarking. Testers verify that new releases work on real hardware and in real workflows. Fuzz testers find edge cases that deterministic logic should handle. Benchmarkers validate performance claims. This track is ideal for methodical thinkers who enjoy breaking things.

API references, user guides, tutorials and translation. Technical writers can propose improvements through the documented project route, and most documentation tasks do not require coding. Check the project for its tooling and review process.

Bug fixes, performance improvements, new features and refactoring. Several foundations use Rust, with other languages appearing where the project needs them. Follow the project's source-access, review and test instructions; public entry points are not guaranteed.

Software engineering, documentation, quality assurance and design. The available project route and point of contact vary by foundation.

We organise contribution into four broad tracks. Each foundation describes its available route, scope and review terms. You can approach the work as an individual, university research group or engineering team, subject to the project access boundary.

Code, docs, testing, and design. Every skill has a place here.

Teams that contribute through a project’s route can build deeper expertise than teams that only consume it. Engineers learn the internals of systems they depend on and can develop relationships with maintainers when the project supports that contact.

A well-scoped contribution can inform a project's roadmap when its maintainers accept it. Organisations should treat contribution time as work with a clear scope, review route and access boundary, not as a promise of product control.

Project visibility follows the release schedule. HEDL is public; every other foundation carries a public description now and its repository and documentation when its round arrives. Read each project documentation and licence before deciding what you can inspect, verify or reuse.

Dweve is incorporated in the Netherlands and develops in the European Union. Project licences, governance and data handling are described per project and may differ. Contributing does not by itself establish regulatory compliance; check the terms and evidence that apply to your use.

Contributing gives you a way to examine how a project handles data, decisions and governance. Check the route and evidence that apply.

Jurisdiction, transparency, influence, and talent.

For organisations, contribution can be strategic when the project accepts the work. A well-scoped code, documentation or testing proposal can inform a roadmap while your team builds expertise in the technology it uses. Treat that influence as a project outcome, not as a promise of control or compliance.

Europe needs AI infrastructure whose ownership and operating boundaries can be examined. Dweve is building that alternative, but the contribution route is not identical for every foundation: HEDL is public and other source access is by request. Project pages and the contact route keep the current scope, review and access terms visible.