ORCHORDS Public Documentation

⭐ If you like this documentation or find it useful, please consider starring this repository. It helps more people discover the project.

Interested in sponsoring ORCHORDS? Sponsorships start at US$1,000. Depending on the sponsorship level, sponsors may receive public recognition, logo and website placement, sponsor updates and early previews, roadmap-feedback briefings, priority issue triage, and engineering or integration discussions. Sponsorship does not buy control of the roadmap or guarantee feature implementation. Contact crm@orchords.com.

Independent software studio founded in 2025.

This repository publishes ORCHORDS company-wide documentation — currently 13,189 Markdown files covering governance, security, privacy, engineering, compliance, standards, reusable technical knowledge, and related policy areas. It is useful for customers and partners conducting due diligence, engineers and researchers comparing public policy practices, and anyone evaluating how a small independent studio documents security and governance expectations.

Start here

If you need…	Start with
Security posture and reporting	Security Policy
Engineering expectations	Engineering Standards
How decisions and policies are structured	Governance · Policy Hierarchy
Customer/due-diligence material	Customer Trust — assurance package, shared-responsibility guidance
Which standards and versions are referenced	Standards Register
How documents are controlled and reviewed	Document Control

How to read this repository

These documents describe public policy expectations, not certifications or verified implementations. Nothing here is evidence that a control is certified, audited, or implemented.

Every controlled document carries YAML front matter:

• status — approved, review, draft, or deprecated;
• last-reviewed / next-review / review-cycle — when it was last checked and when it is due again (typically 90 days).

Normative meaning follows RFC-style normative language and restricted assurance terms are governed by Public Assurance Terminology.

Evidence and sources

Factual and standards-based content follows the Citation Source Policy: primary authoritative sources are preferred, secondary sources are non-normative, drafts are labeled as drafts (Framework Status Policy), and the versioned Standards Register records which edition each claim tracks.

Documentation map

The established controlled-document collection remains under docs/policies/, with 42 subject categories spanning:

• Trust & assurance — security, privacy, compliance, customer-trust, accessibility
• Governance & corporate — governance, legal, ethics, finance, tax, treasury, internal-audit, records
• Building & operating — engineering, data, AI, product, operations, resilience, quality, project-delivery, releases
• Organization — people, workplace-safety, human-rights, communications, marketing, knowledge, strategy, research
• Commercial & partners — commercial, partnerships, procurement, third-party, customer-success, support, corporate-development
• Working artifacts — standards, SOPs, templates

Reusable project-neutral knowledge is organized under docs/knowledge/, grouped into domain families.

Tip: for a repository this size, use GitHub's file finder (t) or code search to jump directly to a document.

Public-repository boundary

This repository must not expose product-specific implementation details, deployment topology, credentials, private endpoints, customer information, internal identifiers, banking details, tax identifiers or filings, treasury balances, facility-security details, personal medical information, worker grievance identities, active transaction details, or unannounced work.

Public documentation may describe principles, responsibilities, controls, decision criteria, and repeatable procedures. It must not create false assurance or present planned controls as implemented.

Bulk or externally sourced knowledge is accepted only after project-neutral sanitization, sensitive-data screening, duplicate and collision checks, relative-link validation, manifest/file-count verification, and cryptographic checksum verification. The reusable-knowledge migration validated 8,006 source Markdown files before publication. Six previously reviewed articles remain the canonical public copies and replace their transfer duplicates; all other accepted files are published under docs/knowledge/ in project-neutral domain families.

Documentation workflow

Authorized routine documentation maintenance is performed directly on main. Feature branches and pull requests are not required for routine documentation growth or maintenance; external contributions and larger changes use pull requests — see CONTRIBUTING.md.

Changes must be evidence-based, duplicate-checked, narrowly scoped, and reviewed for public-safety and sensitive-data boundaries before commit. Use current primary or authoritative sources for standards, regulatory, security, and vendor claims.

See CONTRIBUTING.md, SECURITY.md, and SUPPORT.md.

Citing this documentation

Content is MIT-licensed (see LICENSE). When citing a document, reference its URL together with the document's last-reviewed date. The concept DOI 10.5281/zenodo.22109314 identifies the documentation series across archived versions, as recorded in the citation metadata. Do not treat the concept DOI as a version-specific identifier. For a reproducible citation to v1.0.0, a later release, or an untagged state of main, pin the Git tag or exact commit SHA and use a version-specific archive DOI only when that DOI has been independently verified.

Brand

ORCHORDS — BUILD DIFFERENT.

License

See LICENSE.