README.md opened the egress gap with "It is not an id question at all -- the two
runtimes carry different tables, cut at different granularities", and sent the
reader to scope_planned.blockers as the authority. Since 4356caa that blocker
opens reason (1) with "NO ID SPACE ON THE COMMONS SIDE. This is the hard
blocker." Before 0.7.2 the README was out of date; after it, two files on a
public remote disagreed, and it was our commit that made them.
The paragraph now carries the three measured, independent reasons from
docs/secret-egress-divergence.md. The counts survived the falsification, so
"different tables" and 19-against-25 are kept; only "cut at different
granularities" and the pending-reconciliation claim are gone. It deliberately
omits the outgoing question's status (true on the day written, untested by
anything, and dated in the manifest) and the standing entry_points_by_scope
requirement (a requirement, not a fourth reason).
conformance/manifest.json 0.5.1 -> 0.5.2 in the same release: the blocker
misquoted the contract it cites, rendering the value without the backticks the
field carries around `order`. The data file is unchanged and was never wrong.
Round-trip proved byte-neutrality before the edit; the read-back matched the
decoded string against the data file that owns it, since json.tool passes on
wrong escaping.
No case minted, no data file touched, no id proposed.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SZ5vrpu2kxcRktiW59b7s3
Two loose ends from v0.7.0.
The README sent a reader to case_id_derivation.variant_suffix in the manifest
for the rule about variant cases. That was correct until v0.7.0 made the rule
normative in spec section 6 and left the manifest block as the MEASUREMENT
behind it. Left alone it reproduces in one line the defect v0.7.0 closed: a
reader sent to the wrong authority. Both are named now, each for what it is.
And the release that made a point of re-measuring '--' rather than copying the
manifest's 0.3.0 numbers forward had inherited the adjacent '__' claim
untested. Measured now across all five published id spaces - 83 lexicon ids, 7
active: ids, 3 carrier: ids, 7 malware rule ids, 19 secret-egress entry names -
neither '__' nor '--' occurs in any of them. The one-to-one transform holds, so
no text changed; the sentence was true and is now measured.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01M4xrxV3EXbSALqvB23kpeY
Adopting `active:raw-html-link` was one id. Publishing it honestly was the whole
of `active_tag_class` — one function, three branches, no way to state the split
without the no-URL narrowing and the 0.6.0 external-target rule. On the old
predicate a bare `</a>` is active by name, so a consumer implementing from the
hybrid would emit the new label where the seed runtime emits nothing.
The file is now two pins, stated as two: v0.3.4/0bf0729 everywhere except the
raw-HTML classifier, v0.7.0/be9759b there. The drift between them was measured
field by field against the imported module rather than assumed, after stripping
inline-flag rendering and applying the file's own declared quote normalisation
so a spelling difference could not masquerade as drift. Exactly one published
field had moved, and not the one this release was about: `html.active_tags`
carried the MUTATOR's 23-name set where the gate means the SCANNER's 22. Correct
at the 0.3.4 pin, wrong from 0.6.0 on. Kept as `html.mutator_tags`.
The sweep covered 93 cases, not the 6 obvious ones. The narrowing can silence an
`active:` finding inside the `observed_out_of_scope` evidence of a LEXICON case,
and that field is guarded by no test anywhere — stale entries there survive
forever. One case moved: html-obfuscation__aria-label, whose `<a aria-label=…>`
carries no URL attribute. Its fixture is deliberately not rewritten; the residue
is true at the commit `measurement` pins, and rewriting one of 83 would leave two
commits under a header naming one. Recorded, dated and pinned in the manifest.
The strongest check is not the digest: the checker rebuilds the published
classifier from the JSON alone, importing nothing from the runtime, and
differential-tests it against `active_tag_class` over 42 probe tags. 0
disagreements. That is what licenses shipping a classifier as data.
No `aliases.llm_security` published, on this file or on carriers.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01LTTaT4quwNPwBYVqmgAt8t
Both runtimes answered the 2026-08-11 decision request, and they did not ask
for the same name. The guard ruled `sanitize:` names its `Finding.detector`
and offered all three labels for verbatim adoption. llm-security, asked
directly, answered that the name would make its conformance result read as a
claim about neutralisation it does not perform.
Two things decided it. The guard's own unprompted correction: prefix ==
detector holds for those six labels and is no general law in its runtime
(`egress:*` carries detector="output"; decode-and-rescan yields two-part
`decoded:lexicon:*`). A prefix whose meaning is recoverable only by reading
one implementation cannot carry a shared id space. And a measurement taken
here at be9759b: on the surface the guard's own ruling pinned, `sanitize()`
returns changed text on all three carriers, so the counterargument's decisive
case -- that `scan_output` mutates nothing -- does not reach this surface.
Not a mediation. Neither runtime claimed the shared id must equal its label,
and `override:ignore-previous` already carries two different alias strings.
- carriers.json 0.1.0 -> 0.2.0: carrier:zero-width / :bidi-override /
:unicode-tag, aliased to the guard's labels. No aliases.llm_security --
that runtime's carrier findings carry no id yet, and publishing the alias
is the irreversible act that forces the table into its declared set.
- manifest 0.3.4 -> 0.4.0: entry_points_by_scope, carrying findings accessor
and fixture presentation per scope per runtime. This was objection (c), and
it blocked minting harder than the name did.
- Corpus 90 -> 93. Measured through sanitize(text, source=Source.INPUT) at
guard v0.7.0; verified by a separate checker that re-derives everything from
disk -- a generator agreeing with itself proves nothing.
- CLAUDE.md gains the two rules that are not derivable from the data: a shared
id space cannot rest on a one-runtime prefix, and publishing an alias -- not
minting the case -- is the irreversible act.
Not minted on purpose: no artifact-side id (the other runtime would only fail
them), and no ZWJ-exemption case (U+200D between two emoji is exempt on both
guard surfaces since v0.6.1; the fixture avoids it rather than trips it).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01U3o4zSQ2kwLsgJNU7apK3Z
The carrier decision request went to both runtimes today. Then re-reading our own
spec turned up an error in it: the request said the corpus has no verdict for a
case a runtime cannot reach. It has one, and this repository wrote it — §1.1
`not-applicable`, attaching to a declared table. A correction went to both.
What the correction found is sharper than the mistake. llm-security declares the
lexicon table alone (`DECLARED_TABLES`, measured at 47905da), so carrier cases
are not-applicable there today. Their suite derives the registered set by walking
each vendored file for any node carrying `aliases.llm_security`, then asserts
every registered table is declared — the §1.1 anti-narrowing floor. Granularity
is the file. So one aliased carrier id would force `codepoints/carriers.json`
into their declared set, oblige them to run all six carrier cases, and convert
the three artifact-side ones into failures. Publishing the alias is the
irreversible act, not minting the case.
manifest.json 0.3.3 -> 0.3.4; README's carrier paragraph carried the same
superseded "labels differ by pipeline stage" claim and now carries the measured
one. No case, no id and no expected.json moved.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01F1HPHHP1zDNk1tMKDPuLCC
CONVENTIONS.md consolidates rules that already applied but were readable only to
the maintainer: the charter (CLAUDE.md), versioning and vendoring (README.md),
the reporting route (SECURITY.md), and file conventions visible only in the shape
of the files.
Two things stop being inferences. Why pull requests are off: this repository is
vendored into runtimes that pin a tag, so a data change changes what they find,
and that must be coordinated before it exists. And when a value may change: the
three recorded mechanisms - re-extraction, retraction, owner-directed authoring -
each tied to its source_fidelity key, with merit named as not among them.
The four offline checks are included and were each proven to go red on a planted
violation, not merely green on a clean tree. They are one-liners because a script
would be .sh and check 4 would fail on it.
No data file changed; a runtime passing 0.4.1 passes 0.4.2 unchanged.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01KDRVXSFhKpFTzdoyjpjL17
No data file changed and no pattern moved. A published figure was wrong.
llm-ingestion-pipeline-security flagged it (coord, 2026-08-11T19:51:55Z) by
measuring the hybrid-xss:iframe-src row themselves instead of citing ours, and
got roughly 4x our number. They attributed the gap to measurement surface -
their composed scan_lexicon() against our standalone regex - and said no
re-measure was needed.
Re-measured anyway, because the claim was about OUR number. Their diagnosis does
not hold: our standalone 100 000-char figure is 7.86 s against their composed
8.95 s, so the two surfaces differ by far less than the error did. Standalone,
Python 3.14.0, same unit the document claims:
iframe-src [^>]* 822.7 ms @ 32k 51 477.4 ms @ 256k
published 119.6 ms @ 32k 16 857 ms @ 256k
script-tag [^>]* 87.4 ms @ 32k 5 222.6 ms @ 256k
published 21 ms @ 32k 5 440 ms @ 256k
So the Python script-tag figure at 256k reproduces and the one at 32k does not,
and the iframe-src pair reproduces at neither point. Error ratios are not
constant, so a single mis-sized input does not explain it, and the original
harness lived in a previous session's scratchpad and is gone. Recorded as NOT
DIAGNOSABLE rather than given a plausible cause - a guessed cause would read
like a finding.
Superseded figures are struck in place rather than overwritten. Anyone who cited
the old number needs to be able to discover that they did.
The 0.4.0 decision does not depend on this. Every corrected figure is larger, the
shape is unchanged (quadratic, x4 per doubling), and both [^><]* forms stay flat.
The 0.4.0 CHANGELOG section still quotes the old figure and is left alone: that
section is the record of what was released, not a live claim.
Verified: JSON well-formed, specs normative, charter clean, README vendoring
examples and prose moved to v0.4.1.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01JLEZ4XCSnSrQUFA8SzkQB4
One table re-extracted from a pinned upstream commit, the way every value here
has moved until now. Two lexicon rows authored here at the source owner's
direction, which has never happened before and needed a reason that is not "we
measured it and we were right."
Consumers: byte-identity against v0.3.0 goes red by construction - pattern text
changed. Ids, labels, aliases, family membership, case ids and every count are
unchanged.
README version sync: vendoring examples move to v0.4.0 (both subtree and
fork-and-own), the secret-egress table count 18 -> 19, and the divergence-doc row
stops claiming no data file was changed because of it. Two were - and the row now
says why that did not come from the document.
Verified: JSON well-formed, every JSON has top-level version, every spec still
normative, charter clean.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01JLEZ4XCSnSrQUFA8SzkQB4
org-ops recorded SECURITY.md as missing against the org standard (coord,
2026-08-11) and this repository owed it for a sharper reason than "given what
the repo is about": nothing here runs, so a report is never a crash — it is a
detection entry that looks like it works and is not looking.
SECURITY.md therefore answers what an ordinary policy does not have to: how to
report that a detection-table entry is WRONG, and why a confirmed defect in
extracted data is decided in the runtime it was extracted from before it is
changed here. Correcting it here would make the copy disagree with the
implementation it was taken from — two runtimes, two answers on one input, the
exact failure this repository exists to prevent. Two classes skip that routing:
a real secret in the history, and data authored here rather than extracted.
Fix latency is stated plainly as bounded by the owning runtime's schedule and
the consumer's pull, not by ours.
secret-egress 0.1.0 -> 0.2.0 is a staleness DISCLOSURE, not a data change: all
18 patterns byte-identical, one evidence_limits entry added. llm-security
reports the source table at 19 entries now; recorded as their report and not
reproduced, because the commit carrying it is not on their public remote —
measured at b1ba1fb today. What was measured here: none of the 18 patterns
matches a legacy sk-...T3BlbkFJ... shape. A consumer vendoring this file
under-matches the seed hook by one entry, and now reads that in the file.
manifest 0.3.0 -> 0.3.1 corrects the secret-egress blocker. Through 0.3.0 it
named gcp-service-account-json and openai-api-key-legacy together as ids
"absent here". Measured against the guard at e671edb by running this file's own
18 patterns over a service-account document: a COMPLETE service-account key
file is matched here at order 11, since the PEM entry's prefix group is
optional and the bare PKCS#8 header matches; the same document with private_key
removed matches nothing here while the guard's marker still fires. That is a
cut-point difference, which is what the blocker is about, not a missing entry.
openai-api-key-legacy IS a real hole and is now recorded as one. Folded into
the existing blocker string rather than a sibling key, because blockers is a
map from table path to text.
Verified: all JSON well-formed; every non-fixture JSON has a top-level version;
charter clean (no executable code); patterns[] and count byte-identical to HEAD
for secret-egress; manifest key set unchanged and count still 90; 90 case
directories untouched; every spec still carries its normative marker.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01T85QqeiWBEoBMjWaMiBnxD
v0.2.0 changed what a runtime must DECLARE. This one changes what a conforming
runtime FINDS. A consumer that vendors 0.3.0 and re-runs its suite will see a
finding on inputs that produced none under 0.2.0. In 0.x that is a minor bump by
the rules; the CHANGELOG says so at the top rather than leaving it to be found in
a diff.
The lexicon 0.6.0 entry that sat under [Unreleased] is folded into this release —
committed but never tagged, and 0.7.0 supersedes its central claim (that commons
does not follow the upstream change).
Version sync: README's subtree-add and clone examples move v0.2.0 -> v0.3.0, the
two "as of v0.2.0" markers move with them, the corpus row goes 89 -> 90 cases and
83 -> 84 lexicon cases, and the scope breakdown now says 84 cases over 83 patterns
rather than implying one case per pattern. schema/conformance-declaration.schema.json
gains its own row; the corpus-spec row now mentions the declared table set, since
§1.1 is the reason a reader would go looking.
Verification run before tagging: all JSON well-formed; every non-conformance JSON
carries a top-level version; every spec carries Status: normative; charter guard
clean (no executable code); manifest count == cases[] length == directories on disk
== 90, no duplicate ids; every case's recorded bytes and sha256 recomputed from
disk, zero mismatches, no trailing newlines; measured count_by_scope equals the
manifest's; declaration schema valid draft 2020-12 with its example validating.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01HuudQLGMyMenuyeZk8fKs5
A runtime that conformed to v0.1.0 does not conform to this one until it declares the
set of commons data files it implements (spec section 1.1). In 0.x that is a minor
bump by the rules, but it is breaking in substance, and the CHANGELOG entry says so
rather than leaving a consumer to discover it in a failing suite.
Both consumers were notified by coord before this tag existed, which is the wrong
order in one respect: they were told to expect a contract change they could not yet
vendor. README says to vendor a tag and never main, so the notice was unactionable
until now. Tagging closes that gap rather than opening a new one.
Version sync: README's subtree-add and clone examples pinned v0.1.0 and now pin
v0.2.0; the subtree-pull example is a placeholder rather than a version, since it
demonstrated "move to a newer tag" while naming the current one. The two remaining
v0.1.0 mentions are historical statements about what that release promised and stay
as they are.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CVouC9nsfrfV5jRSejxbvQ
The corpus goes 83 -> 89 and scope_covered gains signatures/active-content.json.
The blocker in STATE dissolved under measurement, the same way last session's
13-pattern one did. "An id space for carriers/active-content/secret-egress" was one
question in name only; the three tables have three unrelated problems:
- active-content needed NO id space invented. label_format ("active:{class}") and the
constructs keys were already extracted verbatim from the seed runtime, and their
concatenation IS what it emits - verified by comparing the six keys to the six class
strings at its _flag call sites. What blocked these cases was never naming; it was
spec section 1, fixed in the parent commit.
- carriers has no adoptable id space AND an entry-point dependence underneath it.
- secret-egress is not an id question at all: the two runtimes carry DIFFERENT tables.
18 entries here against the guard's 25, cut at different granularities - this file's
single `GitHub Token` is four ids there, `Private Key PEM Block` three, `Database
connection string` four - with membership diverging both ways. `aws-access-key-id`
is the one clean 1:1, which is why exactly one egress case was ever offered. That
number was a symptom, not modesty.
Both blockers are now recorded under scope_planned.blockers, measured, replacing a
blanket "no runtime has agreed to an id space" that was wrong for both.
Generated from measurement, not written. Payloads were extracted from the seed
runtime's coverage.py by AST - evaluating each _scan_case argument in that module's
own namespace rather than retyping detection data - then run through its public
output gate, the same entry point the 83 lexicon cases used. The fixtures were then
re-read from disk by a separate checker that re-computed every digest, re-scanned the
bytes and applied exact-within-scope independently of the generator: 6 cases, 0
failed checks.
Six built from seven offered. The runtime's matrix drives two payloads at
`active:markdown-image`; measured, their in-scope finding sets are identical, and the
second's only distinguishing signal (entropy:base64-blob) falls outside every table
this repository publishes. Dropped rather than given a discriminated case id, and
named under omitted_payloads so the count reads as a decision.
These six prove LESS than the 83, and the manifest says so: their payloads come from
the only runtime implementing the table, so no second implementation's agreement
could be measured. They pin one runtime's behaviour as a contract a future
implementer can be held to - less than cross-runtime agreement, more than nothing.
llm-security's absence of the table is measured at b0de0ca, not assumed: a tree-wide
search finds no implementation, and `git log -S` over --all returns zero commits,
closing the "it was there once" reading. Absent table is not absent capability -
their entropy scanner reaches markdown-image URLs by another route - and the manifest
says that too.
Provenance and measurement for the active-content half are kept in their own blocks:
a different source structure at a different commit, and one pin must not stand for
two measurements. The guard's HEAD moved twice during the work (3c56d50 -> de09711 ->
398eb74); measurement ran at de09711 and the drift is recorded, including that
active_content.py is NOT identical to the 0bf0729 the data file pins - the change
adds a scan-cap self-safety finding and touches no construct.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01CVouC9nsfrfV5jRSejxbvQ
The corpus was blocked on a decision nobody had to take. The 13 divergent
lexicon patterns were measured on witness inputs -- an attribute run padded
past 256 characters, an interior '<', an unclosed <script> -- and the corpus
payloads contain none of those shapes. Run through both runtimes' public
entry points, all 83 patterns produce identical lexicon finding sets, the 13
included. No winner picked, because the question was never reachable from
these inputs.
Measured at each runtime's entry point (scanForInjection() at b0de0ca,
scan_output(source=OUTPUT) at 0bf0729), never at a rebuilt regex table --
the layer mistake the divergence document already had to retract once.
- conformance/<case>/{input.txt,expected.json} x83, plus manifest.json
- spec/conformance-corpus.md, normative: bytes not text, id-only findings,
exact-within-scope, and observed_out_of_scope as evidence not expectation
Verified by a harness that does not share the generator's knowledge: reads
only the case directories, re-runs both runtimes, checks every field
including digests -- 83 cases, 0 failures. Severity agrees with what commons
publishes 83/83. Deleting the middle third of each input breaks 76 of 83
expectations; the 7 survivors are the shortest payloads, a weak mutation
rather than a weak fixture, and are recorded as such.
Scope is 83 and not 94 for a different reason than expected: the 11
non-lexicon convertible cases have no ratified cross-runtime finding id, and
writing them would mint a contract unilaterally in the same stroke as the
tag. Named in manifest.json under scope_planned.
Docs corrected in place rather than edited away: extraction-plan and
lexicon-port-divergence both claimed the 13 blocked the corpus.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01WhXDL82FRrQWedEmUg12Pj
The last missing data file. Seven known-bad-identity signatures over four
families - webshell, reverse_shell, cryptominer, hacktool - reproduced
verbatim from llm-security/knowledge/signatures.json at b0de0ca, key order
included. The file was generated from the parsed source rather than typed,
and provenance pins the source's byte length (2494) and SHA-256 so the
claim is checkable rather than asserted.
Note the family spellings: reverse_shell with an underscore, and
cryptominer rather than miner. The working note this file was planned from
had both wrong. They are policy keys - the engine filters on them and
interpolates them into every finding title - so a rename is a breaking
change, which is exactly why the table was read instead of recalled.
The rules were the easy half. The substance is engine_behaviour_not_data,
which draws the line between the table and the runtime around it. No rule
carries a flags field, because the engine compiles every pattern with `i`
unconditionally at signature-scanner.mjs:48 - so a consumer compiling these
case-sensitively silently under-matches all seven, and the dialect block
records that where a reader will hit it. Also engine, not data: matching
against five decode variants rather than raw bytes, the enabled-families
policy filter, per-file rule dedup, custom-rule merging, and a loader that
defaults four missing fields instead of rejecting a rule.
Two limits are stated as evidence limits rather than left implied. Seven
signatures are not malware coverage; a clean SIG result is not "no
malware", and the seed runtime's own header calls the table deliberately
tight. And three of the seven match on names - xmrig, mimikatz,
meterpreter - so a document discussing those tools matches. The seed
runtime hides that by excluding knowledge/, tests/, docs/ and
node_modules/, which is scan scoping and does not travel with the table.
Verified: 7/7 rule objects field-identical to source including key order,
no non-ASCII bytes, all seven compile in Node bare, i and iu (21/21) and in
Python re (7/7). Charter guard clean - no executable code in the repository.
README and CHANGELOG updated: the file moves out of "planned, not in
v0.1.0" and out of "not included".
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01SNMcqrfNyoLRQ7qXUFZnb9
Advisor review found six gaps the session's own checks did not cover. The one
that mattered was outward-facing: the divergence report told the guard repo
that two sub-agent bounds were undocumented. That was wrong. lexicon.py's
module docstring documents them explicitly under "Bounded token gaps", and
git log -S dates {0,12} to the original port commit f397cd9 and [^><] to the
ReDoS fix cff0437. Every divergence on the guard's side is documented and
traceable. The claim rested on two sed slices of one file; an absence claim
needs a search over the whole repository. Corrected here and by coord.
lexicon/injection-lexicon.json 0.2.0 -> 0.3.0:
- pattern_id_space.alias_evidence records the two aliases separately instead
of averaging them. llm_ingestion_guard is verified — coverage.py asserts on
that exact string, so it is demonstrably what a guard finding carries.
llm_security is not: it is the pattern table's name, the finding producer
was never supplied, and the known Node finding shape uses title, not label.
- normalisations[].affects now keys on id, with the prose names kept beside it
as affects_labels. An internal cross-reference on label was a second
identity space inside the file the id exists to unify.
Detection data unmoved again: labels, patterns, flags and the ids and aliases
added in 7b70f5b are all byte-identical in sequence; 166/166 Node compiles.
Also: the README lexicon row described thematic families the file does not
have (they are severity families; the theme is the id prefix), and the
conformance convertibility table gained its missing second condition — a case
is buildable only if the label it asserts maps to data this repository
publishes. Eleven cases fail that test (entropy, decoded, the sanitize rows,
the OKF scans), so the buildable set is ~94, not 105.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FaYqid3mejFmd9ZHsiHgp3
The guard's coverage.py turned out to be readable from a session here — the
read boundary covers llm-security only. Counting it instead of estimating
corrected two published numbers and surfaced the real conformance blocker.
Counted, not estimated: CORE_CASES holds 134 cases (128 caught, 6 gap), not
the "126 classes + 4 gaps-must-hold" the extraction plan claimed. 105 are
convertible to static input/expected; 29 assert a runtime API surface this
repository does not own, and are named as out of scope rather than faked.
Measured while counting, and the reason the corpus is still blocked: the
commons lexicon and the guard's are two ports of one source file, and they
disagree. 83/83 patterns correspond, 64 byte-identical, 6 differ only by
escaping and are proven equivalent by string identity, and 13 behave
differently — with a witness input for each and misses in both directions.
Cause is two different ReDoS mitigations of the same table: the Node side
bounds the run ({0,256}), the guard excludes the anchor character ([^><]).
Each has a recall cost the other does not.
No data file changed. Behaviour preservation is a v0.1.0 invariant, so the
divergence is reported to the owning repositories, not fixed here. The 8
hybrid severities the guard's port assigns are deliberately NOT copied in —
a second-hand port is not the producing module.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FaYqid3mejFmd9ZHsiHgp3
repo-standard's gate flagged 10 dead internal README links. Seven now
resolve because the files landed this session. The remaining three are
unlinked and marked "Planned, not in v0.1.0" rather than invented:
- signatures/malware-signatures.json — seed data not delivered
- spec/decode-pipeline.md — needs the decode implementation, which is engine
code and was not supplied. A normative spec guessed from a data dump would
be worse than an absent one: it would carry a Status: normative marker and
pass every convention check while saying nothing anyone verified.
- conformance/ — corpus form is still an open decision
The changelog claimed 0.1.0 shipped "a conformance corpus". It does not.
Rewritten to enumerate what is actually present, to state which files were
proven differentially and which one (calibration) carries verified: false,
and to name what is not included. Moved back under [Unreleased] because the
tag has not been cut.
README also now tells a reader that each data file records its own provenance
and verification strength, and which file currently says false.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FaYqid3mejFmd9ZHsiHgp3
The risk-score tier constants, verdict thresholds, risk-band cutoffs and
posture grade thresholds. Constants only — the log scaling and the if/else
chains that consume them are engine and stay in the consumer.
This file is the exception in this repository and is marked as such in its
own verification block. Every other data file here was rebuilt from its
commons JSON and diffed against an imported module. This one arrived as a
human-written PROSE SUMMARY of severity.mjs, so there was nothing to import
and nothing to diff. verified: false, with the two skipped checks named
rather than a caveat attached to a pass.
The consequence inverts this repository's central rule and the file says so:
for every other file a disagreeing consumer is wrong; for this one, until the
module arrives in executable form, a disagreement is not automatically the
consumer's bug.
What COULD be checked was: bands are contiguous and non-overlapping across
0-100, the BLOCK trigger (65) is exactly the Critical band floor, the WARNING
trigger (15) is exactly the Medium band floor, and the per-tier reachable
minima recompute exactly (80/48/20/4, exact because log2(2) is 1).
Corrects README and the extraction plan in the same commit: both promised
entropy floors, scan caps and disposition ranks. None arrived — 0 occurrences
each across the whole dump. Named in the file under not_supplied so the
absence is visible rather than inferred, and both rows now describe what is
actually present.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01FaYqid3mejFmd9ZHsiHgp3
Data+contract+fixtures repository for runtime-neutral LLM/agent security
detection. Charter is hard: no engine code, no dependencies, no runtime —
JSON data, normative specs and conformance fixtures only.
Scaffolding only; the seed data files land in follow-up commits from
verified source dumps (never from recollection).
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_0191AKc2qW6tmXDFSx1xn53q
