Summary
There is a stated principle for handling near-duplicate attack instances (merge into an existing record's mutation_count/example_patterns rather than mint a new ID, per AVE_V1.1.0_MIGRATION_BRIEF.md's record-count discipline), but no explicit, checkable policy for where that line actually sits. This issue exists to design that policy properly rather than continue operating on the principle alone.
Credit
Raised by endor_sarah (Reddit), disclosed as working for Endor Labs, in a comment on the r/cybersecurity launch post. Not solicited; identified independently while reading through the actual schema and record set.
The problem, as raised
Reported count: 17 of 59 records are prompt injection variants. Independently verified against the live corpus while triaging this issue: attack_class across records/*.json has exactly 17 values with the Prompt Injection - prefix out of 59 total records, and every attack_class value in the corpus is currently unique (no exact-string duplicates). The 17/59 count is confirmed.
The real question underneath the count: what makes two attack instances the same behavioral class, warranting one record with the second folded into mutation_count, versus genuinely distinct classes warranting separate records? Without an explicit answer, a registry with real external contribution risks minting a new ID every time someone publishes a write-up of what's behaviorally the same attack, worded differently.
Why this is a real, hard problem, not a formality
CWE has spent years on exactly this: its base/variant/class/category hierarchy exists specifically because "is this the same weakness or a different one" doesn't have an obvious answer at scale, and getting it wrong either fragments a taxonomy into thousands of near-duplicate IDs or collapses genuinely distinct classes into an unhelpfully broad bucket.
AVE is small enough today that this hasn't bitten yet; it will, the moment external contribution volume increases, which the recent cfgaudit PR (#67) suggests is already starting to happen.
Proposed first pass, scoped deliberately small
Before building anything resembling CWE's full parent/child hierarchy (a real, larger schema change, explicitly not proposed here), write an explicit, short decision procedure and add it to AVE_V1.1.0_MIGRATION_BRIEF.md's record-count discipline section or a
new docs/specs/abstraction-policy.md. A candidate starting rule, proposed for discussion, not asserted as final:
- Same
provenance_vector.entry_class AND same payload_surface AND same escalation AND the only difference is the literal attacker text: mutation of the existing record, add to mutation_count and example_patterns.
- Different
entry_class, or different escalation, or a materially different payload_surface: new record.
- Genuinely ambiguous cases: human judgment call at review time, same as today, but the criteria above should resolve most cases without one.
This reuses fields the schema already has (provenance_vector) rather than requiring new schema. If this simple rule proves insufficient as the corpus grows, a CWE-style hierarchy becomes the next real option; not proposed now, noted so it isn't forgotten.
Status
Not scheduled. This issue exists to make the gap visible and properly credited, and to hold the proposed first-pass rule for discussion, not to commit to a timeline or a final answer.
Summary
There is a stated principle for handling near-duplicate attack instances (merge into an existing record's
mutation_count/example_patternsrather than mint a new ID, perAVE_V1.1.0_MIGRATION_BRIEF.md's record-count discipline), but no explicit, checkable policy for where that line actually sits. This issue exists to design that policy properly rather than continue operating on the principle alone.Credit
Raised by endor_sarah (Reddit), disclosed as working for Endor Labs, in a comment on the r/cybersecurity launch post. Not solicited; identified independently while reading through the actual schema and record set.
The problem, as raised
Reported count: 17 of 59 records are prompt injection variants. Independently verified against the live corpus while triaging this issue:
attack_classacrossrecords/*.jsonhas exactly 17 values with thePrompt Injection -prefix out of 59 total records, and everyattack_classvalue in the corpus is currently unique (no exact-string duplicates). The 17/59 count is confirmed.The real question underneath the count: what makes two attack instances the same behavioral class, warranting one record with the second folded into
mutation_count, versus genuinely distinct classes warranting separate records? Without an explicit answer, a registry with real external contribution risks minting a new ID every time someone publishes a write-up of what's behaviorally the same attack, worded differently.Why this is a real, hard problem, not a formality
CWE has spent years on exactly this: its base/variant/class/category hierarchy exists specifically because "is this the same weakness or a different one" doesn't have an obvious answer at scale, and getting it wrong either fragments a taxonomy into thousands of near-duplicate IDs or collapses genuinely distinct classes into an unhelpfully broad bucket.
AVE is small enough today that this hasn't bitten yet; it will, the moment external contribution volume increases, which the recent cfgaudit PR (#67) suggests is already starting to happen.
Proposed first pass, scoped deliberately small
Before building anything resembling CWE's full parent/child hierarchy (a real, larger schema change, explicitly not proposed here), write an explicit, short decision procedure and add it to
AVE_V1.1.0_MIGRATION_BRIEF.md's record-count discipline section or anew
docs/specs/abstraction-policy.md. A candidate starting rule, proposed for discussion, not asserted as final:provenance_vector.entry_classAND samepayload_surfaceAND sameescalationAND the only difference is the literal attacker text: mutation of the existing record, add tomutation_countandexample_patterns.entry_class, or differentescalation, or a materially differentpayload_surface: new record.This reuses fields the schema already has (
provenance_vector) rather than requiring new schema. If this simple rule proves insufficient as the corpus grows, a CWE-style hierarchy becomes the next real option; not proposed now, noted so it isn't forgotten.Status
Not scheduled. This issue exists to make the gap visible and properly credited, and to hold the proposed first-pass rule for discussion, not to commit to a timeline or a final answer.