The terms GTT uses, each with one definition. Definitions follow the GTT Canonical v2.1 and the published GTT Bootstrap and GTT CLI documentation; where this page and the canonical differ, the canonical is right: https://github.com/GTT-Community/gtt-method/blob/main/GTT-CANONICAL-v2.1.md
Method, implementation and tooling
GTT / GTT-Method
GTT (Governance Through Thinking) is a methodology and governance control plane for governed AI-assisted software development. It lets AI agents and ADEs take part in software development without becoming the authority over the system.
GTT Canonical
The single canonical definition of the current GTT generation (GTT 2.1). If an implementation, website, manual or CLI contradicts it, the contradiction must be surfaced and resolved. Source: https://github.com/GTT-Community/gtt-method/blob/main/GTT-CANONICAL-v2.1.md
GTT Bootstrap
The reference implementation of the GTT Method. It owns the GTT semantics and exposes them through versioned contracts. See https://gtt-method.org/methodology/
GTT CLI
The operational surface of GTT: the gtt command-line tool that installs, validates, operates, updates, exports and recovers GTT projects through the Bootstrap contracts. It is not a second GTT engine. See https://gtt-method.org/cli/
Method Plan
The operating profile chosen for a project: Light, Medium, Hard or Team. It sets how much operational work is delegated to GTT. It is not a quality level, and no plan turns governance off.
Context and evidence
Governed Context
The controlled, authoritative body of information used to understand and reason about a system: requirements, architecture, ADRs, rules, constraints, approved decisions, evidence and governed state.
Execution Context
The minimum relevant subset of the governed context that GTT selects for a specific operation, task, artifact or decision.
Evidence Boundary
The separation between authorized sources, grounding, the evidence dossier, reasoning, proposals, human decision and governed artifacts. Agents reason over governed evidence instead of treating arbitrary context as authority.
Grounding
The step that retrieves and exposes evidence from authorized sources. Grounding does not decide architecture.
Evidence Dossier
The consolidated evidence available for reasoning. It is a governed representation of evidence, not a source of authority, and it exposes conflicts instead of resolving them silently.
Provenance
The traceable relationship between a statement and its supporting evidence. GTT uses explicit markers to distinguish evidence, missing information, conflicts and proposals.
Architectural Intent
The intended architecture and design decisions of the system, expressed through ADRs, specifications, rules, constraints and governed state. Architectural drift must be surfaced, not silently accepted.
Reasoning, decision and change
THINK
The reasoning mode of GTT. Agents analyze evidence, identify gaps and conflicts and produce proposals. THINK is re-entrant: the project returns to it whenever a change requires governance.
Proposal
A change identified by an agent that requires human authority. A proposal makes the intended change explicit so a human can decide; it is not a decision.
Human Decision Boundary
The explicit separation between reasoning and decision authority. A human may approve, reject, modify or request further analysis of a proposal. Agent reasoning is not change authorization.
ADR
Architecture Decision Record: the record of a governed architectural decision.
Governed State
An accepted state of the project.
Freeze
The boundary established around an accepted governed state. After freeze, changes follow a governed change path. There is no implicit or autonomous unfreeze.
Change Request
The entry point for changing a frozen state: change request, impact analysis, THINK, proposal, human decision, new governed state and freeze.
GTTGuard
The GTT capability that protects artifacts (files, classes, methods) from autonomous modification. It protects the authority to change code; it does not hide code from agents.
Validation
Deterministic checks of the GTT project, run by Bootstrap rather than left to the judgment of an agent.
ADEs and sessions
ADE
AI Development Environment: the environment in which an agent executes development work, for example Claude Code, GitHub Copilot, Codex or Kiro. The ADE executes; GTT governs.
Agent
The reasoning and execution capability working inside an ADE. An agent may analyze, propose and implement within the authority granted by GTT.
ADE Adapter
The GTT integration surface installed for a participating ADE. Adapters let an ADE take part in GTT and never become an authority of their own.
Primary ADE
The one participating ADE chosen as the principal workflow environment of a project. It is a workflow identity and carries no governance authority.
Session Continuity
The ability to resume work from session state that GTT derives from actual project state. Session state is operational orientation, not architectural authority.
Clean Export
A clean delivery copy of the project without GTT-owned material, produced without modifying the development project.
Recovery Snapshot
The portable information needed to reconstruct a GTT installation and its operational state. It is not a full repository backup.
Related pages
- Methodology: https://gtt-method.org/methodology/
- FAQ: https://gtt-method.org/faq/
- GTT CLI: https://gtt-method.org/cli/