Skip to content
Rivoryxa Technologies
Discuss a problem

How an engagement runs.

Start with a clearly scoped pilot or smaller verification task. Evaluate the findings and handover before deciding whether to extend the engagement.

  1. 01

    Tell us the problem

    A coverage hole, a bug, a property to prove, or a testbench to build. Share a short, non confidential description. Do not include confidential files or details.

  2. 02

    Define the scope

    We agree in writing on the scope, deliverables, and what counts as done.

  3. 03

    NDA before confidential material

    We do not ask for confidential project material until a non disclosure agreement is in place.

  4. 04

    Investigate

    We run the agreed checks, investigate any reproduced failure, and record findings and remaining unknowns.

  5. 05

    Deliver evidence

    You receive the agreed deliverables, with the tests, properties, logs, traces, and documentation needed to reproduce the result.

  6. 06

    You verify the result

    Your team can rerun the agreed checks in your environment and independently verify the result.

01

Scope before work starts.

Before starting, we assess feasibility, confirm tool compatibility, and agree the scope, timeline, deliverables, and progress updates. The written agreement also defines responsibilities, cost, acceptance criteria, and the stopping point.

02

What you receive.

The exact deliverables depend on the problem. They can include tests, properties, logs, traces, coverage results, scripts, and a plain language technical handover.

03

If the result remains open.

At the agreed stopping point, you receive the findings, checks completed, remaining unknowns, and what would be needed to continue. Further investigation is agreed separately; a fix is not guaranteed.

A sample investigation handover.

Based on our public CV32E40P controller demonstration. This is an example of the handover format, not a client engagement. The faults were deliberately introduced into test variants. The original upstream source remains unchanged.

Question investigated
Can a brief halt request be lost when it arrives around a pipeline stall, exception flush, or debug return?
Finding
Ordinary tests pass on the original controller and four seeded variants. Targeted timing checks expose faults that incorrectly gate request retention or fetch fault handling.
Supporting evidence
The recorded matrix contains 15 builds and 30 simulation outcomes, with passing controls and specific expected failures. Eleven runner tests check result classification. Source hashes, commands, and logs are retained.
Limits and remaining work
This checks the controller at its module boundary. It does not establish whole processor correctness, external debug transport behaviour, or formal proof. Those require separately scoped work.
Handover files
Ordinary and temporal testbenches, timing boundary cases, the runner, reproduction commands, and recorded evidence. The linked example provides the files and assumptions needed to repeat the checks.
Inspect the evidence and rerun instructions

Security and IP.

No confidential project material is requested before an NDA. The exchange method, work environment, access, retention, and deletion are agreed in writing.

Read our security approach

Ready to start?

Share the problem in a few lines. We will discuss the scope before any confidential project material changes hands.

Discuss a verification problem