What we can defend, and what we cannot yet
This page exists so a security review can start from facts rather than a questionnaire. It covers deployment, data handling, cryptography and failure behaviour, and it ends with the things a company of this size genuinely cannot offer yet.
Fail closed, everywhere, without exception
If a gate cannot be reached, if a check times out, if a dependency is unavailable, the result is recorded as unavailable. Never as a pass. An outage cannot silently become an approval.
This is the least convenient design decision available and it is the reason the evidence is worth anything. A verification layer that degrades to permissive under load is not a verification layer, it is a latency tax. It is also the first thing a chief risk officer asks about, and the first thing an external reviewer should test.
How to test it
Block network access to a gate during a pilot and confirm the verdict comes back as unavailable rather than accept. We will help you construct that test rather than ask you to take it on trust.
Someone else has already tested this one
An integration partner's technical audit examined this specifically. Their finding was that a transport record is stitched into every verdict, so an HTTP failure or an authentication error is marked degraded rather than scored as a valid safety abstention. In other words, an outage cannot disguise itself as the system having thought about your request and declined to answer. That distinction is small in code and large in an audit, and we did not think of it first.
Classified on our evidence page as partner-verified rather than independent, because the party that tested it is also the party that integrated it.
And one we found in our own code
We ran a concurrency harness against our own metering and evidence-chain code. The chain held under concurrent writes from multiple processes with no duplicate or missing sequence numbers. Metering did not: it lost charges when more than one worker ran at once. We fixed it, re-ran the harness, and the harness is in the repository so the result can be reproduced. It is listed on the evidence page along with everything else we have got wrong.
Where the data goes, in each model
| Model | What leaves your network | Suits |
|---|---|---|
| On your infrastructure | Nothing. Lanes are deterministic and require no external inference call, so verification runs entirely inside your boundary. | Regulated data, data-residency constraints, air-gapped environments |
| Hybrid | Only what you choose to send. Sensitive lanes stay local while non-sensitive ones use the hosted service. | Mixed sensitivity in one workflow |
| Hosted | The output or evidence you submit, plus the metadata needed to verify it. Retention is configurable and defined in the pilot agreement. | Evaluation and lower-sensitivity workflows |
The deployment model is chosen during pilot scoping, and the data-residency position is written into the pilot document rather than assumed. Field 10 and field 22 of the pilot template exist for exactly this.
How a pack is signed, and how you check it
| Property | Implementation |
|---|---|
| Signature | Ed25519 over the canonical serialisation of the verdict and its inputs. |
| Chaining | Each record is anchored in a tamper-evident chain, so removal or reordering is detectable. |
| Independent verification | The public key is published. A third party can verify a pack with standard libraries, without our source code and without contacting us. |
| Replay | A sealed pack can be re-run later to detect verification drift between the original run and the current code. |
| Determinism | The same input produces the same verdict. A result that does not reproduce is treated as a defect, not as variance. |
| Key custody | Signing key custody and rotation are defined per deployment. For customer-hosted deployments the keys are yours. |
If you find a vulnerability
Report it to admin@jvi3.com. We will acknowledge receipt, tell you honestly whether we can fix it and when, and credit you unless you would rather we did not.
We will not threaten anyone who reports a defect in good faith. Given the product, a researcher who breaks a gate is doing the most valuable thing anyone can do for us, and our own record of finding and publishing our own failures is on the evidence page.
A machine-readable policy is served at /.well-known/security.txt.
What a company this size cannot offer yet
A vendor-risk assessment will surface all of these. Reading them here first is faster for both of us, and it tells you something about how the rest of the page should be read.
- No certifications are held. Not ISO 27001, not SOC 2, not ISO/IEC 42001. Controls are built to be auditable, which is a weaker and more accurate claim.
- No third-party penetration test or security assurance report exists yet. Commissioning one is planned, and it has not happened.
- Headcount is one. There is no 24/7 on-call rotation, and we will not pretend otherwise in a support schedule.
- No formal business continuity or disaster recovery certification exists. Source escrow and the fact that most gates are public repositories are the practical mitigations, and both should be discussed before a pilot rather than after.
- No cyber insurance position is claimed on this page. Ask, and you will get the actual answer.
- The security benchmark measures our own lanes. It is not a penetration test of your systems and should never be read as one.
Why this section is on the page rather than in a questionnaire response
Every item here would emerge in the first vendor-risk assessment anyway. A company that volunteers them is easier to assess than one that discloses them under pressure, and if any of these is disqualifying for you, both sides should find that out in week one rather than week six.
Send the questionnaire
We will complete a vendor-risk questionnaire honestly, including the fields where the answer is no. If a control does not exist, the response says it does not exist.