The questions that come up, answered as they are asked.

No. Known applications are mapped automatically on import. Anything unknown is mapped by the software itself, and the examiner reviews the result.

The visual editor exists so that your examiners keep full control and can correct anything, rather than because they are expected to do the work.

That is treated the same way as an application nobody has seen before, and it is far more common. VERA generates a new mapping for the changed structure and the examiner validates it. You are not waiting for someone else to notice the change and ship a fix.

No. The library holds parsing definitions, which describe how to read a given application's data structure. It never holds evidence.

It is self-hosted on your infrastructure, and you decide who it is shared with, including nobody.

You see it before it is applied. What reaches the examiner is a preview over the real records rather than a specification to read, so a mapping that has misunderstood the source is usually obvious immediately.

The examiner corrects it in the visual editor or discards it. Nothing enters the case until a human accepts it.

You do not have to take its word for it. Every statement links to the exact file, table and row behind it, and one click puts you on the source.

The assistant proposes and your examiner decides. Nothing enters a report unverified.

Admissibility rests on the examiner's verification of source data rather than on the tool. VERA is built so that verifying takes one click instead of an afternoon.

It does not replace the examiner's judgement. It makes exercising that judgement practical at scale.

Every action the assistant takes and every result it receives is written to a log held inside your deployment. Records carry their provenance from ingestion through to display, and recovered records carry their recovery status, so a carved row is never presented as a live one.

They can challenge any finding, and they should be able to. What VERA provides is the material to answer with: the original record, its path, and the fact that an examiner verified it before it entered the report.

A finding that could not be traced back to a source record is not one we would want in a report either.

I would expect one. The architecture makes it simpler than most: no external connection, no telemetry, no vendor remote access, no data leaving your perimeter.

The questions that normally arrive in a review are answered in advance on the sovereignty page. I will answer whatever questionnaire you use, and anything not covered gets added to that page.

No. There is no remote support tunnel, no maintenance access and no mechanism by which I could reach a deployment. That is also why deployment documentation matters: the system has to run without me because I cannot reach into it.

The models run on your own hardware and can be replaced by you. Naming the specific models publicly would be a level of detail no vendor in this category publishes, and it would date badly, because the point of the design is that a model can be swapped without touching the client.

In a technical evaluation under a confidentiality frame this is a reasonable question and it gets a straight answer.

No. There is no online activation and no licence check that requires a network. A deployment that has never had an internet connection works exactly like one that has.

I am. That is why the deployment is fully documented, why the software runs without me, and why I am having this conversation with you rather than building a sales team.

If continuity is a concern, source escrow can go into the contract, along with a perpetual licence on the deployed version.

A fair question, and the honest answer has two halves. Contractually, source escrow and a perpetual licence on the deployed version are both available. Practically, a deployment that requires no internet connection and no vendor access does not stop working because the vendor did.

Below the direct-award threshold there is no formal procedure required, which is exactly why I would propose a pilot at that scale rather than a large contract.

If your service has a supplier-size requirement that a pilot does not solve, tell me early. That is a real constraint and I would rather know it before either of us spends time.

I can. It depends on the shape of the deployment, so it is a short conversation rather than a page on this site.

The structure is published: an annual licence per organisation rather than per seat, which matches the centralised architecture, with pilot arrangements available. What I would suggest first is a pilot small enough that procurement is not the difficult part.

Deployment support during installation, written documentation for the deployment, and a training session for the examiners who will use it. Support afterwards is direct with me, by email, without a ticketing layer in between.

I will not describe a twenty-four-hour support desk that does not exist. If your service requires one contractually, that is a real conversation to have before anything else.

That depends on what the deploying institution is willing to have said publicly, and I will not put words in their mouth on this website. Ask during the demonstration and I will tell you exactly where that stands at the time.