Cassette Build Report 005 — Eighty Questions Need a Stopping Rule
Cassette became buildable only after I turned its open engineering problem into a finite queue with decisions, proof, and reopening conditions.
Scope note: This post explains the research method Cassette uses to turn unresolved engineering questions into build decisions. It does not present the queue as proof that the final system will work.
A question this large can keep producing questions forever.
Once I restored the opening architecture, I asked for the unresolved engineering questions: lawful model acquisition, download and conversion, removable-drive durability, Apple memory behavior, latency, training state, rollback, model revision, client protocols, quality, and proof that the full parameter capacity still mattered.
The list grew to eighty questions.
That number was not a badge of seriousness. It created a second risk. Research can remain active forever when every answer discovers three respectable side questions. The work can look disciplined while delaying the decision that the implementation needs.
I wanted a method that knew when an answer was complete enough to use. I asked for a reusable skill that would take a finite queue, resolve each question, and reach a clear “this is the answer, moving on.” The intended recipient was another agent that would build Cassette, not a reader choosing among recommendations.
Each answer therefore had to contain more than a conclusion. It needed the relevant equations, data structures, protocols, build instructions, acceptance checks, and conditions under which the answer should be reopened. The next agent needed to know what to implement and what evidence would prove the implementation wrong.
That request produced recluse-build-directed-research.
The skill made the queue executable. A question could be closed only after the answer had been checked against the original remit, related decisions, and the physical operation it claimed to support. A decision could be reopened if new evidence crossed a stated boundary. A nearby topic did not enter the queue merely because it was interesting.
This is a different use of research from collecting a literature review. A literature review can tell me what other people have said. Cassette needs to decide how bytes move, what state exists, which component owns a transition, what a failure leaves behind, and what the build must measure. Papers can inform those decisions. They cannot make them for us.
The method also changes the role of the agent. An agent is not asked to keep talking until the subject feels thoroughly discussed. It is asked to resolve one question under an explicit scope, record what it knows, and leave the queue in a state the next agent can trust. That constraint is useful because an agent’s fluency can make unfinished work sound complete.
I care about this beyond Cassette. Many AI projects are described as research when they are still collecting possibilities, and as engineering when they have only demonstrated a narrow path. A finite queue does not remove uncertainty. It makes uncertainty visible, assigns it a decision, and prevents the project from hiding inside its own vocabulary.
The queue is not the product. It is the agreement about how the product will stop being a question.