← Back to catalogue
Published

Source Repository

vr.wm-sft-005 · wm-sft-005-source-repository

Version-controlled stores of source code with history, branches, access and provenance.

World Models Information and virtual systems INF.SFT.REPO
Bundle → Layer → Finding → QuestionsClassifiersWhat it isWhy it existsDistinguishing featuresWhat robots and AI may and may not doMoral aspectsOwnersLinks to other meta-modelsIdentity and identifiersDirect propertiesRecognitionCapabilities and actionsHazards and failure modesStandards and interfacesContext of useSources

Bundle → Layer → Finding → Questions Filled

3 bundles · 3 layers · 5 findings · 11 questions

Identity and ownership Which repository and who is responsible.

Location and owner

Hosting location, owning organisation and maintainers.

Repository identity

The repository has a canonical location, an owner and named maintainers.

  1. What is the canonical location of the repository, and which mirrors exist?
  2. Which organisation owns it, and who are the maintainers?

Licence

The licence under which the content is offered.

  1. Which licence applies to the repository content?
  2. Do some files carry different licences or third-party notices?
History and integrity What the repository contains over time.

Commits and references

Commits, branches, tags and their signatures.

Traceable history

Each change is a commit with author, time and parent, and important references are protected.

  1. Which commit does a given tag or release point to?
  2. Are commits and tags signed, and by whom?
  3. Has the history of a protected branch been rewritten?
Governance and security Who may change it and how it is protected.

Access and protection

Permissions, branch protection, review rules and secrets hygiene.

Change control

Changes to protected branches require review and passing checks.

  1. Who has write and administrative access?
  2. Which review and check rules protect the main branch?

Exposed secrets

Credentials and secrets are kept out of the history.

  1. Has secret scanning found credentials in the history?
  2. Were exposed credentials revoked, not just deleted from the files?

Classifiers Filled

Family
World Models
Category
Information and virtual systems
Entry kind
entity
Navigation path
NAV.INF.SFT.REPO
Domain
INF.SFT.REPO
Industry
Cross-industry
Tags
sourcerepositoryinf.sft.repo

What it is Filled

A source repository is a version-controlled store of source code and related files, with its complete history of commits, branches and tags, its access rules and the people who maintain it. The subject is the repository as a governed asset; the software product built from it, its releases and the individual change requests are separate subjects.

In scope

  • Master identity, locators, stewardship and operating state
  • Qualified revisions, named references, observations and copy completeness
  • Linked content and external change request bindings
  • Access/control evidence, integrity and scoped rights assertions
  • Preservation coverage, retention and disposition metadata

Out of scope

  • Software product, release and deployed-system masters
  • WM-SFT-013 review, approval, merge and closure lifecycle
  • Source control hosting infrastructure and identity-provider implementation
  • Build execution, package distribution, dependency resolution and software safety certification
  • Credential contents, exploit procedures, incident-response execution and destructive history operations
  • Complete VCS-specific instance schemas or normative conformance

Why it exists Filled

Version-controlled stores of source code with history, branches, access and provenance.

Distinguishing features Filled

  • It is the version-controlled store with its full history, not the product or a single release built from it.
  • Individual pull requests or change requests are contained in it but are separate records.
  • A commit hash identifies content immutably, so history is evidence.
  • Distinct from a package registry, which holds built artifacts rather than source history.

What robots and AI may and may not do Filled

Must not

  • Push directly to protected branches or bypass review rules.
  • Rewrite or force-push shared history.
  • Commit secrets, credentials or personal data.
  • Copy code into the repository in breach of its source licence.
  • Change repository permissions or delete the repository.

Only with a human decision

  • Approving and merging changes to protected branches.
  • Changing access rights, branch protection or repository visibility.
  • Archiving, transferring or deleting the repository.

May

  • Read code and history within granted access.
  • Propose changes through branches and pull requests.
  • Run checks, scans and builds on proposed changes.
  • Report the commit and signature behind a release.

Moral aspects Filled

  • Repositories are a software supply chain link: a compromise reaches every downstream user.
  • Contributor attribution and licences must be respected.
  • Commit metadata contains personal data of contributors.

Who is affected

  • Maintainers and contributors
  • Downstream users of the software
  • Organisations owning the code

Owners Filled

Steward

The engineering team or open source project that maintains the repository and decides on its access and changes.

Roles

Repository steward
Defines purpose, continuity and accepted governance profile.
Repository administrator
Maintains external access and control policy under a mandate; provides scoped evidence.
Contributor
Provides source and attribution evidence within allowed scope; cannot self-grant approval.
Evidence reviewer
Checks observation scope, trust distinctions and unresolved conflicts.
Rights reviewer
Evaluates scoped rights assertions and records decisions without inferring from visibility.
Preservation custodian
Maintains preservation scope, retention decisions and recovery evidence.

Master systems

  • Version control hosting service
  • Software archive
  • Identity and access management system

Links to other meta-models Filled

child

  • WM-SFT-013 - Optional contained reference to a separately mastered change or pull request; zero or more proposals. Only repository binding and revision scope are local; proposal review, approval, merge and closure remain in the child model.

aligned

  • SLSA Source v1.2 - Conceptual source identity and control-evidence alignment; no maturity level or normative implementation claimed.
  • SPDX license expressions v2.3.1 - Optional rights-assertion vocabulary; not rights ownership or legal compatibility determination.
  • PROV-O - Optional evidence-lineage mapping without replacing external provenance record masters.
  • SWHID v1.2 - Optional archival-object links; no conflation with repository identity or hosting availability.

neighbor

  • WM-SFT-013 Change / Pull Request - Registry CONTAINS is realized as optional CHILD bindings: zero or more externally mastered proposals. Repository scope is local; proposal review, approval and merge lifecycle remain in the child model. A repository exists without a proposal subsystem.
  • Software product and release - A repository may serve multiple products; a release may draw on multiple repositories. Keep exact source revision links without importing product or release state.
  • Copy, mirror, fork and nested repository - A copy is an observed view of a repository. An independently governed fork has a separate repository identity and lineage link. Nested repositories keep their own history and access.
  • Hosting platform and identity service - The repository records authority and enforcement evidence; hosting, authentication and access-control execution stay in external systems.
  • Archival object and provenance record - An intrinsic object ID names an archived object, not the enduring governed repository; source provenance describes an assertion without certifying its truth.

contains

  • WM-SFT-013

What else AI and robots need to interact with it Filled

Identity and identifiers required Filled

  • A repository is identified by its canonical URL on the hosting service.
  • Content is identified by commit hashes, and archived states by Software Heritage identifiers (SWHID).

Direct properties not applicable Not applicable

Not applicable

A source repository is a digital information asset with no physical properties to measure.

Recognition optional Filled

  • A repository is recognised by its URL, its version control metadata and its commit history.
  • Often confused with the product it builds, a fork or mirror, or a package in a registry.

Capabilities and actions required Filled

  • History can be inspected, compared and bisected.
  • Changes can be proposed, reviewed and merged under protection rules.
  • Commits and tags can be signed and verified.

Hazards and failure modes required Filled

  • Leaked credentials in the history.
  • Malicious commits from compromised accounts.
  • Loss of history when a hosting account is deleted without an archive.

Standards and interfaces required Filled

  • Git protocol and object model.
  • SLSA framework for build provenance from source.
  • SPDX licence identifiers in files and metadata.

Context of use required Filled

  • Used in every software development process, open or closed.
  • Secure development frameworks such as the NIST SSDF set expectations for repository protection.

Sources Filled

  1. Git repository layout - Git project
  2. Git clone - Git project
  3. SLSA Source: Requirements for producing source - Open Source Security Foundation
  4. Secure Software Development Framework Version 1.1 - National Institute of Standards and Technology
  5. SWHID Specification Version 1.2 - Clause 4: Syntax - SWHID Contributors
  6. SPDX Specification v2.3.1 - Annex D: SPDX license expressions - SPDX Project
  7. PROV-O: The PROV Ontology - World Wide Web Consortium
  8. Date and Time on the Internet: Timestamps - Internet Engineering Task Force
  9. Git fsck - Git project
  10. Git bundle - Git project
  11. Git submodules - Git project
  12. Git cryptographic signature formats - Git project
  13. Secure Software Development Framework, SP 800-218 (NIST)
  14. Supply-chain Levels for Software Artifacts, SLSA (Open Source Security Foundation)
  15. Software Heritage persistent identifiers, SWHID (Software Heritage)

Open questions

  • Run the prepared source checker outside the sandbox, inspect source content and pin editions; HTTP success alone is not substantive verification.
  • Develop and test adopting profiles with empty stores, partial copies, moved references, unknown trust, mixed licences, missing nested content, stale permission views and restricted disposition fixtures.
  • Restore independent external review before canonical or publishable-draft promotion.
  • Independent external review is absent; Claude and Grok skipped by owner instruction.
  • Direct source HTTP checks are unattempted under the owner-reported sandbox block; response status, body hashes and current release pins remain unmeasured.
  • Non-Git VCS, large-file payload, hosted review export and authorization mappings need tested profiles.
  • Nested candidate data schemas, required-field unknown representation, cardinality constraints and conformance fixtures are not implemented.
  • Rights/privacy applicability, retention periods and destructive-operation authority require adopting-profile review.

Machine files

Card as JSON Specification AGENTS.md Source Card backlog vercy.card/1

Provenance

world-models research · reviewable-draft

Built from: models/wm-sft-005-source-repository/spec.yaml, ver-cy/world-models/card-supplements/wm-sft-005-source-repository.json