For engineers
How breakmy.AI validates the whole chain.
What runs where, what a check looks like, how it decides pass or fail, how it reaches your test environment, and what it never touches.
Web and API checks · You approve every check · Test environments only · EU-hosted, your own LLM key
Where it runs and what it talks to.
The agent and runner live in our EU environment. They talk to your test environment and your partners' test systems over HTTPS, with credentials you scope. Production is out of scope.
breakmy.AI (EU): the agent turns your plain-language flows into checks, the approval gate means nothing runs until you approve the check, and the runner executes checks on schedule or on request. Your test environment: your platform (web app and API, test accounts only) and your test data. Partners and devices: partner test systems (OEM clouds, roaming or market sandboxes, where they exist).
Outputs: a report in plain language plus evidence. A runner inside your own network is on the roadmap.
What your SRE needs for the allowlist ticket.
Authentication — API keys, OAuth2 client credentials and test-user logins.
A runner inside your network is on the roadmap.
Plain language for you. A deterministic spec underneath.
What you approve: “After we send the night-tariff schedule to the Ghent test depot, every charger, from every brand, has that schedule active within 5 minutes. The API answering ‘accepted’ is not enough.” Written by the agent from your flow description and your incident summary. You edit or approve it in plain language.
check: every-charger-accepts-schedule
flow: night-tariff schedule, depot "Ghent-test"
given:
- 6 test chargers, 3 brands
when:
- POST /schedules { site: ghent-test, profile: night-tariff }
then:
- response.status == 202
- # read back the outcome, don't trust the ack
- within 5m: every charger.activeProfile == "night-tariff"
on_fail:
- verdict: hold
- attach: request, response, charger state timeline
Illustrative format.
How a check decides.
Most integration tests stop at the response code. A breakmy.AI check only passes when the outcome is visible at the other end of the chain.
- Act — Send the command or request through your platform, as a user or system would.
- Read back — Ask the device, simulator or partner for the resulting state. An acknowledgement alone never passes.
- Wait within a limit — Poll until the expected state or the timeout you defined in the check (for example 5 minutes).
- Verdict — Pass, or hold with evidence: requests, responses and a state timeline your developer can replay.
A failure, an inconclusive hop, and a pass, told apart.
Every red line comes with the requests, responses and state timeline your developer needs to replay it.
Release 2.14 · nightly run · test environment — Hold · 1 failure, 1 inconclusive. Night-tariff schedule reaches every charger: fail (Brand B: profile not active after 5 min. CSMS logged SetChargingProfile accepted. Timeline attached). Tariff partner returns prices: inconclusive (partner sandbox timed out 3 of 3 attempts; its status page shows degraded. This hop was not tested. Your release policy decides: hold (default) or ship with a warning). Battery setpoint read back from OEM sandbox: pass (setpoint active after 42 s). Illustrative report.
Capabilities, honestly labelled.
- Web flows (browser) and API flows (HTTP/JSON) — Available
- Checks written from plain-language flow descriptions — Available. Described in chat or in the setup call.
- Approval gate before any check runs — Available. The Trust Stack: a human approves every new or changed check.
- Scheduled runs (nightly) and runs on request — Available
- Bring your own LLM key; EU hosting — Available. Default model configurable per workspace.
- Battery and heat-pump simulators — Roadmap
- Reading code changes from your repository — Roadmap
- Self-hosted runner inside your network — Roadmap
- Native mobile apps — Roadmap. Not planned for the energy focus.
What it touches, and what it never touches.
Scope — Test environments and partner test systems only. No production, no live devices. Use synthetic test data only; we confirm this with you at setup.
AI model — Or plug in your own key so your own provider contract applies. Your data is not used for training.
What we need from you.
Nothing to install in your product, no code changes.
- A test environment reachable from our fixed IPs. No public exposure needed if you allowlist them. Plus test accounts with the rights a real user or system would have.
- Access to partner test systems. Or the go-ahead to use a simulator where none exists.
- Your 3 critical flows. Described in plain language, with the time limit that matters (for example “within 5 minutes”).
- One or two past incidents. A short summary, no raw logs needed.
- A 45-minute setup call. With the engineer who knows the flows. Total team time over two weeks: about 2 hours.
Questions engineers ask
Why not write these checks ourselves? You can, in a sprint. The part that rots is keeping them right across charger brands, firmware and partners that change. We maintain that, and you keep the exported code.
Our partners' sandboxes are flaky or don't exist. Where a sandbox exists, partner noise is labelled separately from your failures. Where none exists, we use a simulator or a narrower check, and the report says which hops were simulated.
Will it load our test systems or our partners'? Each check declares its maximum calls and polling interval per run, and you approve it. There is a kill switch per workspace.
What if the agent writes a wrong check? You see every check before it runs. A wrong check gets edited or rejected, never run silently.
You're one founder. Who supports this? Thomas, during CET business hours. Your checks are exportable, so you're never locked in.
Do you test production? No. Production is your monitoring tool's job. We gate releases so fewer regressions reach it.
Want to see a check run against your own flow?
A 30-minute technical walkthrough with Thomas, or go straight to the free scan. Scan my 3 critical flows, free