Six lanes, one programme.
Each lane starts from a question about RISC-V software, becomes a prototype that answers it, and then becomes a product. Each entry below states where it currently sits on that path.
Research lanes
The question, the proof, the product.
Open a lane for what research means for it, what a prototype has to demonstrate, and what a developed product would be.
Lane A: RISC-V software compatibilityIn DevelopmentWhat actually stops existing software from running on RISC-V, and how early can that be detected?Open
- Research
- How Linux applications, web applications, applications derived from open mobile foundations, native libraries and AI models behave across RISC-V profiles.
- Prototype
- A compatibility scanner that inspects a package and names what blocks it.
- Development
- Certification reports and the badges a store listing carries.
Lane B: RISC-V developer cloudPrototypeHow do developers build and test for a target they cannot buy?Open
- Research
- How developers build and test software without owning RISC-V hardware, and where emulation stops being a faithful substitute.
- Prototype
- A QEMU-based build and test runner.
- Development
- Cloud continuous integration, build logs, benchmarks and deployable bundles.
Lane C: RISC-V AI runtimeResearchWhich models are practical on RISC-V systems, and at what size and precision?Open
- Research
- How ONNX, TensorFlow Lite, GGUF and smaller AI models behave on RISC-V systems, including which operators have no implementation.
- Prototype
- A model readiness scanner.
- Development
- An AI runtime, benchmark reports and model listings in the Store.
Lane D: RISC-V mobile softwareResearchWhat does a mobile software platform need once vendor-specific services are not available?Open
- Research
- AOSP-derived mobile operating system concepts for RISC-V, and which system services have to be replaced rather than ported.
- Prototype
- An emulated mobile system shell.
- Development
- Aevornix Mobile: application framework, account service, permissions, update service and store integration.
Lane E: RISC-V app storeResearchWhat does a buyer need to know before installing software built for an architecture they may not have?Open
- Research
- How to distribute software by architecture, operating-system target, licence, performance and trust.
- Prototype
- A RISC-V category in the Aevornix Store.
- Development
- Verified listings, architecture badges, security scans and compatibility scores.
Lane F: RISC-V securityResearchWhat has to be true about a package before a platform is willing to sign and distribute it?Open
- Research
- Supply-chain scanning, application signing, firmware signing, software bills of materials, permission models and trusted updates.
- Prototype
- A security report inside the app scanner.
- Development
- RVStack Certify.
Research questions
Seven questions the programme exists to answer.
These are open. Where an answer emerges it changes the roadmap, which is why the roadmap carries stages rather than dates.
Which applications are portable to RISC-V today?
Which native libraries block migration?
Which AI runtimes are practical?
Which mobile services need replacing?
Which store trust signals matter?
Which benchmarks prove readiness?
Which developer workflows need automation?
Working assumptions
What the programme is betting on.
Positions rather than findings. Each is something the lanes are meant to confirm or overturn, and each names what changes if it turns out to be wrong.
Emulation is a sufficient development target for most software work, and only performance work needs real silicon.
If false, the developer cloud needs hosted physical RISC-V machines far earlier than planned.
Native libraries, not application code, are the dominant blocker to porting.
If false, the app scanner is looking in the wrong place and source-level analysis matters more.
Smaller quantised models are the practical AI workload on RISC-V for the foreseeable term.
If false, the AI runtime needs vector-extension work and accelerator interfaces much sooner.
Application compatibility on an open mobile foundation is bounded by native code and system services rather than by the application framework.
If false, the mobile track becomes a framework project rather than a services project.
Distribution trust can be earned with published, checkable scan results rather than a closed review process.
If false, the store needs human review capacity before it needs badges.
RVA-profile convergence continues, so one build can serve most 64-bit application-class targets.
If false, the build matrix multiplies and certification has to be per-profile.
Prototype targets
What a proof has to be.
Seven things that, when they exist and run, close a research lane. Each carries the stage it is genuinely at.
RISC-V app scanner
Take a package, report what prevents it running on a RISC-V profile.
RISC-V AI model scanner
Take a model, report unsupported operators, precision and estimated memory.
RISC-V emulator runner
Run a build against an emulated profile and capture its output.
RISC-V store category
A category in the Aevornix Store carrying architecture and target metadata.
RISC-V compatibility badge
A published, checkable statement of what a package was tested against.
Aevornix Mobile shell
An emulated mobile system shell with Aevornix services in place of vendor ones.
RVStack CLI
One command line across build, emulate, scan, certify and publish.
RISC-V