provenance: pin the FastLED rc1 authority to immutable content

[zackees]

Context

AUTH-0025 identifies a versioned authority, FastLED Reciprocal License 1.0-rc1, but its declared source and citation point to mutable blob/main/LICENSE. The research workflow requires exact license version and version history before applying a comparison.

A future edit to main can therefore cause an AI to attribute changed language to rc1 without changing AUTH-0025, its verification date, or PR-0002. This is a provenance defect even though FastLED is only a comparison target in the license-agnostic corpus.

Proposal

Pin AUTH-0025 to an immutable repository commit, release, or tag and record a content hash. State separately whether the local LICENSE represents the current working draft or the historical rc1 snapshot. Define a rule that every versioned project-local license authority uses immutable content and receives a new card for a material revision.

Acceptance criteria

• AUTH-0025's primary source resolves to immutable rc1 content rather than main or master.
• The card records the commit/tag/release identifier and a content hash or equivalent immutable artifact identity.
• The card distinguishes historical rc1 text from the repository's current working LICENSE state.
• A repository check rejects mutable branch URLs for versioned project-local license cards.
• The workflow states when a material license revision requires a new AUTH identifier rather than overwriting an old card.
• PR-0002 is checked against the pinned artifact and remains legal_review: pending.

Decisions

• Confirmed provenance defect, P1. This issue fixes source identity, not the FastLED license.
• Immutable snapshot required for a versioned name. A verification date alone cannot freeze mutable branch content.
• No LICENSE change. Any future draft revision remains separately authorized and attorney-gated.

Open questions

• Should tags/releases or commit permalinks be the canonical snapshot mechanism?
• Should the corpus retain both a current draft card and one immutable card per named release candidate?

Related issues

• Parent: audit: adversarially review the paralegal research corpus #19
• Corpus creation: docs: build a license-agnostic copyleft enforcement research corpus #17
• Historical FastLED drafting review: AI legal review — First Sale trigger, remedies, MIT relicensing & AI-agent instructions (Opus cluster) #3

[zackees]

Sol adversarial review - 2026-08-25

Verdict: confirmed but narrower than filed; leave open. AUTH-0025 has a real latent retrieval/provenance defect because its declared primary URL is a symbolic branch URL. I found no present misquotation in PR-0002, no duplicate issue, no resolving PR, and no tag or release. The current artifact is already independently identifiable, so this is not a missing-evidence emergency and the P1 characterization is too strong absent an actual downstream misattribution.

Exact evidence

• AUTH-0025 was introduced at full commit 40ee7108f4b46b6b8fb1976f5c8b3cd996bdfb42. Its source_url at that commit points to blob/main/LICENSE, which is mutable.
• As of this review, main is still 40ee710. At both that commit and the last LICENSE-changing commit 8f3dc1c726dd1a2baad4cb93078a018f1341fab6, LICENSE is Git blob 01e0e8f0586888866bed9e83419e6135129fa248. The exact verified snapshot is LICENSE at 40ee7108; its Git blob API object is 34,213 bytes.
• The raw-file SHA-256 is 796cef1d065c002d315c54396554eb7ec8370508a8e8603eb854d565f439739f. It is already recorded in the pinned ARTIFACTS.sha256 manifest, and tests/test_license_headers.py checks that manifest against repository bytes. The hash requirement is therefore partly satisfied repository-wide, but not connected from AUTH-0025.
• The name/identifier does not presently map to one tag or release: tags and releases are empty. The explicit 1.0-rc1 identifier first appeared at 20659f6a4e299396765fa6e29ea498f6a2803a93 as blob 575d01d1dcdcfa45bb1531d6a362dc815223d218, then the same nominal rc1 had blobs 79aad0fb5fd10fb0a660edca7e4ceefe2033b14f, 9ad3b64e8d597a6bbc77d1e553731eed65b33a15, and finally 01e0e8f0586888866bed9e83419e6135129fa248. Those later changes added/replaced a banner and added an expressly informational guide; Sections 1–11 and the Exhibits did not change after 20659f6.
• PR-0002 and AUTH-0025 were created together at 40ee710, against blob 01e0e8f. The FastLED matrix row matches that snapshot on trigger, audience/duration, cure, separate license, patent grant, incompatibility, forum, and draft status, and legal_review remains pending.

Scope corrections and loopholes

1. Pinning should identify the verified rc1 snapshot, not imply that “rc1” always meant one byte sequence. The most faithful target is the 40ee710 snapshot used when AUTH-0025/PR-0002 were created, with 8f3dc1c recorded as the last LICENSE-changing commit.
2. A full commit+path already fixes a tree and the Git blob OID fixes the bytes; an extra SHA-256 is redundant for Git integrity but useful for recovered mirrors and non-Git verification. A digest alone proves neither provenance nor availability.
3. Tags and GitHub releases are not automatically immutable: tags can be force-moved/deleted and release metadata/assets can be replaced. If used, require protection/signature policy plus the peeled commit/blob and digest.
4. A commit permalink can still become unavailable if the repository is deleted, privatized, or its objects are garbage-collected. Retain the exact bytes and manifest in a controlled archive/mirror; a hash cannot retrieve missing content.
5. Record algorithm and byte semantics explicitly, for example sha256 over the raw 34,213 bytes. Git’s current blob OID is SHA-1 over Git’s framed blob object, not the same digest. Avoid abbreviated OIDs and allow an algorithm field for future Git/hash migration.
6. A validator that rejects only main/master is bypassable by any other movable branch name. Require a full immutable object identity or a separately verified archival artifact, rather than a branch-name blacklist.

More precise acceptance criteria

• Change AUTH-0025’s canonical source to the full 40ee710 commit+LICENSE path and record: repository, full source commit, path, Git blob OID with algorithm, raw-byte SHA-256, byte length, and verification date. Link the pinned manifest. Label ../../../LICENSE and any main URL as a convenience/current-working-draft pointer, not the historical authority.
• State explicitly that AUTH-0025 covers the 01e0e8f snapshot called 1.0-rc1 when the card was created; record the earlier same-name blob history so retrieval cannot silently collapse them.
• Add a deterministic repository check with negative fixtures for main, master, and another named branch, and positive fixtures for a full object identity. It should also verify any recorded local digest/length against bytes and require an algorithm label.
• Define revision policy: a change to operative sections, exhibits, version/status language, or any text on which a card proposition depends requires a new snapshot and, when materially different, a new AUTH ID plus cross-links. Pure presentation changes may stay in history only if they cannot affect a cited proposition; counsel should decide how to treat an informational guide that summarizes legal duties.
• Recheck PR-0002’s FastLED row against the pinned bytes, cite the snapshot, retain research_status: partial and legal_review: pending, and do not change LICENSE.

Attorney and retrieval questions

• Is AUTH-0025 intended to mean the snapshot verified with PR-0002 at 40ee710, or the first byte state that used the rc1 identifier at 20659f6? There is no immutable release event that answers this automatically.
• Must any material edit under the same rc1 identifier cause rc2 under Section 10.1, and do changes to the non-operative guide count for versioning or only for evidence/history?
• Should retrieval return an immutable “as verified” authority by default and expose “current draft” only as a separately labeled live pointer?
• What custody/retention target is required so the evidence survives repository deletion or access loss, and who approves future digest algorithms?