OpenOS-Project-OSP documentation
OpenOS-Project-OSP is the operational continuity layer of the OpenOS Project. This documentation describes how the namespace approaches provenance, independently verifiable copies, recovery, and portable operations across Git hosting services.
The documentation uses forge for a Git hosting service, namespace for the collaborative space hosted by that service, and repository/project for a hosted unit of work. Platform-specific labels do not change the boundaries, provenance, or responsibilities of the content.
Start here
Each hosted repository or project remains authoritative for its own status, license, upstream attribution, and contribution instructions.
Purpose and scope
OpenOS-Project-OSP preserves operational access to open systems work. Its role is to make recovery paths, synchronization boundaries, and provenance visible without treating any single forge as the definition of the project.
Responsibilities
- Maintain accessible repository or project copies and recovery endpoints.
- Record the authoritative upstream and synchronization direction.
- Prefer open formats, replaceable components, and portable automation.
- Treat documentation, accessibility, recovery, and operability as core work.
- Preserve upstream attribution and licensing at every hosted endpoint.
Repository boundaries
A copy does not automatically become an authoritative upstream. Every hosted repository or project should state whether it is canonical, a maintained mirror, an archival copy, or an experimental integration. Its local README, license, and contribution guidance govern participation at that endpoint.
Platform independence
Git hosting services use different terms—including organization, group, workspace, repository, and project—for similar concepts. OSP documentation uses neutral terms where possible and confines provider-specific configuration to deployment adapters such as an individual forge's workflow directory.
Continuity and provenance
Continuity is useful only when a maintainer can explain where a copy came from, how it is updated, and how it can be restored.
Minimum provenance record
Each synchronized repository or project should identify:
- the authoritative upstream location;
- the mirror direction and expected update cadence;
- the most recently verified source revision;
- any paths intentionally excluded or transformed;
- the responsible maintenance contact or process; and
- the license and attribution inherited from upstream.
Verification cycle
- Fetch the declared upstream revision.
- Compare expected content and automation paths.
- Record intentional transformations separately from unexplained drift.
- Test that a documented recovery path can recreate the hosted copy.
- Publish a clear status when verification or synchronization is impaired.
Failure handling
Automation should fail closed when identity, provenance, or destination checks do not match expectations. Recovery procedures should be testable without a single provider account, proprietary export, or undocumented credential.
Support and stewardship
The OpenOS Project public funding page connects contributions to named purposes. OSP interprets tier families as operational scopes rather than rank, access, governance authority, or guaranteed service.
| Tier family | OSP stewardship scope |
|---|---|
| Operations | Hosting, self-hosted services, continuity, and maintenance |
| Engineering | Core research, releases, interfaces, applications, and supporting technology |
| Contributor enablement | Development equipment, project support, and contracted maintenance |
| Community infrastructure | Planning for facilities and essential operational services |
| Shared logistics | Distribution, shipping, and costs coordinated with the ecosystem layer |
Every published tier should identify its purpose, eligible costs, allocation, cadence, public evidence, dependencies, and current status. The live funding listing remains authoritative for availability, wording, amounts, fulfillment, and financial terms.
Fictional character lore is kept separately under characters/lore/. It does
not describe real financial, security, governance, or operational activity.
Forge-neutral README subsystem
OpenOS-Project-OSP uses a reusable README subsystem without treating a GitHub organization as the universal model for every forge.
- Namespace means the containing account, organization, group, subgroup, workspace, or equivalent boundary.
- Project means this hosted Git repository.
- Profile surface means the README location exposed by the current forge.
Fork-Sync-All owns reusable policy and rendered-link engines. OpenOS-Project-OSP owns this project's identity, purpose, links, and contribution guidance. Generated files flow into this project in one direction, preventing a circular mirror from overwriting organization-specific content.
Reusable changes should be promoted to their engine owner. OSP-specific content changes should be made in the OpenOS-Project-OSP profile source and then published through the normal pipeline.