Canonical question: What should a user read first inside the drafting stage?
Expected output: A drafting-stage reading order and one current document plan.
TL;DR
Track D 的正确顺序不是:
先开 Petition Letter -> 写一大段 -> 语言不顺再修
而应该是:
PE object -> RL planning -> PL architecture -> revision order -> cross-document QA
Use this if
- 你已经有基本 route 和 evidence 设计
- 你现在要把东西写成文档系统
- 你不想一上来就掉进 prose polishing
Not for you if
- 你还没做好 evidence design
- 你已经到 final filing / RFE 阶段
The Track D reading order
1. 先把 PE 写成可审对象
先解决 object 和 failure mode,再谈语言。
2. 再规划 RL,不要先群发请求
这里的 proof brief、proof job 都是 internal planning shorthand,不是当前 /app/case/recommendations 的固定字段。
3. 再搭 PL 骨架
PL 的问题通常不是文采,而是 architecture。
4. 再决定 revision order
如果你不先控制 revision order,draft 越改越乱几乎是必然的。
5. 最后做 cross-document QA
A simple drafting flow
PE -> RL planning -> PL -> revision order -> consistency sweep
如果你现在已经在 PL 里写到很长,但 PE 还不稳,就该退回前一步。
If you only have one blocker
- PE 总像 job description:
- 先读
Turn Future Plans into a Defendable Proposed Endeavor - 再读
PE Failure Modes - 推荐信总是重复:
- 先读
How to Brief Recommenders - 再读
RL Portfolio Strategy - PL 越写越散:
- 先读
Petition Letter Architecture - 再读
Revision Order
After reading do this
- 回到
/app/case/proposed-endeavors,确认当前 PE object 是否已经稳定。 - 回到
/app/case/recommendations,只输入当前产品真实支持的 referrer / materials / config 信息。 - 回到
/app/case/petition,先搭document plan,再动 prose。
Related reads
如何把 Future Plans 写成一个 defendable Proposed Endeavor如何 brief recommendersPetition Letter Architecture
Sources / basis
Related reads
- 如何把 Future Plans 写成一个 defendable Proposed Endeavor - Future plans 只有在被写成具体 object、mechanism、beneficiary、boundary 时,才会变成 officer 能审的 proposed endeavor。
- 如何 brief recommenders,而不是逼他们写模板化赞美信 - 推荐人需要的是有边界的 proof brief,不是让他自由发挥夸你。
- Petition Letter Architecture - 好的 Petition Letter 不是把所有事实堆成一封长信,而是让每个 section 只承担一个 adjudication job。
Source basis
- [1] 6 USCIS-PM F.5(D)(2)-(6) - USCIS Policy Manual
- [2] Matter of Dhanasar, 26 I&N Dec. 884 (AAO 2016) - AAO precedent