---
title: "GOVERNANCE.md"
description: "A guide to documenting your product's structural commitments based on the assessment results."
canonical: "https://architecture.reopt.ai/governance"
language: "en"
last-updated: "2026-10-20"
alternate-markdown: "https://architecture.reopt.ai/ko/governance.md"
site-index: "https://architecture.reopt.ai/llms.txt"
source: "reopt architecture"
---

# GOVERNANCE.md

> A guide to documenting your product's structural commitments based on the assessment results.

As AGENTS.md defines the behavioral rules for the AI, GOVERNANCE.md defines the product's structural commitments. Author the four sections below from the assessment (radar) results, and update them with every OCLS pass.

## What is GOVERNANCE.md

A single-page document that sits at the project root. It declares who owns what, under what conditions judgment is made, how collaboration runs, and against what criteria improvement happens. Without a documented structure, both loops and execution lose direction.

## Sections

Section order: Diagnostic Snapshot → Ownership Structure → Judgment Contracts → Collaboration Rules → Improvement Criteria. Missing sections or order violations are blocked by linter rules.

### Diagnostic Snapshot

Assessment Snapshot — summarize /assessment results at the top

- Record the latest assessment date and the chosen preset.
- List the top three priority patterns with scores — see at a glance which patterns are most urgent.
- Record one or two key tensions with response guidance — the rationale for trade-off decisions.
- Summarize the recommended maturity stage — where you are now and what comes next.
- Keep the full assessment report at `docs/assessment-YYYY-MM-DD.md` and reference the path.

**Template**

```markdown
## Diagnostic Snapshot

> Last assessment: YYYY-MM-DD
> Preset: <preset name>
> Full report: docs/assessment-YYYY-MM-DD.md

### Top 3 priority patterns
1. **<Pattern name>** (<score>/100)
2. **<Pattern name>** (<score>/100)
3. **<Pattern name>** (<score>/100)

### Key tensions
- <tension description> — <response guidance>

### Recommended maturity
**Stage N — <stage name>**
```

### Ownership Structure (OWN)

OWN — who (human or AI) owns which outcome

- List the product's core outcomes and the owner of each.
- Mark whether each owner is human or AI — the type of owner determines how strict the contract must be.
- AI-owned: every judgment condition must be explicit, with mandatory guardrails and escalation.
- Human-owned: contextual judgment is possible, but the judgment criteria must be documented so the team shares them.
- Identify gray zones with unclear ownership and assign them.

**Template**

```markdown
# Ownership Structure

| Outcome | Owner | Type | Governance level |
|---------|-------|------|------------------|
| Inquiry classification | Intake Agent | AI | Contract-based auto execution, human escalation on misclassification |
| Response quality | Response Agent | AI | Guardrails + post-hoc QA review |
| Refund approval (> ₩500,000) | CS manager | Human | Pre-approval required |
| Cost-ceiling compliance | Ops team | Human | Daily dashboard monitoring |
| Regulatory compliance | Compliance Officer | Human | External audit response |
```

### Judgment Contracts (CONTRACT)

CONTRACT — under what conditions which judgment is made

- Declare each execution unit's input conditions, output format, and refusal conditions.
- Define the classification criteria for auto-approval, post-hoc review, and pre-approval.
- Specify the recovery path and fallback behavior on failure.

**Template**

```markdown
# Judgment Contracts

## Classification criteria
- Auto-approve: cost < ₩100,000, within existing policy
- Post-hoc review: cost ₩100,000–500,000, new cases
- Pre-approval: cost > ₩500,000, legal responsibility, customer commitments

## Refusal conditions
- Response contains PII → block
- Comparative statements about competitors → escalate
```

### Collaboration Rules (LAYER)

LAYER — information transfer and approval flow between actors

- Define which context to include and exclude when passing information between actors.
- Specify collaboration order and dependencies.
- Distinguish areas that can run in parallel from those with sequential dependency.

**Template**

```markdown
# Collaboration Rules

## Information-transfer scope
- Classification → Response: category, sentiment, prior resolution history
- Response → QA: response draft, referenced policy, judgment rationale
- QA → Ops: quality score, violations, improvement suggestions

## Dependencies
- Classification complete → response start (sequential)
- Response + cost calculation (parallel)
- QA runs asynchronously on every response
```

### Improvement Criteria (SHARPEN)

SHARPEN — what to measure and when to adjust the structure

- Define core quality metrics and their targets.
- Set cost-tracking units and budget ceilings.
- Specify the signals that trigger structural adjustment (review cadence, thresholds).

**Template**

```markdown
# Improvement Criteria

## Core metrics
| Metric | Target | Review cadence |
|--------|--------|----------------|
| Response accuracy | > 95% | weekly |
| Token cost / request | < ₩500 | daily |
| Escalation rate | < 5% | weekly |

## Adjustment signals
- Accuracy < 90% for 3 consecutive days → revisit the ownership structure
- Cost budget at 80% → re-tune model assignments
- 10+ new refusal patterns → renew the contract
```

## Linter rules

Each rule is checked by the governance-reviewer skill against the PR diff. Errors must be resolved before merge; warnings are left as review comments.

| Rule | Severity | Target |
| --- | --- | --- |
| `missing-section` | error | §01–§05 중 하나 이상이 비어 있음 |
| `section-order` | error | OWN → CONTRACT → LAYER → SHARPEN 순서 위반 |
| `authority-sprawl` | warning | OWN 섹션에 권한 범위가 선언되지 않음 |
| `contract-gap` | error | CONTRACT 섹션에 input·output·reject_when 누락 |
| `observability-gap` | warning | LAYER 섹션에 trace·log 명세 누락 |
| `validation-gap` | error | SHARPEN 섹션에 metric·임계값·리뷰 주기 누락 |
| `broken-ref` | error | frontmatter의 참조가 본문에서 정의되지 않음 |

→ [Run the rules yourself](https://architecture.reopt.ai/governance/lint.md)

## Machine-readable frontmatter

A YAML representation equivalent to the human markdown. The body targets humans; the frontmatter targets the linter and coding agents. Divergence between the two produces a broken-ref violation.

## Rationale — why OCLS

Four principles implemented across the four OCLS phases. The phase order follows the principle order directly.

- **Design around responsibility units, not features** — An agent is not a function caller — it is a continuously explainable owner of outcomes.
- **A module is not a callable tool — it is an execution unit with a contract** — Only when a module has a contract does the structure support evaluation, replacement, authority control, and testing.
- **Scale is possible only when governed through classification and structure** — As agents multiply, structuring them into categories, layers, and boundaries is what keeps governance intact and scale sustainable.
- **Architecture is a system that evolves in operation** — Responsibility boundaries and policies must keep adjusting from failure logs and evaluation outcomes.

## Related patterns

Which implementation patterns realize each governance commitment. Click a pattern to open its catalog entry.

## Complete example

A complete GOVERNANCE.md example for a customer-support AI. Drop this at the project root and update it on every OCLS pass.

---

_Markdown representation of https://architecture.reopt.ai/governance. Full index: https://architecture.reopt.ai/llms.txt HTML original: https://architecture.reopt.ai/governance · 한국어: https://architecture.reopt.ai/ko/governance.md_