Discussion: Civil-society sector adoption of OKF — open questions on federation, assurance, and organizational knowledge

**Context:** Civil-society organizations maintain two kinds of knowledge: organizational services (who provides what, where, for whom, when) and donated/discounted offerings (what resources are available to nonprofits). Today, this knowledge lives in scattered systems — directories, spreadsheets, databases — that organizations don't own or control.

We believe organizations should own their knowledge in a portable, maintainable format. OKF provides a foundation for that. Core OKF, by design minimal, doesn't address what the nonprofit sector consistently needs. We're proposing [x-civic](https://github.com/TechSoup/okf-civic-sample) — an extension profile.

**What civil society needs that core OKF leaves open:**
- **Eligibility rules** — who can access a service or offer (organization type, region, income, demographics).
- **Lifecycle & operational status** — distinct concepts. A knowledge record can be `ACTIVE` (current/valid) while operationally `comingSoon` or `seasonal` (real-world state).
- **Relationships as capabilities** — not just links, but typed relationships. Two services with the same capability are *alternatives*; two tools with different capabilities are *complements*. The type matters for matching and discovery.
- **Provenance at scale** — when multiple organizations maintain data, you need to know: last verified date, source, who owns it. Essential for distributed trust.

**What okf-civic-sample demonstrates:**
The extension works across the two domains (organizational services and offers). Both use the same profile; both are maintainable by organizations; both feed agents and discovery systems.

**Three open questions we're thinking about:**

1. **Federation & discovery.** If organizations own and maintain their own bundles, how do those bundles surface to each other and to the public? Multiple registries and discovery models may be possible — that's an opportunity, not a problem. But it's unsolved.

*Why it matters:* Decentralized ownership gives organizations control and resilience; but they also need visibility into the broader sector ecosystem.

2. **Assurance & freshness.** Distributed data ownership raises hard questions about trust verification at scale. Our civic profile includes `provenance` and `operational_status`, but they're not sufficient alone. This is a sector-wide challenge (centralized systems have it too), but it's real.

*Why it matters:* Organizations and the people they serve need to trust the data. How do we verify at scale without reverting to centralization?

3. **What becomes possible?** We don't know yet what innovation agents or vendors will build when they can read structured, federated knowledge about the sector. That's the point — standards open possibility.

**A specific extension to explore:** Lightweight conventions around **legal personality** — capturing the regulatory designation of the entity (e.g., 501(c)(3), 501(c)(5)), who owns the data, and jurisdictional context. This anchors accountability as adoption scales.

**Our ask:** We're publishing okf-civic-sample and the x-civic profile as a contribution to how OKF evolves for sector use. We'd like feedback from the OKF community: Do these extensions make sense? Are others exploring federation, distributed trust, and adoption barriers in civil society or adjacent domains? How should legal personality be defined?

Start by reviewing the linked okf-civic-sample and x-civic profile, then separate the federation, assurance, and legal-personality questions. Done is not defined in the issue; the community would first need to turn these open questions into a scoped change.

Written by the indexing model from the issue text.