Skip to content
H1VE

The Method

How H1VE actually works.

The mechanics of the method — the cycle every feature flows through, the artifacts that carry the work, the gates where judgment enters, and what to measure.

See also: The RolesGet Started

01

The cycle

Work flows through a defined sequence. Nothing skips a step, and the system shows where everything stands in real time. The cycle has two parts: a one-time foundation, then a repeating feature loop.

The foundation — once, at the start

Before the first line of code, the project must exist on paper. The founder and architect, assisted by the AI, produce four documents: vision and scope, functional specification, technical specification, and the roadmap. These are the cake; every spec that follows is a slice.

Why this matters

Skipping the foundation is the most common failure. The team codes fast but with no shared north — the AI invents decisions, two devs contradict each other. The foundation costs days and saves weeks.

The feature loop — repeats per slice

Each feature moves through nine stages, and can be parked as blocked from any of them.

  1. Backlog
  2. Spec
  3. Dev + AI
  4. PR
  5. CI
  6. QA + Data
  7. Architect
  8. Main

A feature can be born in the backlog without an owner, but it cannot enter development without one. Assigning an owner is a precondition for work — control by design.

02

The artifacts

H1VE runs on a small set of living documents. Each has a job, a moment, and an owner.

The foundation documents

Vision & Scope
Why the product exists, for whom, and its limits. Founder-led.
Functional Spec
What the product does, from the user's view. Founder + architect.
Technical Spec
How it's built: stack, data model, APIs, decisions. Architect-led.
Roadmap
The scope sliced into phases. Each item becomes a spec. A living document.

The per-feature documents

SPEC-NNN
Created and approved before any code. Defines scope, files touched, acceptance criteria, risks.
DONE-NNN
Created at the end, before the PR. What changed, how to test, the AI declaration.

The memory document

CLAUDE.md
The living memory of the project: stack, non-negotiable rules, critical files, current state. Read before every session, updated after.

The AI declaration

Every PR records which files the AI generated and how much each was reviewed. Not bureaucracy — it tells reviewers where to focus, and makes the whole system auditable.

03

The gates

The gates are where human judgment enters and where quality is enforced rather than hoped for. There are three, in sequence.

Gate 1

CI — automated

The machine checks the machine: type checks, linting, the test suite. Objective and fast. A failure returns the feature to dev. Necessary, but not sufficient — it catches what is mechanically wrong, not what is wrong in judgment.

Gate 2

QA and Data — the double gate

The signature of H1VE. Two independent humans, validating two kinds of risk, neither of whom wrote the code. QA asks: does it do what the spec says? Data asks: is the schema sound? The feature advances only when both sign off — then it moves to the architect automatically.

Why two gates, not one

AI fails differently with logic than with data. Code can be functionally correct and still corrupt the schema silently. One reviewer misses one of the two; two independent gates catch both.

Gate 3

The architect — the merge

The final human gate. The architect reviews the complete picture — CI green, both sign-offs, the DONE written — and merges into main. This authority is exclusive. The AI never merges.

04

The metrics

H1VE measures the health of the system, not the busyness of people.

CI pass rate
Share of CI runs that pass. Below ~80% signals a systemic problem — stop adding features until you know why.
Cycle time
How long a feature takes from spec to main. Rising means a bottleneck — often the architect's queue.
Gate health
How often features are rejected at QA or Data, and why. A pattern points to weak specs or AI errors slipping through.
Blocker age
How long blockers stay open. More than a few days needs direct intervention.
Architect queue
Features waiting on the final gate. A growing queue means the bottleneck is the merge.

Measure the system

These describe the flow, not individuals. Velocity that hides a broken gate is worse than slowness that keeps quality.

05

When to use it

H1VE fits teams that use AI agents as a primary way to write software and that care about quality, traceability, and accountability. Honesty about fit is part of the method.

Use H1VE when

  • Multiple developers work in parallel, each with an AI agent
  • A silent bug in production is costly
  • Someone must answer “who decided this, and why?”
  • The team is scaling and ad-hoc coordination is breaking

It's overkill when

  • A solo throwaway prototype no one will maintain
  • A one-off script with no review needs
  • A team that doesn't use AI agents at all

The value comes from governing generated code at some scale of risk. No risk, no need for the gates.

06

Glossary

The shared vocabulary of H1VE. A common language is what turns a practice into a profession.

Gate
A checkpoint where work must be validated before advancing. H1VE has three: CI, the double QA+Data gate, and the architect's merge.
Double gate
The defining mechanism: QA and Data validating independently, both required to advance.
Spec (SPEC-NNN)
The approved definition of a unit of work, written and approved before any code.
Done (DONE-NNN)
The closing record of a feature: what changed, how to test, what the AI generated.
AI declaration
The record, per PR, of which files were AI-generated and how much each was reviewed.
Appetite
The time a team is willing to spend on a feature. Scope bends to fit the appetite, not the reverse.
Swim lane
The visual board of nine stages showing where every feature stands in real time.
Stage
One position in the cycle: backlog, spec, dev, PR, CI, QA+Data, architect, main, or blocked.
Foundation
The four documents that define a project before the first spec.
CLAUDE.md
The living memory of a project, read before each session and updated after.
Reference implementation
A tool that implements the H1VE method. The method is tool-neutral; an implementation makes it operable.

Ready to run it with your team?

The method is only real when a team ships under it. Get Started takes you from zero to your first slice.