CorrectestThe correct way to test Request a pilot

Roadmap

What's shipped, what's still coming, and what we won't build.

Three labels, used the same way across this site. No label: live in the product today. IN BUILD: decided and designed, not yet live. PLANNED: on the list, not yet designed in detail. Nothing here is a promise of a date.

Recently shipped

The platform is live in production.

The API, the browser worker, the database, and the client application are running on managed cloud infrastructure. Onboarding is deliberately by hand during the design-partner phase: we would rather set your first scan up with you than open self-serve signup and watch you find the sharp edges alone.

Shipped

Story handling, sharpened.

A story written for "a new visitor" scans without a login being invented for it. A criterion you skip stays skipped even when a later extraction re-words its title. A suite from a signed-out scan carries no sign-in step. And a long document is read in full rather than truncated to fit.

Documents & stories →
Shipped

Take your data out, whenever.

A standing "Download your data" control on your dashboard, on each application, and on the notice shown during an offboarding grace window. Your Knowledge Base and your generated suites are yours to take at any time, not on request.

Shipped

The whole platform-coverage cluster.

Component apps, embedded frames, accessibility, charts and Salesforce were a direction a year ago. All five are built and merged, and each is described on this page with what it does today.

In build

Four things this site says IN BUILD, and exactly what they mean.

Wherever a page here carries an IN BUILD label, it points at one of these. Each is decided and designed; none is live.

More than one success path per flow IN BUILD
Every replay depth records one happy-path submission per flow today, and the invalid-input probing is what the depth dial actually varies. The extra success paths at the deepest setting, and the minimum-required-fields path at the standard one, are designed and tracked but not built.
A coverage-gap signal on the lightest depth IN BUILD
The light setting sweeps every field's invalid values in a few rounds. On an application that reports only one error per submission it will under-cover, and today you find that out by re-running deeper. An explicit signal saying so is not built.
Clicking into a chart IN BUILD
Correctest describes a chart, asserts on the chart's own data model where the library exposes one, and visually snapshots the region otherwise. Driving coordinate-level interactions on the canvas itself shipped as a deliberate stub, so a chart that gates a flow is described and snapshotted rather than clicked through.
Mandatory multi-factor authentication on Correctest accounts IN BUILD
The rest of the access controls — deny-by-default authentication, a separately addressed admin console, per-tenant isolation — are live. See the Trust Center.

Any stack

Correctest should walk into a client engagement without worrying what the application is built on.

Modern component apps
Discovery walks inside web components, including content projected into them and icon-only buttons whose labels live in styling rather than text, and it verifies every selector with the same engine your generated tests will run. For the rare applications that seal a component, there is an opt-in, fully disclosed mode that opens them; where a sealed region genuinely cannot be reached, the Knowledge Base records a named, declared-unreachable region rather than skipping it in silence. Pages that assemble themselves after loading get a proper wait-until-settled step, and pages that never settle are recorded as live-updating rather than stalling the crawl.
Embedded frames
Payment widgets, sign-in-with buttons, embedded editors. Discovery walks every frame, the Knowledge Base records each frame's identity and ownership, and generated tests address in-frame elements natively. Each frame is classified by ownership: your own frames are tested into; another company's widget is verified at the boundary — "your page correctly presents the payment box at the right step" — because a test that breaks when the widget's vendor redesigns their internals tells you nothing about your application. Cross-origin does not mean skipped: a first-party frame served from another origin is still tested into. Every excluded third-party region is listed in the coverage documentation and the project README, never a silent gap.
Charts and canvas graphics
Dashboards draw charts onto a canvas: pixels with no structure inside, invisible to structural tools. Correctest chooses a strategy per chart at scan time. It always describes what the chart shows, which is knowledge no pure-structural tool captures. It asserts on the chart's own data model where the charting library exposes one, the most robust option available. Otherwise it snapshots the region visually, self-baselined in your CI. Charts fed by live data are asserted on structure, never on values that legitimately change. IN BUILD Coordinate-level click-through.
Salesforce applications
Correctest tests your Salesforce application against your own observed behaviour. It does not grade, benchmark or monitor the platform. The useful finding from the research: Salesforce is not a wall — its rendering is automatable with exactly the accessible-label-and-role strategy Correctest already prefers, which is the thing Salesforce keeps stable across releases. The adapter adds what is org-specific: deterministic login past multi-factor authentication, correct waiting for Lightning pages, a deny-list of known-unstable selectors, reading your org's own metadata, and a knowledge pack of Salesforce's published component map that we maintain so the scanner recognises standard components on sight. Verified against a real Salesforce developer org before we made any claim about it. Our own first end-to-end engagement on a client org is still ahead of us.

Accessibility

A paid add-on, with a three-consent design.

  1. Observation is always on and costs you nothing. Every scan runs the industry-standard accessibility rule engine at every page state it visits, storing findings in your own Knowledge Base, surfaced nowhere unless you buy the service.
  2. Purchase unlocks the product: the audit report, violations per page and state with evidence, and an AI review of the items rules alone cannot judge, such as whether alternative text is actually meaningful. Because the evidence was stored at scan time, buying later unlocks your recent scan's findings instantly, with no re-scan.
  3. Enforcement is your explicit third choice. Optionally, your generated project gains accessibility regression tests that fail CI only on new violations against the scanned baseline. A green run means "no new detectable issues", never "certified compliant": automation covers roughly a third of the standard's criteria, and every report says so.

For procurement-driven buyers a draft conformance report can be generated, watermarked as a draft, with the human-judgement rows structurally unfillable and its scope printed on it. It is produced only once you have confirmed which flows make up your application and one fresh run has walked every one of them. Wholeness is something you attest to, not something a scan asserts about itself.

There is also a cheaper audit-only scan mode. It keeps the part that makes these findings better than a plain URL scanner — the AI-driven crawl that logs in and reaches the mid-flow and validation-error states where real violations hide — and switches off the spending that exists only to author a test suite.

Built and merged. Our own paid live-verification pass, comparing against a commissioned WCAG audit, is still ahead of us.

Self-heal at generation

When a verification replay of your known flows finds that an element has moved, a repair ladder tries the element's other stored selectors and, failing those, re-identifies it by its meaning, producing a new working selector recorded with a confidence score. Regenerating your suite emits the repaired selector, with no re-scan needed.

A high-confidence repair applies everywhere that selector reaches your project. A low-confidence one is never silently emitted into your CI: that step is left out and flagged for review. The frozen scan snapshot is never modified. And where the structural evidence is simply missing, the matcher is told so plainly, because an absence of evidence must never be read as evidence against a candidate. Genuine ambiguity still ends in "not sure".

Planned

On the list, not yet designed in detail.

PLANNED

Several environments per application.

Today exactly one: the address explored and its sign-in page. QA and staging as separate environments is a later change to the same control. Meanwhile a generated suite already re-points at another environment with one variable.

PLANNED

Scanning as every role in one go.

Today one scan signs in as one role, and the persona-coverage view compares roles across scans. Running one full scan per role from a single click is a command-line path for now.

PLANNED

Several files per upload step.

A story step that needs a real file gets exactly one supplied file today, with an honest record of the limit when a control accepts several.

PLANNED

Reading a scanned PDF.

A PDF with no text layer is asked for as a text version today rather than guessed at. Optical character recognition is deferred, not forgotten.

PLANNED

Per-step pictures for story walks.

Flows found by the crawl already carry a picture per step. Story-guided walks are filmed but do not get the per-step filmstrip yet.

PLANNED

An alerts page.

Notices reach you on the screens where they matter. A single place that collects everything waiting on you across applications is on the list.

Deliberately not

Things Correctest does not do, and won't pretend to.

  • It is not a test runner and not a CI system. It generates the suite; you run it.
  • It does not drive single sign-on, SAML, push approvals, magic links or bot checks. It recognises them, records what it saw so you know why a run stayed shallow, and accepts a browser session you exported by hand instead.
  • It does not drive password resets or sign-outs for real. Doing so would send emails or end sessions; those flows are skipped by policy and the coverage report says so in as many words.
  • It does not invent things: not a file for an upload step, not an observation for a flow it never walked, not a conformant verdict for a story whose comparison did not complete.
  • It does not judge your application. It records what your app does; you decide what it should do.
  • It is not a load-testing or security-scanning tool, and it must not be pointed at a platform vendor's service for those purposes.
  • It shows no dollar figure on any client screen. Your unit is credits, with a hard ceiling per scan that a scan cannot exceed.

The Trust Center is the other half

What's true today, what's in build, what we don't have yet including the certifications we haven't earned, where your data lives and which vendors touch it, and the operating agreement we ask of your organisation. Open the Trust Center →