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.

Taken from our real work on a coverage hole in an open source RISC-V core. This is the format you receive at the end of an investigation.

Question investigated
Can the debug single step code inside the hardware loop state of the controller ever run, or can it be waived?
Finding
Part of the condition can never happen: single step can only be turned on in a way that first returns the controller to its normal state. The rest can happen, so it must not be waived.
Supporting evidence
An unbounded formal proof for the impossible part. A check that the proof fails when the design is broken on purpose. A test that reaches the possible part, and a control run that does not.
Limits and remaining work
The proof covers the build without the floating point unit and was run with open source tools. Other builds need their own run.
Handover files
The report, the assertion, the waiver text for the proven part, and the test with its run instructions.
Read the full case

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?

Describe the problem in a few lines. An engineer replies, and we agree the scope together.

Discuss a verification problem