Repository navigation
# [REFACTOR] Upgrade SignalProcessor Risk Equations for Class-Level Aggregation #109
Description
🎯 Objective
Modify the core execution loop in signal_processor.py to aggregate Function-level risks into their parent Classes before normalizing them into File-level scores.
🛠️ Implementation
prism.pyalready successfully links functions to classes (func["parent_class_name"] = cls["name"]).- Update the
_calc_*methods (e.g.,_calc_algorithmic_dos,_calc_cognitive_load) to iterate throughclassesfirst. - Sum the function impacts within the class boundary, generate a Class-level risk score, and then pass those Class aggregates up to the File-level Sigmoid normalizer.
Activity
squid-protocol commentedon Jul 25, 2026
Dug into the actual code to ground this before starting. Two corrections and one reframing:
Correction: the class-linkage isn't in
prism.py. It'sdetector.py:503(func["parent_class_name"] = cls["name"]), built as part of the class extractor atdetector.py~lines 466-522. That same block already computesmethod_count,state_entanglement, andlcom_scoreper class (confirmed, matches what #110 describes as the currentclass_datastate) -- so the class-detection infrastructure is further along than this issue implies, it's just misattributed.Reframing: don't touch the
_calc_*sigmoid methods. I read_calc_cog_loadclosely (the pattern holds across the other 13). These are density/sigmoid formulas -- they divide by the whole file's LOC and apply file-scale normalization (sigmoid slope/offset, doc-coverage cooling, a Gini multiplier). But per08-01-methodology.md's table, Level 2 (Class) is "count based, 0-∞" -- the same category as Function level. Only Level 3 (File) is "Sigmoid normalized, 0-100."So "iterate through classes first, generate a Class-level risk score, pass those aggregates up to the File-level Sigmoid normalizer" isn't quite the right shape -- sigmoid normalization shouldn't run at the class level at all, and File-level output shouldn't change numerically (summing via classes vs. summing directly from all functions is mathematically identical, since class membership partitions the function list exhaustively).
What's actually needed is a new, separate rollup step: for each class, sum the relevant raw hit-vector counts across its member functions (for the 14 metrics -- see #110 comment for the confirmed list), plus the class-specific extra (Gini for
cognitive_load, LCOM -- already computed! -- forstate_flux, etc.). This produces a raw 0-∞ class vector, stored alongside the class, without touching the existing file-level sigmoid pipeline at all.Proposed starting increment: build that rollup function first (in
detector.py, right after the existing class-physics block, or as a small new method signal_processor.py calls into), validate against a few real files, and stop there -- no schema/persistence changes yet. That's #110's job once the shape of the data is settled.