1 Introduction↩︎

Large language model agents have moved from answering questions to acquiring and executing skills: reusable bundles of prompt instructions, executable code, and tool or API declarations that an agent loads at runtime to extend what it can do [1], [2]. Skills now arrive from many places at once: public marketplaces, internal hubs, partner registries, the Model Context Protocol ecosystem [3], and increasingly from other agents that author skills automatically. As the supply grows, platform and governance teams face an identity problem before they face anything else: they cannot deduplicate, search, version, attribute, or audit a corpus of skills they cannot reliably tell apart.

The natural tool for “are these the same?” is a hash, but no existing hashing primitive answers the question that skill identity actually poses. A skill-identity signature must be simultaneously (a) rewrite-invariant, so that a paraphrased prompt, a renamed function, a refactor, or a swapped tool still maps to the same skill; (b) constant-size and \(O(1)\)-comparable, so a registry can index millions of skills; (c) component-localizing, so that “same code, different purpose” is distinguishable from “same purpose, different code”; and (d) calibrated, so the score means something despite the compression that any bit-signature introduces. Cryptographic hashing fails (a), (c), and (d) by design. Its avalanche property guarantees that one edit decorrelates the output, so it cannot measure similarity at all. Byte-level fuzzy hashes such as ssdeep and TLSH [4], [5] target (a) but rely on spatial byte locality that skills do not have; on rewritten skills they score AUC \(0.53\)–\(0.63\), near chance. Raw embedding cosine is accurate but stores kilobyte-scale floating-point vectors and offers neither a constant-size signature, a bit index, nor calibration, failing (b) and (d). Plain SimHash [6] provides a compact bit signature but was designed for single-document web deduplication [7]: it has no component decomposition and no notion of a calibrated, registry-anchored verdict, failing (c) and (d). No prior method satisfies all four properties together.

In this work we present a per-component, locality-sensitive fingerprint for agent skills that meets the four-property conjunction. We keep the philosophy of a fuzzy hash (a compact, opaque signature compared pairwise) but replace its engine. We decompose each skill into components (prompt, code, tools), embed each component with a learned encoder that acts as a convergent transformation mapping diverse surface forms to nearby vectors [8], [9], and project each embedding to bits with a multi-bank SimHash. The result is a fixed \(120\)-byte signature whose three components are compared independently by Hamming distance and, deliberately, are never collapsed into a single score until the application asks for one. Our thesis is that this decomposition is the contribution: a single similarity number tells you whether two skills are related, but the per-component triple tells you how, and “how” is what deduplication, family clustering, novelty detection, and provenance all need. In one sentence: a per-component embed-then-SimHash fingerprint provides a \(120\)-byte skill-family identity that survives common rewrites and localizes which component carries the reuse, turning similarity into a registry primitive. We claim lineage, not behavioral equivalence. That identity is the complement of behavioral integrity, not a substitute: it tells you a skill is a tampered copy of a known one and where it was changed, not whether the copy is safe. The two axes compose, and we show where the identity axis ends.

We make five findings.

1. A 120-byte signature reproduces a 24,576-bit embedding’s ranking to within \(1\%\) AUC. The fingerprint reaches AUC \(0.974\) overall over \(4{,}950\) pairwise comparisons and, per modality, tracks the embedding cosine to within \(1\%\) (\(0.992\) versus \(0.993\)) at \(77\times\) compression, with the gap predicted by SimHash variance (Section 4).

2. The per-component triple separates reuse from tampering. Code is the strongest identity signal (AUC \(0.997\)) and tools the cleanest (\(1.000\)), while prompt is weakest (\(0.959\)); the spread is what makes relationship classification possible (Section 6).

3. Relationship classification is automatic and precise. The triple yields six relationship types directly; \(62\%\) of same-group pairs are called clones at a \(0.2\%\) cross-group false-clone rate (Section 6).

4. Identity survives adversarial rewriting and stays consistent on real skills. The fingerprint recovers \(45/50\) adversarial rewrites, including cross-language translation, where a lexical baseline recovers \(5/50\); on a \(1{,}000\)-skill community corpus its per-component ranking stays consistent across the \(13\) available positive pairs while mainly exposing that name-based duplicate labels are noisy. We read this as a small out-of-distribution consistency check, not a broad generalization claim (Section 5).

5. Structural identity composes with behavioral integrity. On a \(906\)-skill injection benchmark the fingerprint flags injected skills as tampered copies of a known base and localizes the change, while, by design, identity is not a safety verdict (\(83.7\%\) of malicious skills are near-clones of a benign one; Section 8).

Together these show that a compact, principled fingerprint can give agent skills a durable identity, and that its per-component form is what turns identity into a working registry. We describe the method next.

2 Method↩︎

This section defines the fingerprint in three steps: decomposing a skill into its components, embedding and projecting each component to bits independently, and comparing two fingerprints component by component. The design choice the rest of the paper rests on is to keep the components separate rather than hash a skill as one blob, so that identity can be attributed to the part of the skill that actually carries it; Figure 1 summarizes the pipeline end to end.

2.1 Skills and their components↩︎

We treat a skill as a small structured artifact \(S = \{c_1, \dots, c_m\}\), where each \(c_j\) is a textual component drawn from a fixed vocabulary: the natural-language prompt or instructions, the code that implements the skill, the tool or API declarations it uses, and optionally config and examples. Components are the unit of both fingerprinting and comparison. A skill need not populate every component; absent components are simply omitted from its signature and from any comparison that would involve them.

2.2 The convergent transformation: embedding↩︎

For binaries, similar function implies similar bytes, so a fuzzy hash can operate on the raw bytes. Skills violate this: two prompts that mean the same thing (“Summarize this” and “Write a brief overview”) share no byte patterns, and serializing code to compare it destroys the spatial locality that source code has. We therefore require a convergent transformation \(f\) with the property that functional equivalence of components implies geometric proximity of \(f\)’s outputs. A learned text encoder is exactly such an \(f\). We embed each component with a general-purpose encoder \(E(\cdot) \to \mathbb{R}^{d}\) (here \(d=768\)), which maps paraphrases, renamings, and refactorings of the same component to nearby vectors [8]–[10]. The embedding model is the single most important choice in the system; everything downstream inherits its quality. In our implementation \(E\) is Google’s text-embedding-005, a \(768\)-dimensional encoder served through Vertex AI. We chose it because it embeds both natural-language and code components well (the cosine ceiling the fingerprint approximates is AUC \(0.99{+}\) on prompts and on code; Section 4), and because a hosted, general-purpose encoder lets a registry ride the embedding-quality curve as models improve rather than maintaining a bespoke one. The method is otherwise encoder-agnostic: any sentence or code encoder, such as Sentence-BERT [8], E5 [10], or a code-specialized model like CodeBERT [9], can replace \(E\), and the fingerprint inherits its quality (Appendix 15 ablates four encoders). Because the codes from two encoders are not comparable, an embedding-version tag travels with every signature so cross-encoder comparisons are never made by accident.

2.3 Multi-bank SimHash↩︎

Storing one \(768\)-dimensional float vector per component is accurate but defeats the purpose of a compact, indexable signature. We compress each embedding to bits with SimHash [6]. Given a component embedding \(v \in \mathbb{R}^d\) and a random hyperplane with Gaussian normal \(r \sim \mathcal{N}(0, I_d)\), a single SimHash bit records which side of the hyperplane the embedding lies on: \[b(v; r) = \mathbb{1}\!\left[\, v \cdot r \ge 0 \,\right]. \label{eq:simhash-bit}\tag{1}\] One bit captures the angle between two embeddings. A random hyperplane (Equation 1 ) assigns \(u\) and \(v\) different bits exactly when its normal falls in the angular wedge between them; because \(r\) is isotropic, this happens with probability \(\theta/\pi\), where \(\theta=\arccos(\cos(u,v))\) is the angle between the vectors. A single bit is thus a coin whose bias is the angle, so the fraction of agreeing bits across many independent hyperplanes is an unbiased estimate of \(1-\theta/\pi\), a monotone function of cosine similarity that we make precise in Section 3.

We draw \(B = 320\) independent hyperplanes per component and pack the resulting bits into five \(64\)-bit words, the “banks” that name the method. The banks are a machine-word layout, not five separate estimators: all \(320\) bits are independent and identically distributed, so the estimator’s accuracy is governed by the total bit count \(B\) (Section 3), while the five-word packing makes each comparison five pairs of bitwise exclusive-or and population-count instructions on aligned words. Moving from a single \(64\)-bit word to five lowers the estimator’s standard deviation by \(\sqrt{5}\) for the ordinary reason that it uses five times as many bits, not because the grouping adds information. The projection matrix is seeded deterministically per component name, so the same component always hashes the same way and codes from different components are never accidentally compared.

2.4 The fingerprint↩︎

The fingerprint of a skill is the concatenation of its per-component codes. With the three primary components (prompt, code, tools) at \(320\) bits each, a skill’s signature is \(960\) bits, or \(120\) bytes, fixed, regardless of skill size; including all five components gives \(200\) bytes. Crucially we retain the codes as a triple (one code per component) and do not concatenate them into an undifferentiated blob, because the application layer (Section 6) needs to read the components separately.

2.5 Comparison↩︎

Two skills are compared component by component. For a component present in both skills, with \(320\)-bit codes \(F_A\) and \(F_B\), the similarity is one minus the normalized Hamming distance between them, \[\mathrm{sim}(F_A, F_B) \;=\; 1 - \frac{\mathrm{popcount}(F_A \oplus F_B)}{B}, \label{eq:hamming-sim}\tag{2}\] where \(\oplus\) is the bitwise exclusive-or and \(B=320\). This yields a per-component similarity triple. Applications then reduce the triple as needed: a maximum over components for recall (“does any part match a known skill?”), a minimum for strict clone detection (“do all parts match?”), or a weighted mean for generic search, with default weights favoring code as the component closest to behavior. We also report coverage (the Jaccard overlap of present components) and asymmetry (the spread between the most and least similar components), the latter being the signal that drives relationship classification. Because Equation 2 is a few word-level exclusive-or and population-count operations per component, a full comparison costs under a microsecond, and a registry can compare a query against a million skills in well under a second (Section 7).

Having defined the fingerprint, we next quantify how faithfully its bits preserve the cosine geometry they are derived from, and how many bits that fidelity requires.

3 Why the bits preserve identity↩︎

The fingerprint is useful only if compressing a \(768\)-dimensional embedding to \(320\) bits preserves the ordering of similar and dissimilar skills. This section shows it does, and quantifies the cost: the expected SimHash similarity is a monotone function of cosine that preserves rankings exactly in expectation; the function is concave, which compresses the score scale predictably; and the estimator’s variance falls as \(1/\sqrt{B}\), which fixes how many bits we need.

3.1 Embedding and SimHash share one metric↩︎

The pairing of embeddings with SimHash is not arbitrary; the two share a metric. A learned encoder places functionally equivalent components at small angles, and embeddings are conventionally compared by cosine, an angular similarity. SimHash is the locality-sensitive hash family whose collision probability is itself a function of that angle (Equation 3 below). Quantizing an embedding with SimHash therefore samples exactly the geometry the embedding already defines: the bits are a Monte-Carlo estimate of the cosine the encoder was trained to expose, not a proxy for some unrelated distance. This pairing is what makes the fingerprint feasible at all: Charikar’s random-hyperplane rounding [6] does two things at once. It compresses a \(768\)-dimensional real vector to a few hundred sign bits, and, because each bit is an unbiased sample of the pairwise angle, it preserves the cosine ranking those bits estimate. We therefore discard bits, not the metric. The rest of this section makes both halves precise: that the ranking is preserved exactly in expectation (monotonicity, next), and that the compression needs only a few hundred bits (variance and concentration).

3.2 Monotonicity and rank preservation↩︎

For a random hyperplane with normal \(r\), the probability that two vectors fall on opposite sides is proportional to the angle between them [6]: \[\Pr\!\big[\, b(u; r) \neq b(v; r) \,\big] \;=\; \frac{\arccos\!\big(\cos(u,v)\big)}{\pi}. \label{eq:charikar}\tag{3}\] The expected per-bit agreement, and hence the expected similarity of Equation 2 , is therefore \[\mathbb{E}\big[\mathrm{sim}\big] \;=\; 1 - \frac{\arccos(c)}{\pi}, \qquad c = \cos(u,v). \label{eq:expected-sim}\tag{4}\] Equation 4 is strictly increasing in \(c\), so it is a bijection from \([-1,1]\) onto \([0,1]\) that preserves order. Because the area under the ROC curve depends only on the ranking of scores, the SimHash AUC must converge to the cosine AUC as the number of bits grows: in the limit the bit estimator recovers the cosine ordering it is sampling from.

3.3 The negative floor and gap compression↩︎

Two effects set the score scale, and we separate them because they are easily conflated. First, nominally unrelated skill components are not orthogonal in the embedding space: text and code share vocabulary and structure, and learned encoders are anisotropic [11], so unrelated pairs carry a positive background cosine (a mean of \(0.54\) in our corpus). This positive baseline, not the hash, is what lifts the negative floor: a cosine of \(0.54\) maps through Equation 4 to a SimHash similarity of \(\approx 0.68\), whereas truly orthogonal vectors (\(c=0\)) would sit at \(0.5\). Second, the transfer function is concave, which compresses the positive/negative gap on top of that floor: the gap shrinks from \(0.236\) in cosine space to \(0.109\) in \(320\)-bit SimHash space (about \(54\%\); Equation 4 differentiated at the cosine means predicts \(\approx 57\%\)). The net effect is a useful discrimination range of roughly \([0.65, 1.0]\) rather than \([0,1]\). Neither effect is a defect, but together they make raw scores uninterpretable as percentages, which is why the system calibrates against the empirical negative distribution before exposing a score (Section 7).

3.4 Variance and the bit budget↩︎

Each SimHash bit is an independent Bernoulli trial with \(p = \arccos(c)/\pi\), so the similarity estimator over \(B\) bits has variance \[\mathrm{Var}\big[\mathrm{sim}\big] \;=\; \frac{p(1-p)}{B}, \label{eq:variance}\tag{5}\] and its standard deviation falls as \(1/\sqrt{B}\). At \(B=320\) bits the per-comparison noise is \(\sigma \approx 0.023\) (Equation 5 ), accurate to about two decimal places after a single comparison, and the predicted AUC (\(0.98\)) matches the observed \(0.992\). Five banks of \(64\) bits is the knee of this trade-off: it drives the noise low enough to recover the cosine ranking while keeping the signature small and word-aligned. Figure 2 shows both effects together: the concave transfer function that compresses the gap (left) and the AUC-versus-noise trade-off across bit budgets (right). The estimator also concentrates, not merely averages; a Hoeffding bound makes the per-comparison fidelity a high-probability guarantee, and a bit-budget table traces the \(\sigma\)/AUC trade-off across \(B\) (Appendix 12).

3.5 A few hundred bits preserve the ranking↩︎

A \(768\)-dimensional float embedding occupies \(768 \times 32 = 24{,}576\) bits; the \(320\)-bit multi-bank SimHash is \(77\times\) smaller. The variance bound of Equation 5 is what establishes that so few bits suffice to recover the ranking; the Johnson–Lindenstrauss lemma [12] is independently consistent with this: random projections preserve pairwise distances within \((1\pm\varepsilon)\) using \(O(\log n / \varepsilon^2)\) dimensions, a few hundred at our evaluation scale. We do not claim \(320\) bits is optimal, only that a few hundred random sign bits comfortably preserve the ranking the registry needs, which is why the \(77\times\) compression costs under \(1\%\) of AUC.

With the fidelity of the bits established, we now measure the fingerprint end-to-end.

4 The fingerprint recovers identity↩︎

A \(120\)-byte signature reproduces the ranking of a \(24{,}576\)-bit embedding to within \(1\%\) AUC. We evaluated the fingerprint on a corpus designed to stress every lineage-preserving rewrite and reuse axis, and found that it recovered skill-family identity at AUC \(0.974\) overall. This paper reports several AUCs, each measured on a different corpus and aggregation, so Table 1 lists them side by side as a key. The two most easily confused are the headline \(0.974\) (registry identity on the constructed corpus) and the “within \(1\%\) of cosine” figure (\(0.992\) versus \(0.993\)), which is the single-component rewrite micro-benchmark of Table 2. The empirical content of the identity claim is not this constructed number, which a lexical baseline matches (Section 5.2); it is that the same fingerprint survives adversarial rewriting that erases surface text (Section 5.1) and that its per-component ranking is stable on a small out-of-distribution community check (Section 5.3).

4.1 Corpus and protocol↩︎

We construct \(100\) skills spanning \(40\) domains, organized as \(20\) groups of \(5\) designed variants each. Within a group the variants are an original and four controlled rewrites: a clone (prompt rewritten, code and tools unchanged), a repurposed skill (same code, different-domain prompt), a reimplemented skill (same prompt, different code), and a toolswap (same prompt and code, tools removed). Variants in the same group are lineage positives; variants in different groups are negatives. This yields \(4{,}950\) pairwise comparisons (\(200\) positive and \(4{,}750\) negative) and a ground truth that isolates each rewrite axis. We report AUC because it depends only on score ranking, matching the guarantee of Section 3. Because the variants are generated along the same invariance axes the embedding is built to absorb, these results should be read as a controlled upper bound on real-world separation; robustness and out-of-distribution behavior are tested in Section 5.

4.2 End-to-end accuracy↩︎

The fingerprint attained an overall AUC of \(0.974\) (95% CI \([0.956, 0.994]\) by a skill-level bootstrap that resamples the \(100\) skills, which accounts for the shared-skill dependence among the \(4{,}950\) pairs); the positive-pair mean was \(0.876\) and the negative-pair mean \(0.623\) (gap \(0.254\)). The separation was clean enough that a single global threshold near \(0.80\) already gave high precision (Figure 3). It achieved this at \(120\) bytes per skill and a comparison cost of a few word-level exclusive-or and population-count operations per component (the Hamming similarity, Equation 2 ), the constant-size, constant-time-per-pair property the registry requires.

4.3 Structure of the similarity matrix↩︎

The \(100\times100\) similarity matrix, ordered by group, showed the structure the ground truth predicts (Figure 4): clean \(5\times5\) blocks along the diagonal where each group’s variants cluster, no spurious high-similarity blocks off the diagonal, and faint cross-group bands only where domains are genuinely related (for example, several infrastructure-orchestration skills). The single highest cross-group similarity (\(0.834\)) was between a cloud-provisioning skill and a workflow scheduler, which is not a failure but a true semantic and operational overlap that the name-based ground truth does not encode.

4.4 The embedding supplies invariance, the hash compression↩︎

The embedding, not the hash, supplies the rewrite-invariance; the hash supplies the compression for free. Table 2 places the fingerprint against the alternatives on a micro-benchmark of aggressive single-component rewrites (a prompt fully paraphrased, code renamed and refactored). Byte-level approaches failed: raw context-triggered piecewise hashing scored AUC \(0.53\)–\(0.61\), and even AST-normalized hashing reached only \(0.63\), recovering exact (Type-2) clones but collapsing on refactors (Type-3). An LLM that rewrites each component into a constrained vocabulary before hashing did better (\(0.89\)) but added latency and model noise. Embedding cosine was the ceiling (\(0.99+\)); the multi-bank SimHash matched it (\(0.992\)–\(0.996\)) at \(77\times\) less storage.

4.4.0.1 Supporting analyses.

Three analyses that back these results are deferred to the appendix. The \(320\)-bit code reproduces the full-precision embedding cosine to within \(0.004\) AUC per component (Appendix 13). SimHash is not the most accurate way to compress the embedding, but it is the only basis-free, codebook-free, Hamming-indexable representation, the right trade for a portable registry (Appendix 14). And the fingerprint is encoder-agnostic: a newer, wider encoder buys \({\approx}\,0.04\) AUC at \(4\times\) the embedding size while the signature stays \(40\) bytes and lookup stays \(O(1)\) (Appendix 15).

The constructed corpus is, by design, easy. We now stress the fingerprint where identity is hardest to preserve: adversarial rewrites that erase surface text, and real community skills the method never saw.

5 Robustness and generalization↩︎

The fingerprint survives rewrites that erase surface text, and we stress it on real skills the method never saw. The decisive tests are an adversarial benchmark of ten transforms up to cross-language translation, and a \(1{,}000\)-skill community corpus with noisy labels.

5.1 Adversarial robustness↩︎

We built an adversarial benchmark of \(50\) positive pairs from five source skills, each transformed by ten rewrite operators: prompt paraphrase, restyling, and obfuscation; code renaming, refactoring, and minification; cross-language translation to JavaScript, TypeScript, and Go; and a full rewrite of both components (LLM-generated, one component targeted per transform). These are the worst case for a surface signature, since a translated or obfuscated component shares almost no character \(n\)-grams with its original.

The fingerprint survived every transform, and the per-component triple shows why: an attack on one component left the others at \(1.0\). Prompt attacks dropped the prompt similarity to \(0.74\)–\(0.88\) while code stayed at \(1.000\); code attacks dropped code while the prompt stayed at \(1.000\); cross-language translation was the hardest single case (code similarity \({\approx}\,0.82\), consistent with the cross-language limitation of Section 9). A lexical TF-IDF baseline collapsed on exactly these transforms (Figure 5): on the targeted component it fell to \(0.14\) for paraphrase, \(0.20\) for obfuscation, \(0.38\) for minification, and \({\approx}\,0.44\) for cross-language translation, against the fingerprint’s \(0.74\)–\(0.98\).

The operating-threshold view makes the gap concrete and corrects a metric trap. Ranking AUC was near \(1.0\) for both methods, but only because the negatives are cross-source skills with almost no surface overlap (TF-IDF negative mean \(0.07\)); AUC rewards a method for separating easy negatives even as its positive scores collapse. At the \(0.85\) threshold the registry uses, the fingerprint recovered \(45/50\) adversarial rewrites at zero false positives, while TF-IDF recovered \(5/50\) (Table 3). This is the evidence the constructed corpus could not provide: where surface text is preserved a lexical signature suffices, but under adversarial rewriting only the embedding recovers identity, and the per-component fingerprint localizes the change. The benchmark is small (50 pairs from five source skills, with few negatives), so we report it as a stress test of transform-invariance rather than a powered detection study.

5.1.0.1 Cross-language, precisely.

Cross-language rewriting is the boundary case. Controlled translation is recovered because the unchanged prompt carries it (overall \({\approx}\,0.90\), above \(0.85\)) even as the translated code degrades to \({\approx}\,0.82\); an independently authored reimplementation in another language shares no component and is not recovered, a stated limitation (Section 9). Appendix 16 gives the per-scenario numbers.

5.2 What the constructed corpus does and does not show↩︎

The adversarial result also recontextualizes the headline corpus. There, a character-\(n\)-gram TF-IDF cosine matches the fingerprint (\(1\)-nearest-neighbor purity \(0.99\) and AUC \(0.999\), against \(0.96\) and \(0.974\); Table 4). The reason is built into the construction: every designed variant keeps at least one component byte-identical and the negatives are cross-domain, so shared surface vocabulary alone separates positives from negatives. The constructed corpus therefore validates the fingerprint’s compression fidelity (Section 3) and per-component structure (Section 6); it is not evidence of superiority over lexical matching. That evidence is the adversarial benchmark above, where the same lexical baseline recovers \(5/50\) rewrites to the fingerprint’s \(45/50\), and the OpenClaw corpus below, where the fingerprint separates true clones from same-name reimplementations that share little surface text.

The fingerprint’s standing advantage over a lexical vector is twofold. First, it is a constant-size \(120\)-byte signature compared in \(O(1)\) by Hamming distance, whereas the TF-IDF vector averages about \(8.4\) kB per skill (a \(31{,}887\)-dimensional sparse vector) and is not bit-comparable, a \(70\times\) size gap that decides feasibility at registry scale. Second, lexical overlap is exactly what disappears under same-meaning rewriting and in independently authored skills. The honest summary is partial superiority: a lexical baseline matches the fingerprint on lexically easy data; the fingerprint wins on compactness everywhere and on accuracy wherever surface text is not preserved.

5.3 Out-of-distribution: a community corpus↩︎

The harder test is real skills with noisy labels. We applied the fingerprint to OpenClaw [13], a public registry of \(45{,}266\) community-contributed agent skills, sampling \(1{,}000\) (\(611\) with code, \(389\) prompt-only). Ground truth here is weak by construction: \(12\) name-based duplicate groups plus \(3\) content-hash groups give only \(13\) positive pairs against \(5{,}000\) sampled negatives, and “same name” does not imply “same skill” when skills are authored independently.

The per-component fingerprints stayed consistent across this noisy community check: prompt AUC \(0.992\), code \(0.999\), tools \(0.998\) (Figure 6), each within a point of its constructed-corpus value (with only \(13\) positive pairs this is a consistency check, not a generalization claim). The overall AUC, however, fell to \(0.739\). The drop is a property of the labels, not the fingerprint. The positive pairs are bimodal: true clones cluster at \(0.85\)–\(1.00\) (two are exact, at \(1.000\)), while six “duplicates” that merely share a name fall at \(0.27\)–\(0.53\), so a label set that calls all \(13\) pairs positive is itself roughly half wrong. In the clearest case two independently written prompt-optimizer skills score \(0.265\): one does iterative refinement, the other single-pass style transfer, and they cannot substitute for each other. With only \(13\) positive pairs every AUC here is a small-sample estimate, but the per-component robustness and the bimodal positive distribution together indicate that the fingerprint tracks implementation, and that on community data it is often more precise than the name-based ground truth it is scored against. An LLM-judge spot check agrees in direction: on the weak-positive (same-name) pairs both judges side with the shared name (\(0/5\) agreement with our low scores), the same concept-versus-implementation split the code component is built to capture (Appendix 17).

Across the constructed, adversarial, and community corpora the overall number averages over markedly different components. The next section opens up the triple: reading the spread across components is what classifies how skills are related and organizes a registry.

6 Per-component signal classifies how skills are related↩︎

Code is the strongest identity signal (AUC \(0.997\) versus \(0.959\) for prompt), and the per-component triple is what turns that into usable structure. This section shows the three components carry distinct, separable signal, that the pattern of high and low similarities across them classifies how two skills are related, and that the same per-component distances organize a registry of families and novelty.

6.1 Components carry distinct signal↩︎

Table 5 reports AUC per component on the corpus of Section 4.1. Code is the strongest discriminator (AUC \(0.997\)), tools the cleanest (AUC \(1.000\)), and prompt the weakest yet still strong (AUC \(0.959\)); Figure 7 visualizes the spread. The ordering is the empirical content of the design principle that code is the most behavior-proximal component: the implementation discriminates skills more sharply than the natural-language intent wrapped around it, because intent paraphrases freely while implementation does not. The spread across components is not noise to be averaged away; it is the signal the next subsection reads. The components are also non-redundant: among related (same-group) pairs the per-component similarities are uncorrelated to mildly anticorrelated (prompt versus code \(r=-0.40\)), and across the diverse SkillsBench corpus [14] prompt and code similarity are nearly independent (\(r=0.08\) over \(26{,}565\) pairs). The triple is not three views of one number, which is why repurposing (high code, low prompt) and reimplementation (high prompt, low code) separate at all. An independent LLM-judge cross-check is consistent with this: agreement with the fingerprint rises with judge capability, which a purely lexical signal would not predict (Appendix 17).

6.2 The triple classifies relationships directly↩︎

Because the components are kept separate, the relationship between two skills is read directly off the pattern of high and low per-component similarities, with no extra model. A high-prompt, high-code pair is a clone; high-prompt, low-code is a reimplementation; low-prompt, high-code is a repurposing (the same code aimed at a new domain); a tool-only drop is a tool swap; moderate-across is a variant; low-across is unrelated. These high and low cutoffs are fixed a priori from the SimHash floor of Section 3, not tuned on this corpus, so the classification rates below are not the product of in-sample threshold search. A verdict combines three signals so that absent components do not silently distort it: per-component similarity where both components are present, the presence (coverage) delta between the two skills, and the asymmetry across present components. A tool swap, for example, is read from the change in tools presence together with the drop in tools similarity, not from a low tools score alone, which matters because tools are populated for only a minority of skills (Section 9). A concrete case from the corpus: a CSV analyzer and a health-metrics skill share code similarity \(1.000\) but prompt similarity \(0.772\), which the triple reports as repurposed (the same implementation serving a different purpose), a distinction a scalar score cannot make.

These classifications were accurate. Among the \(200\) same-group pairs, \(62\%\) (\(124/200\)) were correctly called clones and a further \(24\%\) (\(48/200\)) tool-swaps; among the \(4{,}750\) cross-group pairs, only \(0.2\%\) (\(\approx\!10/4{,}750\)) were falsely flagged as clones (Table 6). The asymmetry between \(62\%\) recall and a \(0.2\%\) false-clone rate is exactly what a deduplication or impersonation workflow needs: it surfaces genuine reuse while almost never crying wolf across unrelated skills.

6.2.0.1 False merges on legitimately-overlapping real skills.

That \(0.2\%\) is measured on a constructed corpus whose negatives are cross-domain. The production cost of a clone detector, though, is flagging genuinely different but overlapping real skills: shared utilities, common templates, the same domain. We measure it on the \(502\) benign skills of the BIV benchmark (Section 8), which are real and independently authored, over the \(125{,}678\) pairs with distinct skill names. At the operating threshold the false-clone rate is \(0.01\%\) (\(11/125{,}678\); \(0.10\%\) at the looser \(0.80\)). The handful of flagged pairs are not spurious; they are genuine reuse families: a builder and its base (“mcp-builder” and “mcp”, \(0.92\)), a workflow variant and its tool (“git-advanced-workflows” and “git”, \(0.91\)), and a cluster of diagram and dashboard “creator” skills built on one scaffold. The per-component triple attributes each flag to the component the two skills actually share, so the false-merge rate on real overlapping skills is effectively zero and the residual flags are correct relatedness that the triple explains rather than errors it hides.

6.3 The same distances scale to families and novelty↩︎

The same per-component distances scale from pairwise relationships to corpus-level structure. Running density-based clustering [15], [16] on the per-component Hamming distances groups skills into families (sets of skills that implement the same capability) without specifying the number of clusters in advance and with built-in handling of singletons. Each family exposes a canonical member (the skill nearest the family centroid), which is the concrete answer to “you have twelve PDF parsers; which one should everyone use?” A skill that matches no family, either as a clustering singleton or by exceeding the \(95\)th-percentile intra-family distance, is flagged novel and routed to human review rather than discarded. Families, canonical members, and novelty are all reductions of the same triple, which is why a single fingerprint suffices for deduplication, search, and triage at once.

This corpus-level structure is recovered cleanly on the \(20\)-group ground truth. The nearest neighbor of a skill was a true same-group variant for \(96\%\) (\(96/100\)) of skills, and of each skill’s four genuine variants \(88.8\%\) appeared in its top four neighbors. Connected-component clustering of the overall fingerprint at a threshold of \(0.80\) produced \(23\) families at \(90\%\) cluster purity against the \(20\) designed groups, the over-segmentation being the expected price of a conservative threshold.

Novelty is detected rather than mis-merged. Withholding a family from the registry and querying its members (leave-family-out), their best cross-family match falls to a mean of \(0.760\), down from a same-family support of \(0.932\); at the \(0.85\) operating threshold all \(100\) held-out skills are flagged novel rather than attached to a nearby family (\(0\) mis-merges, separability AUC \(0.973\) between family-present and family-absent), and at the looser \(0.80\) threshold \(17\) would mis-attach to a genuinely similar neighbor. Novelty is therefore a reliable signal at the calibrated threshold, not just a system sketch.

Having shown what the decomposition buys analytically, we turn it into a system.

7 The fingerprint becomes a registry↩︎

A signature that is small, fast, and component-attributable is already most of a system of record for agent skills. This section builds that system on the fingerprint, with per-component indexing, calibration, a CycloneDX skill bill of materials, and an optional triage gateway, and reports its operating costs.

7.1 Indexing and lookup↩︎

Each component is indexed independently for binary nearest-neighbor search, so a query skill can ask, per component, “which known skills are closest here?” A component code is exactly the input a binary (Hamming) index consumes: the per-component store is a bit-packed array of \(40\) bytes per skill (\(320\) bits), \(40\) MB for a million skills, queried with the same exclusive-or and population-count kernel as the pairwise comparison. A flat binary index (FAISS’s binary-flat index) returns exact Hamming neighbors by SIMD popcount [17] and answers a query in \(0.15\) ms over \(1{,}000\) skills, \(2\) ms over \(10{,}000\), \(20\) ms over \(100{,}000\), and roughly \(200\) ms over \(1\) million.² Beyond that, a binary HNSW or IVF index makes the search sub-linear, and the bit-block routing of [7] for fast Hamming lookup applies to the \(320\)-bit codes unchanged. The composite index reduces the per-component results three ways: a union ranked by the best-matching component (for recall), an intersection ranked by the worst-matching component (for strict clone lookup), and per-component top-\(k\). This is the constant-size, constant-time-per-comparison property of Section 2 realized at registry scale.

7.2 Calibration↩︎

Raw SimHash similarity is not directly interpretable because of the compression floor of Section 3: unrelated skills sit near \(0.65\), not \(0.5\). The registry therefore calibrates each component’s raw similarity against an empirical distribution of negative pairs [18], mapping a raw score to a \(z\)-score and then through the standard normal CDF so that \(0.5\) denotes the random baseline, \(0.84\) roughly one standard deviation of signal, and \(0.98\) roughly two. Calibration is a per-component rescaling that makes scores comparable across components and across corpus snapshots; it does not, and is not claimed to, convert a similarity into a probability of any behavioral property. The calibration statistics are versioned alongside each corpus snapshot so that lookups are reproducible. They are fit on the evaluation corpus itself, so the calibrated thresholds should be revalidated on held-out skills before deployment.

7.3 SkillBOM: a portable bill of materials↩︎

Because the fingerprint is constant-size and component-structured, it serializes naturally into a software bill of materials. We emit a CycloneDX-shaped SkillBOM [19] in which each skill records its per-component fingerprint (tagged by component), its family and canonical sibling, its novelty score, a provenance block (source, owner, version), and a reserved slot for behavioral attestations. Each entry also carries a cryptographic content hash, signable with standard supply-chain tooling [20], so the bill of materials records both exact integrity (the hash) and lineage (the fuzzy per-component fingerprint) for every skill. The SkillBOM follows the same documentation-as-artifact lineage as model cards and datasheets [21], [22] and the supply-chain provenance frameworks for conventional software [23], extended to the agent-skill artifact. Because it is portable and hash-based, it can be shared without shipping skill source, which is what makes a cross-organization registry tractable.

7.4 An optional triage gateway↩︎

When a policy decision is wanted rather than a lookup, the same components feed a gateway that fingerprints an incoming skill (with caching), searches the registry, and resolves a verdict against curated families: a strong, calibrated match to a trusted family routes to allow; a strong match to a flagged family routes to block; mixed or novel signals route to review with the per-component evidence attached. We deliberately frame the gateway as a router, not an oracle: its value is that a skill whose code matches a flagged family but whose prompt looks benign is sent to review with evidence, rather than silently allowed or silently blocked. The verdict is one application of the registry, not its purpose.

The registry recognizes skills and flags tampered copies of known ones. The harder question is whether recognizing a skill tells you it is safe. We test that boundary next.

8 Recognition is not trust: identity and integrity compose↩︎

An injected malicious skill is, structurally, the benign skill it was injected into. This makes the agent-skill threat setting the cleanest possible test of what a structural fingerprint can and cannot do: it should recognize the injected skill as a tampered copy of a known base, and it should not, on its own, decide whether the skill is safe. Recognition is not trust. We test both on the \(906\)-skill benchmark of the behavioral integrity verification (BIV) work [24]: \(502\) benign and \(404\) malicious skills drawn from in-the-wild malicious skills [25] and two injection generators [26], [27], in the indirect-prompt-injection tradition [28], [29], that splice malicious capabilities into a clean base. We fingerprint all \(906\).

8.1 The fingerprint recognizes injection as tampering, and localizes it↩︎

The fingerprint saw an injected skill as a near-clone of a benign one. Across the \(404\) malicious skills, the nearest benign skill had mean fingerprint similarity \(0.924\), and \(83.7\%\) were near-clones (similarity \(\ge 0.85\)) of some benign skill, against a \(0.789\) benign-to-benign baseline. The injection does not hide the lineage; it rides on top of it. The per-component triple then localized the tampering. Pairing each skillject injection with its clean base, the natural-language prompt stayed at \(0.992\) and the tools at \({\approx}\,1.0\), while the code component dropped to \(0.92\)–\(0.95\) across all four attack types (Figure 8). The change lives in the code, exactly where a description-only or metadata-only check cannot see it, and the fingerprint points to it without any attack-specific tuning. For provenance this is the useful signal: “this skill is a modified copy of trusted base \(X\), and the modification is in the code.”

8.2 Identity is not a safety verdict↩︎

The same fact that makes the fingerprint a good provenance signal makes it a poor safety detector: if \(83.7\%\) of malicious skills are structural near-clones of benign skills, structural similarity cannot separate malicious from benign. We make this precise. Used as a detector (flagging a skill when its fingerprint matches a known-malicious skill of a different base, leave-base-out), structural similarity reached only F1 \(0.735\) at a \(32\%\) false-positive rate (Table 7). It beat a rule-based scanner (\(0.44\)) by recognizing repeated injection payloads as a family, but fell well short of behavioral verification, which reaches F1 \(0.946\) on the same benchmark [24]. This is not a deficiency of the fingerprint; it is the boundary of the identity axis. The fingerprint answers “is this a copy of a skill we know?”; it does not answer “does this skill do what it claims?”

8.3 The two axes compose↩︎

The axes are orthogonal and complementary (Table 8). The dominant malicious case, \(338\) of \(404\) skills, is a tampered known skill: a near-clone of a benign skill (so the identity axis says “known, trusted-looking”) that nevertheless carries an injected capability (so the behavioral axis says “malicious”). Neither axis catches this alone: a structural registry waves it through as a known skill, and a behavioral check that ignores lineage cannot tell a first-party update from an adversarial fork. Together they do: the fingerprint flags a high-similarity match to a trusted base and localizes the change, while the behavioral check adjudicates the injected capability. This is the two-axis model of Section 9, now measured: structural identity (this work) and behavioral integrity [24] are the two halves of skill trust.

Having shown where the identity axis ends, we state the method’s boundaries precisely.

9 Scope and limitations↩︎

The fingerprint’s limitations define where it applies, and several are findings in their own right.

9.0.0.1 It measures artifacts, not behavior.

The fingerprint compares what a skill is (its prompt, code, and tools), not what it does at runtime. Two skills with the same code can behave differently in different contexts, and a skill can be tampered with in ways that preserve its artifact. This is not a gap to paper over but the second axis of a two-axis model: structural identity (this work) is orthogonal and complementary to behavioral integrity [24] (probing a skill and comparing its observed behavior to its declared contract). Section 8 measures the orthogonality directly: on a \(906\)-skill injection benchmark \(83.7\%\) of malicious skills are structural near-clones of a benign skill, so structural identity used as a safety detector reaches only F1 \(0.735\) against behavioral verification’s \(0.946\). The structural fingerprint says “I recognize this skill, and here is the part that changed”; a behavioral check says “it does what it claims”; the tampered known skill needs both.

9.0.0.2 Locality-sensitive, not collision-resistant.

The fingerprint is a similarity primitive, not an authenticity one. An adversary who knows the encoder and the projection planes can move a component’s embedding to evade a match, or shape a skill to mimic a trusted family and appear benign, and the fingerprint makes no integrity guarantee about the artifact it summarizes. It is therefore a registry, triage, and lineage signal, to be paired with cryptographic content hashes and signatures for exact integrity and with behavioral verification for safety, not a replacement for either.

9.0.0.3 The useful score range is narrow.

As Section 3 explains, the positive background cosine of unrelated components (a property of the embedding, not the hash), compressed by the concave SimHash transfer, floors unrelated skills near \(0.65\), so the discriminative range is roughly \([0.65, 1.0]\) rather than \([0,1]\). Calibration against the empirical negative distribution absorbs this, but raw scores must not be read as percentages of similarity.

9.0.0.4 Identity is bounded by the embedding.

The fingerprint inherits the embedding model’s blind spots. Most concretely, the same algorithm implemented in two languages embeds differently, so cross-language equivalence is not recovered today; a code-specialized multilingual encoder [30] is the natural remedy and would lift this limit without changing the method.

9.0.0.5 Component coverage.

Skills do not populate every component. In the constructed corpus the tools field is present for only \(28\%\) of skills, and in the OpenClaw corpus \(39\%\) of skills are prompt-only (code present for \(61\%\)). The fingerprint scores over the components present in both skills, and the OpenClaw per-component AUCs of Section 5.3 were measured on this mixed-coverage corpus, so the method degrades gracefully when a component is absent. One number must be read with this in mind: a per-component AUC is only as broad as that component’s coverage, so the tools AUC of \(1.000\) rests on the minority of skills that declare tools.

9.0.0.6 Evaluation scale and labels.

Our constructed results are on \(100\) skills and \(4{,}950\) pairs, and we add a \(1{,}000\)-skill out-of-distribution check on community data (Section 5.3). The Johnson–Lindenstrauss argument of Section 3 predicts the ranking quality persists at larger corpora, but two gaps remain. First, the community corpus supplies only \(13\) positive pairs, so its overall AUC is a small-sample estimate and the per-group analysis, not the single number, carries the signal. Second, we report one false-merge check on legitimately-overlapping benign skills (Section 6) but still owe broader validation across larger, independently curated registries and at \(10{,}000\) skills and beyond. We make no \(100\%\)-style claim without the denominator that would back it.

These boundaries are sharp on purpose: each says exactly when the fingerprint is the right tool and when a second signal is required.

10 Related work↩︎

10.0.0.1 Locality-sensitive hashing and near-duplicate detection.

Our fingerprint is built on SimHash [6], the signed-random-projection member of the locality-sensitive hashing family [31]–[33]; MinHash [34] is the set-resemblance counterpart. SimHash was popularized for web-scale near-duplicate detection with a bit-block index for fast Hamming search [7], the same ideas we use to index components. The Johnson–Lindenstrauss lemma [12] underpins why so few projected bits preserve rankings. We contribute the per-component decomposition and registry that plain SimHash lacks.

10.0.0.2 Fuzzy hashing for binaries.

Context-triggered piecewise hashing (ssdeep) [4] and TLSH [5] are the byte-level fuzzy hashes that inspired our problem framing. They exploit spatial byte locality, which skills lack; we keep their philosophy (a compact, opaque, pairwise-compared signature) and replace the engine with an embedding so that semantic lineage and implementation-level similarity, rather than byte locality, are preserved.

10.0.0.3 Embeddings and code representation.

The convergent transformation at the core of the method is a learned text encoder [8], [10], evaluated broadly by embedding benchmarks [35]. For the code component we rely on the demonstrated ability of code-aware encoders to capture program semantics [9], [36], [37].

10.0.0.4 Code clone detection.

The rewrite axes we test mirror the Type-1 through Type-4 clone taxonomy [38]: renaming (Type-2) and refactoring (Type-3) are exactly where token- and tree-based detectors [39], [40] trade recall for precision. Our embedding-based fingerprint recovers Type-3 clones that byte- and token-level methods miss, which is the empirical basis for treating code as the strongest identity signal.

10.0.0.5 Agents, tools, and skills.

Agents that reason and act with external tools [1], [2] and that select among large tool libraries [41], [42] are the setting that makes skill identity necessary; surveys and benchmarks [43], [44] document the explosion in skill supply. The Model Context Protocol [3] and agent skill formats [45] are the artifacts our fingerprint spans across frameworks.

10.0.0.6 Agent attacks and behavioral evaluation.

The threat our two-axis framing addresses is studied as indirect prompt injection through external content and tool outputs [28] and as malicious tool use in tool-integrated agents [29]; behavioral risk is evaluated in LM-emulated sandboxes [46] and dynamic attack-and-defense environments [47]. These target runtime behavior; the fingerprint is the complementary structural-identity axis (Section 8).

10.0.0.7 Provenance and bills of materials.

The SkillBOM extends software bill-of-materials standards [19] and the documentation-as-artifact lineage of model cards and datasheets [21], [22], situated within the broader supply-chain provenance effort [23], to the agent-skill artifact.

10.0.0.8 Evaluation with LLM judges.

Our cross-check follows LLM-as-judge methodology [48] while accounting for its documented biases [49]; the novel observation is that judge–fingerprint agreement increases with judge strength.

10.0.0.9 Indexing and clustering.

At scale the registry draws on vector-search systems [17], [50] for nearest-neighbor lookup and on density-based clustering [15], [16] for family detection, both applied here over per-component Hamming distances.

11 Conclusion↩︎

Agent skills need an identity that survives the way they are actually copied (paraphrased, renamed, refactored, and re-tooled), and cryptographic hashing provides the opposite. We showed that embedding each component of a skill and projecting it to bits with a multi-bank SimHash yields a fixed \(120\)-byte fingerprint that recovers skill-family identity at AUC \(0.974\) over \(4{,}950\) pairs, within \(1\%\) of the embedding cosine it approximates at \(77\times\) less storage, with ranking preserved in expectation and finite-bit concentration from Charikar’s random-hyperplane rounding. The contribution, though, is not the compression: it is that keeping the fingerprint as a per-component triple, rather than collapsing it to a scalar, localizes which part of a skill carries its identity. That single design choice turns one similarity number into the relationship classification, family clustering, novelty detection, and portable SkillBOM that make up a skill registry. Identity is one axis of trust, not the whole of it: the fingerprint recognizes a tampered copy of a known skill but cannot, on its own, decide whether it is safe, so recognition is not trust and structural identity composes with behavioral verification rather than replacing it. As agents increasingly write skills for other agents, identity at the family level, not byte equality at the file level, is the primitive a governable agent ecosystem will be built on, and a compact per-component fingerprint is a practical way to supply it.

11.0.0.1 Broader applicability.

Nothing in the recipe is specific to skills. Decomposing an artifact into components, embedding each with a transformation that maps “different surface, same meaning” to nearby vectors, projecting to a constant-size per-component bit signature, and reducing it into families, novelty, and a bill of materials is artifact-agnostic; the reusable core is the convergent transformation, the encoder whose geometry already encodes the equivalence one cares about and that SimHash inherits for free. The same shape plausibly fits other LLM-era artifacts whose identity survives surface change: models, whose fingerprints could be built from probe responses or weight summaries [51], [52], and the de-duplication of machine-generated findings across re-scans. Each would need its own convergent transformation and its own validation, which we leave to future work. Because the signatures are hash-only, they are shareable without exposing source, weights, or code, which opens the door to a federated, privacy-preserving identity index across organizations. Cryptographic hashing answers whether an artifact changed; a locality-preserving per-component fingerprint answers whether it is the same artifact, and that question recurs wherever LLM-era artifacts are rewritten, reused, and re-shared.

Reproducibility and availability↩︎

The quantities needed to reproduce our results are specified in the text: corpus construction and sizes (Section 4.1), the \(5\times64\) bit budget and the deterministic per-component projection seeding (Section 2), the calibration procedure and operating thresholds (Section 7), and skill-level bootstrap procedures for every confidence interval. The embedding and judge models are public, third-party services accessed through their APIs; the OpenClaw community corpus is public; and the injection benchmark is from prior behavioral-integrity work [24].

Ethics and broader impact↩︎

This work targets the governance of agent skills: deduplication, provenance, and lineage tracking for a rapidly growing supply of reusable agent components. Its intended impact is defensive, helping platforms recognize, attribute, and audit skills and flag tampered copies of trusted ones. Two considerations bound its use. First, the fingerprint is an identity signal, not a safety verdict (Section 8): used alone it can wave through a tampered-but-familiar skill, so it must be paired with behavioral verification. Second, it is locality-sensitive, not collision-resistant (Section 9): an adversary who knows the encoder and projection planes can perturb a component to evade a match or shape a skill to mimic a trusted family, so we position the fingerprint as a triage and lineage signal to be combined with cryptographic integrity and behavioral checks, not a standalone gatekeeper. Our evaluation uses only public models and public or synthetically constructed skills, and involves no human subjects or personal data.

Acknowledgements↩︎

We thank Hui Gao and Badar Ahmed for their support.

12 Bit budget and concentration↩︎

The bit-budget claims of Section 3 follow from the SimHash estimator’s variance (Equation 5 ). Beyond the \(1/\sqrt{B}\) standard deviation, the estimator concentrates, not merely averages: as a mean of \(B\) independent values in \([0,1]\), a Hoeffding bound gives \[\Pr\!\big[\, \lvert \mathrm{sim} - \mathbb{E}[\mathrm{sim}] \rvert > t \,\big] \;\le\; 2\,e^{-2 B t^{2}}, \label{eq:hoeffding}\tag{6}\] so at \(B=320\) a deviation larger than \(0.1\) has probability below \(2e^{-6.4}\approx 0.003\). The fidelity is therefore a high-probability guarantee on each comparison, not just a low-variance tendency in aggregate. Table 9 traces the consequence across bit budgets: five banks of \(64\) bits (\(B=320\)) is the knee of the curve and the operating point used throughout.

13 Quantization fidelity against the embedding cosine↩︎

The comparison the fingerprint is built for is against the full-precision embedding cosine it approximates. Re-embedding the corpus and clustering on the raw \(768\)-dimensional cosine versus the \(320\)-bit fingerprint computed from the same vectors, the fingerprint reproduces cosine to within \(0.004\) AUC on every component (prompt \(0.971\) versus \(0.975\), code \(0.991\) versus \(0.994\), tools \(1.000\) for both) and to within \(0.03\) overall (\(0.931\) versus \(0.959\)), at \(77\times\) less storage (Table 10). The \(320\)-bit signature loses bits, not the metric: the quantization that buys the \(77\times\) compression and the \(O(1)\) Hamming comparison costs almost nothing in clustering quality. This controlled re-embedding is consistent with the primary fingerprint matrix (pairwise correlation \(0.956\)).

14 Alternative compressions of the embedding↩︎

The fingerprint is not the most accurate way to compress the embedding, and it should not claim to be. Table 11 compares it on the same corpus against float16, int8, a \(64\)-dimensional PCA, and an \(8\times16\) product quantizer [53]. On accuracy alone a corpus-fit PCA matches or beats every other representation (its in-sample AUC is an optimistic upper bound), and even a \(4\)-byte product quantizer edges the fingerprint. The fingerprint’s advantage is operational, not accuracy: it is the only representation here that is simultaneously a constant-size, self-contained bit string searched by exclusive-or and population-count, with no shared basis or codebook that every consumer must distribute and keep synchronized as the registry grows, and with per-component bit attribution. float16 and int8 are basis-free but \(19\)–\(38\times\) larger and not bit-indexable; PCA and product quantization are small but require a shared, corpus-fit transform. For a portable, append-only, cross-organization registry the basis-free bit string is the right trade, at a cost of \(\le 0.03\) AUC against full cosine.

15 Encoder ablation and ingestion cost↩︎

Because the encoder is the most important choice in the system (Section 2), we vary it. Open encoders such as E5 and CodeBERT were unavailable in our environment, so we ablate across four Vertex encoders of different generations and dimensions, with identical preprocessing (Table 12). The encoder matters: overall AUC ranges from \(0.934\) for a multilingual encoder (weakest on code) to \(0.976\) for gemini-embedding-001, which is newer and \(4\times\) wider, a \(0.04\) spread that a better encoder simply buys (per-component AUCs follow the same ordering).

That accuracy is not free at ingestion. gemini-embedding-001 is \(4\times\) wider (\(12.3\) versus \(3.0\) kB per component) and \({\approx}\,30\%\) slower per call (\(228\) versus \(\sim170\) ms), and as a larger model it also carries a higher per-call price; we report latency as the compute proxy and do not quote prices. Crucially, this cost is paid once, at ingestion: the fingerprint is \(40\) bytes per component and the lookup is \(O(1)\) Hamming regardless of the encoder, so a registry’s storage and query cost do not change with the encoder, only its embedding bill does. And the fingerprint is encoder-agnostic: its overall AUC tracks each encoder’s cosine to within \({\approx}\,0.03\), so a stronger encoder yields a stronger fingerprint (gemini-embedding-001 lifts it to \(0.935\) from \(0.926\)) without changing the hash, the signature size, or the index. The ablation stays within one vendor family; an open-encoder comparison is left to an environment that can host them.

16 Cross-language, by scenario↩︎

We claim robustness to cross-language rewriting and also list cross-language equivalence as a limitation (Section 9); these are not in conflict, and Table 13 makes the boundary exact. Under controlled translation the prompt is unchanged, so overall identity is recovered (overall \({\approx}\,0.90\), above the \(0.85\) threshold) even though the translated code component degrades to \({\approx}\,0.82\): the prompt carries it while the code signal weakens. What is not recovered is an independently authored reimplementation in another language, which shares neither the prompt nor the code surface; we list that as a limitation rather than a measured result, as we lack a labeled independent-multilingual corpus.

17 Agreement with an LLM judge↩︎

As a sanity check, not core evidence, we compare the fingerprint against a competent reader. We sampled \(20\) pairs from the SkillsBench benchmark [14] across four cells (true positive, true negative, and the two hard cells: same-name/different-implementation and different-name/similar-implementation) and elicited an independent similarity judgment from two judges of different strength, Gemini 2.5 Flash and Pro, following standard LLM-as-judge practice [48] and noting its biases [49]. Agreement with the fingerprint rose with judge strength, from \(70\%\) (\(14/20\)) for Flash to \(85\%\) (\(17/20\)) for Pro (Figure 9), and the gain was entirely in the same-name/different-implementation cell, where the stronger judge flipped from \(0/5\) to \(4/5\) agreement. We read the direction as suggestive: one would not expect a stronger reasoner to agree more if the signal were purely lexical, which is consistent with the code component capturing implementation-level differences. At \(20\) pairs with overlapping Wilson intervals (Pro \([0.64, 0.95]\), Flash \([0.48, 0.85]\)), and with both judges sharing a vendor family with the embedding, this is a sanity check rather than a powered or independent result, and we do not count it among the paper’s findings.

References↩︎

---

1. All three authors contributed equally; the author order was determined by a game of rock-paper-scissors.↩︎

2. Our prototype computes the Hamming kernel in numpy: the binary-flat path in the FAISS version we used returned wrong distances at code widths \(\ge 256\), so we ran an equivalent exact scan. This changes neither the asymptotics nor the results.↩︎