Editorial Method

The Fieldbook treats every chapter as our current best understanding, not a permanent final answer.

Chapter shape

Each mature chapter should cover:

1. Thesis — the chapter’s central claim.
2. Problem — the engineering problem being addressed.
3. Mental model — a useful way to reason about the problem.
4. Design options — the main available approaches.
5. Trade-offs — benefits, costs, and conditions.
6. Failure modes — how implementations commonly go wrong.
7. Industry evidence — primary sources and public cases.
8. Fieldbook guidance — our resulting point of view.
9. Checklist — questions for design and review.
10. References — traceable sources.

Evidence selection

OpenAI and Anthropic are core sources for the Fieldbook. Their research, technical documentation, engineering reports, evaluation material, and production-agent experience provide some of the most direct and substantial primary material available for current agent engineering. Relevant material from both organizations should normally be examined rather than omitted for cosmetic source diversity.

Core does not mean exclusive or automatically universal. The Fieldbook also uses standards bodies, public institutions, original research, other vendors, and engineering communities to corroborate claims, reveal different results, and cover subjects that OpenAI and Anthropic do not own.

• Use international, regional, and national standards or public-institution material according to the claim and affected jurisdiction. Record whether a source is a law, adopted standard, voluntary framework, final guidance document, draft, consultation, research report, or concept paper.
• Use original research for empirical and theoretical claims, while checking task, dataset, method, reproduction, and limits on generalization.
• Use vendor documentation to establish the behavior of that vendor’s products and interfaces. Treat engineering articles and case studies—including those from OpenAI and Anthropic—as experience reports published by the organization itself, and seek independent corroboration before turning them into cross-vendor principles.
• Include other relevant commercial, open-source, and open-weight model ecosystems when they add original evidence, a materially different implementation, or a credible counterexample. Describe licenses and openness according to the actual release terms.
• Use canonical repositories, versioned code, tests, specifications, design proposals, releases, issues, and maintainer discussions as distinct forms of community evidence. Popularity signals such as GitHub Stars do not prove correctness, security, or best practice.

Evidence diversity is not a quota. Relevance and source quality come first, but each research brief must disclose material concentration, jurisdiction limits, vendor incentives, document maturity, and missing independent reproduction. Broad recommendations should, where feasible, combine independent evidence classes rather than repeat several sources from the same organization.

Publishing flow

English is the source language:

Research → English outline → English draft → review → Chinese translation → consistency review → publish

The translation script records a source fingerprint in each generated Chinese file. When the English source changes, the Chinese page becomes stale until it is translated again.