GTT Methodology | GTT-Method

GTT is a methodology for governing software development when AI agents participate in the development process. It establishes the governance model for project context, evidence, architecture, proposals, decisions, constraints, rules, validation, freeze and controlled change.

It is implemented through GTT Bootstrap and operated through GTT CLI.

GTT Method
Methodology & Governance
        ↓
GTT Bootstrap
Reference Implementation
        ↓
GTT CLI
Operational Tooling
        ↓
ADEs + Human

GTT Governance Canonical: https://github.com/GTT-Community/gtt-method/blob/main/GTT-CANONICAL-v2.1.md

What is GTT?

GTT is a methodology for governed AI-assisted software development.

It defines how project context, evidence, architecture, rules, constraints, proposals, decisions, validation and controlled change are managed when AI Development Environments (ADEs) and AI coding agents participate in software development.

GTT is designed around a separation between four things:

The methodology and its governance semantics.
The implementation of those semantics.
The operational tooling used to install and operate them.
The ADEs and agents that perform development work.

This separation is what allows GTT to remain independent of any specific AI development environment.

The problem GTT solves

AI agents produce software at high speed. That speed creates concrete engineering and governance problems, and GTT addresses each of them explicitly.

AI Agents
    │
    ▼
High-speed software production
    │
    ├── Context drift
    ├── Architecture drift
    ├── Uncontrolled assumptions
    ├── Session discontinuity
    ├── Multiple ADEs
    └── Weak traceability
            │
            ▼
          GTT
            │
    ┌───────┼────────┐
    ▼       ▼        ▼
Govern   Evidence   Change
    │       │        │
    └───────┼────────┘
            ▼
     Governed AI Development

Context is not automatically governance

An AI agent can receive large amounts of information without that information having a defined authority. GTT provides an explicit model for determining what participates in governed development context and how that context is used.

Evidence and reasoning must be distinguishable

GTT establishes an evidence boundary. The system must be able to distinguish:

What came from authorized evidence.
What is missing.
What conflicts.
What is proposed.
What has actually been decided.

This prevents generated reasoning from silently becoming project authority.

Proposals are not decisions

AI agents can generate architectural and implementation proposals. GTT separates proposals from ratified decisions: the agent can reason and propose, and the governed project state is established through the GTT decision process.

Architecture must remain governed

GTT prevents the implementation produced by an agent from silently becoming the project's new architectural authority. Architectural intent, constraints and decisions remain explicit GTT artifacts.

Freeze must establish authority

GTT uses a freeze mechanism to establish the governed state. A freeze is not simply a Git operation: it is a governance boundary. After freeze, changes must follow the GTT change process rather than silently rewriting governed state.

Multiple ADEs need one governance model

A project can be touched by several development environments, for example Claude Code, Codex, GitHub Copilot, Kiro and other supported ADEs. GTT therefore uses:

one GTT governance model
+
multiple ADE integration surfaces
+
exactly one Primary ADE

The Primary ADE is a workflow identity. It does not receive governance authority.

Development must be recoverable

GTT also addresses operational continuity. Project state can be inspected, and session context can be derived from actual project state. The goal is not to make an agent's private memory the authority: the project remains the source of governed truth.

The GTT methodology

GTT is a governance methodology, not a command-line product. The methodology establishes the rules and semantic contracts around:

GTT METHOD
│
├── Governance
├── Context
├── Evidence
├── Grounding
├── Provenance
├── Architecture / Intent
├── Proposals
├── Decisions
├── ADR semantics
├── Rules
├── Constraints
├── Validation
├── Freeze
├── Change
├── ADE participation
├── Session context
└── Lifecycle governance

These semantics are owned by the GTT Method and implemented in GTT Bootstrap. The CLI does not duplicate them.

How GTT works

GTT METHOD
                       │
                       ▼
                Project Context
                       │
                       ▼
                    GROUNDING
                       │
                       ▼
                Evidence / Context
                       │
                       ▼
                     THINK
                       │
              ┌────────┴────────┐
              ▼                 ▼
          Proposals          Gaps /
          Analysis           Conflicts
              │                 │
              └────────┬────────┘
                       ▼
                 Human Decision
                       │
                       ▼
                    FREEZE
                       │
                       ▼
                      WORK
                       │
                       ▼
                Change Discovery
                       │
                       ▼
                Change Request
                       │
                       ▼
                     THINK
                       │
                       ▼
                 New Decision
                       │
                       ▼
                  New FREEZE

THINK is not a one-time phase. The reasoning mode is re-entrant: whenever a change requires governance, the project returns to THINK.

Evidence and provenance

GTT separates retrieval and evidence from reasoning.

AUTHORIZED SOURCES
        │
        ▼
    GROUNDING
        │
        ▼
 EVIDENCE / CONTEXT
        │
        ▼
   THINK / AGENTS
        │
        ▼
    PROPOSALS
        │
        ▼
 HUMAN DECISION
        │
        ▼
      FREEZE

An agent's generated reasoning must not silently become evidence or governed project truth.

GTT distinguishes evidence, proposals and decisions. This is one of the methodology's central governance mechanisms.

Freeze and controlled change

FREEZE
  ↓
Governed project state
  ↓
WORK
  ↓
Discovery of change
  ↓
CHANGE REQUEST
  ↓
THINK
  ↓
Decision
  ↓
NEW FREEZE

There is no "unfreeze" workflow in GTT. The governance model is based on controlled re-entry and re-freeze, not on turning governance off.

Method Plans

GTT is applied through a Method Plan, chosen once per project:

LIGHT
MEDIUM
HARD
TEAM

A Method Plan is an operating profile, not a quality level, and no plan turns governance off. The CLI lets the project select the plan; Bootstrap owns what each plan means. The plans are documented in the Bootstrap repository: https://github.com/GTT-Community/gtt-bootstrap/blob/main/.gtt/docs/method-plans.md

Session continuity

GTT provides session-context capabilities to help recover where work is and what remains to be done. Two things are kept apart:

GOVERNED PROJECT STATE
        │
        ├── Architecture
        ├── Decisions
        ├── Constraints
        └── Validated state

SESSION / OPERATIONAL CONTEXT
        │
        ├── Current work
        ├── Current progress
        ├── Pending work
        └── Operational orientation

Session context is not an alternative architecture authority. This matters most when a project uses several ADEs.

GTT + ADEs

GTT is ADE-independent.

GTT
                Methodology / Governance
                           │
                           ▼
                    GTT Bootstrap
                           │
                           ▼
                       GTT CLI
                           │
          ┌────────────────┼────────────────┐
          ▼                ▼                ▼
     Claude Code         Codex            Kiro
          │                │                │
          └────────────────┼────────────────┘
                           ▼
                     Project Work

The ADE is the development environment. GTT is the governance model.

Bootstrap supports several ADE integration surfaces (currently Claude Code, GitHub Copilot, Codex and Kiro) while maintaining one governance model and one Primary ADE. The Primary ADE is a workflow role, not a governance role. Secondary ADEs are not ignored: if they participate in the project, their GTT integration is represented according to Bootstrap contracts.

GTT Bootstrap

GTT Bootstrap is the reference implementation of the GTT Method.

It contains the semantic and operational contracts required to apply GTT to a real software project, including governance, evidence, architecture and context semantics, proposals, decisions, validation, freeze, ADE integration and project lifecycle services.

Bootstrap is the implementation source of truth for GTT semantics. The CLI consumes Bootstrap; it does not reimplement GTT.

What Bootstrap solves

Project governance foundation: the project structure and contracts required to operate GTT.
Governance semantics: governance is implemented in Bootstrap, not left to CLI interpretation.
Evidence boundary: grounding, evidence and provenance semantics.
Architecture and context semantics: the model used to govern architecture and context.
Proposals versus decisions: proposals are kept distinct from governed decisions.
Freeze: freeze semantics and the validation surrounding the governed state.
ADE integration and multi-ADE coordination: several participating ADEs, one Primary ADE.
Deterministic validation, status and session context derived from actual project state.
Index, retrieval, reconciliation, guard synchronization, export and recovery contracts.

Bootstrap service catalog

Service	Purpose
Governance Engine	Implements the GTT governance semantics that define how project context, evidence, proposals, decisions, architecture and freeze are handled.
Evidence & Grounding	Establishes the boundary between authorized source material, evidence and generated reasoning.
Provenance	Maintains the relationship between project assertions and their supporting evidence or governance state.
Architecture / Context Semantics	Provides the semantic model for governing architecture, context and project intent.
Proposal Management	Supports the distinction between agent-generated proposals and governed project decisions.
Decision / ADR Semantics	Provides the semantic contracts used to record and relate governed decisions.
Freeze	Establishes and validates the governed project state.
Validation	Runs deterministic GTT validation rather than relying on an AI agent to decide whether the project is structurally valid.
ADE Integration	Provides the integration surfaces required for AI Development Environments participating in the project.
Multi-ADE State	Tracks participating ADEs while preserving a single GTT governance model.
Primary ADE	Identifies the ADE used as the primary workflow participant without granting it governance authority.
Templates	Provides Bootstrap-owned templates used during project initialization and GTT workflows.
Initial Design Questionnaire	Provides a Bootstrap-owned questionnaire when the project does not have sufficient initial design or source material.
Source Manifest	Provides the structure required to identify and manage initial project source material.
Working Agreements	Provides Bootstrap-owned structures for project working agreements without confusing them with GTT governance authority.
Status	Derives operational project and GTT state from actual project artifacts.
Session Context	Derives operational continuity information from actual project state, so work can be resumed without making agent memory the project's authority.
Technical Index	Maintains the machine-oriented project indexing needed by GTT services.
Query / Retrieval	Provides structured access to indexed project information.
Reconciliation	Detects and reconciles relevant differences between GTT-managed state and project state according to Bootstrap contracts.
GTTGuard	Provides the GTT protection and guard synchronization mechanisms defined by Bootstrap.
Clean Export	Defines what GTT-owned material can be excluded when producing a clean delivery artifact.
Recovery	Defines the portable recovery information required to reconstruct a GTT installation and operational state.
Session Memory Adapter Contracts	Defines the integration boundary for session-memory mechanisms without transferring project governance authority to an ADE's private memory.

Bootstrap architecture

GTT METHOD
                             │
                             ▼
                    GTT BOOTSTRAP 1.x
                             │
          ┌──────────────────┼──────────────────┐
          │                  │                  │
          ▼                  ▼                  ▼
      Governance          Engine / Domain     ADE Services
      Evidence            Validation          Templates
      Provenance          Status              Questionnaire
      Architecture        Freeze              Integrations
      Proposals           Query               Session
      Decisions           Reconcile           Recovery
          │                  │                  │
          └──────────────────┼──────────────────┘
                             │
                             ▼
                    Versioned Contracts
                             │
                             ▼
                         GTT CLI

Because the semantics live in Bootstrap behind versioned contracts, the CLI stays small.

GTT CLI

GTT CLI is the operational surface of GTT.

It provides the command-line lifecycle for discovering, installing, configuring, validating, operating, updating, resuming, freezing, exporting and recovering a GTT project through the GTT Bootstrap contracts.

GTT CLI is not a second GTT engine. It consumes and orchestrates Bootstrap, and it does not reproduce GTT methodology semantics. Every command is deterministic and needs no LLM.

What the CLI solves

Installation complexity: one consistent way to initialize GTT in a project and install a compatible Bootstrap.
Bootstrap resolution: resolves the required Bootstrap and verifies compatibility.
ADE discovery: detects available ADEs and manages their GTT integration.
Primary ADE selection: establishes one Primary ADE, which has no governance authority.
Initial source selection: discovers candidate design documents and asks for an explicit selection.
Missing design source: requests the Bootstrap-owned Initial Design Questionnaire.
Operational lifecycle: validation, status, inspection, resume, freeze and update, all delegated to Bootstrap contracts.
Recovery, clean export and clean removal of GTT from a project.
CI/CD: non-interactive, machine-readable workflows suitable for automation.

CLI service catalog

Service	What it does
Project Discovery	Detects the host project and determines whether GTT is already present.
Bootstrap Resolution	Finds and resolves a compatible GTT Bootstrap release.
Compatibility	Verifies CLI/Bootstrap compatibility before unsafe operations.
ADE Detection	Detects supported ADEs represented in the project or environment.
ADE Installation	Installs the GTT integration surfaces for the participating ADEs.
Primary ADE Configuration	Establishes exactly one Primary ADE for the project's workflow.
Source Discovery	Finds candidate project and design source documents during initialization.
Initial Source Selection	Allows explicit selection of the source material used to initialize the GTT project.
Method Plan Selection	Selects the Method Plan. The CLI selects it; Bootstrap defines its meaning.
Project Initialization	gtt init orchestrates the complete initialization workflow.
Status	gtt status exposes deterministic project and GTT state.
Inspection	gtt inspect exposes installation topology and operational state.
Validation	gtt validate delegates validation to Bootstrap.
Resume	gtt resume supports continuation from deterministic project state.
Freeze	gtt freeze invokes the Bootstrap freeze contract.
Doctor	gtt doctor provides operational diagnostics.
Audit	gtt audit exposes operational traceability according to Bootstrap contracts.
Update	gtt update manages safe Bootstrap updates and compatibility.
Clean Export	gtt export --clean produces a clean delivery artifact while leaving the development project intact.
Clean	gtt clean removes GTT from the current project after explicit confirmation.
Recovery	Recovery snapshots hold the portable information needed to reconstruct the GTT installation and operational state.
Version	gtt version reports the CLI version.

Command surface

gtt init
gtt status
gtt inspect
gtt validate
gtt resume
gtt freeze
gtt doctor
gtt audit
gtt update
gtt export --clean
gtt clean
gtt version

This page is not a command reference. Installation and command details are on the GTT CLI page: https://gtt-community.github.io/cli

Initialization flow

gtt init
   │
   ├── detect project
   ├── detect existing GTT
   ├── resolve Bootstrap
   ├── verify Bootstrap
   ├── check compatibility
   ├── detect ADEs
   ├── choose participating ADEs
   ├── choose Primary ADE
   ├── choose language
   ├── discover source documents
   ├── select initial sources
   ├── if insufficient → Bootstrap questionnaire
   ├── choose Method Plan
   ├── install Core
   ├── install ADE integrations
   ├── persist operational state
   ├── validate
   ├── create Bootstrap handoff
   └── optionally invoke Primary ADE

The CLI does not design the system. It initializes and orchestrates the GTT environment.

Deterministic state

GTT Project State
       │
       ▼
Bootstrap / CLI
       │
       ▼
Derived operational status

Never the other way around: agent prose does not become project truth. The CLI derives operational and session information from real project state. Agent memory remains an ADE-level mechanism; GTT governance remains in the project and in the Bootstrap contracts.

Clean export and recovery

GTT Development Project
        │
        ▼
gtt export --clean
        │
        ▼
Clean delivery artifact

Clean export produces a clean delivery artifact while preserving the development project.
gtt clean removes GTT from the current project. It is destructive, so it requires explicit confirmation and offers a recovery snapshot.
Recovery preserves the portable information needed to reconstruct the GTT installation and operational state. It is not a full repository backup.

CI/CD

GTT CLI is designed for automation: deterministic and non-interactive validation, stable operational behavior, machine-readable output, version and compatibility checks, and safe lifecycle operations.

Method vs Bootstrap vs CLI

Layer	What it is	Main responsibility
GTT Method	Methodology	Defines how AI-assisted development is governed.
GTT Bootstrap	Reference implementation	Implements GTT semantics, governance and versioned capabilities.
GTT CLI	Operational tool	Installs, orchestrates, validates, operates, updates, exports and recovers GTT projects.
ADE / Agent	Development environment	Performs development work within the governed project.

The CLI must not become the mind of GTT.

What GTT is not

Not an LLM. GTT does not generate software by itself.
Not an AI coding agent. GTT does not replace Claude Code, Codex, Kiro, Copilot or other ADEs.
Not an IDE. GTT is independent of the development environment used by the developer.
Not only a CLI. The CLI is the operational surface of the methodology.
Not only Bootstrap. Bootstrap is the implementation of the methodology.
Not a prompt library. GTT is a governance methodology with explicit project state, evidence, proposals, decisions, validation and change control.

Get started

Read the methodology: https://github.com/GTT-Community/gtt-method
Explore the reference implementation: https://github.com/GTT-Community/gtt-bootstrap
Install and operate with the CLI: https://gtt-community.github.io/cli

References

GTT Method: https://github.com/GTT-Community/gtt-method
GTT Canonical: https://github.com/GTT-Community/gtt-method/blob/main/GTT-CANONICAL-v2.1.md
GTT Bootstrap: https://github.com/GTT-Community/gtt-bootstrap
GTT CLI: https://github.com/GTT-Community/gtt-cli
GTT CLI releases: https://github.com/GTT-Community/gtt-cli/releases/latest

In one page

GTT is the methodology: it defines how AI-assisted software development is governed. GTT Bootstrap implements that methodology and provides the semantic and governance capabilities a GTT project requires. GTT CLI provides the operational surface for installing, configuring, validating, operating, updating, recovering and exporting GTT projects. AI Development Environments and agents perform the development work inside that governed environment.

GTT METHOD
             Methodology / Governance
                          │
                          ▼
                  GTT BOOTSTRAP
             Reference Implementation
                          │
                          ▼
                      GTT CLI
               Operational Surface
                          │
                          ▼
                    ADE / Agents
                          │
                          ▼
                  Software Development