Features

The part of Lastest that matters under GxP.

Lastest is a broad platform. This page lists only what a validation lead, a QA manager or an IT security reviewer at a pharma company will ask about - and leaves out what they will not. The complete list is on lastest.cloud/features.

01 · Regulated profile

Nothing probabilistic produces a verdict

A model may draft or repair a test. Only deterministic replay decides pass or fail. Text and DOM layers default to enforce so Part 11 manifestations - who, what, when, the meaning of a signature - are checked literally, not visually. Gamification is removed from the product entirely.

02 · Identity

Nothing leaves the tenant anonymously

Every action, export and share is tied to an authenticated identity. Public share links and anonymous access are off. Per-repo credentials are stored encrypted at rest and injected only at run time.

03 · History

Every change carries a reason

Each edit, AI fix or baseline restore is versioned with who did it, when, and why. Builds are composed from specific test versions, so the suite that produced a piece of evidence can be reconstructed exactly.

01 · Veeva Vault suites

Vault CRM, PromoMats, Clinical, RIM

Seeded by the regulated onboarding fork: auth bridge, object pages, call reporting, samples, consent, rendition checks, study and submission structures. Plain Playwright in your repository - a starting point that removes weeks of authoring, not a substitute for your PQ scripts.

02 · Scenario data

Spreadsheet-driven, one column per country

Synthetic scenario data lives in a spreadsheet you own. Each market is a column: local call-reporting rules, sample and consent regulations, disclosure fields, locale. The same flow replays per column, so adding a country does not mean recording a suite.

03 · Coverage matrix

Flow x layer x market, from run artifacts

Coverage is computed from what the runs actually reached and which layers produced a verdict there - not from a tracker someone fills in. Gaps per market are visible before the general release, and the history is kept per build.

04 · Health score

Weighted 0-100 per repository

Pass rate (60%), non-flaky rate (20%) and route coverage (20%) combined into one trend an application owner can read across releases.

01 · 9 check layers

Visual, text, DOM, network, console, performance, URL, API, storage

Each layer set to enforce, log or off per repository, with a11y and design-system layers available as plugins. Per-layer approve, reject or snooze on every step comparison, so a font-rendering change is not triaged the same way as a missing signature row.

02 · 3 diff engines

Pixel, structural, perceptual

Every captured screen is compared three ways, so a renamed tab, a relocated field or a broken layout surfaces even when the functional assertion still passes - the failure a green suite hides.

03 · Flake guards

Real Chromium in a container, twelve flaky-test guards

Network idle, animation settle, font readiness, clock freezing and record-ID masking are applied before a screen is compared. A difference is a difference in the application, not in the runner.

04 · Bring your own model

Your endpoint, hosted or local

The model used at authoring time is one you point at - a hosted provider under your contract or a local one inside your network. No test content is sent anywhere you did not choose.

01 · Interactive playback

Session video on a step-synced clock

Per-step tick marks, click a step to seek, network, performance and URL panes that follow the scrubber. A reviewer sees what the screen did at the moment the check ran.

02 · Evidence-grade issues

Confirmed regressions file complete issues

Baseline, actual, diff, step context and run metadata attached; assignable to an engineer, closed automatically when a subsequent build passes. Nothing is retyped.

03 · Ownership

Files on disk you control

Suites, spreadsheet, baselines and reports are files in your repository and your storage. Export them into your validation records; run them without Lastest installed.

01 · Self-hosted

Docker Compose on your infrastructure

Runner, screens, baselines and reports stay inside your network boundary. Air-gapped operation is supported. Source is available for your security review before anything is installed.

02 · CI/CD

GitHub Actions, GitLab, Jenkins, scheduled runs

Replays run on a schedule against the prerelease Vault, on every configuration change, and after each limited release, and post their results back to the systems you already watch.

03 · MCP server

Coverage and results readable by agents

The same coverage matrix and run history are exposed over an MCP server, so your internal tooling and assistants read the facts instead of a summary.

Deliberately not on this page

The practice playground, the Beat the Bot leaderboard, achievements and seasonal play, public share links, the launch board and the free-tier pricing table. They exist in Lastest; the regulated profile turns the gamified ones off, and none of them is why you would evaluate a test runner for a Vault release. If you need one of them, ask in the release-readiness review.