Patent Testing Strategy

Proofarc is built around 9 provisional patents covering continuous release readiness scoring, finding lifecycle, log correlation, compliance mapping, predictive failure analysis, scan orchestration, contract coverage, cross-engine UI testing, and release risk. Each patent is a real code path in this repository, and each one needs to keep working as the platform evolves — both as a product correctness concern and to avoid diluting the patent claim itself.

This page describes how we test each patent end-to-end on every release.

The 9 patents

#	US App	Title
1	64/039,668	Continuous Release Readiness Scoring with Code-Aware Quality Plan Generation and Dynamic Score Degradation
2	64/040,805	Release Readiness Scoring with Version-Aware Finding Lifecycle, External Issue Tracker Integration, and Fix Velocity
3	64/040,807	Runtime Log Correlation with Test Results and Source Code (the "Code-Test-Log Triangle")
4	64/042,838	Automated Compliance Evidence Generation and Multi-Framework Control Mapping
5	64/043,268	Predictive Test Failure Analysis Using Historical Code-Change-to-Test-Outcome Correlation
6	64/043,272	Compliance-Driven Security Scan Orchestration with Multi-Tool Pipeline Execution
7	(standalone)	API Contract Coverage Scoring
8	(standalone)	Cross-Engine Browser Compatibility Scoring
9	(standalone)	Predictive Release Risk Scoring

Full claims and specifications live under docs/patent/ in the source repo.

Where the tests live

Each patent has a dedicated UI Test Suite under the Proofarc Platform project (project ID 11):

Patent	Suite ID	Suite name
#1	7	Patent #1 — Continuous Release Readiness Scoring
#2	8	Patent #2 — Version-Aware Finding Lifecycle
#3	9	Patent #3 — Runtime Log Correlation (Code/Test/Log Triangle)
#4	10	Patent #4 — Automated Compliance Evidence Generation
#5	11	Patent #5 — Predictive Test Failure Analysis
#6	12	Patent #6 — Compliance-Driven Scan Orchestration
#7	13	Patent #7 — API Contract Coverage Scoring
#8	14	Patent #8 — Cross-Engine Browser Compatibility Scoring
#9	15	Patent #9 — Predictive Release Risk Scoring

The "Doc/App Verification Sweep" suite (id 6) is the regression baseline of 28 tests that exercise the platform UI itself; it currently doubles as the Patent #8 cross-engine evidence (every test runs on both WebDriver and Playwright).

Test type per patent

Different patents need different testing primitives. Pick the most direct:

Patent	Primary primitive	Why
#1 Readiness Scoring	API scenario	Score is computed from inputs and emitted via REST. Test feeds known inputs, asserts the score
#2 Finding Lifecycle	API scenario	Lifecycle transitions (NEW → SUPPRESSED → REOPENED) are REST-driven. Verify each state change end-to-end
#3 Log Correlation	API scenario + UI assertion	Trigger a failing test, assert pod logs are captured, assert correlation IDs in the test result
#4 Compliance Evidence	API scenario	POST a compliance profile, assert the evidence document JSON has the expected control mappings
#5 Predictive Test Failure	API scenario	Send a code-change diff, assert predicted failure list with non-zero probabilities matching P_fail = 1 - Π(1 - correlation(f_i, t_j))
#6 Compliance-Driven Scan Orchestration	API scenario	Submit a compliance profile, assert N scan jobs created across tools (NMAP, ZAP, Nuclei, Trivy, etc.)
#7 API Contract Coverage	API scenario	Import a known Swagger, assert N scenarios generated and coverage % computed
#8 Cross-Engine Browser Compat	UI suite, drivers: [WEBDRIVER, PLAYWRIGHT]	Run the suite on both engines, assert per-step parity ≥ threshold; CrossEngineComparator drives the score
#9 Predictive Release Risk	API scenario	Feed dev-activity signals (commits, churn, ownership), assert risk band emitted matches expectation

Per-test contract

Every test in a patent suite follows the same shape so the suite is deterministic and re-runnable:

1. Setup — known fixture (e.g. a project + env + test user already present in the cluster's bootstrap data).
2. Action — call a single REST endpoint or run a deterministic UI YAML. No flaky assumptions about clock or external services.
3. Assert — exact-match on the patent's observable, or threshold comparison for percentage scores.
4. Cleanup — the test deletes anything it created so re-running it produces the same result.

How to run

Per-patent suite

# Patent #8 — cross-engine sweep
curl -X POST "$APP_URL/api/ui-test-suites/14/run" \
     -H "Authorization: Bearer $TOKEN" \
     -H "Content-Type: application/json" \
     -d '{
           "target": "'$APP_URL'",
           "environmentId": 7,
           "drivers": ["WEBDRIVER", "PLAYWRIGHT"]
         }'

All patents (release gate)

Run each suite in turn, fail the release if any returns a step failure. A "Patent Validation" master suite (suite-of-suites) is on the roadmap.

Maintenance rules

1. Map every change in patent territory to a patent # in the commit message, e.g. feat(scoring): time-bound severity decay (Patent #1 Claim 6).
2. Bug fixes inside a patented mechanism must add a regression test to the relevant suite before the issue is closed.
3. Don't bypass a patented mechanism when fixing a test or doc gap. For example, replacing an EXECUTE_JS step with a plain NAVIGATE_TO removes a usage of the patented YAML interaction model — even if the test still passes, the claim is weaker. Prefer enhancing the patented path (e.g. a two-step expand-then-click EXECUTE_JS) over routing around it.
4. Patent suites are part of the release gate — failing patent tests block the version tag.