The Completion Gradient Protocol
A staged multi-intelligence method for moving a remembered project from almost specified to human-accepted
Abstract
AI project work commonly fails at the boundary between almost coherent and coherent enough to build. A model can generate a long specification, but the human cannot easily see which decisions were authored, which were assumed, what remains unresolved, or whether a later critic improved the project or silently replaced its target.
The Completion Gradient Protocol (CGP), also presented as Hayden's Elite Workflow Method, converts that boundary into an explicit staged process. A memory-rich primary intelligence drafts toward an operator-selected specification target, normally 80–90%. It expresses the remaining distance as consequential questions. The human may answer those questions or delegate them to a context-separated second intelligence. That second intelligence also returns an overall critique, but in a separate file. The primary intelligence closes the specification from the answers before the critique is disclosed, then adjudicates the critique using its fuller project memory. The specification may become 100% dispositioned, while project completion remains capped at 99% until explicit human acceptance.
The method is implemented as a public deterministic instrument and reusable AI instruction packet. Its originating success is founder-reported operational evidence, not a controlled benchmark. Claims that the method improves quality, speed, or model calibration remain unestablished.
1. The problem is not the first 80%
The early majority of a project is unusually easy for a capable model. A user can describe an idea, attach references, discuss constraints, and receive a specification whose breadth feels nearly complete. The difficulty appears afterward.
Three failures tend to collapse together:
- Hidden remainder. The model fills unresolved decisions with plausible language instead of naming what it does not yet know.
- Friction cliff. The human receives dozens of questions in an unstructured exchange and stops because answering them costs more attention than initiating the project.
- Target drift. A later reviewer sees genuine weaknesses but lacks the project history, so its critique pulls the work toward a different project.
Ordinary chat has no stable primitive for “this object is coherent to a declared degree, and this named gradient still separates it from its intended gestalt.” It therefore alternates between vague incompleteness and premature declarations of completion.
CGP treats the remainder as the primary work object.
2. Completion requires opposition
A percentage alone is decorative. “The specification is 85% complete” has no operational meaning until the current specification is opposed by a declared completion contract.
Let:
- (W_t) be the current working object at stage (t);
- (G) be the target gestalt expressed as a completion contract;
- (p) be the chosen first-pass coverage target;
- (\Delta_p) be the material decisions, constraints, evidence, and acceptance conditions not yet dispositioned in (W_p).
The useful relationship is not a numerical claim about quality. It is:
working object Wp
opposed by
completion contract G
exposes
question-addressable gap Δp
The percentage is therefore a control parameter for the intelligence layer. It instructs the primary intelligence how aggressively to close the contract before stopping to externalize the remainder. It is not:
- model confidence;
- empirical accuracy;
- proof of requirement coverage;
- a universal quality score;
- authorization to call the project done.
The metric becomes useful only when the completion contract names what must be decided, specified, materialized, verified, and accepted.
3. The canonical artifact chain
The protocol materializes seven files:
SPEC-p.md
QUESTIONS-TO-100.md
ANSWERS.md
CRITIQUE.md
SPEC-100.md
CRITIQUE-APPLICATION-LOG.md
ACCEPTANCE-REQUEST.md
Each file has one responsibility.
3.1 SPEC-p.md
The primary intelligence drafts toward the selected target (p). It preserves accepted decisions, constraints, rejected directions, vocabulary, aesthetic intent, technical boundaries, and project history. It does not silently invent high-impact unknowns simply to reach the target.
3.2 QUESTIONS-TO-100.md
The primary intelligence converts (\Delta_p) into a bounded question set. Each question states why the answer matters, what it changes downstream, a safe recommended default where one exists, and whether the decision requires the human.
This file is the decisive move. Unknown work becomes addressable work.
3.3 ANSWERS.md
The user chooses the friction level:
- authorship lane: the human answers in their own words;
- low-friction lane: a context-separated intelligence answers, labeling uncertain answers as assumptions.
The protocol does not pretend these lanes are identical. The first preserves more direct human authorship. The second preserves momentum. Both return the same numbered answer interface.
3.4 CRITIQUE.md
The independent intelligence also reviews the overall project as a cold-started reader. It receives the current specification and completion questions, but not necessarily the full project conversation. Its critique is valuable precisely because it does not share every assumption of the primary thread.
The critique must remain separate from the answers. Answers close the declared target. Critique tests whether the target or implementation is weak.
3.5 SPEC-100.md
The primary intelligence integrates ANSWERS.md into its fuller project memory. At this point, “100” means every item in the declared specification contract has a disposition. It may be decided, constrained, delegated, deferred, or explicitly excluded. It does not mean the product is built correctly or accepted.
3.6 CRITIQUE-APPLICATION-LOG.md
After baseline closure, the primary intelligence receives the critique and records each item:
APPLIED;ADAPTED;REJECTED;DEFERRED.
The classification prevents criticism from disappearing into an untraceable rewrite.
3.7 ACCEPTANCE-REQUEST.md
The final machine return names what was materialized, what was verified, what remains limited, and what the human must inspect. The AI reports at most 99% project completion and requests an explicit verdict.
4. The blind closure gate
The protocol's most important rule is temporal:
QUESTIONS
↓
ANSWERS
↓
SPEC-100
│
├── critique remains sealed
↓
reveal CRITIQUE
↓
memory-aware adjudication
The primary intelligence closes the answer-based specification before reading the critique.
This is not secrecy for its own sake. It prevents review-induced target substitution. A cold-start critic can identify real defects while still misunderstanding the user's taste, prior decisions, constraints, emotional target, or deliberate exclusions. If critique enters before closure, the critic may define what “complete” means before the memory-rich intelligence finishes the user's own contract.
After closure, the same critique becomes safer. The primary intelligence now has a coherent baseline against which to test each suggestion. It can distinguish “this reveals a defect” from “this proposes a different project.”
The strongest implementation withholds the critique artifact technically until SPEC-100.md exists. The founder-tested practice used ordinary chat boundaries: the critique file could be present, while the primary intelligence was instructed first to complete the answer-based work without being told to consult it. A production implementation should prefer an enforceable staged disclosure gate.
5. Why a cold critic returns to a warm primary
Multi-model workflows often treat the second model as a superior answer source or ask multiple agents to vote. CGP uses a different division.
The second intelligence provides distance. The primary intelligence provides continuity.
The cold critic can notice:
- missing reader context;
- weak interfaces between sections;
- unexplained assumptions;
- incomplete failure behavior;
- implementation ambiguity;
- contradictions visible to a new entrant.
The warm primary can judge:
- whether an apparent omission was deliberate;
- whether a suggested feature violates the user's doctrine;
- whether a technical “improvement” breaks the desired experience;
- whether the critic is optimizing the wrong user, platform, budget, or time horizon;
- whether the issue has already been resolved elsewhere in project memory.
The critic does not own canon. The primary does not escape pressure. The staged relationship preserves both.
6. Two distinct meanings of 100%
The method distinguishes specification completeness from project acceptance.
6.1 One hundred percent specified
A specification is 100% dispositioned when the declared contract contains no silent high-impact unknowns. Every item is:
- decided;
- bounded by a rule;
- delegated to a named later stage;
- deferred with a reason;
- excluded from scope;
- or explicitly waiting on evidence or human choice.
This is possible before implementation.
6.2 Ninety-nine percent machine complete
An AI system may produce the artifact, execute allowed checks, compare the result against the contract, and return evidence. It still cannot self-authorize the final state transition.
The remaining 1% represents human authority rather than unfinished polish:
machine: proposed → materialized → verified → 99%
human: accept / revise / reopen
This aligns with the broader Glyphd rule: verification is not acceptance.
7. Why the protocol reduces user friction without erasing the user
The system exposes a meaningful choice.
If the user wants to shape the last 10–20% personally, the questions create a compact authored aperture. The user does not need to rewrite the full project or restate its history. They answer only decisions whose consequences remain open.
If the user is tired, busy, or simply trusts the default direction, the independent intelligence can answer. Momentum survives. Crucially, those answers remain visible as an artifact, and uncertain answers remain assumptions rather than being smuggled into a polished specification.
This is not laziness as failure. It is friction allocation. The user spends agency where they want it and delegates the rest without losing the structure needed to inspect what happened.
8. Failure modes and stop conditions
The protocol fails when:
- No completion contract exists. The number becomes theater.
- The first-pass model silently closes consequential unknowns. The question gap is falsified.
- Answers and critique are blended. Closure and target pressure become indistinguishable.
- Critique is revealed before baseline closure. The project is vulnerable to target substitution.
- The cold critic writes canon directly. Context separation becomes authority expansion.
- The primary dismisses critique without an application log. Continuity becomes insulation.
- “100% specified” is presented as “correctly built.” Specification and evidence collapse.
- An AI commits DONE. Verification and acceptance collapse.
High-stakes medical, legal, financial, safety-critical, structural, or security work also requires domain-qualified human review. A completion gradient does not create competence or authority the system does not possess.
9. Evidence state
The present evidence has two layers.
Implemented
Glyphd Labs publishes:
- the canonical method;
- a deterministic browser instrument;
- an adjustable target from 60–99%;
- human and independent-AI answer lanes;
- the blind critique gate;
- the required file chain;
- an AI-readable Markdown entry packet;
- a human-only acceptance boundary.
This supports the note-level state IMPLEMENTED.
Founder-reported operational success
Hayden Lindley reports that the exact staged workflow successfully closed a real project after extended attempts to solve project continuity and completion. The originating record includes the process description and a handwritten flow sketch dated July 30, 2026.
This is meaningful origin evidence. It is not a matched-condition benchmark, a calibrated percentage study, or independent reproduction.
10. Benchmarkable claims
A future study should compare at least:
- single-model unstructured specification;
- primary model plus user question answering;
- primary plus independent answers with critique revealed early;
- full CGP with blind baseline closure;
- expert human project editor.
Candidate measures include:
- unresolved consequential decision count;
- hidden-assumption count;
- intent preservation under blind human review;
- specification contradiction rate;
- revision count after implementation begins;
- time and user interaction required to reach an accepted spec;
- cold-reader comprehension;
- critic recommendation acceptance, adaptation, rejection, and reversal rates;
- implementation rework attributable to specification gaps;
- difference between predicted percentage and rubric-scored coverage.
Any numerical benefit claim requires versioned project inputs, model identities, prompts, outputs, reviewer rubrics, raw ratings, limitations, and receipts.
11. Relationship to the Glyphd program
CGP is an applied bridge among several Glyphd mechanisms:
- The Manifestation Gap explains why generated project language is not completion.
- Generated Operational Memory supplies the warm primary with accepted project state rather than a lossy recollection.
- WorkPage OS gives the completion contract and question gap an operable surface.
- Spark-Dex can represent proposed, accepted, materialized, verified, stale, and refused work.
- Work / Return / Verification / Acceptance preserves the final human-only commit.
The protocol's new contribution is the ordered gradient closure cycle: target, question gap, optional answer delegation, separate cold critique, blind closure, memory-aware adjudication, and human acceptance.
12. Reusable execution packet
The public instrument generates the complete packet and exposes a static default at:
/protocols/hayden-completion-gradient.md
The default uses an 85% first pass and a 15% question gap. The instrument may generate other targets up to the 99% machine ceiling.
Publication boundary
This note records the public workflow architecture, staged artifacts, execution prompt, and evidence limits. It does not claim that the percentage is objectively calibrated, that the method is universally optimal, that a second model always improves a project, or that a complete specification guarantees a successful product.
Source register
- N18-S01 — Hayden Lindley, founder-recorded Completion Gradient workflow description and handwritten process sketch, July 30, 2026. Private source bytes retained outside the public site; SHA-256
28bcc6232d428b9df59418a5fc8bc6952315d6c9574337b2dce1beb43dedf99e. - N18-S02 — “Generating Language Is Not the Same as Doing What the Language Says,” Glyphd Labs P01.
- N18-S03 — “From Conversation to Project Core,” Glyphd Labs P08.
- N18-S04 — “Work, Return, Verification, Acceptance,” Glyphd Labs N05.
- N18-S05 — “Spark-Dex: A Manifestation Sidecar for IDE Agents,” Glyphd Labs N17.