A practical verification methodology for reusable code snippets: provenance, license, scans, tests, compatibility, revocation and proof receipts.
Verification must name its scope
A clean malware scan does not prove business correctness. A passing unit test does not prove compatibility with a different runtime. A known license does not prove the code is secure. These are separate signals and they should remain separate in the interface.
A trustworthy listing states exactly what is known: where the artifact came from, which content hash was reviewed, which license applies, when automated scans ran, whether tests or examples exist, and whether the artifact has been corrected or revoked.
Moresq uses “verified” to describe the evidence attached to the artifact and the admission controls it passed. The consuming developer remains responsible for project fit, threat model and final tests.
The minimum evidence bundle
The artifact record should be useful before source retrieval. Search results need enough metadata for an agent to reject a candidate early and for a human to understand why a result is ranked.
- Stable artifact identifier and content hash.
- Source or contributor provenance.
- Explicit license and allowed-use state.
- Language, runtime, framework and dependency constraints.
- Review or scan status with a real date.
- Examples, test pack or documented edge cases when available.
- Known limitations and security-sensitive assumptions.
- Current revocation and correction state.
Admission and retrieval need different gates
Admission asks whether an artifact is eligible to exist in the corpus. Retrieval asks whether the same artifact fits a particular task. A generic retry helper can be safe to list and still be wrong for a payment operation that must never retry automatically.
Admission should block secrets, unclear provenance, incompatible licenses, obvious duplication and unsafe payloads. Retrieval should evaluate task similarity, environment, risk class, freshness, evidence and budget. Keeping these decisions separate prevents a listing badge from becoming an automatic apply permission.
- 01Normalize and scan the candidate without exposing secrets.
- 02Confirm provenance, rights and public or tenant scope.
- 03Deduplicate against existing artifacts.
- 04Attach tests, examples and compatibility metadata.
- 05Publish a compact card with an immutable identifier.
- 06Require a new fit decision for every retrieval.
A proof receipt records the reuse decision
When an agent retrieves code, the resulting receipt should bind the exact artifact to the retrieval event. Useful fields include the content hash, source, license state, trust evidence, price, actor, project and timestamp. A local lock file can keep that record beside the consuming repository.
Receipts support incident response. If an artifact is later revoked, consumers can identify which repositories retrieved it. If a developer corrects the adaptation, the outcome can improve future guidance without rewriting history.
The receipt should not contain secrets or private source material. It is an audit pointer and evidence summary, not another copy of the implementation.
Claims a verification page should avoid
Do not claim that automated scanning makes code secure, that a receipt is a formal proof of correctness, or that a reused pattern no longer requires review. Those statements collapse context-dependent engineering into a badge.
The defensible promise is narrower: the artifact is attributable, its evidence is visible, its state can change, and the reuse event can be audited. That still represents a major improvement over anonymous generated code.
- Avoid “safe in every environment.”
- Avoid “fully audited” without publishing the audit scope.
- Avoid hiding stale scan dates.
- Avoid transferring private artifacts into a public catalogue.
- Avoid ratings that cannot be decomposed into evidence.
FAQ
Frequently asked questions
Does a verified snippet still need code review?
Yes. Verification exposes provenance and technical evidence, but the consuming repository must still validate interfaces, dependencies, threat model and tests.
What should a proof receipt contain?
At minimum: artifact identifier, content hash, source, license state, evidence or trust status, retrieval timestamp, project and lifecycle state.
Can a verified artifact be revoked?
It should be. Security findings, licensing changes and better implementations can all make a previously accepted artifact unsuitable for future reuse.
Is a malware scan enough to call code verified?
No. It is one signal. Verification should also cover provenance, rights, compatibility, tests or examples, known limitations and current lifecycle state.