Skip to content

value stakeholders milestones

Jump to bottom
Dan Connolly edited this page Jul 19, 2026 · 4 revisions

Milestones (with OCap Architecture)

This is a draft of milestones for the Oros Governance Engine, structured around the Endo object-capability architecture. When the milestone structure stabilizes, each section should become a GitHub milestone; each story and design issue link should become a GitHub issue with the appropriate label.

Value has many forms

Code contributions mint CONTRIB tokens with a known spec. Financial contributions will be denominated differently — and dollars come with more or fewer constraints (restricted grants, PRIs, equity). The governance system must handle multiple value types, not a single fungible pool.

This means every milestone has economic consequences:

  • Sprint 0 minting rules ("1 CONTRIB per merged PR") are a bootstrap convention, not final policy — but they're already creating liabilities.
  • M1 escrows real value when a task is posted.
  • M2 delegation and revocation control who can authorize payouts.
  • M3 the trust graph affects who can approve value flow.
  • M4 meta-governance sets monetary policy: minting rules, exchange rates, treasury backing, cash-out terms.
  • M5 (out of scope) patient data-access capabilities are consistent with the architecture but are not implemented in this project.

The capability model gives structural safety: every operation exposed by the governance API follows a stated contract enforced by the program itself. The API provides no application-level admin override. Deployment administrators may retain out-of-band powers; these must be minimized, audited, and treated as part of the trusted computing base.

Stakeholders

A major goal of this project is to let diverse stakeholders participate in the same governance ecosystem — patients, providers, developers, community builders, researchers, funders, and more — even though each wants different rights and protections:

  • Patients want privacy and agency — control over who accesses their data, assurance that the system serves their health, not just research.
  • Providers want to provide better care — knowing which of N conditions to focus on in a short visit, collaborate effectively with research institutions — and get paid: efficiently supplying the data that payors require.
  • Developers want clear contribution paths — know what to build, get paid for it, and see their work used.
  • Community builders want to grow the ecosystem — run events, publish newsletters, celebrate contributor milestones, welcome newcomers, champion the project's brand and mission.
  • Researchers want access to data — clear protocols for data use, attribution for their analysis work, transparency about methodology.
  • Funders (VCs, foundations, government grants) each want different returns — ROI, mission alignment, or public health outcomes. Each dollar comes with its own constraints (restricted grant, program-related investment, equity); the governance system must track what strings are attached.

Following the architecture's facet pattern, each stakeholder gets a facet tailored to their relationship:

  • A developer holds a claimBounty() capability and a submitPR() capability — but no approveGrantCycle() capability.
  • A provider holds a verifyDataQuality() capability and a reportBug() capability — but no voteOnPriorities() capability.
  • A patient holds a consentToDataUse() capability and a revokeConsent() capability — but no mergePR() capability.
  • A foundation holds a voteOnPriorities() capability — but no withdraw() capability.
  • A VC holds a preferredDistribution() capability — but no approveGrantCycle() capability.
  • A government grant holds an auditAttributionLog() capability and a verifyHealthOutcomes() capability — but no voteOnPriorities() capability.
  • A community builder holds a stewardRole() capability that composes many of the above.

The design challenge is specifying the facet matrix — mapping each stakeholder role to the capabilities they need — and ensuring the composition is correct: distributions might require both VC approval (for return) and foundation approval (for mission alignment), for example.

Governance activities

These are the things the system must enable. Milestones are organized around which activities become practical for real community members, in what order.

  1. Fund work — "This CKM data task is worth 5 CONTRIB, who wants it?"
  2. Do work — "I'll claim that task" → complete it → attribution happens
  3. Evaluate work — "This deliverable meets spec, release the payment"
  4. Delegate authority — "You handle the CKM domain, I trust your judgment"
  5. Pull back authority — "That domain needs new leadership"
  6. Vouch for someone — "I've worked with Sam, they know what they're doing"
  7. See the state of things — "Who's in charge, what's been done, where's the money?"
  8. Set and oversee the rules — "How do we decide what CONTRIB is worth, who qualifies as a steward, what quality standards apply, how to add new roles?"
  9. Build the community — "Let's run a hackathon, publish a newsletter, celebrate a contributor milestone, welcome new people."
  10. Access and protect data — Out of scope for this project; consistent with the architecture. "Can I use this dataset for my research?" "Has my consent been respected?"

TODO: Make the bottom-up build order explicit

  • Map every milestone to its persistence, capability/value, audit, and UI layer dependencies.
  • Schedule the transition from the flat-file fallback to the pet daemon formula graph.
  • Specify where full Endo ERTP purses and mints become prerequisites for real escrow and treasury operations.
  • Schedule Horton interposition before milestones depend on attributed delegation chains.
  • Schedule the governance state view and other UI needed to exercise each slice top-down.

Sprint 0: First Attribution (2 weeks)

Activity: #2. Existing story: code-merge-attribution. Bootstrap minting convention ("1 CONTRIB per merged PR") is provisional.

Target: 2 weeks Consumers: Lead steward (bootstrap principal) Producers: Dev team, including Principal Architect

  • story/issue-14-award-a-contrib-nft-for-a-merged-pr (GH #14)

    The governance decision happens on GitHub: a PR is reviewed, approved by a maintainer, and merged. The NFT adds attribution that GitHub doesn't provide — quantified value recorded in a double-entry ledger.

    AT: A merged PR in vattr97 triggers a script that records a CONTRIB attribution in the GnuCash ledger, with idempotent re-runs.

    Note: "1 CONTRIB per merged PR" is a bootstrap convention chosen by the lead steward, not a final policy. The mint capability is held by the script; M4 will govern who holds it and under what rules.

M1: Full Work Cycle (Month 2–3)

Activities: #1, #3, #2 again. Someone posts a task with a CONTRIB reward (taken from escrow), someone completes it, someone approves it, attribution fires. CONTRIB value makes the escrow real — posting a task commits real resources. This exercises the architecture's ERTP value layer.

M2: Multiple Stewards (Month 4–6)

Activities: #4, #5, #7. A lead steward appoints domain stewards, they appoint reviewers. Delegation controls who can authorize payouts; revocation is an economic control. The state view shows authority and balances. Revocation uses the architecture's CareTaker pattern, and attributed delegation chains use its Horton audit layer.

M3: Trust & Community (Month 7–10)

Activities: #6, #9. Peer endorsements, events, contributor spotlights. The trust graph affects who can approve value flow — vouching has financial consequences.

M4: Meta-Governance (Month 11–14)

Activity: #8. Monetary policy: who holds the mint capability, under what rules, what determines exchange rate, how the treasury backs CONTRIB with real money, who can cash out and under what terms. Also: who qualifies as steward, how domains are added, how the rules themselves change.

M5: Data Access & Consent — Out of scope for this project

Activity: #10. Patient consent capabilities, researcher data-use protocols, privacy-scoped audit. These capabilities are consistent with the architecture's facet, revocation, and audit patterns but are not implemented in this project.

Navigation

Clone this wiki locally