# SQCM v2.1 - supplementary validation note

Author: Erik Fernandes, ScaleQuality. Audit date: 2026-09-15. License: CC BY 4.0.

This note accompanies the consolidated methodology. Paper v2.1 describes score calibration v2.2. It records the scope of an internal implementation audit, not an independent certification or a population study.

## Audited implementation

| Component | Source revision inspected |
|---|---|
| Diagnostic/scoring service | 0aedaf2fa296dc63851454894bcf3c672c04913d |
| Insights/persistence service | cb70c9fb6c91c133b684032e3479993e6f306312 |
| Application frontend | a83dae05c26c7998f5b0e49e33718763a916d03d |
| Published CI client | @scalequality/check 0.5.3 |

Active service image identifiers were inspected separately from code. This is a dated deployment observation, not evidence that every supported integration was exercised end to end. The supplementary source identifiers are for traceability; the proprietary source repositories and scoring coefficients are not distributed here.

## Executed regression groups

The existing Jest suites were selected by exact file paths and executed against isolated checkouts. The reported elapsed times are test-harness durations, not diagnosis latency.

1. Composition, coverage integration/import/upload, measurement states, repository verifiability, and agent maturity delta: 7 suites, 36 tests, all passed.
2. Coverage receipt validation, format parsing, report paths and freshness, preflight and run provenance: 6 suites, 83 tests, all passed.
3. Coverage projection, project trends, CI report ingestion, measured-coverage service, and read-only MCP contracts: 5 suites, 71 tests, all passed.
4. Paper-specific compositor probes: 1 suite, 4 tests, all passed.

Total: 19 suites and 194 passing tests. This total does not imply 194 independent observations or complete system test coverage. The original logs and exact test selections are retained in the internal audit record.

## Controlled compositor probes

The probes invoke the real score composer. Their common architecture fixture uses a layered PHP stack; strong tests, coverage, CI, typing, lint and commit practices; an absent mutation practice; test/module ratio 0.5; no durability observations; and successful security/static stages without findings. A report-based Clover coverage value is varied where stated. These inputs are deliberately synthetic and contain no customer code.

| Probe | Input change | Recorded outcome |
|---|---|---|
| Continuous coverage | Report ratio 0.70 / 0.80 / 0.905 / 1.00 | Reliability 84 / 86 / 89 / 91; Maintainability 92 / 93 / 94 / 95; overall 93 / 94 / 95 / 96. |
| Newly measured Supply Chain | Dependency stage unavailable versus available with no findings plus clean image evidence, at 90.5% coverage | Overall 95 versus 96; Supply Chain unavailable versus 100. |
| Current secret | Add one current-tree synthetic critical secret, at 90.5% coverage | Security 60 (ATTENTION); overall capped at 55. |
| Structural posture | Hold structural architecture fixed at ratio 0.5; switch qualitative posture from SPARSE to WELL_TESTED | Overall 82 versus 96. This is a sensitivity probe, not an empirical test of stochastic model variability. |

Existing measured-coverage tests also check that coverage-dependent domains can improve while a critical-exposure cap holds the overall result. The CSV distributed alongside this note contains the four continuous-coverage rows. It is illustrative output, not a general conversion rule or calibration dataset.

## Evidence not newly collected

No new customer repository scans, complete language/toolchain campaign, runtime security assessment, deep-analysis benchmark, independent defect corpus, or longitudinal outcome study was performed for this revision. August performance and detection observations are cited as historical results from paper v2.0, not as reproduced measurements.

The tests support the specific implementation contracts and counterexamples they exercise. They do not establish causal effects, predictive validity, calibrated confidence probabilities, general precision/recall, or end-to-end latency guarantees.

## Availability and reproduction limits

The conceptual method, this note, and the illustrative CSV are public. Full independent reproduction of the proprietary instrument requires access to its implementation, toolchain, rule versions and external-data snapshots, which this publication does not provide. Given those inputs, replay should preserve the revision, reports and their scope, analysis time, execution status, and scoring calibration. Recollecting evidence at the same commit at a later date need not yield identical inputs.