A New Era of AI Collaboration: Six Falsifiable Principles Reshape Project Efficiency and Accuracy

In AI-assisted project collaboration, smooth handoffs between tools and stages are essential. The first principle (P1) states that every AI output handed off across workflow stages must include a “Handoff Header.” This header contract contains key metadata such as the task ID, input fingerprint, status, evidence level, and next action. Its core hypothesis (H1) is that it can significantly reduce rework when taking over tasks across tools or devices and help prevent context-related “mismatch” errors. With a standardized data contract, downstream tools or people can take over unambiguously and move work forward efficiently without having to reinterpret lengthy conversation histories.

To validate P1’s effectiveness, we will audit handoff-header coverage across existing outputs and design an A/B test: one group of tasks will be required to use a handoff header, while the other will proceed without one. We will compare takeover time and the number of rework cycles. If, across a large number of handoffs, outputs with headers reduce rework by less than 10%, or fewer than 30% of handoff-header fields are actually read, P1 will be downgraded from mandatory to optional. This validation is intended to ensure the protocol is practical rather than merely formal, and to address the handoff challenges commonly found in AI collaboration.

The long-thread pattern common in AI interactions often creates fertile ground for context drift and accumulating errors. The second principle (P2) emphasizes “one task, one thread, one deliverable,” advocating that information be passed between task stages through explicitly saved outputs rather than conversation history. Its core hypothesis (H2) is that error rates and context drift in long threads (for example, those exceeding 20 turns or involving multiple deliverables) are significantly higher than in short, focused execution. Breaking complex tasks into clearly bounded short segments, each completed independently and producing a saved output, can effectively keep the AI on track and prevent it from straying from the task’s objectives.

P2 will be validated by reviewing historical coding threads to analyze how long and short threads perform in cases of “goal drift,” and by designing a controlled experiment: run equivalent tasks in two modes—“one long thread” and “three slices with a persisted handoff header”—then compare first-pass accuracy, number of rework cycles, and total time. If the long-thread group’s rework rate is no higher than the sliced group’s and takes less total time, or if the sliced group’s efficiency drops substantially because of “restart costs,” the requirement for P2 may be downgraded, with long threads recommended only during the exploration phase. The aim is to find the best balance between quality and efficiency.

In a diverse ecosystem of AI tools, Principle 3 (P3) advocates assigning roles by capability rather than locking them to a particular brand. It also requires dual verification for every step that produces an external-facing conclusion: a primary tool and an independent tool from a different source. A single-tool process is not permitted to run end to end. This means assigning tasks based on each tool’s strengths in areas such as research, long-form synthesis, coding, and independent review, rather than relying on one tool to do everything. The core assumption (H3) is that cross-source, two-tool review can effectively catch material errors missed by a single tool—such as numerical mistakes, source bias, or incorrect API parameters—and that its detection rate is high enough to offset the additional time required.

To validate H3, we will create a “review log” documenting, for each review, the review tool, the assertion being reviewed, and the severity of any discrepancy found. The key is to have the primary tool independently produce and seal its conclusion first, then have the review tool answer independently without seeing it, to avoid anchoring effects. If, after 20 cross-tool reviews, the rate of substantive discrepancies caught is zero or all discrepancies are merely wording-level, P3’s “mandatory cross-tool review” will be scaled back to apply only to high-risk assertions. Conversely, if the capture rate is significant (for example, above 20%), the review mechanism will become mandatory for assertions at E2 or higher, ensuring greater reliability in AI outputs.

In AI-driven projects, effectively preserving knowledge is the foundation for reuse and iteration. The fourth principle (P4) emphasizes “Artifact-first”: only outputs that are saved to disk, include metadata, and can be reused without conversational context are recognized as valid “outputs.” Conclusions that have not been saved to disk are considered ephemeral and should not be included in research findings. Its core hypothesis (H4) is that outputs saved to disk with metadata will be cited again within 30 days at a significantly higher rate than outputs without metadata; saved outputs without effective indexing are as valuable as unsaved ones, leading to the inefficiency of “reinventing the wheel.”

This principle requires a series of key pieces of information to be persisted to disk, including the task specification (task spec), ADR-style decision records, evidence tables, the full text of deliverables, index entries, and records of failures and counterarguments (falsification ledger). All outputs must follow strict formatting conventions. For example, filenames must use the format `{RQ or project}_{topic}_{version}_{date}.md`, and YAML front matter with a minimal set of fields such as `task_id`, `version`, and `status` is required to ensure metadata is complete and machine-readable. Table data should also be provided in Markdown whenever possible to facilitate version control and diff comparisons.

To prevent knowledge-base decay, P4 also introduces explicit deduplication rules and anti-decay mechanisms. Deduplication uses both exact-hash matching and semantic-similarity thresholds, while enforcing a “no version overwrites” rule: each new version uses `supersedes` to point to the previous one, which is then moved to the archive. Physical deletion is prohibited to preserve a complete chain of historical evidence. The system also conducts a monthly “knowledge health check,” automatically identifying topics that have gone unused for a long time or are duplicates for archiving or merging, and periodically rebuilds the index to keep the knowledge base active and searchable.

AI hallucinations are a core obstacle to trustworthiness. The fifth principle (P5) introduces an “Evidence Gate” mechanism, requiring every claim included in project conclusions to carry clear source attribution and an evidence level. Unsupported claims about external facts must not appear in the conclusions; they may only be placed in the “To Verify” section. The core hypothesis (H5) is that without the Evidence Gate constraint, AI outputs have a much higher error rate for external facts (such as numbers, dates, and citations) than for reasoning, and that the Evidence Gate, combined with trigger-based review, can keep the error rate within acceptable limits.

We established a four-level evidence scale (E0–E3): E0 is generated by a model without sources (with a high risk of hallucination) and must not be used in conclusions; E1 comes from a single, unverified source and may be used only as a lead; E2 is supported by cross-checking multiple sources or by an accessible primary source and may be used as a conclusion; E3 requires a primary source and consistent, independent verification from a different source, making it the standard for external delivery. All sources must follow a consistent citation format that includes the URL, access date, source type, and evidence level. Vague phrases such as “according to research” or “data shows” are prohibited. In addition, claims involving high-risk areas for hallucinations—such as numbers, dates, API parameters, and people’s names—as well as claims that affect decisions or conflict with existing conclusions, trigger independent, blind verification using a different source.

To continuously improve and quantify hallucinations, we propose establishing a “falsification ledger.” Each claim verified as incorrect will be recorded there along with its original wording, source, reason for the error, how it was detected, and measures to prevent similar errors in the future. The ledger will serve not only as the sole reliable source of data on the distribution of hallucination types, but also as a key basis for assessing P5’s effectiveness and making ongoing adjustments. Through this rigorous verification and feedback loop, we aim to minimize the risks of AI hallucinations and ensure the accuracy and credibility of research findings.

Modern workflows often span multiple devices, including Macs, Windows PCs, servers, and phones. Ensuring seamless continuity of task status across these environments is key to effective AI collaboration. The sixth principle (P6) proposes a design built around a “single source of truth (SSOT) + explicit state machine + session handshake”: task status must be persisted as a version-controlled file (such as in a Git repository), with devices serving only as readers and writers. At the start of each session, the device must first “pull and read” the latest status; at the end, it must “commit and update” that status. This is intended to prevent progress from being tracked solely through memory or chat history.

In practice, we model task status as an explicit state machine (captured→planned→running→blocked→review→done→archived). Each task has a single record of its current state in `state.json` or a Markdown table, along with metadata such as `owner_device`, `next_action`, and `updated_at`. The Git repository serves as the single source of truth for versioning code, documentation, and status. Phones are used mainly to capture tasks and view information, while servers focus on automated execution of long-running tasks, keeping each device’s role clear and distinct.

The core assumption behind this principle (H6) is that network issues are not the main cause of cross-device disconnections; instead, context is lost because state has not been persisted or committed. Introducing a mandatory session handshake protocol should reduce task recovery time from tens of minutes to just a few minutes. We will record recovery times and the causes of interruptions during device switches, then compare the results before and after introducing the handshake protocol. If the protocol fails to reduce the median recovery time by more than 30%, or if network issues remain the main cause of interruptions rather than state management, P6’s mandatory requirement may be relaxed: only state persistence would remain mandatory, while handshake frequency could be adjusted to suit different scenarios.

The six principles above are not merely theoretical; they are closely tied to five “seed hypotheses” that can move directly into validation. These hypotheses form the smallest validation units in our research. Each comes with an actionable task, clear success and failure criteria, and an expected validation period. For example, seed hypothesis S1, “Handoffs significantly reduce rework across tools,” will be tested through an A/B test on a real project, such as *Voice Consultation Survey Project — Preparation Plan v1.1*, comparing the number of rework instances and time spent with and without handoffs. This rigorous empirical approach ensures that every step of our research is grounded in observable, measurable evidence rather than subjective assumptions.

The tool division matrix is a key implementation strategy for Principle P3. Based on the capabilities of the tools currently available (such as Codex for code execution, DSH for general reasoning, Grok for real-time information, WorkBuddy for workflow automation, and Doubao for Chinese writing), we have developed preliminary routing recommendations that specify the “primary tool” and “independent cross-check tool” for each step. For example, Grok is the primary tool for time-sensitive research, DSH provides the independent cross-check, and E2 evidence is mandatory. We emphasize, however, that these are all “[inferences] based on general tool categories, not empirical testing.” Any cases in actual projects that contradict these judgments should prompt us to update the matrix, rather than force the workflow to conform to our assumptions.

Our routing strategy follows three core principles: avoid brand lock-in and continuously update the tool matrix based on measured performance; prohibit any single tool from handling a task end to end, requiring every E2-or-higher assertion to receive at least one independent cross-source review; and assign a single accountable owner, with one primary tool for each deliverable and all others serving as reviewers, so responsibilities stay clear. Through these verifiable hypotheses and a dynamically adjusted division of labor among tools, we aim to bring AI-assisted project collaboration from disorder to structure, shift it from experience-driven to evidence-driven, and ultimately build an efficient, accurate, and continuous intelligent work environment.