Australis
DocsPricingFor Work
Get the beta
Verification

Every build ends with proof.

An independent verifier drives your app the way a customer would — clicks, types, books, breaks. Each promise gets checked by name and signed off in green. Green means proven, not probably.

A verified build is one that compiled, booted, answered on every page, passed each behaviour you asked for, and survived a phone-width visual check — with the receipt to show it.

Get the betaThe security model
✓Verification run — Sunset Yoga, bookingsRUN #2 · 41s
✓ Compiles — zero errors✓ Boots and stays up✓ All 6 pages respond✓ Booking a class decreases spots left✓ Full classes offer the waitlist Customer details hidden unless signed in SECURITY✓ Works at phone width — 375px sweep
PROVEN
Share it as a public receipt at australis.io/r/…

What does a verified build have to pass?

A build isn't done when the code is written — it's done when it survives all six.

1It compiles

Every file builds cleanly. Syntax errors and broken imports never reach you — they're caught and repaired before the run continues.

2It boots

The app starts in a clean sandbox and stays up — no crash on launch, no silent white screen.

3Every page responds

Each screen in the plan is visited and answers. Dead routes, broken links, and error pages fail the run.

4Behaviors, by name

The promises from your plan — "booking a spot decreases availability" — are each driven end-to-end and checked individually. Your proof list uses your words.

Data stays protected

Four named security checks ride on the same receipt: no secrets in the code that ships, no secret behind a public prefix, private pages behind sign-in, and the database's own security advisor. Each reads proven, found wanting, or skipped — with the reason.

6Phone-ready sweep

Every screen re-checked at phone width in a browser — nothing cut off, nothing unreachable. It checks the web app at phone size, not on a real phone.

Independent by design

Who checks the build?

The agent that writes your code and the agent that checks it are separate — different roles, different context, different incentives. The verifier only sees the plan's promises and the running app, so it tests what you asked for, not what the builder thinks it built.

When a check fails, the failure goes back to the builder with the specific broken promise — and the run repeats until every gate is green or we stop and tell you honestly.

🔨Builder agentwrites code from the approved plan
hands off the running app — nothing else
Verifier agentdrives it like a user, grades against the plan
They never share notes. That's the point.
Share the receipt

Any build's receipt can become a public, read-only page at australis.io/r/… — what was checked, what passed, each behaviour by name. Press Share receipt on the verdict card or in the preview toolbar, then send the link to a client or a teammate.

Is it locked down?

The security pass runs again each time a build lands, and its findings show as a shield on the receipt. A check that couldn't run — no database, nothing to sign in to — says so instead of pretending to pass.

What happens if a build fails?

Proof isn't just a quality bar — it's part of the billing rule. If a build fails verification, you get half its credits back, on every plan, worked out from what the build really spent.

How pricing works →

See your first proof this week.

Request the beta, describe an app, and watch the verifier drive it. The proof does the convincing.

Get the betaSee how a build works
© 2026 Australis Technologies Pty Ltd · ACN 700 968 930. All rights reserved.
PrivacyTermsDPA & subprocessorsSecurity