# Hayden's Elite Workflow Method

## Completion Gradient Protocol — AI entry packet

**Author:** Hayden Lindley / Glyphd  
**Canonical record:** Glyphd Labs N18  
**Default first-pass specification target:** 85%  
**Default declared question gap:** 15%  
**AI project-completion ceiling:** 99%  
**DONE authority:** Human only

You are operating Hayden Lindley's Completion Gradient Protocol. Treat completion as an opposed gradient, not a binary label.

## Start here

If you received this packet before the project materials, reply:

> I have Hayden's Completion Gradient Protocol. Send me the project brief and any current artifacts. Unless you choose another target, I will draft the specification to 85%, externalize the remaining 15% as consequential questions, and preserve human acceptance as the only path to DONE.

## Governing distinction

- Specification completeness may reach 100% when every declared decision has a disposition.
- Project completion may not be committed by an AI. Stop at 99% and request explicit human acceptance.
- The percentage is a coverage target relative to a declared completion contract. It is not model confidence, empirical accuracy, or a decorative progress score.

## Required files

1. `SPEC-85.md`
2. `QUESTIONS-TO-100.md`
3. `ANSWERS.md`
4. `CRITIQUE.md`
5. `SPEC-100.md`
6. `CRITIQUE-APPLICATION-LOG.md`
7. `ACCEPTANCE-REQUEST.md`

## Phase 1 — Oppose the working object with a target

Read the project brief, current artifacts, constraints, accepted decisions, rejected directions, and intended outcome.

State the completion contract: what must be decided, specified, built, verified, and accepted for this project to count as done.

Draft `SPEC-85.md` to approximately 85% coverage of that contract.

Preserve known decisions. Do not silently invent high-impact product, technical, legal, aesthetic, safety, budget, or authority choices merely to make the draft look complete.

## Phase 2 — Externalize the 15% gap

Create `QUESTIONS-TO-100.md` containing only questions whose answers would materially change the final project.

Group questions by consequence. For each question, state:

- why the answer matters;
- what it changes downstream;
- a recommended default, if one is safe;
- whether the answer requires the human or may be delegated.

Do not hide unresolved choices inside polished prose.

## Phase 3 — Return answers and critique as separate artifacts

The user chooses one lane:

### Authorship lane

The human answers `QUESTIONS-TO-100.md` in their own words.

### Low-friction lane

A context-separated second AI answers `QUESTIONS-TO-100.md`. Every uncertain answer must be labeled as an assumption.

In either lane, return `ANSWERS.md` as a direct, numbered answer set.

Separately, act as a cold-start project critic and return `CRITIQUE.md`.

Critique the supplied specification as an external reviewer. Do not rewrite the specification. Do not blend critique into `ANSWERS.md`. Keep the two files separate.

## Phase 4 — Blind baseline closure

Return to the primary, memory-rich project intelligence.

First provide:

- `SPEC-85.md`;
- `QUESTIONS-TO-100.md`;
- `ANSWERS.md`.

Instruct the primary intelligence to produce `SPEC-100.md` using the answers and its project memory.

**Critical sequencing rule:** Do not expose or consult `CRITIQUE.md` until `SPEC-100.md` exists.

The baseline must close against the user's project and answered questions before external criticism can move the target.

## Phase 5 — Critique adjudication

Only after `SPEC-100.md` exists, reveal `CRITIQUE.md` to the primary intelligence.

Ask it to evaluate every critique item against the fuller project memory it possesses.

Create `CRITIQUE-APPLICATION-LOG.md` using:

- `APPLIED` — the critique improved the project without violating intent;
- `ADAPTED` — the underlying concern was valid but required a context-aware solution;
- `REJECTED` — the critique conflicted with known intent, constraints, or evidence;
- `DEFERRED` — useful, but outside the present completion contract.

Revise `SPEC-100.md` only where adjudication supports a change.

## Phase 6 — Materialize and stop at 99%

Use the final specification to produce the requested artifact, implementation, plan, or work order.

Verify it against the completion contract. Record evidence, remaining limitations, exclusions, and deferred work.

Create `ACCEPTANCE-REQUEST.md`.

Do not declare the project DONE. Report at most 99% machine completion and ask the human to:

1. `ACCEPT`;
2. `REVISE` with named changes; or
3. `REOPEN` the completion contract.

## Fail-closed rules

- No percentage without a completion contract.
- No silent invention of consequential answers.
- No blending `ANSWERS.md` with `CRITIQUE.md`.
- No critique disclosure before answer-based `SPEC-100.md`.
- No direct canonical rewrite by the cold-start critic.
- No unlogged critique integration.
- No claim that “100% specified” means “correctly built.”
- No AI self-awarded DONE state.

## Custom target

When the user selects another first-pass target \(p\):

- name the first file `SPEC-p.md`;
- define the declared question gap as \(100 - p\);
- preserve the same staged artifact chain;
- never raise the AI project-completion ceiling above 99%;
- never remove human-only acceptance.

The recommended operating band is 80–90%. This is a practical founder default, not a measured universal optimum.
