Skip to content
Vraelis
Sign inOpen Vraelis

The platform

Write one guarantee. Approve the plan. A real browser proves it on your live deployment.

This is the mechanism, in the order it runs. Vraelis crawls the system you connect, derives the requirements and browser journeys your guarantee implies, and shows you that plan. You approve it, a hosted Chromium browser drives the pinned deployment step by step, and the run ends on one of three words with the screenshots and the step record kept behind it.

Open Vraelis→How agents are handled→

One record per guarantee

Everything Vraelis knows lives on one object.

Not eight disconnected tools. One guarantee is one durable record, and it accumulates the context, the approved plan, the run, the findings, the decisions, the repairs, the evidence, the completion, and the full history.

The shape of one guaranteeVerified

Existing customers are never overcharged when usage billing ships.

Everything Vraelis learns about this guarantee accumulates here, in one place, in order.

Systems affected
Stripe / billing / dashboard
Work being judged
Add usage-based billing to the dashboard
Evidence
Screenshots, step record, console and network errors
History
Every state preserved, nothing overwritten
  1. Guarantee writtenRecorded

    One sentence the business depends on is recorded before any work is judged.

  2. Guarantee approved

    A person approves what must remain true. It is held outside the code, where the agent cannot move it.

  3. Plan approved

    A dry run derives the checks and the browser flow. A person approves that exact plan, and the paid run consumes it unchanged.

  4. Run recorded

    A real browser drives the live deployment. Each step is recorded as it happens, with the evidence it produced.

  5. Assumption challengedNeeds proof

    “Existing customers keep their current price” is contested until it is proven.

  6. Finding raisedFinding

    The usage meter is not enforced on the free plan. Recorded against the guarantee.

  7. Decision requiredReview

    The new pricing cannot ship until a person approves the change.

  8. Repair re-checked

    The fix is re-run against the same guarantee in a real browser, as its own record.

  9. Completion acceptedVerified

    The guarantee now holds, checked independently. Earlier records stay intact.

Guarantee

Start from the outcome, not the code.

A company does not care which files changed. It cares whether something it depends on still holds. Every record begins with one plainly stated guarantee, written by a person and kept outside the code the agent is changing.

What must remain true

Existing customers are never overcharged when usage billing ships.

GuaranteeStated as an outcome
ApprovalReviewed by a person
LocationHeld outside the code

Work

Every guarantee, and where each one stands.

The work surface is the portfolio view: every guarantee you have written, the system it is held against, and how its most recent run decided, in one decision vocabulary.

Existing customers are never overcharged when usage billing ships
Stripe / billing
In review
A paid customer keeps Pro access after signing back in
auth / api
Verified
An export contains only the requesting account's data
api / storage
Blocked
A new account reaches the dashboard without help
web / onboarding
Verified

Run activity

What Vraelis observes is the run, not the agent.

A check begins at the point work is claimed complete. From there a real browser drives the live deployment and each step is recorded as it happens, with its evidence attached. Plans, code changes and tool calls are not ingested while an agent is working.

What a run is given
  1. A deployment it can reach

    The hostname is resolved before the run is admitted, above the credit hold, so a mistyped address costs nothing rather than buying a report that the address was wrong.

  2. A guarantee, in one sentence

    Written by a person and held outside the code, so the standard a change is judged against cannot be edited by the work being judged.

  3. A plan that was approved

    Minted by a dry run, reviewed, then consumed exactly as approved. Vraelis declines to charge when it cannot build a check that would prove the claim.

The states a run moves through
  1. Queued

    Admitted, and waiting for a worker to lease it.

    in flight
  2. Running

    A real browser is driving the live deployment, one approved step at a time.

    in flight
  3. Verified

    The guarantee held, and the evidence behind that decision is kept with the record.

    Verified
  4. Failed

    The guarantee did not hold. The evidence and a repair prompt are written onto the issue.

    Failed
  5. Blocked

    No verdict could be reached, so none is reported. Nothing is recorded as proven.

    Blocked

Verified, Failed and Blocked are the only three answers a run can end on, and they are the same three the API, the CI gate and the webhooks return. Blocked means no verdict could be reached, which is the answer that keeps the other two worth having. How a run is recorded

Findings

Where a claim and the evidence disagree.

A finding is what remains when an agent's confidence meets what the software actually does. Contradictions, missing evidence, and unsafe assumptions are recorded against the guarantee, not buried in a log.

“Usage billing is complete.”Contradiction
The usage meter is not enforced on the free plan.
“Existing customers keep their price.”Missing evidence
No evidence was produced. The assumption is unproven.
“Checkout works end to end.”Failed check
Access was not granted after a successful payment.

Repair, live today

A fix is finished when the guarantee holds, checked independently.

This is the verification engine, one part of oversight. It holds the guarantee outside the code and proves the running software against it in a real browser. A repair is not done because the agent changed something. It is done when the guarantee passes again, as its own record, without overwriting the earlier ones.

How Vraelis challenges an agent’s claim→
Guarantee, held outside the code

A paid customer keeps Pro access after signing back in.

The agent claimedcheckout complete
Paymentsucceeded
Accessnot granted
First repairdid not survive sign-in
Later repairindependently Verified
Verified / 72c98eearlier records preserved

Completion

Completion is a decision, not a claim.

When an agent says it is done, Vraelis returns one of three states. The agent that produced the work does not get to certify it.

Verified

The guarantee holds, checked independently against the plan a person approved.

Failed

The software does not meet the guarantee. The gap is recorded as evidence.

Blocked

No verdict could be reached, so none is reported. Nothing is recorded as proven.

Knowledge

A real body of work behind the product.

Not footer links. Authored surfaces that explain how Vraelis thinks, how it works, and what it has shipped.

Documentation

Use and administer Vraelis

Open→

Vraelis Method

The worldview behind the product

Open→

README

Why Vraelis exists

Open→

Changelog

What shipped, dated

Open→

Research

The methodology and open questions

Open→

What it can reach

The browser is where this started, not where it stops.

The model does not change from one kind of system to the next. A requirement is written down and held outside the code, the running system is exercised against it under controlled conditions, what happened is captured as evidence, and a decision is made by something other than the thing that did the work. What changes is only how the system is reached and what counts as evidence once you are there. That is why the list below is a reach problem rather than a second product.

  • Deployed web applications

    Live

    A real browser drives the running software the way a person would, against the deployment you name.

    This is the surface the product was proven on, and every guarantee verified so far ran here.

  • HTTP APIs

    Live

    Requests, chained calls, the identity they run as, and the state they leave behind afterwards.

    Generally accessible and technically live. The engine's internal canary passed, including a genuine refusal. A third-party customer-path proof has not been run, and is not claimed.

  • Mobile, desktop and native applications

    Direction

    The application as a user runs it, on the platform it ships to.

    Not covered. The boundary today is what a real browser and an HTTP client can observe from outside, and a native binary is outside it. The limitations page says the same thing.

  • An SDK that carries evidence back

    Direction

    For systems no browser and no HTTP client can reach from outside. The SDK would register the exact build, model, firmware and configuration under test, receive the verification instructions, and emit signed execution checkpoints that attach to that exact identity.

    Not built. The SDK is an integration direction and has never been run as a verified surface. It is the piece the three rows below depend on, which is why it sits above them.

  • Connected devices, simulators and the edge

    Direction

    Device-control APIs, fleet and operator surfaces, and simulators standing in for hardware that is expensive or unsafe to exercise directly.

    Not built. Nothing in the product reaches a device or a simulator today.

  • Physical systems

    Direction

    Robots, drones and industrial equipment, where the evidence is telemetry, command receipt, internal state transitions, actuator outcome, timing, and how the system recovers when something goes wrong.

    Not built, and further out than everything above it. Stated because it is where the model leads, not because any part of it can be run. Vraelis verifies defined behaviour against stated requirements; it does not certify safety and never will.

A surface moves to Live when a real failing case has been driven end to end through the product on that surface and the product reported the failure truthfully. Not when the code exists, and not because it is close.

Honest about what is live

What Vraelis does today, and what it does not.

The verification engine is real and in use. Everything under Direction is a plan, and each line says what actually happens today instead. Next, Later and Horizon say how much of a line already stands, not when it lands. Nothing there is a delivery date, and nothing under Live today is coming soon.

Live today
  • A guarantee, held outside the code, with the plan that proves it approved by a person
  • Execution of the running software in a real browser, with evidence
  • A refusal to charge when no check could prove the claim, on every path that starts a run
  • Human review, findings, and a repair package written for a coding agent
  • Verified / Failed / Blocked decisions, with history preserved
  • Deployed web applications and HTTP APIs
  • API, an installable CLI, webhooks, GitHub, Vercel, and Slack
Direction
  • The command line installs with npm installNextToday it installs from a script served as plain text, on macOS, Linux and Windows. The package is prepared and is not published, so npm install does not reach it.
  • A plan is rehearsed before a person is asked to approve itNextToday a plan goes from prepared to approved with nothing having tried to run it in between. The rehearsal that refuses to mint a plan which cannot pass is an operator script, outside the product.
  • Every run asserts a value no earlier run could have left behindNextToday a plan can assert a value an earlier run wrote, so software that has stopped saving can still come back Verified. Clearing that state is a script somebody runs.
  • An outcome sentence is required when a system is connectedNextToday a contract that never named an outcome has no claim to gate, so its launches are recorded as ungated rather than counted as having passed.
  • The repair reaches your coding agent on its ownLaterToday a failure writes a repair package onto the issue: what should have happened, what happened instead, and the evidence. Vraelis does not send it anywhere. You copy it.
  • A repair is a durable record of its ownLaterToday the repair table exists and nothing writes to it, so the surfaces that read it are switched off. The repair package itself is real and lives on the issue and on the run report.
  • A new deployment is noticed, and rechecked without being askedLaterToday Vraelis reads the deployment you point it at when a run is launched. Nothing watches for the next one, and every recheck is started by a person.
  • One page per guarantee, showing every failure, repair and recheck in orderLaterToday each run records the guarantee and the exact approved meaning it was proved against. No surface puts that history in a line yet.
  • Live agent activity read as it happensHorizonToday a check begins at the point work is claimed complete. Plans, code changes and tool calls are not ingested while an agent is working.
  • Surfaces beyond a browser, and beside the agentHorizonToday the boundary is what a real browser and an HTTP client can observe from outside. Mobile, desktop and native applications are not covered.
  • Reliability memory, and autonomy earned from a recordHorizonNot built. How much an agent may be trusted to do alone should be a conclusion drawn from what it has actually got right, rather than a setting somebody chooses.

A line moves from the right column to the left when it works in the product, and the changelog records the date it did. Nothing moves because it is nearly done.

Direction

Human judgment at the boundary.

Not built. Most oversight can be mechanical and some of it cannot. Today a person approves or refuses a plan as a whole, and no step inside an approved plan is held on its own. The direction is to raise exactly the sensitive and irreversible moments to a person, deliberately and rarely, instead of holding the whole plan or none of it.

Approve the new pricing before it ships to existing customers
Decides: Billing owner
Direction
Confirm the data export is allowed for this account
Decides: Security
Direction
Accept the irreversible migration on the auth service
Decides: Engineering lead
Direction
Direction

Memory that makes the next guarantee faster to judge.

Not built. Today every run against a guarantee is preserved, with the plan that was approved, the step record, the screenshots and the decision, and nothing is overwritten. Nothing reads that history back. The direction is that what Vraelis learns on one guarantee sharpens the judgment on the next, so the accumulated, company-specific understanding is worth more than any single verdict.

01Company requirements
02Architecture boundaries
03Recurring failures
04Approved decisions
05Repair history
06Agent behavior
07Trusted completion standards

Let an agent do the work. Keep the sentence it is not allowed to break.

One guarantee, one plan you approved, one real browser run on your live deployment, and one decision with the evidence kept.

Open Vraelis→How agents are handled

Product

PlatformWhat it can reachWhat is builtAgentsIntegrationsPricingEnterprise

Developers

DocumentationAPICLIWebhooks

Company

Who it is forHow this is differentResearchMethodIn publicREADMEChangelogAbout

Trust

SecurityLimitationsPrivacyTermsData rightsSubprocessorsTrademarkContact

Vraelis checks what AI agents build against what the business actually requires.

© 2026 Vraelis
XLinkedInSecurityPrivacyTerms