The Open Work System Specification

Home / The Open Work System / The Open Work System Specification

The Open Work System

Funding the work that builds everything.

Specification

The Open Work System is an AI-driven coordination, attribution, evaluation, and incentive system for open-source development. It establishes a unified framework for measuring meaningful work across projects, mapping contributions to canonical modules, preventing duplicate compensation, verifying project completion, and distributing pooled funding according to verified contribution value.

The system treats open-source development as an interconnected ecosystem rather than a collection of isolated repositories. Projects, modules, contributions, dependencies, contributors, and funding are represented as connected elements within a common system of attribution and value.

Core Principles

The Open Work System shall:

Treat meaningful open-source work as measurable economic value.
Allow funding to be pooled across many projects.
Allocate funding across projects, modules, and individual contributions.
Establish a global system for identifying canonical software modules.
Prevent equivalent work from being compensated repeatedly as though it were unique.
Preserve attribution for every accepted contribution.
Use AI to evaluate contribution value, originality, impact, and integration.
Maintain human oversight for consequential acceptance and payout decisions.
Make contribution valuation transparent and auditable.
Require projects to satisfy all defined completion criteria before reaching 100% completion.
Require completed projects to be functional, integrated, deployable, secure, and structurally adaptable.
Maintain a continuously evolving ecosystem graph of projects and their relationships.
Support multiple repositories, projects, funding sources, and contribution models.
Remain vendor neutral and designed for long-term ecosystem interoperability.

Core Modules

Global Incentive Pool System

The Global Incentive Pool System manages pooled funding committed to open-source development.

It shall:

Allow a funding pool to support one project or many projects.
Allow funders to define the total amount available for a development mission.
Support pools containing hundreds or thousands of projects.
Allocate funding dynamically according to project, module, and contribution value.
Track the remaining available balance of every pool.
Maintain a complete ledger of funding allocations and distributions.
Prevent allocations from exceeding available funding.
Support changes to funding allocations when project priorities or contribution values change.
Preserve historical funding decisions for auditability.
Separate committed funding from earned funding and distributed funding.

Project Mission & Structure System

The Project Mission & Structure System defines what a project is intended to accomplish.

Each project shall have:

A clearly defined mission.
A complete set of announced criteria.
A defined functional scope.
A collection of required modules.
Dependencies between modules where applicable.
Completion requirements.
Security requirements.
Integration requirements.
Deployment requirements.
Adaptability and future-proofing requirements.
A defined completion state.

The project mission shall be established before incentive distribution begins whenever practical.

The system shall preserve the original mission criteria so that completion cannot be redefined after work has been performed solely to manufacture a 100% completion state.

Canonical Module Registry

The Canonical Module Registry establishes the global library of unique and reusable software work.

It shall:

Define canonical modules independently of individual repositories.
Assign persistent identities to canonical modules.
Record the purpose and functional scope of each module.
Record relationships between modules.
Track multiple implementations of the same canonical capability.
Identify equivalent or substantially equivalent work.
Track dependencies between canonical modules.
Support versioning and evolution of modules.
Preserve historical module identities.
Prevent the same underlying work from being treated as multiple independent pieces of work solely because it appears in different repositories.
Allow an implementation to become the recognized canonical implementation when appropriate.
Distinguish genuinely novel work from alternate implementations of existing capabilities.

The registry shall function as the global reference system for determining whether a contribution represents new work, an improvement to existing work, or an implementation of an already recognized capability.

Contribution Ingestion System

The Contribution Ingestion System captures work submitted to participating projects.

It shall support:

Source-code contributions.
Documentation contributions.
Testing contributions.
Security contributions.
Architecture contributions.
Research contributions.
Design contributions.
Bug fixes.
Performance improvements.
Integration work.
Refactoring.
Maintenance work.
Module creation.
Module improvement.
Dependency improvements.
Other recognized forms of meaningful project work.

Every contribution shall be associated with its contributor, project, affected modules, relevant dependencies, submission time, and available provenance information.

AI Contribution Evaluation Engine

The AI Contribution Evaluation Engine evaluates submitted work against the project’s mission and the broader ecosystem.

It shall evaluate factors including:

Originality.
Functional significance.
Technical or architectural depth.
Difficulty.
Integration impact.
Security impact.
Reusability.
Ecosystem importance.
Dependency significance.
Improvement over existing implementations.
Contribution to project completion.
Relationship to existing canonical modules.
Confidence in the evaluation.

The evaluation engine shall produce structured contribution-value assessments rather than relying solely on subjective descriptions.

AI evaluations shall remain subject to validation mechanisms appropriate to the consequence of the decision. High-impact funding decisions shall support human review, challenge, correction, and appeal.

Duplication & Equivalence Detection System

The Duplication & Equivalence Detection System determines whether submitted work duplicates or substantially overlaps existing work.

It shall:

Compare contributions against the Canonical Module Registry.
Detect semantically equivalent implementations.
Detect substantially duplicated functionality.
Identify copied or derivative work.
Identify independent implementations of the same capability.
Distinguish legitimate improvements from redundant duplication.
Identify overlapping contributions across unrelated repositories.
Maintain evidence supporting equivalence determinations.
Allow disputed equivalence decisions to be reviewed.
Prevent duplicate compensation for the same underlying work.

Equivalent work shall not automatically receive the same reward as genuinely novel work.

Contribution Value Mapping System

The Contribution Value Mapping System converts evaluated work into measurable contribution value.

It shall map:

Contributors to contributions.
Contributions to modules.
Modules to projects.
Projects to missions.
Contributions to completion progress.
Contribution value to available funding.

The system shall support proportional attribution so that a project reaching 100% completion represents the fulfillment of the entire announced mission rather than an arbitrary accumulation of commits.

Contribution percentages shall reflect meaningful work and verified impact rather than raw commit counts.

Project Completion Engine

The Project Completion Engine determines whether a project has achieved its mission.

A project shall reach 100% completion only when it is:

A fully working program, application, database, or other defined software system.
Functionally complete according to all announced criteria.
Properly integrated.
Deployable from its defined source.
Free of unresolved critical dependencies required for operation.
Validated against defined security requirements.
Resilient against defined adversarial threats.
Tested under appropriate failure and stress conditions.
Structurally adaptable to future changes.
Fully resolved against the Canonical Module Registry.
Ready to operate as the system defined by its original mission.

The completion engine shall support weighted progress below 100%, but no project shall be declared complete solely because its weighted score reaches 100%.

Hard completion gates shall override percentage calculations.

Security & Verification Layer

The Security & Verification Layer validates whether project work is trustworthy and suitable for completion and reward.

It shall evaluate:

Known vulnerability classes.
Authentication and authorization weaknesses.
Input validation.
Data protection.
Dependency integrity.
Supply-chain risks.
Malicious module insertion.
Unsafe integrations.
Privilege escalation risks.
Injection risks.
Resource exhaustion.
Fault tolerance.
Failure handling.
Fuzzing and robustness results where applicable.
Stress and load behavior.
Build and deployment integrity.
Security regressions.

Security verification shall be continuous rather than limited to a single point in time.

The system shall not claim that a project is permanently immune to every future attack. Instead, future-proofing shall mean that the project is structured to support continued security assessment, replacement of vulnerable components, versioned interfaces, dependency updates, and architectural evolution.

Incentive Distribution Engine

The Incentive Distribution Engine converts verified contribution value into financial distributions.

It shall:

Calculate earned value for accepted work.
Allocate funding proportionally across projects.
Allocate project funding across modules.
Allocate module value across contributors.
Account for contribution overlap and duplication.
Respect project-specific funding rules.
Respect global pool constraints.
Record every distribution decision.
Prevent unauthorized or duplicate payouts.
Support pending, approved, disputed, and distributed states.
Preserve a permanent audit trail of incentive decisions.

Funding shall follow the conceptual flow:

Pool → Project → Module → Contribution

Anti-Duplication Reward System

The Anti-Duplication Reward System prevents the incentive system from rewarding the same underlying work multiple times.

It shall:

Link contributions to canonical work.
Detect duplicate implementations.
Detect equivalent work across projects.
Distinguish independent innovation from repeated implementation.
Credit improvements according to their incremental value.
Preserve attribution for contributors even when work is not independently rewardable.
Prevent duplicate full-value compensation for identical or equivalent work.
Support shared-value attribution where multiple contributors materially improve the same canonical module.

The system shall reward the creation of new value rather than the repetition of already compensated value.

Ecosystem Graph System

The Ecosystem Graph System represents relationships across the open-source ecosystem.

It shall connect:

Projects.
Contributors.
Canonical modules.
Implementations.
Dependencies.
Contributions.
Funding pools.
Missions.
Organizations.
Versions.
Integrations.
Completion states.

The graph shall allow the system to identify high-leverage modules, shared dependencies, ecosystem bottlenecks, redundant development, and opportunities for coordinated funding.

Reputation & Trust System

The Reputation & Trust System records verified contribution history.

It shall consider:

Accepted contributions.
Contribution quality.
Security history.
Review outcomes.
Successful project completion.
Accuracy of submitted work claims.
Contribution originality.
Dispute outcomes.
Maintainer and peer validation.
Long-term reliability.

Reputation shall be based on verified behavior and contribution history rather than popularity alone.

Transparency & Auditability Layer

The Transparency & Auditability Layer provides traceability for system decisions.

It shall maintain records of:

Funding commitments.
Funding allocations.
Contributions.
Contribution evaluations.
Canonical module mappings.
Duplication decisions.
Project completion progress.
Security verification.
Incentive calculations.
Distributions.
Reviews.
Disputes.
Corrections.
Governance decisions where applicable.

The system shall make the reasoning and evidence behind consequential decisions inspectable to the greatest extent possible without exposing protected information.

Multi-Repository Integration

The Multi-Repository Integration System allows the Open Work System to coordinate work distributed across different repositories.

It shall:

Associate repositories with projects.
Track contributions across repository boundaries.
Map repository implementations to canonical modules.
Detect equivalent work across repositories.
Aggregate project completion across multiple repositories.
Preserve contribution provenance.
Support forks and derivative projects.
Maintain relationships between upstream and downstream work.

A project’s contribution history shall not be fragmented merely because its work is distributed across multiple repositories.

Funding Flexibility Layer

The Funding Flexibility Layer supports multiple approaches to incentive allocation.

It shall support:

Equal project allocations.
Proportional project allocations.
Priority-weighted allocations.
Module-based allocations.
Contribution-based allocations.
Milestone funding.
Completion-based funding.
Performance-based funding.
Funder-defined allocation policies.
Hybrid funding models.

Funding policies shall be explicit, auditable, and enforceable by the incentive system.

Open Contribution Attribution Standard

The Open Contribution Attribution Standard establishes a common method for preserving contributor identity and contribution history.

It shall:

Identify contributors.
Identify their specific work.
Associate work with canonical modules.
Preserve contribution history across repositories.
Preserve attribution through forks and derivative works.
Preserve attribution when contributions are incorporated into larger projects.
Provide machine-readable contribution relationships where appropriate.
Support human-readable attribution.

Attribution shall remain distinct from financial reward. A contribution may deserve attribution even when it does not qualify for independent financial compensation.

Governance & Policy Layer

The Governance & Policy Layer provides optional mechanisms for ecosystem-level rules and oversight.

It may support:

Funding policy creation.
Evaluation policy creation.
Canonical module governance.
Dispute resolution.
Reviewer roles.
Appeal processes.
Policy versioning.
Rule changes.
Community participation.
Conflict-of-interest controls.
Governance transparency.

Governance mechanisms shall not be required for basic operation where project-level rules are sufficient.

Optional Plugin Modules

Optional plugins may extend the core system without changing the fundamental contribution, attribution, canonicalization, completion, and incentive model.

Funding Source Plugins

Funding Source Plugins may connect external funding sources and support:

Grants.
Donations.
Sponsorships.
Institutional funding.
Community funding.
Corporate funding.
Public funding programs.
Other compatible funding mechanisms.

Repository Integration Plugins

Repository Integration Plugins may connect additional source-control and project-hosting services.

They may provide:

Contribution synchronization.
Issue synchronization.
Pull request synchronization.
Review synchronization.
Repository metadata.
Release information.
Fork relationships.

Payment Plugins

Payment Plugins may connect approved payment systems for distribution of earned incentives.

They may support:

Contributor payment accounts.
Payment authorization.
Distribution processing.
Payment status.
Payment reconciliation.
Payment reporting.

Identity Plugins

Identity Plugins may provide optional identity and authentication integrations.

They may support:

Contributor identity verification.
Organization identity.
Account linking.
Credential verification.
Identity portability.

Review & Validation Plugins

Review & Validation Plugins may provide additional human or automated validation mechanisms.

They may support:

Maintainer review.
Peer review.
Security review.
Independent audits.
Specialized evaluation.
Evidence submission.
Dispute review.

Security Analysis Plugins

Security Analysis Plugins may extend security verification with additional analysis capabilities.

They may support:

Vulnerability analysis.
Dependency analysis.
Static analysis.
Dynamic analysis.
Fuzzing.
Threat modeling.
Supply-chain verification.
Security regression detection.

Analytics Plugins

Analytics Plugins may provide ecosystem analysis including:

Funding effectiveness.
Contribution trends.
Project progress.
Module demand.
Contributor activity.
Ecosystem bottlenecks.
Reward distribution.
Duplicate work detection metrics.

Governance Plugins

Governance Plugins may provide additional governance models for communities, organizations, funding pools, or ecosystems.

They may support:

Voting.
Delegation.
Proposal systems.
Reviewer selection.
Appeals.
Policy approval.
Community oversight.

External Knowledge Plugins

External Knowledge Plugins may provide additional public information used to evaluate project context, dependencies, standards, vulnerabilities, or ecosystem relationships.

External information shall remain attributable and traceable to its source.

Contribution Lifecycle

The system shall treat meaningful work as a lifecycle rather than a single event.

A contribution may progress through states including:

Submitted.
Ingested.
Evaluated.
Canonically mapped.
Reviewed.
Accepted.
Valued.
Allocated.
Distributed.
Disputed.
Corrected.

Each state transition shall preserve relevant evidence and attribution.

Canonical Work Lifecycle

Canonical modules may progress through states including:

Proposed.
Evaluated.
Registered.
Implemented.
Improved.
Superseded.
Deprecated.
Archived.

Canonical identity shall remain stable even when implementations evolve.

Project Completion Model

Project completion shall distinguish between progress and mission accomplishment.

A project may accumulate measurable contribution value while remaining below 100% completion.

The final completion state shall require satisfaction of every mandatory mission criterion and every applicable hard gate.

A project shall not receive a 100% completion designation because:

A sufficient number of commits exist.
A funding threshold has been reached.
A weighted contribution score reaches 100%.
AI predicts that the project is complete.
A maintainer declares completion without satisfying the defined criteria.

The project must satisfy the actual mission.

Security and Future-Proofing Requirements

Future-proofing shall be treated as architectural adaptability rather than a claim of permanent technological immunity.

A future-proof project shall provide, where applicable:

Modular components.
Replaceable dependencies.
Versioned interfaces.
Versioned data schemas.
Upgrade paths.
Migration paths.
Dependency isolation.
Configurable policies.
Avoidance of brittle assumptions.
Continued security evaluation.
Mechanisms for replacing obsolete components.

The system shall continuously reassess whether completed projects remain viable as their environments change.

Specification Branding License (SBL)

Standard

Fully AGPL-3.0+ compliant system
Copyleft enforced for network deployments
Required attribution:
- Roxanne Ardary
- https://www.roxanneardary.com/

Optional

Specification Branding License (SBL)
- Attribution-free commercial deployment
- Pricing based on scale, usage, and deployment scope
- https://roxanneardary.com/the-open-work-system/

License & Notice Requirements

The Open Work System is released under the GNU Affero General Public License v3.0 or later (AGPL-3.0+).
By contributing to any Open Arsenal project, you agree that your contributions will also be released under this license.

Please note the following:

All contributions must comply with the AGPL-3.0+ terms.
Under Section 7 of the license, all redistributions, forks, and derivative works must preserve attribution to:
Roxanne Ardary and roxanneardary.com.
The Open Work System specifications are free to use with attribution. A Specification Branding License can be negotiated upon request.
The project’s notice.md file tracks attribution requirements and contributor acknowledgments.
Any update that adds new contributors or modifies attribution should also update notice.md.
When submitting a pull request, ensure that any new files maintain the attribution headers where applicable.
Network-deployed versions of this software must also remain fully AGPL-3.0+ compliant, including exposure of source code modifications when applicable under the license.

For full legal details, please refer to the AGPL-3.0+ license and the project’s notice.md file.

Notice – The Open Work System

Attribution Requirement: Under Section 7 of the AGPL 3.0+ license, all redistributions, forks, and derivative works, including network-deployed versions of this project, must provide attribution to Roxanne Ardary and roxanneardary.com.

Contributors

This file tracks contributors and their specific contributions to the project.

Roxanne Ardary, roxanneardary.com – May 24, 2026
Created the repository for The Open Work System. Defined the foundational architecture for an AI-driven open-source contribution valuation and incentive system.
[Add other contributors here] – [Date]
[Describe contribution in one sentence]

License – The Open Work System

This repository is licensed under the GNU Affero General Public License v3.0 or later (AGPL-3.0+).

Key Points:

You are free to use, modify, and distribute the code.
All redistributions, forks, and derivative works or network-deployed versions must also be licensed under AGPL-3.0+ and provide attribution to Roxanne Ardary and roxanneardary.com as required under Section 7 of the license.
The software is provided “as is,” without warranty of any kind.

For the full license text, see GNU AGPL-3.0 License.