How Readiness Scoring Works
Proofarc computes a single 0-100 readiness score that answers: "Is this safe to ship?"
The Score
The score is a weighted average of milestones — each representing a quality dimension:
| Milestone | Weight | What it measures |
|---|---|---|
| Security | 25% | Vulnerability findings by severity (CRITICAL/HIGH/MEDIUM) |
| API Tests | 20% | Scenario pass rate + API contract coverage |
| UI Tests | 15% | Browser test pass rate + cross-engine compatibility |
| Performance | 15% | Response times, error rates, throughput vs thresholds |
| Code Quality | 10% | Engineering practices, CI/CD, linting, health checks |
| Log Health | 10% | Runtime log anomalies during test execution |
| Approval | 5% | Manual sign-off by release manager |
How It Differs From Other Tools
| Feature | Traditional Tools | Proofarc |
|---|---|---|
| Test results | Pass/fail per test | Weighted contribution to score |
| Security findings | Count by severity | State-adjusted: FIXED=0, REOPENED=1.2x penalty |
| Stale results | Still show green | Time decay reduces confidence over days |
| Practice compliance | Not measured | Score ceiling: no CI/CD = max 75% |
| Prediction | None | Pre-test risk signals + failure probability |
Predictive Signals
Before tests run, 7 signals predict risk:
- Changeset Classification — DB migrations and auth code = higher risk
- Code Review Quality — unreviewed commits = risk
- Change Velocity — late changes near release = risk
- Contract Drift — API spec vs runtime response mismatch
- Dependency Chain — upstream API changed after you tested
- UI Testability — interactive elements without test IDs
- Environment Pattern — testing only in staging, skipping dev/QA
Repository URL is required for Git-derived signals
Three of the predictive signals — Code Review Quality, Change Velocity, and Deployment Risk — require a Git clone to compute. They are sourced from commit history, PR coverage, and file-level churn analysis, not from runtime data.
If the readiness plan for an application has no repoUrl configured, those three sections won't render and the page shows an inline notice:
Repository URL not configured for AppName. Deployment risk, code review quality, and change velocity can't be computed without a Git repo. Set
repoUrlon the readiness plan to enable these scores.
This is a configuration gap, not a backend failure — the endpoints return 200 OK with { unconfigured: true, message: "..." } rather than crashing. Set repoUrl via the readiness plan editor in the UI and the scores will populate on next page load.
How the overall status rolls up
Release readiness reports one overall status per area (tests, security, performance), with a strict precedence: RED → GREY → YELLOW → GREEN.
- GREY means "no recent data" — and it blocks. An area with nothing recent can never roll up as GREEN; unknown is not ready. RED anywhere wins over everything.
- Security counts are triage-aware. Findings marked
FALSE_POSITIVEorFIXEDstop counting toward (and stop blocking) the security roll-up — triage work is reflected immediately. - A scan still in flight holds the area at YELLOW ("N scan(s) still running") rather than reading ready.
After Tests Run
The Code-Test-Log Triangle catches hidden issues:
- Tests pass but application logs show errors → health drops
- Stack traces map to source files → specific code identified
- Recently changed files producing errors → regression detected
Patent-Protected
The scoring algorithms are protected by 9 provisional patent applications covering readiness computation, finding lifecycle, log correlation, predictive analysis, compliance evidence, and orchestration.