Repository navigation
prism/detector: string-literal shielding is selective by signal family (if/try/open count inside a literal, eval does not) #2535
Description
Summary
Found by the #1096 control corpus (first reference language, python): string-literal
shielding for signal counting is selective by signal family. Keywords inside the same
string literal count toward branch/safety/io but NOT toward high_risk_execution.
Repro (verified 2026-08-31, full_precision venv, galaxyscope --db-only)
Two-file git repo; identical except the literal's content:
# s1.py
M = "if eval fails, try open"
def alpha(x):
return x# s2.py
M = "plain words only here"
def alpha(x):
return xObserved diff (s1 minus s2, nonzero signals only):
| signal | s1.py | s2.py |
|---|---|---|
| branch | 2 (if, try) |
0 |
| safety | 1 (try) |
0 |
| io | 1 (open) |
0 |
| high_risk_execution | 0 (eval did not count) |
0 |
| sec_tainted_injection | 1 | 0 |
So eval inside a literal is suppressed from the structural count (it appears to route to
the taint sensor instead), while if/try/open in the same literal all count.
Question
Is this intentional (dangerous-token literals deliberately reclassified as taint, ordinary
keywords deliberately counted as "code-shaped mass in strings")? Either answer is fine for
the #1096 corpus — but it should be documented, because right now the comment surface is
fully stripped (verified: the same keywords in comments contribute 0) while the string
surface is inconsistently half-counted, which is invisible to anyone reasoning about
cross-language equivalence.
If unintentional, the fix direction needs a decision first: shield literals for ALL
code-stream signals (comment-parity), or count them for all and let sec_* be additive.
References
- Feature: multi-language control corpus to validate structural extraction equivalence across languages #1096 corpus,
data/python/expected_signals.jsondecoy outcomes (string decoy baked in at branch +2 / safety +1 / io +1). prism.pyliteral shielding; the counting path that consumes code_stream.
Activity
squid-protocol commentedon Aug 31, 2026
Cross-language addendum from the #1096 corpus (cobol + javascript reference folders now scanned):
"if eval fails, try open",if/trycount (branch +2, safety +1) whileevaldoes not count high_risk_execution.DISPLAY 'IF ALTER FAILS TRY OPEN AGAIN'., ALL ofIF(branch),ALTER(high_risk_execution +1), andOPEN(io) count from inside the literal.So the selective shielding isn't a global high-risk-family rule — it varies by lexical family (the c-family/python-family masking path vs. cobol's positional stripper). Whatever the intended semantics, they're currently inconsistent across languages, which is precisely the language-bias shape #1096 exists to catch.
squid-protocol commentedon Aug 31, 2026
Legacy-batch addendum (fortran, ada, abap, assembly reference folders now scanned) — the shielding matrix is now three distinct profiles plus one amplification:
ALTER,GOTO,jmp,syscall, adaif) — ARM's single-letterbmnemonic even matches the filename inside%include "b.asm"TRYin a literal does count safety (micro-repro isolated: comment-only file 0, string-only file 1)Amplification: a branch keyword inside a literal creates phantom branch context that triggers the state-flux ×3 weighting on unrelated real code — micro-repro: an ada file with two real
:=and the literal"while"records state_mutation 6; with"plain words"it records 2. The flux weighting itself looks deliberate (1:=inside a realif→ 3, confirmed); the literal-triggered version is a pure FP multiplier.docs(language-status): cobol §10 rosetta consistency capstone (#2567 …
docs(language-status): python §11 rosetta consistency capstone (#2593 …
docs(core): document + pin the x3 cascading-flux weighting (#2546) (#…
squid-protocol commentedon Sep 1, 2026
Investigated 2026-09-01 — closing as not-a-bug (root cause identified)
Traced this to ground with direct scans (not just re-reading regexes). Summary: there is no
string-literal shielding mechanism in the engine at all — strings are never stripped or
masked from the code stream for any structural signal, in any language checked (only comments
are). What looked like "selective shielding by signal family" is the ordinary Silencer
Region dampener (
spatial_correlation.py'sapply_dampener_correlations, Block 2:high_risk_execution ← safety, 500-char radius, same-scope) — the same mechanism documentedin #2546's proximity-correlation table — firing because the corpus's single shared decoy
sentence ("if eval fails, try open") happens to contain both a real danger keyword and a real
safety keyword for some languages, purely by accident of which language's own rule
vocabulary the English words land on.
Evidence (isolated micro-repros,
galaxyscope --db-only, direct DB queries)state_dangereval+trytryis a safety keyword)try→useswapevalonlyevalpanic!/todo!/unimplemented!/process::exit/abort, noevalconceptTRY+ALTERALTER)END-IF/END-PERFORM/.../VALIDATE/CHECK, notTRYTRUNCATE+TRYTRYis an abap safety keyword)Deleting
tryfrom the python/js/rust decoy and re-scanning flipshigh_risk_executionfrom0 to 1 immediately, with nothing else changed — conclusively isolates the cause.
What this means
The "four shielding profiles" the corpus ledger described are a corpus-authoring artifact: one
English sentence translated per language without checking whether it accidentally collides
with that language's own safety/danger rule vocabulary, not an engine design inconsistency.
The engine's actual behavior is already uniform and correct: strings count like ordinary code
text for every signal, always; the Silencer Region dampener does its job (a danger call
guarded by a nearby real error-handler is legitimately lower risk) regardless of whether the
danger/safety tokens happen to sit inside a string literal or in real code — which is the
right behavior, not a bug. The same explanation applies to #2546's "phantom branch trigger
from string literals" — that's the ×3 flux dampener correctly finding a branch keyword that's
genuinely present as text, because (as this issue also establishes) nothing shields it.
No engine change is warranted. Follow-up is scoped to the corpus: redesigning the decoy
sentences to stop conflating "is a literal correctly uncounted" with "does an incidental
nearby safety keyword dampen an unrelated danger keyword" — tracked in a new keyword-rosetta
issue, and the
string-literal-selective-shieldingledger entry + the capstones that cite it(jcl.md, cobol.md, python.md §10/§11) are being corrected to match this finding.
Closing. Re-open if a genuine case surfaces that this explanation doesn't cover.
docs(language-status): correct #2535 references in cobol/python capst…
docs(contracts): contract roadmap, signal contract sheet + baseline-g…