Skip to content

Adoption Guide

Terng Dechanon edited this page Jul 23, 2026 · 1 revision

Adoption Guide

For teams evaluating Genesis Governance OS for real systems.

What you are adopting

A specification, not a dependency. There is no package to install, no runtime to run, no vendor to depend on. You implement four short standards in the language and stack you already use — the way you would adopt OpenAPI or MCP.

That means: no supply-chain surface, no version-pinning risk, no upstream outage.

Evaluation checklist

Question Where to look
Is it specified precisely enough to implement? Conformance — RFC-2119 language, stable requirement IDs
Can compliance be verified, not just claimed? 18 automated checks + published attestation requirements
Does it work on our platforms? CI: Linux/macOS/Windows × Python 3.9/3.11/3.12
How do breaking changes happen? CONFORMANCE §7 — new MUST requires a MAJOR bump; IDs never reused
How are security issues handled? SECURITY.md — spec flaws treated as a distinct, higher class
What are the known gaps? Published openly in CONFORMANCE §5 — nothing is hidden
What is the license? Apache-2.0 — OSI-approved, express patent grant

License: Apache-2.0

The project is released under the Apache License 2.0 — an OSI-approved licence that standard corporate review processes accept without a bespoke legal negotiation. Free to use, modify, and redistribute, including commercially; keep the licence and NOTICE, and state any changed files. It includes an express patent grant.

(Versions through 2.0 were released under a custom licence with a revenue-share clause. It was replaced in v2.1 precisely to remove adoption friction — a standard's value is its adoption.)

One naming condition, not a usage restriction. Apache-2.0 §6 does not grant rights to the project's marks. A derivative that strips the safety invariants — separation of powers, honest-failure, human-in-the-loop — must be renamed and must not imply endorsement. Conformance claims are governed by Conformance.

Recommended rollout

Phase 1 — Core (L1), one workflow. Pick a single multi-agent workflow already in production. Add GTS-1 Task State and GPS-2 Permission. Measure: incidents from unauthorised actions, duplicated work, tasks marked done that were not.

Phase 2 — Full (L2). Add GOP-3 Orchestration — routing by fit and a hard loop guard. Measure: runaway retries, wasted spend, workflows that never converge.

Phase 3 — Governed (L3). Add GOS-0 Constitution when agent count exceeds what one person can watch. Measure: whether any component can legislate, execute, and judge at once.

Phase 4 — Publish your claim. State your level and attestations per Conformance §6.

Integrating with what you already run

The standards are deliberately orthogonal to agent frameworks. If you use LangGraph, CrewAI, AutoGen, or an in-house orchestrator, GTS-1 is a state shape, GPS-2 is a call you make before tool execution, and GOP-3 is a policy on your existing routing loop. You are not replacing your stack; you are constraining it.

The honest limits

  • The reference implementation is not production infrastructure (in-memory, single-process).
  • Five requirements cannot be verified by any test suite and require your own attestation.
  • Two requirements are not yet automated (GOP-3.2, GOP-3.5).
  • This is an early standard with a single maintainer. Evaluate governance risk accordingly.

Clone this wiki locally