B. Iterative Research: Fail Quickly and Let It Be Documented

Purpose: The principle "fail quickly and let it be documented" comes from design thinking and agile development. It describes a fundamentally different relationship with failure than the one academic culture typically offers. This document makes the case that this principle applies to research — particularly research that involves AI assistance — and describes what it means in practice: how to scaffold the micro-discovery loops that iterative research depends on, and why documentation is not optional overhead but the mechanism that makes iteration productive.

This document is the conceptual foundation for the B.lifecycle series. The five phase documents describe where in the lifecycle AI is productive and what the feedback signals look like. This document explains why those feedback signals should be actively sought, captured early, and treated as primary research outputs rather than embarrassing deviations from plan.

Two models of research

Model 1: Try not to fail. Plan the research thoroughly. Design the study to succeed. Execute the plan. When things do not go according to plan, manage it, work around it, and report the clean version. Failure is a problem to be avoided and, when it cannot be avoided, concealed. The published paper looks like a waterfall: question → design → data → analysis → conclusion.

Model 2: Fail quickly and let it be documented. Expect failure. Design to discover failures as early as possible. Treat each failure as information about the research problem. Document it, adjust, and iterate. The published paper still looks like a waterfall. The research was a series of redirections, each one cheaper than the one it avoided.

Academic culture runs strongly on Model 1. The conventions of published scholarship — the retrospective clean narrative, the hidden failed hypotheses, the methods section that describes what worked not what was tried — actively conceal the iterative reality of how research is produced. This concealment has costs: researchers who encounter the normal difficulties of research feel they are failing in some unusual way; teams do not share what did not work; the same mistakes get made independently by different researchers.

Model 2 is not a rejection of rigour. It is a different account of where rigour lives — not in avoiding failure but in processing it honestly and systematically.

The cost curve of failure

Not all failure is equally expensive. The same fundamental problem — a research question that cannot be answered with the available evidence, a method that does not fit the phenomenon, a coding scheme that does not carve the material at its joints — costs different amounts depending on when it is discovered.

Cost of discovering the problem
         │
    High │                                         ████
         │                                    ████
         │                               ████
         │                          ████
    Low  │  ████████████████████████
         └──────────────────────────────────────────────→
            Question  Literature  Data      Analysis  Manuscript
            formation engagement  capture

A research question that is wrong costs hours to discover during literature synthesis. It costs months to discover during manuscript writing. A data collection design that cannot produce the needed evidence costs a pilot week to discover early. It costs a year of fieldwork to discover late.

"Fail quickly" is not a preference for failure. It is a preference for early failure — for actively working to surface problems at the stage where they are cheapest to address, rather than hoping they will not appear and discovering them after the cost has compounded.

This reframes what "testing" means in research. A pilot study is not a smaller version of the full study. It is a structured attempt to make the design fail quickly, so that the full study can be designed to succeed. A pre-mortem is not pessimism. It is an attempt to discover the most likely failures in advance, when they can still be avoided.

What AI changes

AI does not make research fail less. It compresses the time and cost of each iteration cycle.

In traditional research, the feedback loop between "collect data" and "discover the design problem" might take weeks or months — because processing the data takes that long. When processing is compressed to hours, the same loop runs faster. The problem that would have been discovered at month three is discovered at week two. The redirect happens earlier, when it is cheaper.

This is the mechanism behind the claim in B.lifecycle that AI enables "more agile research, not just more efficient research." Agility is not speed — it is the ability to respond to discoveries before they become embedded in irreversible commitments. AI's processing speed directly increases research agility by shortening the feedback loops between phases.

The same principle applies within phases. During data collection, rapid processing of incoming material — running OCR, extracting entities, doing first-pass synthesis — means that what you find today can redirect what you look for tomorrow, rather than redirecting what you look for in three months when processing is complete.

The faster the loops run, the more iterations fit within a project lifecycle, and the closer to a viable design you arrive before the high-cost phases of full data collection and analysis.

The two halves: fail quickly AND document

The full principle has two parts, and they are not equally easy.

Fail quickly

This is the half that AI directly supports. Rapid prototyping of research designs, fast processing of early material, anticipatory failure analysis — all of these compress the time between "commit to a direction" and "discover whether that direction works."

Specific practices:

The pre-mortem. Before committing to a research design, run a structured pre-mortem: imagine the project has failed — what happened? List the most plausible failure modes. This is not pessimism; it is a structured attempt to discover predictable failures before they occur. Claude is well-suited to this: "Here is my research design. What are the most likely ways this could fail to produce the evidence I need? What assumptions am I making that might not hold?" The pre-mortem does not prevent all failures — it prevents the most obvious ones, which are often the most expensive.

The minimum viable pilot. Before committing to full data collection, design the smallest version of the study that could tell you whether the approach works. Not a miniature of the full study — a targeted probe designed specifically to fail quickly if it is going to fail. What is the one thing that most needs to be true for this approach to work? Can you test that one thing with a week of work rather than six months?

Anticipatory signals. At the start of each phase, identify what failure would look like in this specific phase. What data would suggest the research question needs to change? What pattern in the first interviews would indicate the method is not right? What would you see in the first batch of archival material that would send you back to the design? Naming the signal in advance makes it visible when it appears.

Rapid early synthesis. Process the first material of each phase as quickly as possible — not to reach conclusions, but to detect systematic problems before they propagate. Ten interviews processed immediately reveal more about method problems than fifty interviews processed at the end.

Include verification instructions in the task. The single highest-leverage addition to any AI-assisted task is telling Claude what correct output looks like — before it runs. "Process the first 3 files and show me a sample row before continuing" or "After extraction, count the total rows and flag any file with zero extractions" are not extra steps; they are the mechanism by which you catch systematic errors at cost-1 rather than cost-40. This is the practical form of the "fail quickly" principle at the individual task level: design each task so that failure surfaces immediately, not after the full batch completes.

Let it be documented

This is the harder half — not technically, but culturally and practically.

Documentation of failure is uncomfortable. It requires admitting that the first version of the research question was not right, that the first design did not work, that the coding scheme needed three revisions before it fit the material. Academic culture trains researchers to present the polished retrospective, not the iterative mess. Documentation violates that reflex.

It is also practically difficult because Claude does not remember between sessions. Undocumented micro-discoveries simply disappear — the insight from Tuesday's processing is not available to Friday's session unless someone wrote it down. The documentation is the memory.

What documentation of productive failure looks like:

The redirect record. Every time a micro-discovery changes the direction of the project — a revised hypothesis, an adjusted method, an expanded scope, a narrowed question — record it. Not just what changed, but why: what was found, what it meant, what the new direction is. This is the project's actual intellectual history, more informative than any summary of what the final design looked like.

The abandoned hypothesis. When a working hypothesis is falsified or abandoned, document it alongside the reason. The abandoned hypothesis is not wasted work — it is the evidence that the current hypothesis has been tested. A research project that cannot show what it has ruled out has not established what it claims to have established.

The version history of the research question. The research question at the end of a project is often different from the question at the start. Tracking that evolution — version 1 was this, it failed for this reason, version 2 adjusted by this, version 3 is the current formulation — is both intellectually honest and practically useful. When manuscript writing sends you back to the question, you need to know where the question has been.

The pattern across failures. As micro-discoveries accumulate, they may cluster around a persistent problem — the same assumption keeps failing, the same category keeps not fitting, the same kind of source keeps turning up unexpectedly. Claude can help identify these patterns across a session's worth of documented discoveries. A pattern of failures is more informative than any individual failure.

Scaffolding the micro-discovery loops

A scaffold for iterative research is a structure that makes the loops explicit, supports their documentation, and keeps the learning from each iteration available for subsequent iterations. It has three moments.

Before: design the iteration

Before each significant phase, session, or data collection block, answer three questions:

  1. What am I looking for? — the expected finding, the hypothesis being tested
  2. What would failure look like? — the specific signal that would indicate this approach is not working
  3. What would I do if it fails? — the redirect, so that when the signal appears you respond rather than continue

These questions can be answered in five minutes. Claude can help: describe the next phase of your project and ask "What signals in this phase should prompt me to reconsider my design?" The act of answering forces clarity about what you are actually testing and what would count as a negative result.

During: process close to collection

The scaffold during a phase is fast processing — keeping the gap between "collect material" and "synthesise what was collected" as small as possible. Daily or weekly synthesis of incoming material, rather than processing everything at the end.

For DISSINET-scale corpus work: batch processing of each day's or week's scans, with a brief structured summary of what the batch revealed — new entities, unexpected patterns, gaps or contradictions relative to the working hypothesis. This summary is the micro-discovery record for that iteration.

After: capture and close the loop

After each significant phase or discovery, a structured capture:

This does not need to be long. Two hundred words per major micro-discovery is enough. The discipline is doing it immediately — before the next session, while the reasoning is still accessible.

The project infrastructure as iteration scaffold

The project infrastructure described across the A-docs is already, in part, an iteration scaffold. Reframing it as such changes what goes into it.

CLAUDE.md is not just a briefing document — it is the current state of the research design after all iterations to date. When it is updated to reflect a redirect, it captures the current version of the research question, the current method, the current constraints. A CLAUDE.md that is never updated is a record of version 1 that is being used to guide version 7.

The project history file (_history.md pattern — see A.markdown.history) is the iteration log: the record of what changed, when, and why. Used as an iteration scaffold, it is not just a narrative of what happened — it is an explicit record of the redirects, the abandoned hypotheses, the micro-discoveries that changed the direction. This is the documentation half of "fail quickly and let it be documented."

Session notes and progress files. A brief structured note at the end of each session — what was found, what it changes, what the next session should look for — is the smallest unit of iteration documentation. Claude can help draft these: "Based on what we did today, summarise what changed in the research design and what the most important open questions are." The output is the record.

Together, these three components — current state (CLAUDE.md), iteration log (_history.md), session notes — constitute a research memory that survives between sessions and makes each iteration available to subsequent ones.

The cultural dimension

"Fail quickly and let it be documented" requires a culture that normalises iteration and treats documented failure as a research output rather than a source of embarrassment. This is not the default in academic humanities research.

The conventions of academic publication reward the clean retrospective narrative. Researchers learn, over time, to present work as if it always pointed in the direction it ended up. The failed hypotheses, the abandoned designs, the redirects — these disappear from the public record. They also, over time, disappear from internal documentation, because documenting them feels like documenting failure.

Changing this requires naming the principle explicitly. In a team context, it requires a shared norm: we document our redirects; we share what did not work; we treat the iteration log as a collective resource rather than a private embarrassment. The pre-mortem becomes a team practice, not just an individual habit. The project history file is shared, not hidden.

The conversation about "here is what we tried and why it didn't work" is structurally the same as "here is my draft, what do you think?" — both require bringing unfinished work into a shared space and trusting that the response will be constructive. A team that already has habits of sharing draft work and giving each other direct feedback has a head start on this; a team without that culture will need to build it deliberately rather than assume the iteration log will get used the way it is meant to.

Iterative research and intellectual ownership

A final note on the relationship between "fail quickly" and intellectual ownership.

The redirects — the decisions to change the research question, revise the design, abandon a hypothesis — are among the most important intellectual acts in a research project. They require judgment, field knowledge, and accountability to a scholarly community. They are also the moments most at risk of being short-circuited by AI involvement: Claude suggests a new direction, the researcher accepts it without fully evaluating it, and the redirect happens without the researcher having actually done the intellectual work of deciding.

The pre-mortem, the anticipatory signal identification, the structured redirect record — these are all practices that keep the researcher's judgment in the driver's seat at the moments that matter most. The scaffold supports the iteration; the intellectual decisions within each iteration remain the researcher's responsibility.

Failing quickly, documented honestly, with the redirects owned by the researcher: this is the iterative research practice that AI makes newly available at scale without displacing the human intellectual work that gives research its meaning.

Related