Governance

Current governance state

The project documents a long-term aspiration for representative, multi-stakeholder stewardship. An independent or neutral steward does not yet exist, and this repository must not imply otherwise.

Goals

The governance model should:

• make current authority visible;
• keep decisions and their reasoning public where safety permits;
• allow reversible experimentation without unnecessary ceremony;
• give standards changes more scrutiny than editorial changes;
• protect founders and institutions from commercial or political capture;
• separate interoperability rules from any one hosted product; and
• evolve as contributors and adopters earn durable responsibility.

Roles

Maintainers

The current founding maintainers and vision co-developers are:

• Jeremy Fritzhand (@fritzhand)
• Krish Chittmalla (@krshh)

Maintainers can merge pull requests, manage releases, moderate project spaces, and resolve decisions that do not reach consensus. They are responsible for security triage, licensing consistency, truthful status language, and protecting compatibility commitments.

Maintainer status is earned through sustained, constructive contribution and demonstrated judgment. New maintainers are appointed publicly by existing maintainers, with the reason recorded in an issue or pull request.

Contributors

Anyone who submits a useful issue, review, design, standard proposal, research note, code change, translation, or documentation improvement is a contributor. Contribution does not require organisational affiliation.

Working groups

Maintainers may charter time-bounded working groups for areas such as the data standard, privacy, accessibility, operator workflows, or conformance. A charter must name its scope, facilitator, expected output, decision authority, and end condition. Working groups advise unless authority is explicitly delegated.

Adopters and affected participants

Founders, operators, mentors, institutions, implementers, and public bodies may participate in design and review without becoming code contributors. For standards and governance decisions, evidence from affected participants should carry more weight than implementation convenience alone.

Decision process

Routine and reversible changes

Documentation corrections, publishing improvements, tests, and compatible implementation changes use pull-request review. Maintainers seek lazy consensus: if objections are addressed and no unresolved material concern remains, a maintainer may merge.

Significant implementation decisions

Changes to security boundaries, identity, tenancy, data retention, deployment, module contracts, or compatibility should include:

1. the problem and affected users;
2. alternatives considered;
3. privacy, security, accessibility, and migration impact;
4. how the decision will be tested; and
5. rollback or revision conditions.

Material architecture decisions should be recorded as an ADR or linked design document.

Standard changes

A change to the Innovation Hub Data Standard requires a public RFC before it can become normative. The RFC must include:

• the use case and stakeholder evidence;
• schema or semantic changes;
• ownership, consent, visibility, and retention effects;
• backward-compatibility and migration treatment;
• valid and invalid examples;
• conformance-test changes; and
• any implementation-specific assumptions.

Until a standards council is established, maintainers make the final decision after public review and must record unresolved objections.

Governance and licensing changes

Governance, licence scope, trademark, or certification changes require a dedicated pull request, at least 14 days of public review, and explicit maintainer approval. Existing contributions cannot be relicensed retroactively without the rights required to do so.

Security-sensitive decisions

Vulnerabilities and accidental data exposure follow SECURITY.md privately. A public record may be added after remediation when disclosure is safe.

Resolving disagreement

Discussion should focus on user impact, evidence, compatibility, and the project principles—not seniority or affiliation.

If consensus is not possible:

1. summarise the disputed points and available evidence;
2. identify whether a smaller reversible experiment can answer them;
3. ask an unconflicted maintainer or relevant working group for review; and
4. have a maintainer record the decision, rationale, dissent, and revisit condition.

Maintainers may decline a change that conflicts with privacy, portability, licensing, or current project scope even if it is technically sound.

Conflicts of interest

Participants should disclose material interests in a decision, including paid implementation work, vendor relationships, procurement involvement, or control of a competing standard. Disclosure does not automatically exclude participation, but an unconflicted maintainer should make the final call where the conflict is significant.

Standards, certification, and trademarks

The data-standard work is preliminary. There is currently no official conformance release, certification mark, certified deployment, or authorised certification auditor.

Future rules must keep conformance available to independent implementations and must separate certification decisions from paid implementation sales. Until those rules exist, contributors and adopters may describe experiments as “based on” or “exploring” OIS, but not as officially certified.

Releases and compatibility

Maintainers approve releases. Published releases should identify:

• which artefacts are normative and which are exploratory;
• the applicable code and content licences;
• compatibility or migration implications;
• known security or privacy limitations; and
• the exact conformance-suite version, if one exists.

Draft documents may change without compatibility guarantees. Released standard versions must follow the versioning policy defined in standards/README.md.

Evolution of governance

Governance should broaden when there is evidence to support it, such as:

• sustained contributions from multiple unaffiliated organisations;
• real adopters affected by standards decisions;
• independent conforming implementations;
• stable funding for public maintenance; and
• a clear mechanism for participant representation and recusal.

A future transition may create a representative council or independent legal steward. The transition must be proposed publicly, define authority and asset ownership, protect existing licences, and avoid giving one vendor automatic control.

Conduct and enforcement

Participation is governed by CODE_OF_CONDUCT.md. Maintainers may moderate or restrict participation to protect contributors and the project. Security reports, conduct reports, and personal information must not be posted publicly.