中文译文

技术白皮书写作

为什么需要这项技能

大多数 AI 生成的白皮书读起来像营销文档：含糊其辞的论断、过多的形容词、把功能清单当作创新来呈现、缺乏支撑的性能数字、泛泛而谈的架构图，以及用路线图代替技术证据。

一份出色的白皮书则应当解释为什么某个问题存在、所提出的系统做了什么、它如何运作、设计为何如此组织、它做了哪些假设、它在正常与故障条件下如何表现，以及该设计在哪些方面仍有局限。

目标是让文档读起来像工程与技术研究，而不是销售宣传册。

白皮书应当让具备技术能力的读者能够回答：

正在解决什么问题？
为什么现有方法会失败或变得不足？
提出了什么方案？
所提出的系统实际上如何运作？
主要组件有哪些，它们如何交互？
该设计做了哪些假设？
正常运行期间会发生什么？
出现故障时会发生什么？
有哪些证据支撑这些技术论断？
有哪些局限和未解决的风险？
这与现有方法有何不同？
要实现、评估或部署它，需要做什么？

写作应当优先考虑清晰、技术精确、可追溯性和智识上的诚实，而非听起来唬人的措辞。

第 1 步 — 写作前先收集输入

在核心信息齐备之前，不要开始起草完整白皮书。如果关键信息缺失，应当主动询问（见第 20 步），而不是凭空编造。

1. 问题。 用一句清晰的话陈述它，然后描述一个具体场景，展示在没有所提解决方案的情况下会出现什么失败。

避免：“这个行业需要一种革命性的新方法。”
更倾向：“当前系统要求每个应用独立集成多个模型提供商，导致集成逻辑重复、可观测性不一致，并且难以切换提供商。”

2. 项目类型。 确定主要类别（以及任何重要的次要类别），不要强行将项目归入不合适的类别。例如：AI/ML 系统、LLM 应用、AI 基础设施、数据平台、开发者工具、云/分布式系统、网络安全系统、网络系统、数据库/存储系统、硬件/嵌入式系统、机器人系统、科学/研究系统、企业架构、SaaS 平台、API/中间件、智能体系统、金融科技、医疗科技、工业或能源科技、协议/标准系统，或其他。

3. 核心机制。 描述系统内部实际发生了什么——输入、处理、状态、转换、决策、输出、反馈回路、外部依赖、失败路径、系统边界。不是功能列表。

避免：“该平台提供智能路由、安全性、可观测性和可扩展性。”
更倾向：“传入请求会根据模型、延迟、成本和策略要求进行分类。路由层选择一个符合条件的提供商，执行请求，记录遥测数据，并在所选提供商失败时应用重试或回退逻辑。”

4. 系统边界。 什么在系统内部，什么在外部？哪些组件是可控的，哪些是依赖项？数据从哪里进入和离开？信任从哪里开始，到哪里结束？

5. 参与者与利益相关者。 只包括与系统相关的参与者（例如，最终用户、开发者、管理员、运维人员、服务、模型、智能体、数据/基础设施提供商、验证者、攻击者、外部系统）。对于每个重要参与者：他们做什么、需要什么、控制什么、能观察到什么，以及哪些激励或约束塑造了他们的行为。 6. 资源、经济或代币——仅在适用时。 如果系统涉及代币、积分、使用单位、订阅、费用、激励、奖励、惩罚、算力分配或配额，请解释其机制性用途。绝不因为白皮书「理应」包含代币经济学或金融机制就强行引入。如果不存在经济机制，则省略本节。

7. 已知局限与风险。 哪些方面可能失败、退化或仍未解决——可扩展性限制、延迟约束、依赖风险、模型局限、数据质量问题、安全假设、运维复杂度、成本约束、硬件限制、隐私顾虑、监管不确定性、可用性依赖、集成复杂度。明确陈述这些内容；不要隐藏它们。

第 2 步——选择白皮书结构

不要强行让每个项目套用同一模板。默认的技术主线：

摘要
引言
问题与动机
现有方法
设计目标与非目标
提议的架构
核心机制
系统工作流程
技术设计
安全 / 安全 / 可靠性模型
性能与可扩展性
实现考量
完整示例
评估 / 证据
局限与开放问题
未来工作
结论
参考文献

并非每个章节都是必需的——只使用那些能实质性提升理解的部分：

简单的软件架构可以跳过繁重的数学分析。
AI 研究系统可能需要实验与评估方法。
网络安全系统可能需要详细的威胁模型。
硬件系统可能需要物理约束与基准测试。
分布式系统可能需要一致性、容错与故障分析。
商业 SaaS 平台可能需要部署/运维架构，而非形式化证明。

第 3 步 — 确立技术差异

如果项目基于或扩展现有技术，请明确梳理：

此前存在什么 → 仍存在什么局限 → 本设计改变了什么 → 为何这一改变重要。

避免：“这是世界上首个革命性架构。”
优先：“现有方法 A 提供了 X，但需要 Y。方法 B 去除了 Y，但引入了 Z。所提出的架构将 X 与一种不同的执行模型相结合，在去除 Y 的同时接受 Z 方面的明确权衡。”

第 4 步 — 从最小模型构建机制

逐步引入复杂性，而不是一次性呈现完整架构：

直觉 — 用简单语言表达的想法。
最小模型 — 能够解决问题的最小系统。
架构 — 主要组件。
数据 / 请求流 — 信息如何在系统中移动。
技术机制 — 算法、协议、模型、API、状态转换、策略。
故障行为 — 当组件失败或假设被打破时会发生什么。
优化 — 性能、可扩展性、缓存、批处理、路由、并行化。

第 5 步 — 应用证据纪律

诸如 更快、更便宜、更安全、可扩展、可靠、准确、更低延迟、更高吞吐量、减少幻觉、提高效率 之类的断言，绝不能在缺乏支持的情况下作出。

在可能的情况下，提供：基准测试结果、测量数据、公式、阈值、实验结果、架构推理、引用、假设或比较方法。

避免：“该架构提供极低延迟。”
优先：“在评估配置中，路由层在 Y 工作负载下增加 X 毫秒的中位处理开销。”

如果某个数字不可用，就说明这一点。绝不捏造测量数据。

第 6 步 — 分析每个重要参与者

对每个参与者：职责、输入、输出、权限、依赖、激励、约束、失效模式，以及行为不当的后果。示例集合（根据实际项目调整）：

用户 — 提交请求并接收响应。
应用 — 对请求进行身份验证并调用平台 API。
模型提供方 — 处理推理请求。
网关 — 应用路由、策略、重试和可观测性逻辑。
运维人员 — 配置策略并监控系统健康状况。

第 7 步 — 定义威胁、失效或风险模型

根据项目情况，分析相关风险：恶意用户、被攻陷的组件、未授权访问、数据泄露、模型操纵、提示词注入、供应链攻击、拒绝服务、数据损坏、错误输出、基础设施/依赖失效、网络分区、硬件故障、运维人员失误、配置错误、对抗性输入、经济攻击、隐私侵犯。

对每一个重大威胁：

威胁 → 攻击/失效机制 → 影响 → 缓解措施 → 剩余风险

避免：“该系统高度安全。”
更可取：说明针对什么安全、在哪些假设下安全、有哪些控制措施。

第 8 步 — 包含一个完整示例

每一份有实质内容的 whitepaper 都至少需要一个具体、端到端的示例——一个交易生命周期、API 请求、推理请求、数据管道、用户工作流、状态转换、攻击场景、失效场景或数值计算。在有帮助的地方加入真实数字。

示例形态：

客户端提交请求。

网关校验策略。

路由器选择提供方。

提供方执行推理。

响应通过校验。

记录遥测数据。

客户端收到响应。

第 9 步 — 清晰地解释架构

架构描述应当回答：主要组件有哪些？每个组件做什么？它们如何连接？哪些协议/接口将它们连接起来？状态存储在哪里？计算在哪里发生？决策在哪里做出？安全边界在哪里？故障可能在哪里发生？

仅在能反映现实时才使用分层结构，例如：

User / Client Layer
        ↓
API / Interface Layer
        ↓
Application / Orchestration Layer
        ↓
Core Processing Layer
        ↓
Data / Model / Storage Layer
        ↓
Infrastructure Layer

不要仅为视觉对称而添加层级。

第 10 步 — 恰当处理数学

当方程能阐明机制时使用方程：优化目标、概率模型、评分函数、成本/延迟/吞吐量计算、容量规划、密码学公式、机器学习目标、资源分配、经济模型、可靠性计算。始终用通俗语言解释每个方程。绝不纯粹为了外观而添加数学。

第 11 步 — 恰当处理 AI/ML 系统

清晰区分模型架构、训练、微调、推理、检索、编排、评估、安全、监控、数据管道和人在回路流程。

明确框定管道：

输入 → 处理 → 模型 / 检索 / 工具使用 → 验证 → 输出

在相关处，涵盖：模型选择、训练方法、数据集假设、上下文管理、检索策略、评估方法、幻觉缓解、护栏、延迟、推理成本、可观测性和模型失效模式。

避免使用「智能」「认知」或「类人」等模糊术语，除非有技术定义。

第 12 步 — 与现有方法比较

在相关处，按具体维度进行比较：

维度	现有方法	所提方法
架构	...	...
延迟	...	...
可扩展性	...	...
成本	...	...
安全性	...	...
灵活性	...	...
运维复杂度	...	...

每一行都需要有可辩护的依据——不要仅为显得完整而构建表格。

第 13 步 — 讨论权衡

每个有意义的架构都有权衡。明确讨论相关权衡：性能 vs. 成本、灵活性 vs. 复杂度、安全性 vs. 可用性、一致性 vs. 可用性、延迟 vs. 准确性、集中化 vs. 去中心化、自动化 vs. 人工控制、计算 vs. 内存、精确率 vs. 召回率、隐私 vs. 可观测性。绝不声称该设计消除了权衡取舍——要解释选择了哪些取舍，以及为什么。

第 14 步——将当前能力与未来工作分开

不要将路线图项目作为系统当前可用的证据来呈现。要区分：

当前设计——今天已存在或已有技术规范的内容。
实验性 / 已验证——已实现并已测试的内容。
拟议扩展——以后可能构建的内容。
开放研究问题——仍未解决的内容。

路线图不是技术可行性的证明。

第 15 步——反模式过滤器

在呈现草稿之前，扫描并改写：

营销语言——revolutionary、groundbreaking、game-changing、next-generation、world-class、unprecedented、highly intelligent、infinitely scalable、military-grade、enterprise-grade——除非有技术定义和支持。

无依据的声明——“10x faster”、“99.99% reliable”、“100% secure”、“zero hallucinations”、“fully autonomous”、“unlimited scalability”——除非存在证据。

功能堆砌——一列功能不是架构。

流行词替换——“AI + blockchain + cloud + quantum + autonomous agents”不是机制。

路线图当作证明——未来计划不能证明当前可行性。

没有目的的代币经济学——不要凭空发明经济机制。

没有比较的新颖性——不要在没有解释此前已有成果的情况下声称创新。

没有威胁建模的安全性——不要在没有指明威胁和缓解措施的情况下声称安全。

没有数据流的架构——仅有组件不能解释一个系统。

缺失局限性——每个严肃的设计都有局限性；要把它们说明。

第 16 步——外部研究与引用

使用外部信息时：引用每一项外部技术声明，优先使用一手和权威来源，科学声明引用研究论文，技术规范引用官方文档，标准引用标准机构，供应商特定行为引用供应商文档。使用行内编号引用：

Transformer 架构使用自注意力来建模 token 之间的关系 [1]。

## References
[1] Vaswani et al., "Attention Is All You Need," 2017.

绝不编造参考文献。绝不引用实际上并不支持该陈述的来源。

第 17 步 — 写作风格

像一位经验丰富的工程师或研究者向另一位技术能力相当的人解释一个复杂系统那样来写。

偏好： 精确的语言、短到中等长度的段落、清晰的解释、明确的假设、具体的例子、在有用之处展现技术深度、在合适之处使用结构化文本图示、有意义的章节标题。

避免： 过多的形容词、创业公司式的炒作、重复的结论、泛泛的使命宣言、不必要的术语、人为的复杂性、虚假的确定性。

语气：“这是问题所在。这是现有方法为何吃力。这是我们提出的机制。这是它如何运作。这是证据。这是它可能失败的地方。”

而不是：“我们正在革新技术的未来。”

第 18 步 — 输出结构

用 Markdown 生成白皮书，根据实际项目调整章节编号（省略不相关的章节）：

# Title

## Abstract
## 1. Introduction
## 2. Problem and Motivation
## 3. Existing Approaches
## 4. Design Goals and Non-Goals
## 5. Proposed Architecture
## 6. Core Mechanism
## 7. System Workflow
## 8. Technical Design
## 9. Security, Safety, and Reliability
## 10. Performance and Scalability
## 11. Worked Example
## 12. Evaluation
## 13. Limitations and Open Problems
## 14. Future Work
## 15. Conclusion
## References

篇幅应取决于技术复杂度，而非任意设定的页数。 简单的系统写一篇简洁的论文；复杂的系统则需要更深入的论述。

第 19 步 — 发布前自检

在宣布白皮书完成之前，逐项核实：

检查项	状态
问题是具体的	PASS / FAIL
失败场景已解释	PASS / FAIL
项目类型已正确识别	PASS / FAIL
核心机制已清晰解释	PASS / FAIL
系统边界已定义	PASS / FAIL
架构可被理解	PASS / FAIL
数据 / 请求流已解释	PASS / FAIL
已有方案已讨论	PASS / FAIL
技术差异清晰	PASS / FAIL
重要参与者已分析	PASS / FAIL
存在威胁 / 失败模型	PASS / FAIL
主要论断有证据支撑	PASS / FAIL
至少有一个完整示例	PASS / FAIL
权衡取舍已说明	PASS / FAIL
局限性已明确陈述	PASS / FAIL
未来工作与当前能力已区分	PASS / FAIL
外部论断已引用来源	PASS / FAIL
无捏造的数字或引用	PASS / FAIL
无以营销炒作替代技术解释	PASS / FAIL

报告一份简短的 白皮书质量检查，总结这些结果。如果缺少重要信息，明确说明，而不是凭空编造。

第 20 步 — 缺失信息处理原则

如果缺少关键信息，在起草该部分之前先询问。绝不捏造： 技术规格、基准测试结果、客户数量、采用统计数据、收入、市场规模、团队资历、合作伙伴关系、安全保证、性能测量、代币经济学、实现细节或研究结果。

当某项内容未知时，明确标注：

未指定 / 需要验证 / 假设： ……

绝不将假设悄悄转化为陈述的事实。

核心原则

白皮书应回答一个高于一切的问题：

一位具备技术能力的读者能否理解这个系统做什么、如何运作、为何如此设计、有哪些证据支撑，以及它可能在哪里失败？

如果是，白皮书就尽到了它的职责。

English original

Technical Whitepaper Writer

Why this skill exists

Most AI-generated whitepapers read like marketing documents: vague claims, excessive adjectives, feature lists presented as innovation, unsupported performance numbers, generic architecture diagrams, and roadmaps used as substitutes for technical evidence.

A strong whitepaper instead explains why a problem exists, what the proposed system does, how it works, why the design is structured that way, what assumptions it makes, how it behaves under normal and failure conditions, and where the design remains limited.

The goal is a document that reads like engineering and technical research, not a sales brochure.

The whitepaper should let a technically capable reader answer:

What problem is being solved?
Why do existing approaches fail or become insufficient?
What is being proposed?
How does the proposed system actually work?
What are the major components, and how do they interact?
What assumptions does the design make?
What happens during normal operation?
What happens when something goes wrong?
What evidence supports the technical claims?
What are the limitations and unresolved risks?
How is this different from existing approaches?
What would someone need to implement, evaluate, or deploy it?

Writing should prioritize clarity, technical precision, traceability, and intellectual honesty over impressive-sounding language.

Step 1 — Gather inputs before writing

Do not begin drafting the full whitepaper until the core information is available. If critical information is missing, ask for it (see Step 20) rather than inventing it.

1. The problem. State it in one clear sentence, then describe a concrete scenario showing what fails without the proposed solution.

Avoid: "The industry needs a revolutionary new approach."
Prefer: "Current systems require each application to independently integrate multiple model providers, resulting in duplicated integration logic, inconsistent observability, and difficult provider switching."

2. The project type. Identify the primary category (and any important secondary categories) without forcing the project into an inappropriate one. Examples: AI/ML system, LLM application, AI infrastructure, data platform, developer tool, cloud/distributed system, cybersecurity system, networking system, database/storage system, hardware/embedded system, robotics system, scientific/research system, enterprise architecture, SaaS platform, API/middleware, agentic system, FinTech, healthcare tech, industrial or energy tech, protocol/standards system, or other.

3. The core mechanism. Describe what actually happens inside the system — inputs, processing, state, transformations, decisions, outputs, feedback loops, external dependencies, failure paths, system boundaries. Not a feature list.

Avoid: "The platform provides intelligent routing, security, observability, and scalability."
Prefer: "An incoming request is classified according to model, latency, cost, and policy requirements. The routing layer selects an eligible provider, executes the request, records telemetry, and applies retry or fallback logic when the selected provider fails."

4. System boundaries. What's inside the system vs. external? Which components are controlled vs. dependencies? Where does data enter and leave? Where does trust begin and end?

5. Actors and stakeholders. Only include actors relevant to the system (e.g., end users, developers, administrators, operators, services, models, agents, data/infrastructure providers, validators, attackers, external systems). For each important actor: what they do, need, control, can observe, and what incentives or constraints shape their behavior.

6. Resources, economics, or tokens — only when applicable. If the system has a token, credits, usage units, subscriptions, fees, incentives, rewards, penalties, compute allocation, or quotas, explain their mechanical purpose. Never introduce tokenomics or financial mechanisms just because a whitepaper is "expected" to have them. Omit this section if no economic mechanism exists.

7. Known limitations and risks. What might fail, degrade, or remain unresolved — scalability limits, latency constraints, dependency risks, model limitations, data quality issues, security assumptions, operational complexity, cost constraints, hardware limitations, privacy concerns, regulatory uncertainty, availability dependencies, integration complexity. State these explicitly; do not hide them.

Step 2 — Choose the whitepaper structure

Do not force every project into an identical template. The default technical spine:

Abstract
Introduction
Problem and Motivation
Existing Approaches
Design Goals and Non-Goals
Proposed Architecture
Core Mechanism
System Workflow
Technical Design
Security / Safety / Reliability Model
Performance and Scalability
Implementation Considerations
Worked Example
Evaluation / Evidence
Limitations and Open Problems
Future Work
Conclusion
References

Not every section is mandatory — use only what materially improves understanding:

A simple software architecture may skip heavy mathematical analysis.
An AI research system may need experiments and evaluation methodology.
A cybersecurity system may need a detailed threat model.
A hardware system may need physical constraints and benchmarking.
A distributed system may need consistency, fault tolerance, and failure analysis.
A commercial SaaS platform may need deployment/operational architecture rather than formal proofs.

Step 3 — Establish the technical delta

If the project builds on or extends existing technology, explicitly trace:

What existed before → What limitation remained → What this design changes → Why that change matters.

Avoid: "This is the world's first revolutionary architecture."
Prefer: "Existing approach A provides X but requires Y. Approach B removes Y but introduces Z. The proposed architecture combines X with a different execution model that removes Y while accepting an explicit trade-off in Z."

Step 4 — Build the mechanism from a minimal model

Introduce complexity progressively rather than presenting the full architecture at once:

Intuition — the idea in simple language.
Minimal model — the smallest system that could solve the problem.
Architecture — the major components.
Data / request flow — how information moves through the system.
Technical mechanisms — algorithms, protocols, models, APIs, state transitions, policies.
Failure behavior — what happens when components fail or assumptions break.
Optimization — performance, scalability, caching, batching, routing, parallelism.

Step 5 — Apply evidence discipline

Claims like faster, cheaper, more secure, scalable, reliable, accurate, lower latency, higher throughput, reduced hallucination, improved efficiency must never be asserted without support.

Where possible, provide: benchmark results, measurements, formulas, thresholds, experimental results, architectural reasoning, citations, assumptions, or comparison methodology.

Avoid: "The architecture provides extremely low latency."
Prefer: "In the evaluated configuration, the routing layer adds a median of X ms of processing overhead under Y workload."

If a number is unavailable, say so. Never fabricate measurements.

Step 6 — Analyze each important actor

For each actor: responsibility, inputs, outputs, permissions, dependencies, incentives, constraints, failure modes, and consequences of incorrect behavior. Example set (adapt to the actual project):

User — submits a request and receives a response.
Application — authenticates the request and invokes the platform API.
Model Provider — processes the inference request.
Gateway — applies routing, policy, retry, and observability logic.
Operator — configures policies and monitors system health.

Step 7 — Define the threat, failure, or risk model

Depending on the project, analyze relevant risks: malicious users, compromised components, unauthorized access, data leakage, model manipulation, prompt injection, supply-chain attacks, denial of service, corrupted data, incorrect outputs, infrastructure/dependency failure, network partitions, hardware failure, operator error, configuration errors, adversarial inputs, economic attacks, privacy violations.

For every significant threat:

Threat → Attack/Failure Mechanism → Impact → Mitigation → Remaining Risk

Avoid: "The system is highly secure."
Prefer: explaining secure against what, under which assumptions, and with what controls.

Step 8 — Include a worked example

Every substantive whitepaper needs at least one concrete, end-to-end example — a transaction lifecycle, API request, inference request, data pipeline, user workflow, state transition, attack scenario, failure scenario, or numerical calculation. Include real numbers where useful.

Example shape:

Client submits request.

Gateway validates policy.

Router selects provider.

Provider executes inference.

Response passes through validation.

Telemetry is recorded.

Client receives response.

Step 9 — Explain architecture clearly

Architecture descriptions should answer: What are the major components? What does each do? How are they connected? What protocols/interfaces link them? Where is state stored? Where does computation happen? Where are decisions made? Where are the security boundaries? Where can failures occur?

Use layered structure only where it reflects reality, e.g.:

User / Client Layer
        ↓
API / Interface Layer
        ↓
Application / Orchestration Layer
        ↓
Core Processing Layer
        ↓
Data / Model / Storage Layer
        ↓
Infrastructure Layer

Do not add layers for visual symmetry alone.

Step 10 — Handle mathematics appropriately

Use equations when they clarify the mechanism: optimization objectives, probability models, scoring functions, cost/latency/throughput calculations, capacity planning, cryptographic formulas, ML objectives, resource allocation, economic models, reliability calculations. Always explain each equation in plain language. Never add math purely for appearance.

Step 11 — Handle AI/ML systems appropriately

Distinguish clearly between model architecture, training, fine-tuning, inference, retrieval, orchestration, evaluation, safety, monitoring, data pipelines, and human-in-the-loop processes.

Frame the pipeline explicitly:

Input → Processing → Model / Retrieval / Tool Use → Validation → Output

Where relevant, cover: model selection, training methodology, dataset assumptions, context management, retrieval strategy, evaluation methodology, hallucination mitigation, guardrails, latency, inference cost, observability, and model failure modes.

Avoid vague terms like "intelligent," "cognitive," or "human-like" unless technically defined.

Step 12 — Compare against existing approaches

Where relevant, compare on concrete dimensions:

Dimension	Existing Approach	Proposed Approach
Architecture	...	...
Latency	...	...
Scalability	...	...
Cost	...	...
Security	...	...
Flexibility	...	...
Operational Complexity	...	...

Every row needs a defensible basis — don't build the table just to look complete.

Step 13 — Discuss trade-offs

Every meaningful architecture has trade-offs. Discuss the relevant ones explicitly: performance vs. cost, flexibility vs. complexity, security vs. usability, consistency vs. availability, latency vs. accuracy, centralization vs. decentralization, automation vs. human control, compute vs. memory, precision vs. recall, privacy vs. observability.

Never claim the design eliminates trade-offs — explain which were chosen, and why.

Step 14 — Separate current capability from future work

Do not present roadmap items as evidence the system currently works. Distinguish:

Current design — what exists or is technically specified today.
Experimental / validated — what has been implemented and tested.
Proposed extensions — what could be built later.
Open research problems — what remains unresolved.

A roadmap is not proof of technical viability.

Step 15 — Anti-pattern filter

Before presenting a draft, scan for and rewrite:

Marketing language — revolutionary, groundbreaking, game-changing, next-generation, world-class, unprecedented, highly intelligent, infinitely scalable, military-grade, enterprise-grade — unless technically defined and supported.

Unsupported claims — "10x faster," "99.99% reliable," "100% secure," "zero hallucinations," "fully autonomous," "unlimited scalability" — unless evidence exists.

Feature dumping — a list of features is not an architecture.

Buzzword substitution — "AI + blockchain + cloud + quantum + autonomous agents" is not a mechanism.

Roadmap-as-proof — future plans don't demonstrate present viability.

Tokenomics without purpose — don't invent economic mechanisms.

Novelty without comparison — don't claim innovation without explaining what came before.

Security without threat modeling — don't claim security without naming threats and mitigations.

Architecture without data flow — components alone don't explain a system.

Missing limitations — every serious design has them; state them.

Step 16 — External research and citations

When using external information: cite every external technical claim, prefer primary and authoritative sources, cite research papers for scientific claims, official documentation for technical specs, standards bodies for standards, and vendor docs for vendor-specific behavior.

Use inline numbered citations:

Transformer architectures use self-attention to model relationships between tokens [1].

## References
[1] Vaswani et al., "Attention Is All You Need," 2017.

Never fabricate references. Never cite a source that doesn't actually support the statement.

Step 17 — Writing style

Write as an experienced engineer or researcher explaining a complex system to another technically capable person.

Prefer: precise language, short-to-medium paragraphs, clear explanations, explicit assumptions, concrete examples, technical depth where useful, structured-text diagrams where appropriate, meaningful section titles.

Avoid: excessive adjectives, startup-style hype, repetitive conclusions, generic mission statements, unnecessary jargon, artificial complexity, fake certainty.

The tone: "Here is the problem. Here is why existing approaches struggle. Here is the mechanism we propose. Here is how it works. Here is the evidence. Here is where it can fail."

Not: "We are revolutionizing the future of technology."

Step 18 — Output structure

Produce the whitepaper in Markdown, adapting section numbers to the actual project (omit irrelevant sections):

# Title

## Abstract
## 1. Introduction
## 2. Problem and Motivation
## 3. Existing Approaches
## 4. Design Goals and Non-Goals
## 5. Proposed Architecture
## 6. Core Mechanism
## 7. System Workflow
## 8. Technical Design
## 9. Security, Safety, and Reliability
## 10. Performance and Scalability
## 11. Worked Example
## 12. Evaluation
## 13. Limitations and Open Problems
## 14. Future Work
## 15. Conclusion
## References

Length should follow technical complexity, not an arbitrary page count. A simple system gets a concise paper; a complex one gets deeper treatment.

Step 19 — Pre-publish self-check

Before declaring the whitepaper complete, verify each item:

Check	Status
Problem is concrete	PASS / FAIL
Failure scenario is explained	PASS / FAIL
Project type is correctly identified	PASS / FAIL
Core mechanism is clearly explained	PASS / FAIL
System boundaries are defined	PASS / FAIL
Architecture is understandable	PASS / FAIL
Data / request flow is explained	PASS / FAIL
Existing approaches are discussed	PASS / FAIL
Technical delta is clear	PASS / FAIL
Important actors are analyzed	PASS / FAIL
Threat / failure model exists	PASS / FAIL
Major claims have evidence	PASS / FAIL
At least one worked example exists	PASS / FAIL
Trade-offs are acknowledged	PASS / FAIL
Limitations are explicitly stated	PASS / FAIL
Future work is separated from current capability	PASS / FAIL
External claims are cited	PASS / FAIL
No fabricated numbers or references	PASS / FAIL
No marketing hype substitutes for technical explanation	PASS / FAIL

Report a short Whitepaper Quality Check summarizing these results. If important information is missing, say so explicitly rather than inventing it.

Step 20 — Missing information policy

If critical information is missing, ask for it before drafting that portion. Never fabricate: technical specifications, benchmark results, customer numbers, adoption statistics, revenue, market size, team credentials, partnerships, security guarantees, performance measurements, token economics, implementation details, or research results.

When something is unknown, mark it clearly:

Not specified / Requires validation / Assumption: ...

Never silently convert an assumption into a stated fact.

Core principle

The whitepaper should answer one question above all others:

Can a technically capable reader understand what this system does, how it works, why it was designed this way, what evidence supports it, and where it can fail?

If yes, the whitepaper is doing its job.