RÉGUA — Governance Index v1.0
Status: CANONICAL — INITIAL OPERATIONS
Effective date: 2026-09-16
Owner: Founder / Régua
Scope: Institutional governance and all client projects
Purpose: define where the truth lives, what each system is responsible for, and which source wins when information conflicts.
1. Core rule
One question = one canonical source.
No chat, document, board, branch, PDF or AI output may silently become a second source of truth.
When two sources conflict, the canonical source defined in this index wins until an explicit reconciliation is approved.
2. Canonical sources by subject
| Question | Canonical source | Notes |
|---|---|---|
| What is Régua and how is it positioned? | REGUA_Documento_Institucional_v1.0 (supersedes Documento_Fundador_v0.1) | Strategic identity, positioning, offer, principles (APPROVED v1.0, 2026-09-17) |
| How does the Régua method work? | REGUA_Metodo_v1.0 | R–É–G–U–A, Gates, evidence, artifacts |
| What visual rules are official? | REGUA_Figma_Master_v1.0 | Logo, colors, typography, visual system (approved/locked status lives in metadata, not in the filename) |
| How does Régua operate internally? | 01_REGUA_OPERATING_SYSTEM_v1.0.md | Execution rules, statuses, evidence, change control |
| What is the current execution status of a project? | Linear | Current status, owner, priority, blockers, target dates |
| What is the current code? | Git repository | Code and code history |
| What is the current infrastructure state? | Infrastructure repository + environment evidence | IaC/config where applicable; otherwise documented verified state |
| What is the approved architecture of a project? | Project canonical architecture/system map | Architecture decisions must be versioned |
| What decisions were made and why? | Project Decision Log | Must link to issue/evidence when relevant |
| What is still unknown? | Project Unknown Log | UNKNOWN is explicit, not hidden |
| What was proved? | Evidence Pack / issue evidence | PASS requires evidence |
| What is the client-facing weekly status? | Weekly Executive Update | Summary only; not a replacement for Linear |
| What happened in an AI/chat session? | Handoff / committed artifact | Chats are working interfaces, not official memory |
| Where is canonical documentation read/published? | Docs site (Docusaurus), generated from Markdown + Git | Derived read-only layer; never edited directly |
3. Tool responsibilities
3.1 Linear
Purpose: execution control.
Linear stores:
- issue status;
- owner;
- priority;
- blockers;
- target date;
- dependencies;
- acceptance criteria;
- evidence links;
- comments that explain execution changes.
Linear owns current execution state and links. The Decision Log owns decisions and rationale; the Unknown Log owns unknowns; the Evidence Pack (or evidence artifact) owns proof. Linear references these artifacts when applicable — it does not duplicate their full content.
Linear does not replace:
- source code;
- long-form architecture documents;
- institutional policies;
- evidence files;
- canonical project documentation.
3.2 Git
Purpose: code and versioned technical documentation.
Git stores:
- source code;
- versioned technical documents;
- configuration intended to be versioned;
- migration files;
- test assets;
- runbooks where appropriate.
A commit proves that something was committed. It does not prove that it was deployed or validated.
3.3 AI tools and chat
Examples: ChatGPT, Claude, Claude Code, Codex, Gemini, Kimi.
Purpose: analysis, drafting, implementation assistance, review and execution support.
AI/chat output is not canonical by default.
A conclusion becomes official only when it is transferred to the correct canonical source.
3.5 Documentation site (Docusaurus)
Purpose: derived, read-only publication layer for the canonical documentation.
Markdown + Git are the documentation source of truth. The site is generated from them and is never edited directly, and never becomes a second editable source. Every documentation change happens first in Markdown, then the site is regenerated.
3.4 Client communication
Email, WhatsApp and meetings may contain valid decisions, but any decision that changes scope, priority, architecture, target date, risk or acceptance must be recorded in the canonical project system.
4. Conflict resolution
If information conflicts:
- Identify the question being answered.
- Identify the canonical source for that question.
- Treat all other sources as non-authoritative until reconciled.
- Record the reconciliation if it materially changes execution.
- Do not silently edit history to make sources appear consistent.
5. Status vocabulary
The words below have fixed meanings across Régua projects.
| Status | Meaning |
|---|---|
PLANNED | Approved work not yet started |
IN_PROGRESS | Active execution |
IMPLEMENTED | Code/config/process change created, but not necessarily deployed |
DEPLOYED | Change placed in the intended environment |
VALIDATING | Deployed/implemented change is under evidence-based validation |
DONE | Acceptance criteria met and evidence recorded |
BLOCKED | Progress cannot continue due to a known blocker |
UNKNOWN | Required fact is not yet established |
CANCELLED | Work intentionally stopped |
Never collapse these states
IMPLEMENTED ≠ DEPLOYED ≠ VALIDATED ≠ DONE
6. Evidence rule
PASS requires evidence.
Examples of acceptable evidence:
- reproducible test result;
- log output;
- monitoring data;
- screenshot from the correct environment;
- database query/result;
- client acceptance;
- validated API response;
- before/after metric with source;
- deployment record.
Examples that are not enough by themselves:
- “Claude said it works”;
- “the code looks correct”;
- “the branch exists”;
- “someone said it was deployed”;
- “there was no error in the chat”.
Evidence durability
Evidence used for PASS, Gate decisions or DONE records captures, when applicable:
SOURCE/LOCATOR= · ENVIRONMENT= · CAPTURED_AT/VERIFIED_AT= · CLAIM_SUPPORTED=
If the source is ephemeral (temporary logs, console output, expiring links), preserve enough evidence in durable storage to support the claim. Do not copy gigabytes of logs; preserve only what sustains the statement.
7. UNKNOWN rule
UNKNOWN is an accepted state.
When something is unknown:
- record it explicitly;
- assign an owner if resolution matters;
- define how it can be verified;
- do not convert it into an assumption without labeling the assumption.
UNKNOWN > invented certainty.
8. Decision rule
A decision must be recorded when it materially affects:
- scope;
- architecture;
- cost;
- delivery date;
- risk;
- security;
- data handling;
- client responsibility;
- acceptance criteria;
- rollback;
- production behavior.
A valid decision record contains:
- date;
- decision;
- reason;
- evidence/context;
- consequences;
- owner/approver;
- related issues/files.
9. Versioning rule
Avoid parallel “final” files.
Preferred naming:
DOCUMENT_NAME_v1.0.md
When a canonical document changes materially:
- increment version intentionally;
- record what changed;
- archive or supersede the previous version;
- do not keep multiple editable “final” variants without an explicit status.
Forbidden pattern:
FINAL_FINAL_CORRECTED_NEW_v2_REAL_FINAL
10. Project bootstrap and artifact catalog
Every new client project starts from the Régua Project Template Pack.
Bootstrap minimum (day one):
- Project Charter;
- Unknown Log;
- Decision Log.
All other artifacts are activated by phase or need, as defined by the Delivery Playbook activation matrix (Radiografar: Current State Map, System Map, Opportunity Register; Estabelecer: Baseline Plan; active project: Weekly Executive Update; on demand: Pilot Spec, Evidence Pack, Runbook, Handoff, Closeout).
TEMPLATE AVAILABLE ≠ DOCUMENT MUST EXIST. An artifact is instantiated only when its phase or risk requires it.
Canonical artifact catalog
CORE (part of the standard system — NOT necessarily created on day one; the activation matrix defines when each one is born):
PROJECT_CHARTER · CURRENT_STATE_MAP · SYSTEM_MAP · UNKNOWN_LOG · OPPORTUNITY_REGISTER · BASELINE_PLAN · DECISION_LOG · WEEKLY_UPDATE · EVIDENCE_PACK · HANDOFF
CONDITIONAL (create only when phase or risk requires):
PILOT_SPEC · RUNBOOK · CLOSEOUT
ALIAS / ABSORBED (do not create separate documents):
- System & Data Map →
SYSTEM_MAP; - Implementation Backlog → Linear (no parallel document);
- Future State Map → lives inside
PILOT_SPEC/ Governar materials (no separate template for now); - Risk Register → risks live in existing artifacts/issues; a separate Risk Register only for projects whose risk justifies the overhead.
11. Gate rule
The official Régua gates are:
GATE 01 — Vale fazer?
No implementation starts only because an idea sounds good.
GATE 02 — Funciona com segurança?
Implementation is not enough; behavior, boundaries, evidence and fallback must be validated.
GATE 03 — Provou valor?
Scale only after measurable value is demonstrated at acceptable cost/risk.
Each Gate requires:
- explicit criteria;
- evidence;
- decision;
- owner/approver;
- recorded outcome.
Minimum required approvers per Gate (including Client Owner co-approval triggers and explicit self-approval for solo founder) are defined in the Operating System, section 07. AI is never a responsible approver.
12. Handoff rule
Any material handoff between people, AI agents, chats or execution environments uses the canonical Handoff schema: template HANDOFF.md (Templates → Handoff). This index does not duplicate the field list.
If a handoff cannot reconstruct the project state without guessing, the handoff is incomplete.
13. Terra Fértil application
Terra Fértil will be the first project instantiated under this governance model.
The project must not begin with implementation. It begins with:
- Project Charter + Unknown Log + Decision Log (bootstrap minimum)
- Radiografar: Current State Map, System Map, Opportunity Register
- Estabelecer: Baseline / Measurement Plan
- Governar: future flow, limits, acceptance criteria, rollback
- Gate 01 — Vale fazer?
- Approved implementation
14. Change control for this index
Changes to this Governance Index must be intentional and versioned.
A project may add stricter rules, but it may not silently weaken these institutional rules.
15. Canonical statement
Chats help us think. Linear tells us what is happening. Git tells us what exists in code. Evidence tells us what is true. Canonical documents tell us how Régua operates.