Repositories-as-Policies

• Repositories-as-Policies are architectures that embed governance and policy enforcement directly within repositories, integrating access control, audit, and validation mechanisms.
• They enable object-bound access control and runtime policy interpretation by incorporating executable rules, versioning, and semantic checks into digital artifacts.
• They have practical applications in digital libraries, software supply chains, and scientific repositories, bolstering security, compliance, and operational integrity.

“Repositories-as-Policies” denotes a family of architectures in which repositories, registries, and repository-resident artifacts do not merely store content but embody, interpret, and enforce policy. In its narrowest formulation, the repository is a policy-enforcing substrate for object-bound access rules; in broader formulations, it is the primary site where executable governance, validation, admission control, metadata constraints, and lifecycle rules are authored, versioned, and audited. Across digital libraries, web applications, software supply chains, Policy-as-Code ecosystems, and scientific data infrastructures, the common move is from external or implicit governance toward repository-centered policy specification and enforcement (Payette et al., 2013, Foalem et al., 9 Jan 2026, Brandes, 4 Jun 2026).

1. Conceptual scope

The earliest explicit operationalization centers on policy-carrying and policy-enforcing digital objects. In that formulation, access control is moved “down to the digital object level,” so that objects carry, advertise, and trigger enforcement of their own policies, while the repository interprets those policies at the moment of access rather than relying solely on repository-wide rules. The repository remains responsible for shared global constraints, but fine-grained behavior-oriented control is delegated to policies bound to object behaviors such as disseminators (Payette et al., 2013).

Later work broadens the concept substantially. “Repositories with direct representation” treats repository policy as semantic structure plus procedural services: validation programs, annotation services, version management, and workflow constraints act over richly modeled entities, states, and processes rather than over document metadata alone. In that setting, policy is not expressed as a single access-control language; it is distributed across model admissibility conditions, validation routines, and systematic update mechanisms that govern what the repository will accept, preserve, and narrate (Allen, 2015).

A third strand places repositories and registries at institutional control boundaries. The “Custody Envelope Threshold” defines direct artifact admission as defensible only when object identity, ingress path, and revocation capacity are sufficiently closed relative to delegated execution authority. Here, the repository or registry becomes the institutional policy gate that proxies, policy-mediates, vendor-mediates, internalizes, quarantines, or rejects external artifacts when custody closure is inadequate (Brandes, 4 Jun 2026).

Empirical Policy-as-Code research generalizes the same idea to open-source software repositories. Policies appear as machine-readable, version-controlled artifacts such as .rego, .sentinel, or Kubernetes YAML, evaluated by policy engines in CI/CD, admission control, or service authorization. The repository is thus the primary unit in which governance is authored, reviewed, and enforced (Foalem et al., 9 Jan 2026).

2. Object-centric enforcement and formal security automata

In the Fedora–PoET architecture, digital objects aggregate DataStreams, which may be local or external ReferenceDataStreams, and expose both a generic Primitive Disseminator and content-specific Disseminators bound to executable mechanisms such as Servlets. Policies are attached either as object-internal DataStreams or as reusable group policies referenced by multiple objects. A repository-defined default policy constrains the generic API, while behavior-specific policies are bound to particular disseminators (Payette et al., 2013).

Enforcement occurs at dissemination time. When a client invokes a behavior such as GetVideo(quality), the Mechanism Manager retrieves the relevant code module and policy, and PoET rewrites the Java bytecode to inline policy checks before execution. The trusted rewriter and class loader ensure that only policy-checked code runs inside the JVM. Because PoET was extended for just-in-time rewriting, the same shared mobile code can be loaded under different objects’ policies, and policy changes can take effect when code is next loaded rather than through system-wide recompilation or redeployment (Payette et al., 2013).

The formal model is a security automaton

$A = (Q, \Sigma, \delta, q_0, F),$

where $Q$ is a finite state set, $\Sigma$ is the alphabet of observable events, $\delta : Q \times \Sigma \to Q$ is the transition function, $q_0$ is the initial state, and $F \subseteq Q$ is the set of accepting safe states. At runtime, for event $e \in \Sigma$, the in-lined reference monitor computes $q' = \delta(q,e)$ and requires $q' \in F$; otherwise the event is denied and the offending execution path is halted. The paper’s lecture example encodes the rule “After viewing descriptive metadata, only Cornellians can access the Lesson 1 video,” with events such as viewMeta, accessVideo, and presentID(Cornell) and denial when accessVideo occurs from the unauthorized state (Payette et al., 2013).

This model makes the repository neither a passive store nor merely a front-door access filter. It becomes a runtime orchestrator of per-object, per-behavior policy interpretation. Portability is possible when the receiving environment provides a JVM, Fedora, and PoET or an equivalent in-lined reference monitor, but the paper identifies conflict handling between repository and object policies as an open issue and recommends PKI and secured containers such as IBM Cryptolopes to protect integrity and authenticity during mobility (Payette et al., 2013).

3. Policy-as-Code in software repositories

In software repositories, “Repositories-as-Policies” appears as executable governance embedded in repository artifacts. GitHub Actions workflows encode CI/CD and security checks; SECURITY.md formalizes disclosure and reporting procedures; and CodeQL workflows operationalize static-analysis policy. An empirical study over “just over 173 thousand projects” reports headline adoption rates of approximately $r_{\text{workflow}} \approx 37\%$ and $Q$0. In the top 60 repositories from each of the 34 most popular programming languages on GitHub, the rates rise to $Q$1 for workflows and $Q$2 for security policies. Among repositories whose primary language is supported by CodeQL, only $Q$3 have CodeQL enabled; Kotlin is the lowest observed at $Q$4, and Go the highest at $Q$5 (Ayala et al., 2023).

A larger 2026 study frames Policy-as-Code as executable rules evaluated by a dedicated policy engine returning outcomes such as allow, warn, or deny, with policies kept separate from application code and exposed through APIs. Across 399 GitHub repositories using nine PaC tools, the dominant governance intents are Security Governance at $Q$6 and Compliance Governance at $Q$7. Tool usage is concentrated: OPA accounts for $Q$8 of policy-related files and appears in $Q$9 of repositories; Kyverno, GateKeeper, and Pulumi form the next major clusters. Most projects, $\Sigma$0, use a single PaC tool, while notable co-usage patterns include OPA with GateKeeper at $\Sigma$1 and OPA with Cedar at $\Sigma$2 (Foalem et al., 9 Jan 2026).

These studies situate the repository as the locus of machine-readable and auditable governance. Policies are co-located with source code, reviewed through ordinary version-control workflows, and enforced in pipeline stages or admission controllers rather than by separate organizational documents. This suggests that repository structure itself becomes part of the governance mechanism: where workflows, policy files, and security-reporting documents are absent, policy is correspondingly less explicit, less executable, and less measurable (Ayala et al., 2023, Foalem et al., 9 Jan 2026).

4. Repository-layer enforcement and policy extraction in database-backed applications

For database-backed applications, the repository layer is often the point at which contextual policy can be enforced with sufficient proximity to query semantics. Estrela makes this explicit by attaching policies to schema or repository primitives in Django model classes and selecting them by endpoint context. Policies have the form

$\Sigma$3

where $\Sigma$4 indicates whether the policy rewrites the query before evaluation or transforms result rows after evaluation, $\Sigma$5 is an optional list of API identifiers, and $\Sigma$6 is executable code. Estrela’s runtime intercepts ORM queries, applies pre-evaluation filters, executes the query, and then applies post-evaluation transformations; if no matching pre-policy exists, a default deny policy returns no rows (Bichhawat et al., 2018).

This design permits endpoint-specific overrides, joint-field matching to prevent implicit leaks, and contextual rules such as showing only invited calendar events globally while allowing a location endpoint to access broader event sets and then redact sensitive fields for non-invitees. The framework was retrofitted into several real-world applications, with reported overheads typically below $\Sigma$7 and, in some cases, near $\Sigma$8–$\Sigma$9 (Bichhawat et al., 2018).

A complementary approach does not begin with explicit policies at all. Ote treats the application repository as the single source of truth for actual access behavior and extracts an enforceable policy from scattered Rails access checks and SQL or ORM filters. It models path constraints as

$\delta : Q \times \Sigma \to Q$0

derives conditioned queries from concolic execution traces, and synthesizes a minimized set of parameterized SQL views representing the application’s read policy. A query is authorized if it can be answered using only those views. The extracted policy can then be stored in the repository, reviewed, diffed in CI, and enforced independently, for example by Blockaid (Zhang et al., 2024).

The empirical results are notable because they show both scale and defect discovery. In diaspora*, the People#stream handler produced 1,184,510 paths and 3,260,165 conditioned queries before simplification; in Autolab, the total extracted policy across five handlers was pruned to 51 views, compared with 28 handwritten rules, and comparison with handwritten policies revealed both over-permissive and overly restrictive rules. The extraction also exposed a real access-check bug caused by misuse of the lazy_columns gem (Zhang et al., 2024).

5. Semantic repositories and direct representation

In direct-representation repositories, policy is embedded in semantic admissibility and update procedures rather than in access control alone. The repository stores explicit models of entities, parts, states, causal processes, scenarios, and discourse structures. Domain models are grounded in upper ontologies such as BFO; instance descriptions represent state and state change across time; process chains encode sequences, causation, branching, and loops; and descriptive programs support validation, update, and narrative generation. The repository therefore becomes an active policy engine because its models and validation programs determine what counts as a well-formed object, mechanism, scenario, or explanation (Allen, 2015).

The formal schemata emphasized in the paper concern causation and state change:

$\delta : Q \times \Sigma \to Q$1

and

$\delta : Q \times \Sigma \to Q$2

These express an entity $\delta : Q \times \Sigma \to Q$3 in state $\delta : Q \times \Sigma \to Q$4 causing a transition of entity $\delta : Q \times \Sigma \to Q$5 from $\delta : Q \times \Sigma \to Q$6 to $\delta : Q \times \Sigma \to Q$7, operationalized as a method or function over states. Policies are not given in a dedicated declarative language; instead, they appear as validation programs, extensive version management, and procedural update logic, including prior work that interwove ontology state-change updates in Java with validation using Jena (Allen, 2015).

This conception extends “Repositories-as-Policies” beyond authorization. A repository can reject malformed mechanism descriptions, surface inconsistencies through annotations, preserve older interpretations through versioning, and personalize discourse paths for different user roles or theoretical perspectives. The paper explicitly de-emphasizes heavy OWL reasoning in favor of structural and procedural validation, which suggests a repository model in which policy is enacted by executable descriptive programs over semantically rich content rather than by a centralized policy decision point (Allen, 2015).

6. Admission control, package repositories, and model hubs

In institutional infrastructure, repositories and registries can serve as authority-scaled admission gates for externally maintained artifacts. The Custody Envelope Threshold defines four ordinal conditions: execution authority $\delta : Q \times \Sigma \to Q$8, object identity $\delta : Q \times \Sigma \to Q$9, ingress path $q_0$0, and revocation capacity $q_0$1, each scored from 0 to 3. Direct admission is defensible only when

$q_0$2

and the custody deficit is

$q_0$3

When $q_0$4, the institution selects a governance mode: Admitted, Proxied, PolicyMediated, VendorMediated, Internalized, or Quarantined. Repositories and registries become the “always-invoked, tamper-resistant reference monitor” by enforcing pinning, signatures, provenance, allowlists, scanning, internal feeds, private marketplaces, deny-by-digest, and revocation workflows (Brandes, 4 Jun 2026).

The model is applied to package dependencies, GitHub Actions, container images, Terraform providers and modules, developer extensions, open model artifacts, and held-out MCP servers. It predicts, for example, PolicyMediated treatment for a third-party GitHub Action with repo secrets when full-SHA pinning, org allowlists, least-privilege GITHUB_TOKEN, and Action policy can close the deficit, and Proxied treatment for a public npm package when ingress and revocation are the binding weaknesses (Brandes, 4 Jun 2026).

A related repository-centric perspective appears in the empirical study of ML package repositories. TFHub and PyTorch Hub are treated as policy instruments through their metadata schemas, review workflows, interface conventions, and discoverability mechanisms. TFHub, launched in March 2018 with 471 packages, uses incremental integer versions and release notes; PyTorch Hub, launched in June 2019 with 26 packages, lacks formal versioning and loads from GitHub repository snapshots. The study identifies 33 information elements grouped across delivery, legal information, package information, submission and review, security, software development, and technical documentation, and it emphasizes policy gaps such as absent popularity signals, limited vulnerability workflows, inconsistent documentation of signatures or entrypoints, and non-standardized reporting of package quality evaluation. Only 17 of 26 PyTorch Hub packages and 35 of 383 TFHub packages report performance results, and dependencies are often left implicit or described in free text (Xiu et al., 2020).

Taken together, these works describe repositories as policy gates not only for whether an artifact may enter an institution, but also for how it is described, versioned, reviewed, and trusted once admitted.

7. Scientific repositories, tiered governance, and best-practice policy design

Scientific repositories provide a particularly explicit realization of repository-encoded policy. The BIG-MAP Archive, built on InvenioRDM, encodes staged sharing for BATTERY 2030+ through communities, roles, metadata templates, share links, and versioning constraints. Each project is a community; there is also a consortium-wide community; and datasets can move through the tiers

$q_0$5

Access is determined by community-bound roles, public status, or share-link tokens, while edit tokens are constrained to members of the owner’s community. Once a record is shared, files become immutable and changes require a new version, while metadata may still be updated (Granata et al., 17 Dec 2025).

The platform uses PostgreSQL as the authoritative relational store and OpenSearch as the search index, supports REST APIs and a CLI client, exports metadata in JSON, JSON-LD, DataCite, and Dublin Core, and currently reports more than 260 records, over 450 registered users, and approximately 1.5 TB of stored data. FAIR-by-Design requirements are enforced through structured metadata, ORCID and ROR identity fields, license selection including a BATTERY2030+ custom license, and publication transfer workflows to Materials Cloud Archive, where moderators review submissions and mint DOIs (Granata et al., 17 Dec 2025).

For research software collections more generally, nine best practices define a policy framework for registries and repositories: public scope statement, guidance for users, guidance to software contributors, authorship policy, public metadata schema, conditions of use, privacy policy, retention policy, and end-of-life policy. The paper distinguishes a registry as typically an index or catalog of software stored elsewhere, and a repository as typically a site that both indexes and stores software. In the “Repositories-as-Policies” framing, these documents are not merely descriptive; they are meant to be encoded in submission forms, metadata schemas, validation scripts, review workflows, audit trails, tombstone pages, and continuity plans (Registries et al., 2020).

This research-practice literature broadens the term beyond executable access checks. Repository policy includes eligibility, authorship, licensing, privacy, retention, migration, and end-of-life commitments. A plausible implication is that the most durable form of “Repositories-as-Policies” is institutional: policy remains public, versioned, and enforceable because it is built into repository architecture, operational workflows, and preservation guarantees rather than left to external documentation alone (Granata et al., 17 Dec 2025, Registries et al., 2020).