Contributing

The project is in a foundation stage. A strong contribution may be a corrected assumption, a real workflow, a privacy requirement, a schema example, an accessibility review, a clearer explanation, or a small publishing improvement. It does not need to be a large feature.

Before you begin

Read:

• README.md for the current status and repository map;
• VISION.md for intended outcomes and non-goals;
• ROADMAP.md for current scope;
• GOVERNANCE.md for decisions and roles;
• standards/README.md for standard changes; and
• CODE_OF_CONDUCT.md for participation expectations.

Please open an issue before investing in a large implementation, new module, breaking schema change, governance change, or new external integration.

Useful contributions now

• Validate an operator or founder workflow with non-confidential evidence.
• Turn an unresolved assumption into a precise design question or RFC.
• Propose minimum fields, ownership, consent, or provenance semantics for the data standard.
• Add valid, invalid, and migration examples.
• Review privacy, security, accessibility, multilingual, or low-bandwidth requirements.
• Improve the public site, navigation, metadata, link integrity, or visual explainers.
• Improve contribution automation and documentation checks.
• Identify unsupported claims, stale facts, or places where a scenario is presented as an observed result.

The complete seven-module application is not a suitable first pull request.

Ways to contribute

Report a problem

Use the bug-report issue form for broken links, publishing defects, documentation errors, or reproducible code problems. Do not report vulnerabilities or accidental data exposure in a public issue; follow SECURITY.md.

Propose an improvement

Use the feature-request form. Explain the participant need before the proposed implementation and identify which roadmap stage it belongs to.

Change the data standard

Follow the RFC expectations in GOVERNANCE.md and standards/README.md. Schema convenience for one product is not enough: the change should be understandable to an independent implementation.

Contribute code or content

1. Fork the repository.
2. Create a focused branch.
3. Make the smallest coherent change.
4. Run the checks relevant to the files you changed.
5. Open a pull request using the template.

Keep unrelated cleanup out of the same pull request.

Evidence and status language

This repository must distinguish among:

• an observed fact with a source;
• an experience or prototype described by its author;
• a scenario or estimate based on assumptions;
• a proposed requirement;
• a planned implementation; and
• functionality that is present and verified in this repository.

Do not say that OIS is deployed, certified, nationally adopted, independently governed, or production-ready unless the repository contains current, verifiable evidence for that exact claim.

For statistics, policies, laws, program names, or current institutional facts, link to a primary source and include the date observed. Economic-value figures must keep their assumptions and scenario framing.

Privacy and source safety

Never commit:

• personal data from founders, mentors, applicants, staff, or visitors;
• credentials, private keys, access tokens, cookies, or local environment files;
• confidential institutional documents or screenshots;
• production database exports;
• raw social-platform captures; or
• content you do not have the right to license.

Use invented or irreversibly anonymised examples. Removing a name is not enough if a person or company remains identifiable from context.

If sensitive material is committed accidentally, stop and report it privately through SECURITY.md. Deleting it in a later commit does not remove it from history.

Content and accessibility

• Use descriptive headings and concise paragraphs.
• Give images meaningful alt text; do not encode essential information only in an image.
• Use semantic filenames instead of generator-export names.
• Preserve source attribution and licence information.
• Prefer plain language before project-specific terminology.
• Check links and heading structure.
• Do not copy the text of external articles merely because they are publicly viewable; link to the authorised publication.

Raw local research drafts and source captures are intentionally ignored. The public VISION.md, ROADMAP.md, standards/, and docs/ files are the synthesised contribution surfaces.

Code quality

Follow the commands documented by the component you change. At minimum:

• format changed files;
• run available lint and type checks;
• run targeted tests;
• build affected publishing output; and
• verify changed links and generated metadata.

Tests should cover behaviour and trust boundaries, not only snapshots. Changes to identity, tenancy, permissions, retention, exports, or conformance require negative tests as well as happy paths.

AI-assisted contributions

AI assistance is welcome, but the contributor remains accountable for every line submitted.

• Review generated changes in full.
• Verify claims against cited sources.
• Do not put confidential inputs into third-party models without authority.
• Preserve uncertainty instead of allowing a model to fill gaps.
• Test generated code and examples.
• Mention material AI assistance in the pull request when it helps reviewers understand provenance or risk.

See AGENTS.md for repository-specific agent instructions.

Licensing

By submitting a contribution, you represent that you have the right to submit it and agree that:

• code, scripts, configuration, reference schemas, and test code are licensed under MIT; and
• original documentation, specification prose, articles, diagrams, and visual content are licensed under CC-BY-4.0,

unless a file is clearly marked with another compatible licence accepted by the maintainers.

See LICENSE and LICENSE-CONTENT.md. There is no separate contributor licence agreement at this time.

Pull-request checklist

Before requesting review, confirm that:

• the change belongs to the current roadmap stage or has an approved issue;
• proposal, prototype, and implemented status are clearly distinguished;
• no secrets, personal data, or unlicensed material are included;
• compatibility and migration effects are documented;
• privacy, security, and accessibility effects are addressed;
• relevant tests and checks pass; and
• documentation and examples match the change.