agentsclimarketplace
Sign in

Provenance system design

Skill SylphxAI/skills/skills/provenance-system-design

Design provenance for artifacts, claims, builds, or content—lineage, attestation, verification, and disclosure. Use when provenance is the product concern. Not generic logging and not a one-line changelog note.From its SKILL.md

Install
npx -y skills add SylphxAI/skills --skill provenance-system-design

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

  • 24 days oldThe repository was created 24 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
  • 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

SKILL.md

3.1 KB, 598 tokens by cl100k_base, as published. Nobody here has run it

Provenance System Design

Make lineage queryable and verifiable without pretending that lineage proves correctness. Read references/provenance-models.md before choosing the data model, trust boundary, or interoperability format.

Method

  1. Define the provenance questions, claim boundary, consumers, retention, and decisions the record must support. Do not collect lineage without a query or control that will use it.
  2. Identify entities, activities, agents, plans, sources, derivations, delegations, generations, usages, revisions, and environments. Give each a stable identity and namespace.
  3. Model relations as an append-only graph or equivalent event history. Preserve source identifiers and represent corrections as new records; do not overwrite history silently.
  4. Bind each observation to producer, subject, time, revision or digest, collection method, and trust domain. Separate self-assertion, external observation, independently verified evidence, and cryptographic attestation.
  5. Define capture points at transformation boundaries. Minimize sensitive data, support redaction or cryptographic erasure where required, and keep integrity metadata only as long as justified.
  6. Select interoperable projections where useful: W3C PROV for general lineage, SLSA or in-toto for software supply chain, OpenLineage for data jobs, and C2PA for content credentials. Keep one semantic owner behind projections.
  7. Test missing links, cycles, duplicate events, clock skew, stale identity, replay, tampering, partial disclosure, cross-tenant access, and reconstruction of representative lineage questions.

Output

Produce one Provenance Contract containing:

  • questions, scope, consumers, and authority boundary;
  • entity, activity, agent, plan, and relation model;
  • identifiers, namespaces, versions, digests, and time semantics;
  • capture points, producers, trust classes, and validation rules;
  • correction, replay, deduplication, retention, deletion, and privacy behavior;
  • interoperable projections and loss mapping;
  • required queries, integrity checks, adversarial tests, and known limits.

Boundaries

  • Provenance establishes lineage and custody; it does not by itself prove that content is true, safe, authorized, or high quality.
  • Use evidence-and-claims-standard to decide whether provenance and other evidence support a factual or completion claim.
  • Use source-authoring-standard for commit, candidate, worktree, and source reconciliation semantics.
  • Use work-coordination-standard for portable claim, lease, checkpoint, and handoff semantics; use the matching product adapter for live work state.
  • Use supply-chain or data-domain Skills for domain-specific admission rules; this skill owns their common lineage model and boundaries.

Gives 0 of the 12 instructions most architecture codebase skills give in 598 tokens

Counted across 811 of the 1,134 authors here whose files we hold, read 2026-08-07

  • Ask the user which candidate to explorein 45 of 811, across 15 files
  • Apply the deletion test to suspected shallow modulesin 43 of 811, across 15 files
  • Read any relevant architecture decision records firstin 31 of 811, across 8 files
  • Use exact glossary terms in every suggestionin 30 of 811, across 10 files
  • Accept dependencies instead of creating themin 24 of 811, across 5 files
  • Include before and after visualisations for each candidatein 24 of 811, across 5 files
  • Read the domain glossary before exploringin 24 of 811, across 6 files
  • Return results instead of producing side effectsin 23 of 811, across 4 files
  • Explore the codebase for shallow modules and frictionin 23 of 811, across 3 files
  • Introduce seams only where things varyin 22 of 811, across 3 files
  • Reduce the number of methodsin 21 of 811, across 2 files
  • Design deep modules with small interfacesin 21 of 811, across 3 files

Said here and by no other author read

  • read the references before choosing a model
  • define provenance questions, scope, and consumers
  • give each entity a stable identity and namespace
  • model relations as an append-only graph
  • represent corrections as new records
  • bind observations to time, producer, and trust domain

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 326,696. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.