Platform Overview

Proofarc is the Unified Release Engineering Platform. One place to author, run, and reason about everything that gates a release — tests, scans, performance runs, compliance evidence, readiness scoring. Built around a simple idea: every quality activity should feed the next one.

The Pipeline

Define Tests → Execute → Convert to Performance → Scan for Security
      ↓             ↓              ↓                     ↓
  All results feed into one Readiness Score (0-100)
      ↓
  Automatically mapped to Compliance Controls
      ↓
  Ship or Don't Ship

Why this matters

In a typical setup, you:

1. Write API tests in one tool
2. Rewrite the same scenarios for performance testing in another tool
3. Run security scanners separately
4. Manually compile results for compliance audits
5. Have a meeting to decide if it's safe to release

In Proofarc, you:

1. Write API tests once (YAML)
2. Click "Convert to Performance Test" — same endpoints, same auth
3. Security scanners run against the same targets
4. Compliance evidence is auto-generated
5. One score tells you: ready or not ready

What the platform can do

The short version, with a link to each. If you are deciding whether something is possible here, this table is the answer.

Authoring — getting a test written

Visual element picker	Point at an element in a live page and get a stable selector. In the UI-test wizard at both Discover and Build. →
Crawler	Walks the app and returns an inventory of every interactive element with selectors. HtmlUnit or Playwright. →
From an OpenAPI spec	Point at a Swagger URL and get runnable API scenarios. →
From plain English	Describe a test in a sentence; get a confirmable plan. →
From an existing suite	Import TestRail, Xray, Postman. →
By hand, in YAML	Every surface has a documented YAML format. →

Advisories — what only we can tell you

These are the outputs that improve your application, not just report on it.

UI testability advisory	Grades every control on whether a test can reliably find it, and names the attribute to add. Web and mobile. →
Swagger test-readiness	Scores a spec for whether good tests can be generated from it, before you generate. →
API surface coverage	How much of your documented API has a test — and how much of that actually asserts anything. →
Crawl saturation	Whether a crawl ran out of application or out of budget, so a coverage number is never quoted from a partial crawl. →

Execution

Web UI	Two independent engines — Selenium and Playwright. The same test on both is our strongest bug signal. →
Mobile	Android and iOS, local Appium or a device farm. →
API	Contract, CRUD, auth-conformance, data-driven. →
Performance	Artillery load and queue tests. →
Security	Active scanning — ZAP, Nuclei, SQLMap, Nikto, Nmap, Trivy. Not dependency scanning; real probing of a running system. →

Driving it all from an agent

Every capability above is available over MCP — the platform is designed to be operated by an AI agent rather than only by a human at a keyboard. →

The one exception is the visual element picker, which is inherently point-and-click. An agent uses the crawler and the testability advisory instead.

Core Concepts

Proofarc separates three kinds of things that traditional tooling conflates: what you build, where you run it, and how you organize the work.

Applications

An Application is the deployable thing your team owns — a REST API, a web UI, a mobile app. Applications are top-level and canonical: one user-service row, regardless of how many teams or release contexts reference it. The Application carries its git URL, default branch, registry, and Jira key once — no duplication.

Reference: Applications & branch tracking.

Projects

A Project is a grouping concept — the team or release context that uses one or more Applications. Projects link to Applications through memberships (with a tracking mode: LATEST or PINNED to a branch). A Project doesn't contain Applications; it tracks them.

Reference: Projects & Environments.

Tests belong to Applications

API scenarios, UI tests, performance scenarios, and mobile tests all carry an application_id. They live in a Project for grouping, and point at the Application they cover. That's what lets you ask "what tests cover user-service?" across every Project.

Reference: How tests map to applications.

Environments

Each Project has environments: development, QA, staging, production. An Environment Target says "this is how the user-service Application is deployed in this environment" — the URL, the auth config, the credentials. Same Application, three environments → three Environment Targets.

For network-shaped targets (hosts, subnets, K8s clusters, container registries), Environment Targets link to a canonical Infrastructure Target. That keeps findings on auth-host-prod deduplicated across environments.

Reference: Infrastructure targets.

Test Types

Type	How it works
API Scenarios	YAML or JSON-defined HTTP request sequences with assertions and variable extraction
UI Tests	Browser automation via Selenium or Playwright, defined in YAML
Mobile Tests	Appium-based mobile app testing
Performance Tests	Load testing — converted from API scenarios or defined standalone
Security Scans	Vulnerability scanning with multiple tools (auth inherited from targets)

Readiness Scoring

The platform computes a 0-100 readiness score from weighted milestones:

• Security (findings count + severity)
• API Tests (pass rate + contract coverage)
• UI Tests (pass rate + cross-engine compatibility)
• Performance (response times + error rates)
• Code Quality (practices + review quality)
• Compliance (framework control status)

Prediction

Before tests run, Proofarc predicts:

• Which tests will fail — based on historical code-change-to-test correlation
• Release risk level — from 7 development process signals
• Hidden quality issues — runtime log errors that pass tests but indicate problems

Self-Hosted

Proofarc runs on your infrastructure. Your data never leaves your network.

• Docker Compose — single command, runs everywhere
• Kubernetes — Helm chart for production deployment
• No cloud dependency — works air-gapped