ApolloRaines commited on
Commit
edff01d
·
verified ·
1 Parent(s): ac35eb3

Withdraw the directional provenance claim: bit-identity is symmetric

Browse files
Files changed (1) hide show
  1. README.md +28 -16
README.md CHANGED
@@ -30,26 +30,38 @@ model-index:
30
 
31
  # Sharona Q27B-R CodeSecurity
32
 
33
- > **Provenance correction -- measured, and the version numbers run backwards.**
34
- > This card previously declared no base model at all, so there was nothing for
35
- > a reader to diff against. Probing normalisation and bias survivors across
36
- > 355 shared tensors:
 
 
37
  >
38
- > | candidate | result |
39
- > |:----------|:-------|
40
- > | `Qwen/Qwen3.5-27B` | NOT the immediate parent -- 0/14 bit-identical, cos max 0.9983 |
41
- > | `ApolloRaines/Sharona_Q27B-R_CodeSecurity_v2` | BASE CONFIRMED -- 3/14 bit-identical |
 
 
 
42
  >
43
- > This artifact is derived FROM v2, so the name "v1" does not indicate the
44
- > earlier model. Qwen3.5-27B is a relative or ancestor rather than the parent.
 
 
 
45
  >
46
- > Margin, stated because it is thin: 3 of 14 survivors is exactly the minimum
47
- > our probe accepts. It clears the threshold by nothing, so read this as
48
- > "not a direct child of Qwen3.5-27B" -- which is firm -- rather than as v2
49
- > being settled against every other candidate, which it is not.
50
  >
51
- > Bit-identity on survivors also says NOTHING about method. Restricted
52
- > gradient training with frozen norms leaves this same signature.
 
 
 
 
53
 
54
  A [jBlaze](https://jblaze.dev) representation-engineered code security specialist. 27B parameters, GPTQ W4A16 quantized for efficient deployment.
55
 
 
30
 
31
  # Sharona Q27B-R CodeSecurity
32
 
33
+ > **Provenance note -- author-reported, and NOT independently checkable.**
34
+ > `base_model` on this card names `ApolloRaines/Sharona_Q27B-R_CodeSecurity_v2`.
35
+ > That is Apollo's own record of how the artifact was built, and it is the
36
+ > best provenance available for this repo -- but unlike every other
37
+ > `base_model` field on this account, a reader cannot verify it, and this
38
+ > card previously claimed it was measured. It was not.
39
  >
40
+ > **What was claimed and is withdrawn.** An earlier version of this note said
41
+ > "this artifact is derived FROM v2, so the name v1 does not indicate the
42
+ > earlier model", citing 3 of 14 survivor tensors bit-identical to v2 against
43
+ > 0 of 14 to `Qwen/Qwen3.5-27B`. Bit-identity is SYMMETRIC: sharing identical
44
+ > tensors with v2 is equally true in either direction of derivation. The
45
+ > measurement established shared ancestry and no order, and the directional
46
+ > sentence does not follow from it.
47
  >
48
+ > **Why no measurement can settle it.** This artifact is GPTQ 4-bit, so its
49
+ > 2-D weights are packed integers and cannot be compared to float weights at
50
+ > all. Only the 305 one-dimensional float tensors shared with v2 and Qwen are
51
+ > comparable, and those are precisely the tensors the edit does not touch --
52
+ > layernorms, `A_log`, `dt_bias`. Measured:
53
  >
54
+ > | quantity | v1 | v2 |
55
+ > |:---------|---:|---:|
56
+ > | mean cosine to `Qwen/Qwen3.5-27B` | 0.997623 | 0.997690 |
57
+ > | identical to the other on sampled survivors | 5 of 8 | 5 of 8 |
58
  >
59
+ > v2 is marginally closer to Qwen, in the fourth decimal, which is noise and
60
+ > not a direction. Both sit at 0.9976 because neither modified these tensors.
61
+ >
62
+ > So: the derivation order is undetermined and undeterminable from published
63
+ > weights. The `base_model` field stands as the author's record. Treat it as
64
+ > that rather than as a diff you can run.
65
 
66
  A [jBlaze](https://jblaze.dev) representation-engineered code security specialist. 27B parameters, GPTQ W4A16 quantized for efficient deployment.
67