open org standard · v0.1 working draft

Own your truth.
Share it on your terms.

Open Org is a data standard for self-sovereign organisational profiles, published ideas, living strategies, and transparent access control — designed for a world where organisations own their own story and funders discover rather than gatekeep.

Read the schema Get involved

Version 0.1 — Working Draft · Licence: CC BY-SA 4.0


what it is

Your organisation is more than an application form

The grant application was a technology for a pre-digital information environment. LLMs broke the filter it relied on. We need something different.

Open Org lets organisations maintain a living, structured, machine-readable profile of themselves — not written for any specific funder, but maintained for their own purposes. Funders become discoverers, not gatekeepers. The application form disappears. In its place: self-sovereign profiles, published ideas, and transparent relationships between resource and purpose.

Self-sovereign

Organisations own and host their profiles. No central platform decides who's visible.

Living

Profiles update continuously, fed by existing systems. Evidence accumulates. Ideas evolve.

Tiered access

Organisations control what's visible and to whom. Access is logged, time-limited, and revocable.

Federated

No central platform. Profiles communicate via open protocols. The organisation is its own node.

Interoperable

Builds on existing standards — org-id.guide, ONS codes, Open Referral, 360Giving, Hypercerts.

Ideas-first

Organisations publish what they want to do before being asked. Ideas are visible, connectable, and persistent.


schema

Four objects, one vocabulary

The standard defines four core object types. Each has a minimum viable shape — the smallest set of fields that makes the object actually useful, not just technically valid. The schema is loose so no one is locked out; the tooling guides every object toward the minimum that works. See the minimums for each ↓

open-org/
├── org-profile.schema.json core — The living organisational profile
├── org-strategy.schema.json core — Strategy as a first-class object
├── org-idea.schema.json core — Published ideas — seeds of intent
├── org-access-grant.schema.json core — Permissions, scoping, and audit
├── murmurations-integration.md — Discovery layer mapping
├── system-architecture.md — Agent, interfaces, data governance
└── vocabulary/themes.json — 30 canonical thematic tags

Profile

Identity, mission, evidence, governance, culture, services. The living representation of an organisation — who they are, what they've done, how they work.

org-profile/v0.1

Strategy

Priorities, tensions, learning, relationships, resource model. How the organisation thinks about its future — and what it's chosen not to do.

org-strategy/v0.1

Idea

Seeds of intent — themed, placed, loosely costed, linked to evidence and to other organisations' ideas. Published before anyone asks.

org-idea/v0.1

Access grant

Who can see what, when it expires, and a full audit trail. No indefinite access. The organisation always sees who's looking.

org-access-grant/v0.1

architecture

Tiered integrations, nothing rebuilt

Open Org doesn't replace existing infrastructure. It sits in the middle of a stack, adding the things no one else covers — and connecting to the things others have already built. Two of those connections are load-bearing — the system is weaker without them. The other two are enhancements: valuable, designed-for, but not required to ship.

coreload-bearing — design for these from day one
Murmurations discovery · composable schemas · distributed index
required
Open Org profiles · strategies · ideas · access · the hidden knowledge
this standard
Hypercerts evidence · verification · activity claims · funding receipts
required
futurecompatible by design — not required to ship
.context knowledge packaging · provenance · AI orientation
enhancement
Mozilla Data Collective collective data governance · ethical AI training
enhancement
Design principle: Design the data model first. Treat federation as a transport layer. Murmurations gives discovery without a platform; Hypercerts gives verifiable evidence without inventing an attestation layer. Without those two, Open Org can't do its job. .context and MDC make the system smarter and more sustainable — they earn their place by adding value, not by gatekeeping it.

the local agent

It pulls, it assembles, it federates

The agent runs on or for each organisation. It connects to existing systems via MCP servers and APIs, structures data with LLM assistance, proposes drafts for human review, and federates the published profile across the network. It never publishes without human approval.

Pulls from what exists

CRM, documents, finance, regulatory data. The agent connects to what the organisation already uses. No new systems to maintain.

Enriches from public data

Charity Commission, Companies House, llms.txt profiles. Baseline identity auto-populated without manual input.

Structures with AI

A strategy PDF becomes structured priorities and themes. Board minutes update governance. The agent proposes — humans decide.

Handles access

Funder requests arrive, route to the management interface, and are granted or denied with full audit logging.

Self-hosted

Full control. Own infrastructure. For organisations with technical capacity.

Managed

A trusted provider runs it. The organisation controls the data. The default for most.

Shared

An infrastructure body runs agents for multiple organisations. The equity solution.


strategy as connective tissue

What funders never see — and should

Almost every organisation has a strategy. Funders almost never ask for it. But strategy reveals how an organisation thinks. What trade-offs it's made. What it's decided not to do. How it sees the next three to five years.

Priorities

Ordered strategic priorities with themes, outcomes, dependencies, evidence links, and maturity level.

Not doing

What was considered and rejected — and why. Often more revealing than what they will do.

Tensions

Growth vs depth. Earned income vs mission. Organisations that name their tensions are usually managing them well.

Learning

What failed. What changed. How the organisation responds when things go wrong. The opposite of what applications reward.

Relationships

Who trusts them. Who they trust. Ecosystem position. Community mandate. The social capital that never makes it into a form.

Strategy matching

Structured themes enable cross-org alignment detection. Funders see ecosystems, not individual bids.

The sweet spot: Relational enough to centre human dialogue and trust. Structured enough that discoverability doesn't depend on privilege. The playing field doesn't level itself. You have to build the level into the system.

positioning

Between relational and transactional

Purely relational funding risks reverting to the boys' club — privilege decides who gets the relationships. Traditional applications created an LLM arms race. Open Org sits in between: structured discovery that makes the room possible for everyone.

Purely relational

↑ risk: privilege decides

Trust grows in rooms most organisations never get into. The boys' club reverts.

Open Org structured discovery
that makes the room possible

Traditional applications

↓ risk: LLM arms race

Forms are filled by the best generators, not the best organisations. The filter breaks.


status and roadmap

Where things stand

Version 0.1 — Working Draft

The schema is defined. The architecture is mapped. The integrations are identified. What comes next: define the schema with input from organisations and funders. Build a reference agent. Test it with real relationships.

phase 1

Prove the concept

Static profile generator. Manual strategy and idea creation. Submit to Murmurations. Basic funder search.

phase 2

Add the agent

MCP integrations. LLM-assisted structuring. Management interface. Access request flow.

phase 3

Add the matching

Strategy matcher. Cluster detection. Idea connections. Funder profiles and mutual visibility.

phase 4

Federation and verification

ActivityPub. Hypercerts integration. Funding receipts. Full audit trail.


getting started

Minimum viable for each object

Each of the four objects has its own minimum viable shape — the smallest set of fields that makes it actually useful, not just technically valid. The schema validates loosely so no one is locked out; the tooling and documentation guide every object toward the minimum that works.

Profile

5 human-meaningful fields

The agent generates the metadata (schema_version, updated) automatically. The human-meaningful minimum viable profile is five fields — making the org discoverable by place and theme and verifiable against a public register. From a charity number alone, the agent can auto-populate four of the five.

technically valid

2 fields

Just identity.name and mission.summary. The schema accepts it. But you can't be found by place, matched by theme, or verified. A business card without a phone number.

minimum viable

5 fields

Name, registration, geography, mission summary, at least one theme. Now the system can do its job.

{
  "schema_version": "open-org/v0.1",
  "updated": "2026-05-10T10:00:00Z",
  "identity": {
    "name": "Riverside Community Trust",
    "registration": {
      "charity_commission_ew": "1234567"
    },
    "geography": {
      "primary_area": "North Norfolk",
      "primary_area_code": "E07000148"
    }
  },
  "mission": {
    "summary": "Supporting isolated older people to build social connections.",
    "themes": ["older-people", "social-isolation"]
  }
}

Strategy

human-meaningful · auto-bound to org

Beyond the auto-generated metadata, the human contributes a title, summary, period, at least one priority (themed), and at least one tension. A strategy with priorities only is just an application form by another name. Tensions — what the organisation is actively navigating — are the differentiator. Without them, you don't have strategy; you have an aspiration list.

{
  "schema_version": "open-org-strategy/v0.1",
  "id": "strategy-2026-2029",
  "org": { "id": "GB-CHC-1234567", "name": "Riverside Community Trust" },
  "published": "2026-05-10T10:00:00Z",
  "status": "active",
  "title": "Reaching further, going deeper · 2026–2029",
  "summary": "Move from centre-based services to outreach, while keeping relationships at the heart of how we work.",
  "period": { "start": "2026-04-01", "end": "2029-03-31", "horizon": "3_5_years" },
  "themes": ["social-isolation", "older-people"],
  "priorities": [
    {
      "id": "p1",
      "title": "Reach the most isolated",
      "description": "Move from drop-in centres to outreach in homes.",
      "themes": ["social-isolation"]
    }
  ],
  "tensions": [
    {
      "description": "Growth vs depth — more people reached, less time per person.",
      "approach": "Cap each volunteer's caseload at six. Refuse contracts that require higher throughput."
    }
  ]
}

Idea

human-meaningful · auto-bound to org

Beyond the auto-generated metadata, the human contributes title, summary, themes, place, and status. An idea without place can't be matched to local funders. An idea without status (seed · developing · ready · funded) can't be matched to readiness. These two fields are what turn a published thought into a connection point.

{
  "schema_version": "open-org-idea/v0.1",
  "id": "idea-befriending-pilot",
  "org": { "id": "GB-CHC-1234567", "name": "Riverside Community Trust" },
  "published": "2026-05-10T10:00:00Z",
  "status": "developing",  // seed · developing · ready · funded · archived
  "title": "Retired-volunteer befriending pilot",
  "summary": "Pilot a befriending scheme run by recently retired volunteers, matched to isolated older people in North Norfolk.",
  "themes": ["social-isolation", "older-people"],
  "place": {
    "description": "North Norfolk",
    "area_codes": ["E07000148"]
  }
}

Access Grant

request-and-decision record

A grant has two organisations (granter and requester) and a person inside the granter who authorised it (granted_by). When status becomes granted, the schema requires decided_at, expires_at and granted_by. An access grant without expiry is indefinite access — which the standard rejects. The audit trail is what makes this a grant rather than a permission.

{
  "schema_version": "open-org-access/v0.1",
  "id": "grant-2026-05-10-ncf",
  "granter": { "id": "GB-CHC-1234567", "name": "Riverside Community Trust" },
  "requester": {
    "id": "GB-COH-09876543",
    "name": "Norfolk Community Foundation",
    "type": "funder"
  },
  "requested_at": "2026-05-09T14:00:00Z",
  "decided_at": "2026-05-10T10:00:00Z",
  "expires_at": "2026-08-10T10:00:00Z",
  "status": "granted",
  "purpose": "Reviewing alignment with our older-people funding programme.",
  "granted_by": { "name": "Anita Brooks", "role": "director" },
  "scope": {
    "profile_sections": ["identity", "mission", "strategies", "ideas"],
    "include_narratives": false
  }
}

Across all four objects, the principle is the same: technically valid is not the same as useful. The schema is forgiving so no one is locked out; the minimum viable is what makes the system actually do its job.