Brainstorming Before Planning: Engineering a Persistent Research Loop

by Timothy D Meadows II

A plan can be internally consistent and still solve the wrong problem.

It can contain sensible milestones, a plausible architecture, and a thorough testing strategy while depending on an audience that has never been established, a capability that does not exist, or a requirement that nobody actually agreed to.

The problem is not necessarily poor planning. It is allowing planning to begin before there is a sufficiently developed understanding of what is being planned.

I treat that gap as a separate engineering problem: how do we turn an uncertain idea into a researched, bounded, inspectable input without prematurely converting it into implementation work?

My answer is a persistent brainstorming mode built around an explicit control loop. It has durable state, a fixed research team, stable identifiers, evidence requirements, validation rules, and a deliberate handoff to planning.

The important distinction is that this is not a request for an AI to “think harder.” It is a protocol governing what the system may do while understanding is still being developed.

Discovery Is Not Planning

Discovery, planning, and implementation answer different questions.

Discovery asks what the idea means, what supports it, what remains uncertain, and what a successful outcome would look like.

Planning asks how to reach that outcome under the established constraints.

Implementation performs the authorized work and produces evidence that the result meets its requirements.

The relationship is straightforward:

Uncertain idea  
    -> Clarification and research
    -> Plan-ready element
    -> Explicit selection for planning
    -> Authorized execution

The arrows are transitions, not automatic consequences.

A thoroughly researched idea does not authorize a plan. A plan does not authorize every operation required to implement it. A successful implementation does not, by itself, authorize publication or deployment.

This gives the discovery stage an important invariant:

While brainstorming is active:

    Discovery state may change.
    Delivery state must not change.

The system may capture ideas, ask questions, inspect permitted sources, conduct research, reconcile findings, and update its discovery document. It must not create implementation tasks, issues, delivery branches, commits, or pull requests. Existing delivery artifacts do not become writable merely because they already exist.

“Create a quick prototype to check the idea” also crosses this boundary. Discovery can establish that a prototype is needed and define the question it should answer. Building that prototype belongs to a separately authorized execution stage.

A Persistent Mode, Not a Conversational Mood

The mode must survive a new conversation, a context reset, and an agent restart.

That requires durable state rather than an instruction that exists only in the current transcript. A simple implementation uses a repository-root document named BRAINSTORM.md.

Its mode metadata might look like this:

## Mode
- Status: active
- Active session: BS-003
- Activated at: 2026-09-28T16:00:00Z
- Deactivated at: pending

There are two legitimate stored mode values: active and inactive. The loader also needs two operational outcomes: absent, when no discovery document exists, and malformed, when a document exists but cannot be safely interpreted.

These outcomes are not interchangeable.

An absent document means the optional discovery stage has not been established. Normal planning can follow its ordinary authorization rules. A malformed document means the system cannot establish whether discovery restrictions apply. It must not interpret that uncertainty as permission to proceed.

Absent:  
    Follow the normal workflow's authorization rules.

Active:  
    Permit discovery operations only.

Inactive:  
    Validate the retained document and its exit index
    before accepting a discovery-to-planning handoff.

Malformed:  
    Block state-changing operations until repaired.

This is an application of deny-by-default authorization. OWASP recommends both denying access by default and validating permissions on every request; checking mode only at session startup is insufficient when later operations can mutate state.[1]

Activation and deactivation must be explicit. A casual request to “brainstorm some names” is not necessarily a request to activate a persistent repository-wide restriction. Conversely, inactivity, a new conversation, or an apparently complete idea is not a request to deactivate one.

Repeated activation while already active should be idempotent: no new session, no reset, and no rewritten idea history. Reactivation after an explicit exit creates a new session identifier while retaining existing branches and ideas.

A session is an activation interval, not a chat window.

Figure 1. The outer loop is a persistent mode, not a chat session. Both researcher roles must be available before activation or resumed idea processing. New conversations reload the stored mode; readiness alone does not exit it.

The Team Has Exactly Three Participants

The research topology consists of one coordinator and two researchers.

The coordinator acts as the project manager. It owns clarification, branch placement, reconciliation, lifecycle decisions, and all writes to the canonical discovery document.

The first researcher investigates the problem side: audience, domain, comparable approaches, precedent, and whether the proposed idea addresses a recognizable need.

The second researcher investigates the feasibility side: technical constraints, dependencies, risks, prerequisites, and observable conditions for completion.

Figure 2. Both research returns feed a single reconciliation step. Researcher reports are evidence inputs, not write permissions or votes authorizing implementation. Only the coordinator publishes the validated synthesis.

The researchers are read-only. They return findings, not patches to shared state. Their intermediate reports remain temporary; the coordinator persists the reconciled result, including the evidence and uncertainty necessary to understand it later.

Both researcher slots must be available before activation or resumed idea processing. When the team cannot be established, processing blocks without changing the durable document. It does not silently degrade into a single researcher, sequential role impersonation, or unassisted coordinator research.

This is a workflow contract, not a claim that three participants are universally optimal. The purpose is to make the required perspectives predictable and to make a missing perspective visible.

The researcher roles persist throughout the active working session. After a restart, the host reconstitutes both roles from the durable state before processing another idea. Persistence does not mean an agent process somehow remains alive between disconnected conversations.

Independence Requires More Than Different Role Names

Both researchers should receive the same established understanding and relevant branch context, but different research questions.

For an initial pass, neither should receive the other's conclusions as instructions. Otherwise, the second pass risks becoming an elaboration of the first rather than a separate investigation.

However, procedural separation is not statistical independence. Two researchers may rely on the same upstream document, inherit the same mistaken premise, or interpret the same ambiguous requirement similarly.

The general probability relationship is:

P(both wrong) = P(first wrong) * P(second wrong | first wrong)

Replacing the conditional term with an independent error rate requires an independence assumption. Merely spawning a second agent does not establish that assumption.

Consequently, agreement is not a substitute for evidence. The coordinator must examine source overlap, assumptions, and reasoning rather than counting matching conclusions.

The Unit of Work Is an Idea, Not a Task

Each materially distinct idea receives a stable identifier such as IDEA-017.

A clarification updates that idea. It does not silently create another element. A genuinely distinct proposal receives another identifier even when it shares an audience, component, or dependency with an existing idea.

For example:

IDEA-017: Let a document editor continue working offline.  
IDEA-018: Add real-time collaborative editing.  
IDEA-019: Display synchronization conflicts to users.

These ideas are related, but they do not have identical completion boundaries. Offline editing might be useful without simultaneous collaboration. Conflict presentation may depend on the synchronization policy chosen elsewhere.

Stable identity allows those relationships to remain understandable even when titles change or ideas move between categories.

Identifiers must never be renumbered for presentation, reassigned to a replacement idea, or reused after an idea is parked. The identifier describes continuity of meaning, not position in a list.

Each element has a small metadata envelope:

Idea identifier  
Title  
Branch identifier  
Lifecycle status  
Created timestamp  
Updated timestamp  
Plan-readiness flag  
One-line summary

The body then contains eight required sections:

User Idea  
Base Understanding  
Research Findings and Citations  
Dependencies  
Risks  
Open Questions  
Start Conditions  
Definition of Complete

The original user idea and established understanding are deliberately separate. The first preserves what was requested. The second records the interpretation developed through clarification.

Without that separation, an agent can gradually rewrite the request until its own assumptions appear to have originated with the user.

Incomplete elements still contain the required sections, with missing work explicitly marked. An honest placeholder is preferable to plausible text inserted only to satisfy a schema.

The Inner Loop: Clarify, Research, Reconcile, Persist

The mode has an outer lifecycle loop and an inner idea-processing loop.

The outer loop remains active until an explicit exit request. The inner loop develops one idea to its next defensible state, which may be clarification, further research, readiness, or parking.

Conceptually:

Figure 3. The inner loop advances an idea to its next defensible state, not necessarily to readiness. A request for clarification, a bounded research gap, or a decision to park the idea can all be valid stopping points. Publication still requires validation and a current source revision.

Clarification Establishes a Researchable Question

The coordinator should not ask every conceivable requirements question before research begins. It should ask enough to prevent the researchers from investigating materially different interpretations of the idea.

For an offline editor, “offline support” could mean viewing cached content, editing one document, maintaining a local document library, or merging edits from multiple disconnected devices.

Those are different research problems.

Baseline understanding should establish the intended outcome, relevant users, meaningful constraints, and scope boundaries. Unknowns that research can resolve become research questions. Preferences and authority decisions that only the user can supply remain explicit questions for the user.

The output is not a full specification. It is a sufficiently bounded research packet.

Idea: IDEA-017

Intent:  
    Continue editing an existing document without connectivity.

Established scope:  
    Text documents only.
    Reconnection must not silently discard accepted local edits.

Unresolved decisions:  
    Whether simultaneous multi-device editing is required.
    Whether attachments belong to the first version.

Problem research:  
    Which interruption scenarios should this experience address?
    Which comparable interaction patterns are relevant?

Feasibility research:  
    What persistence and synchronization guarantees are required?
    Which conflict cases could invalidate the proposed scope?

Research Returns Evidence, Not Approval

A researcher should distinguish what a source directly establishes from what the researcher infers.

For example, documentation describing a persistence mechanism is evidence about that mechanism. It is not automatically evidence that users need offline editing, that the proposed user experience is appropriate, or that an entire synchronization architecture is correct.

This distinction is consistent with the W3C provenance model, which separates entities, activities, responsible agents, and derivation relationships. Knowing where a statement came from is different from knowing that the statement is true.[2]

For significant findings, the durable synthesis should retain the claim, supporting source, relevant scope or version, limitations, and its relationship to the idea. Current public claims require retrievable source URLs. A source that could not be inspected must not be represented as inspected evidence.

Useful labels include Evidence, Inference, Disagreement, and Uncertainty. They describe the status of a statement, not its rhetorical importance.

A design recommendation can be valuable while still being an inference. A disagreement can remain unresolved while still being accurately documented.

Reconciliation Is Not Concatenation

The coordinator must do more than append two reports.

It checks whether the researchers addressed the same scope, whether apparently independent sources share an origin, whether proposed dependencies are mandatory or optional, and whether conclusions contradict established constraints.

When the researchers disagree, the coordinator should preserve the disagreement and identify its cause. Perhaps they assumed different consistency requirements. Perhaps a capability is available only on one target platform. Perhaps the necessary evidence is missing.

The useful output is the decision boundary:

If simultaneous disconnected edits are in scope:  
    A merge or conflict-resolution policy is required.

If only one authoritative writer is permitted:  
    A simpler synchronization design may be sufficient.

Unresolved:  
    The user has not selected between these product constraints.

The coordinator can request focused follow-up research or further clarification. It must not manufacture consensus merely to make the element appear complete.

Persist the Reconciled State

Only the coordinator updates the canonical element.

The update preserves identity and original intent, records established understanding, incorporates sourced findings, exposes remaining disagreements, and sets a lifecycle status consistent with the evidence.

Validation follows each update. For a file-backed implementation, staging and validating a candidate before replacing the canonical document reduces the risk of exposing malformed intermediate content.

The loop then returns control. It does not automatically advance into a plan because the current idea happens to be ready.

Branches Organize Meaning, Not Execution

Ideas belong to stable branches such as BR-004. These are conceptual categories, not version-control branches.

An example hierarchy might be:

ROOT  
    BR-001: Product capabilities
        BR-004: Offline behavior
            IDEA-017: Offline document editing
            IDEA-019: Conflict presentation
        BR-005: Collaboration
            IDEA-018: Real-time collaborative editing

Each branch has a stable identifier, parent identifier, title, and summary. Each idea belongs to one canonical branch: the deepest existing branch that meaningfully fits its established scope.

The coordinator creates a new branch only when the existing hierarchy does not provide a suitable home. Initial placement supplies research context; research may justify a later move without changing the idea's identifier.

Structurally, this is a rooted hierarchy. Every non-root parent reference must resolve, and no chain of parent references may contain a cycle.

Dependency relationships are separate. IDEA-019 may depend on a synchronization decision in IDEA-018 without becoming its child in the category tree.

Conflating these relationships produces misleading implications: containment does not necessarily mean dependency, priority, or implementation order.

The visual mindmap is a projection of the canonical document. It should not become a second editable source of truth. A request for the full Markdown should return the full artifact, including incomplete and parked ideas, rather than a selectively shortened reconstruction.

Readiness Is a Contract, Not a Confidence Score

The element lifecycle uses five states:

Figure 4. Representative idea-state transitions. A plan-ready idea can lose that status when its scope or evidence changes. Parking preserves identity and prior findings. Only plan-ready carries a readiness flag of yes; none of these states authorizes planning by itself.

These are not a monotonic progress meter. New constraints may return a researched element to clarification. Contradictory evidence may invalidate previous readiness. A parked idea may later resume.

The explicit readiness flag must agree with lifecycle status:

status == plan-ready  -> plan readiness == yes  
status != plan-ready  -> plan readiness == no

This redundancy is useful only when validated. Otherwise, it creates two contradictory answers to the same question.

Structural Validation

A deterministic validator can check identifier uniqueness, required fields, parent references, branch cycles, recognized statuses, timestamp syntax, required subsection presence, and consistency between status and readiness.

For a plan-ready element, it can also reject pending placeholders and require at least one HTTP or HTTPS citation in the research section.

These are structural checks. They do not establish that a citation supports a claim, that a source is authoritative, or that the supposedly measurable completion condition is actually meaningful.

A URL-shaped string is not a proof.

Semantic Readiness

The coordinator must separately evaluate whether the interpretation is coherent, material claims are supported, disagreements are visible, dependencies and risks are explicit, and start and finish boundaries are sufficiently concrete to support planning.

A useful conceptual predicate is:

PlanReady(idea) =  
    StructureValid(idea)
    AND UnderstandingEstablished(idea)
    AND RequiredResearchReconciled(idea)
    AND MaterialClaimsSupported(idea)
    AND UncertaintyExplicit(idea)
    AND StartBoundaryDefined(idea)
    AND CompletionBoundaryDefined(idea)
    AND NoUnboundedPlanningBlocker(idea)

Figure 5. Readiness combines deterministic checks with evidence-based reconciliation. Passing a schema or supplying a URL is not enough. Preconditions must be defined, but need not already be satisfied. A successful gate updates the idea; it does not start planning.

The last condition does not require zero uncertainty.

“Choose one of two documented storage approaches using a bounded evaluation” may be a legitimate planning decision. “We have not established whether the central capability is possible” may prevent meaningful planning altogether.

The question is whether the remaining uncertainty can be represented honestly inside a plan, rather than silently assumed away.

Defined Preconditions Are Not Satisfied Preconditions

Start conditions specify what must be true before implementation begins. Plan readiness requires those conditions to be understood; it does not necessarily require them to have been satisfied already.

Likewise, the definition of complete describes evidence the future deliverable must produce. It is not evidence that the deliverable already exists.

For the offline editor, hypothetical acceptance conditions might be:

After connectivity is removed:  
    The user can continue editing an already-open text document.

After a process restart:  
    Edits previously acknowledged as locally saved are recoverable.

After reconnection:  
    Local edits are synchronized or surfaced as an explicit conflict.
    Conflicting edits are not silently discarded.

Those conditions are more useful than “offline mode works well.” They describe observable behavior that planning can translate into implementation and verification work.

The distinction remains:

Plan-ready != implementation-ready  
Plan-ready != approved  
Plan-ready != complete

Single-Writer Ownership and Runtime Safety

The write topology is intentionally narrow:

Researcher one write set: empty  
Researcher two write set: empty  
Coordinator write set: canonical discovery state  
Exit operation write set: final discovery state and derived index

This avoids asking independent agents to merge competing edits to the same evolving interpretation.

However, a single coordinator inside one session does not prevent two application instances from opening the same repository. A production host still needs a locking or optimistic-concurrency strategy.

One approach is to bind an update to the revision originally read:

Read revision R.  
Perform clarification and research against R.  
Prepare a candidate update.  
Publish only if the current revision is still R.  
Otherwise reload and reconcile the changed context.

The comparison and publication must be protected as one coordinated operation. An unprotected “check, then write” sequence still permits a competing writer between those steps. This is the same fundamental conflict-detection pattern illustrated by EF Core's concurrency-token checks.[3]

For an asynchronous host, I would also bind research responses to the session, idea, input revision, and request identifier. These are runtime hardening measures around the conversational protocol, not extra votes in the readiness decision.

A late report for an older interpretation must not overwrite a newer clarification. A report arriving after explicit exit must not reactivate the mode or mutate its final snapshot.

The host can retain applicable findings for deliberate reconsideration, but it must not blindly attach them to whichever idea currently occupies the conversation.

Policy Is Not a Sandbox

A role description saying “read-only” is a behavioral instruction. It is not an operating-system permission boundary.

Likewise, a creation command that checks mode protects that command. It does not automatically protect every shell command, API client, or editor available to the agent.

A stronger host enforces the same restrictions at tool dispatch, limits credentials and filesystem access, and treats retrieved content as data rather than executable instructions. OWASP's prompt-injection guidance specifically addresses indirect instructions arriving through external content and recommends tool restrictions and least-privilege access.[4]

Public research material must never be able to authorize exit, issue creation, or implementation. Those transitions come from the user through the trusted control path.

The durable artifact should also exclude credentials, personal data, and private-source extracts. Persistence is not a reason to copy every piece of material the researchers encountered.

Exit Produces a Snapshot Index, Not a Plan

The outer loop ends only after an explicit exit request.

Exit preserves every element, including incomplete and parked ideas. It marks the discovery mode inactive, closes the session interval, and generates BRAINSTORM_SUMMARY.md.

The summary is a branch-grouped index, not a replacement for the research document. Each element appears exactly once with its identifier, title, lifecycle status, readiness, concise summary, and reference to the full record.

It is important that this index be generated from the retained state rather than improvised as another narrative summary. Otherwise, less-developed ideas can disappear during compression.

The index is bound to the final source bytes:

sourceHash = SHA256(final BRAINSTORM.md bytes)

summary.SourceHash = sourceHash

Cryptographic digests provide a mechanism for detecting changes relative to a recorded digest; that is the role described by NIST's Secure Hash Standard.[5]

For this design, the digest is a freshness and integrity check, not an approval token. It does not prove that the research is correct or that the index faithfully describes it. An actor able to rewrite both files can replace the digest as well.

Validation therefore needs more than a hash comparison:

Source is structurally valid and inactive.  
Recorded source hash matches the retained source bytes.  
Every source idea appears exactly once in the index.  
No unknown idea appears in the index.

For stronger index verification, regenerate the expected index deterministically and compare its semantic fields or complete canonical bytes. That also detects altered titles, statuses, or summaries that leave the recorded source hash untouched.

Determinism requires stable ordering and stable metadata. The generation timestamp can use the recorded exit timestamp rather than the clock time of each regeneration.

Repeated exit with an already-valid index should be a no-op. When the source remains valid and inactive but its index is missing or stale, an explicit repair can regenerate the same index without rewriting the ideas.

Two Files Are Not Automatically One Transaction

Writing the final document and its index creates a multi-file consistency problem.

Staging both outputs, validating them, and keeping rollback copies helps with ordinary write failures. It does not make two separate file replacements indivisible across a process crash or power loss.

SQLite's atomic-commit documentation illustrates why durable all-or-nothing publication requires coordinated journaling and recovery rather than merely a sequence of successful writes.[6]

A file-backed host can fail closed whenever it finds an inactive source without a matching valid index. A more durable service can use a transactional store or immutable generations with a protected current-generation pointer.

The required observable behavior is the same: an interrupted exit must not expose a supposedly valid planning handoff assembled from mismatched generations.

After successful exit, the system waits.

Figure 6. Exit preserves every idea, including incomplete and parked elements. The index must match the final source hash and cover every idea exactly once. Planning then requires a separate explicit request, a selected plan-ready element, and valid checks against the same source revision. Execution remains separately authorized.

There is deliberately no automatic CreatePlan() call at the end.

Expressing the Handoff Gate in Code

The discovery-to-planning boundary should be explicit enough to test without invoking a model.

The following C# example represents the gate after parsing and validation. Its inputs must come from trusted host checks and authenticated user intent, not from a model asserting that its own work is valid.

using System;

public enum DiscoveryMode  
{
    Absent,
    Active,
    Inactive,
    Malformed
}

public sealed record HandoffChecks(  
    DiscoveryMode Mode,
    bool SourceValid,
    bool SummaryCurrentAndComplete,
    bool ExplicitPlanningRequest,
    string? SelectedIdeaId,
    bool SelectedIdeaExists,
    bool SelectedIdeaPlanReady);

public sealed record GateDecision(bool Allowed, string Reason);

public static class DiscoveryHandoff  
{
    public static GateDecision Evaluate(HandoffChecks checks)
    {
        ArgumentNullException.ThrowIfNull(checks);

        if (checks.Mode != DiscoveryMode.Inactive)
            return new(false, "Discovery has not been validly closed.");

        if (!checks.SourceValid)
            return new(false, "The retained discovery source is invalid.");

        if (!checks.SummaryCurrentAndComplete)
            return new(false, "The exit index is missing, stale, or invalid.");

        if (!checks.ExplicitPlanningRequest)
            return new(false, "Planning has not been explicitly requested.");

        if (string.IsNullOrWhiteSpace(checks.SelectedIdeaId)
            || !checks.SelectedIdeaExists)
            return new(false, "A retained idea must be explicitly selected.");

        if (!checks.SelectedIdeaPlanReady)
            return new(false, "The selected idea needs further discovery.");

        return new(true, "The selected idea may enter planning.");
    }
}

This gate applies specifically to a retained discovery-to-planning handoff. It does not require every ordinary assignment to create a brainstorm document first.

The checks must also describe the same source revision and selected identifier. Combining the source validity of one revision with the readiness of another would defeat the boundary.

Most importantly, the return value authorizes entry into planning only. Implementation, publication, and deployment still require their own authorization checks.

Testing the Protocol

The useful tests target invariants and failure paths, not whether an agent can produce an impressive-looking document.

For lifecycle behavior, test that casual ideation does not activate persistent mode, repeated activation does not rewrite state, a new conversation preserves an active restriction, and explicit exit retains incomplete ideas. Test that unavailable researcher capacity blocks new processing without mutating durable state.

For document integrity, test duplicate identifiers, missing parent references, branch cycles, missing sections, pending content in plan-ready elements, readiness mismatches, missing citations, and unexpected symbolic links at state-file paths.

For handoff integrity, test source-hash mismatches, missing or duplicate index entries, stale summaries after source edits, deterministic regeneration, and interruption between publishing the source and its index.

For runtime enforcement, test forbidden tool calls directly. A friendly conversation that happens not to create an issue is not proof that issue creation is blocked. Also test late research responses, concurrent coordinators, and external content attempting to change mode.

A valid negative result is often the most important result in this system:

The idea remains captured.  
The uncertainty remains visible.  
The implementation has not started.  
The durable state has not been damaged.

The Output Is Preserved Understanding

The purpose of this loop is not to maximize the number of ideas, the number of researchers, or the volume of generated text.

It is to produce a durable element whose meaning can survive beyond the conversation that created it.

That element should preserve what the user asked for, what the team understood, what the evidence supports, what remains disputed, which prerequisites matter, and how a future result could be judged complete.

The architecture follows from that goal: persistent mode state prevents accidental transitions; two research perspectives expose different classes of uncertainty; single-writer reconciliation preserves one coherent record; stable identifiers preserve continuity; validation rejects malformed claims of readiness; and a hash-bound exit index provides an inspectable handoff without pretending to be approval.

A plan can then begin from an explicit body of understanding rather than an accumulated set of conversational assumptions.

Brainstorming is complete enough when an idea can be handed to planning without hiding what is known, what is assumed, and what still needs to be decided. It is not complete merely because the system has found something it could start building.