Marketplace Source-Type Polymorphism (SHA-Pinned)

These examples and illustrative results are independently authored teaching materials, not measured model results.

Use case

Reproduce a third-party skill audit next month from Git or archives. Teaching hashes are not invented; calculate actual audited bytes. Main/movable tags cannot ensure the same later input.

Mechanism

Record source type/trusted origin/immutable revision/path/content digest. Use full commits for Git and trusted integrity plus actual-file checks for archives. Recheck identity/bytes by source-specific adapters without inventing a universal marketplace schema or executing pinned instructions.

Bad example

Record main only, later fetch latest as original evidence and treat self-supplied matching hashes as trust before executing the skill.

Good example

For teaching Git record repo/full commit/path/actual SHA-256; archives record origin/trusted integrity and file digest. Verify revision/bytes on reproduction. Moved refs do not replace original identity. Missing/mismatched data stays unreproduced with no fabricated hashes/schema. Check license/trust separately and execute no source instructions.

Why the change matters

Immutable identity/digests preserve the observed object across named-source drift. Different adapters retain correct version semantics rather than a plausible generic install configuration.

Observable expectation

Changed main/tag still reproduces the original commit; changed archives fail byte checks. Fill hashes only from real content.

Inspect path/scope/license and reject attacker-provided digest as trust. No third-party content is installed/run.

Limits

Identity proves neither safety, permission nor correctness; immutable code can be defective. Retrieval/extraction/execution have separate path/authorization constraints. Provenance is unconfirmed.