Skip to content
Vraelis
Sign inOpen Vraelis

Limitations

What this cannot do, written down.

A product whose entire claim is trustworthy evidence has no business being vague about its own edges. These are real and current. Most have a workaround, and none of them are quietly handled behind your back.

Coverage

What Vraelis can verify today.

Deployed web applicationsSupported and proven in production
HTTP APIsSupported
Mobile applicationsNot supported
Desktop applicationsNot supported

Where a run needs you

Three things a run cannot do alone.

01

Sign-in that requires a human

A one-time code sent to a phone, a CAPTCHA, or a hardware key cannot be completed by a run. Give Vraelis a test identity that signs in with a password, or a preview environment where the challenge is disabled.

02

Destructive actions

A run will not delete an account or cancel a live subscription unless a flow explicitly permits it. That guard is on by default, so a journey ending in deletion will stop short until you say otherwise.

03

Anything outside the deployment

Vraelis drives your application from the outside, exactly as a person would. It cannot read your database directly, inspect your logs, or reason about code it never sees. If a failure leaves no trace in the interface, a run cannot observe it.

How strong the binding is

What a verification is actually evidence of.

A URL is not a build

A verification is bound to the address it tested, and the same address can serve different code an hour later. That binding is deliberately called weak in the record rather than presented as proof that a specific commit was verified.

A rerun proves the same meaning, not the same bytes

Rerunning a verification re-proves the approved requirements against whatever is deployed now. It is evidence about the current build, not a replay of the previous one.

Older records carry less provenance

Verifications from before requirement provenance existed are labelled as such. Where the ordering or the reviewer of an old contract was never recorded, the record says so instead of presenting a reconstruction.

Authorship and review

The system will not approve its own work.

01

A model may author a requirement. Only a person may review it.

Vraelis derives requirements from your guarantee, and those requirements are marked as machine-authored and awaiting review. They do not become binding because the system produced them.

02

An unreviewed plan does not run

Submit a claim and Vraelis returns the plan it would execute, marked review required, and runs nothing. A person approves the exact plan, and execution then runs precisely that.

03

Discovery may propose, not rewrite

Re-running discovery against an approved contract will not edit what was already approved. It refuses rather than quietly changing the meaning a past verification was measured against.

How access, secrets and evidence are handled is on security. How a verification is produced is on method.

Product

PlatformWhat it can reachWhat is builtAgentsIntegrationsPricingEnterprise

Developers

DocumentationAPICLIWebhooks

Company

Who it is forHow this is differentResearchMethodIn publicREADMEChangelogAbout

Trust

SecurityLimitationsPrivacyTermsData rightsSubprocessorsTrademarkContact
© 2026 Vraelis
XLinkedInSecurityPrivacyTerms