paper-to-architecture-diagram

name	paper-to-architecture-diagram
description	Use when converting research papers, arXiv PDFs, method notes, or literature summaries into architecture diagrams, architecture-diagram SOPs, or Junhao-style research dossier HTML/report artifacts. Trigger for requests like 论文转架构图, paper to architecture diagram, 架构图 SOP, 论文机制可视化, 模块拆解, 输入输出关键组件关键实现, or when a paper needs to become a PM-readable system blueprint with Junhao frontend style.
metadata	{"short-description":"把论文机制转成可追溯的 Junhao 风格架构图 SOP"}

Paper To Architecture Diagram

Purpose

Turn a paper's method into a traceable architecture artifact: not just a pretty diagram, but a system blueprint that preserves the paper's task boundary, data flow, state updates, implementation hooks, and evaluation logic.

Default output language follows the user. For Junhao's Chinese research artifacts, write concise Chinese and use the junhao-frontend-style research dossier visual system when producing HTML, reports, dashboards, or polished visual specs.

Default Deliverables

When the user asks for a complete result, produce these artifacts:

1. Architecture diagram or diagram spec.
2. Component table: module, responsibility, input, output, implementation, paper evidence.
3. Flow SOP: extraction steps from paper to diagram.
4. State and memory map: what persists, updates, resets, or feeds the next round.
5. Metrics and failure cases: what the architecture optimizes and where it can break.
6. If creating HTML: a standalone Junhao-style research dossier with sticky TOC, warm paper background, numbered sections, matrix tables, sprint/SOP timeline, and a clear final output block.

Paper Reading Workflow

1. Define the system boundary

Extract the paper's concrete task:

• User-facing problem: recommendation, agent planning, RL training, retrieval, verification, generation, ranking, etc.
• Runtime mode: training, inference, interactive loop, offline pipeline, online system, or hybrid.
• Scope line: what should be inside the diagram and what should remain external.

Use one sentence as the north-star statement:

This architecture explains how [inputs/state] are transformed by [core mechanism] into [outputs/decision], under [objective/constraint].

2. Extract inputs and outputs

Separate inputs by source:

• User input: query, command, preference, feedback, task instruction.
• System input: history, memory, candidate pool, documents, tools, retrieval results.
• Model input: prompt, trajectory, state, observation, reward, policy context.
• Prior-round input: previous result, updated state, accumulated preference, verifier signal.

Define outputs at two levels:

• Final output: answer, Top-K list, action sequence, policy update, score, plan, decision.
• Intermediate output: parsed intent, updated memory, filtered candidates, tool results, verifier labels, fused score.

3. Identify state and memory

Architecture diagrams become useful when they show what changes over time. Always ask:

• What state persists across turns or training iterations?
• What is explicit memory versus implicit history?
• Which module updates the state?
• Which state feeds the next round?
• What is immutable data, such as a candidate pool or corpus?

Draw persistent data near the bottom of the diagram. Draw cross-round feedback arrows clearly.

4. Split components by mechanism, not code files

Use paper-level mechanisms as components. Each component must have:

• Responsibility: one precise verb phrase.
• Input: named variables or artifacts.
• Output: named variables or artifacts.
• Implementation: formula, prompt, classifier, retriever, ranker, tool call, reward model, optimizer, rule, or learned module.
• Evidence: section, algorithm step, equation, figure, table, or experimental claim.

Avoid generic boxes like "LLM", "Model", or "Database" unless the paper truly treats them as black boxes. Prefer mechanism names such as Parser, Planner, Filter, Matcher, Attenuator, Aggregator, Verifier, Reward Model, Policy Optimizer, Memory Updater, or paper-specific terms.

Concept clarity rule

Do not pile up unexplained labels, chips, or jargon. Every concept introduced in a diagram node must be explained close to where it appears:

• Define what the concept means in plain language.
• State what triggers it or what input it consumes.
• State what it changes downstream, such as a state update, candidate filtering, score increase, score penalty, or tool choice.
• Use standalone chips only when the same viewport already defines the terms. Otherwise prefer short definition rows like hard = must-pass attribute constraint -> Filter or Resolve = replace conflicting preference slots.
• For tool-chain nodes, never show only ToolName + formula. Each tool should state trigger -> operation -> downstream effect, for example: Filter: hard constraints trigger attribute filtering -> I' subset I -> later scorers run only on I'.

Before finalizing a diagram, check whether a reader can explain each box without rereading the paper. If not, reduce labels or add adjacent definitions.

5. Map formulas and algorithms into the diagram

Create a paper-to-diagram mapping before drawing:

Paper evidence	Diagram module	Data consumed	Data produced	Implementation note
Section / Eq. / Algorithm	Component name	Variables	Variables	Formula, prompt, rule, or model

If the paper has Algorithm 1, map each major algorithm block to either:

• A component.
• An arrow between components.
• A state update.
• A training objective or evaluation metric.

6. Build the main architecture layout

Use this default layout, inspired by the reference image:

• Top band: user/system input on the left, task loop in the center, final output on the right.
• Middle band: core intelligent modules and tool chain. Example: Parser for intent/state extraction, Planner for orchestration, then ordered tools such as filter, matcher, suppressor, aggregator.
• Bottom band: persistent state, history, memory, corpus, candidate pool, tools, and environment.
• Footer band: capabilities, guarantees, metrics, constraints, or research contribution.

Use solid arrows for data flow. Use dashed arrows for feedback, optional control flow, or cross-round updates. Label arrows when a variable changes name.

7. Specify key implementation

For each module, include the most likely implementation primitive:

• Prompt or schema extraction.
• Structured parser or classifier.
• Retrieval, reranking, embedding matching, or candidate filtering.
• Tool-calling workflow, planner, verifier, or executor.
• Memory write rule, decay rule, conflict resolution, or summarizer.
• Scoring function, weighted fusion, learned ranker, reward function, or optimization loop.
• Safety, cost, latency, and fallback controls when relevant.

Do not invent training objectives beyond the paper unless the user explicitly asks for design extensions.

8. Add evaluation and failure modes

State what the architecture optimizes:

• Recommendation: Recall@K, NDCG, CTR, conversion, diversity, satisfaction.
• Agent: success rate, reward, tool accuracy, cost, turns, verifier pass rate.
• RAG/QA: exact match, factuality, citation precision, latency, groundedness.
• Training method: sample efficiency, stability, reward, generalization, compute cost.

List likely failures:

• Empty candidates, conflicting preferences, stale memory, hallucinated state, bad retrieval, tool failure, over-filtering, reward hacking, verifier false positives, privacy or cost constraints.

Reference Image Pattern

When following the provided architecture image, preserve this abstraction:

• Input contains both recommendation/context stream and user command.
• Parser converts user intent into explicit preference and updates memory.
• Planner orchestrates tools and adjusts strategy.
• Ordered tools transform candidates: hard filter, positive match, negative suppression, score aggregation.
• Bottom state includes user history, implicit preference, candidate pool, and reusable system capabilities.
• Output includes final score, Top-K result, and next-round stream.

For other papers, rename the modules to match the paper, but keep this discipline:

Input + Previous State -> Core Parser/Encoder -> Planner/Controller -> Tool/Model Chain -> Aggregator/Decision -> Output + Updated State

Junhao-Style Visual Requirements

When producing an HTML/report/visual spec, use the Junhao research dossier style:

• Warm paper/grid background, not a generic blue SaaS palette.
• Centered two-column shell: sticky left TOC and main document.
• Integrated first-viewport hero with a clear north-star statement and a compact briefing board.
• Serif Chinese headings, strong numbered section plates, thin borders, small radius, hard offset shadow.
• Matrix tables for module mapping and paper evidence.
• Sprint/SOP timeline for conversion steps.
• Semantic accents: red for decision/risk, teal for workflow/output, ochre for tradeoff, green for validation, cobalt for technical path.
• Predominantly light panels. Use dark carbon panels only for high-value briefing boards or template headers.
• Do not use decorative blobs, neon gradients, purple AI backgrounds, or repeated generic cards.

Formula Rendering In HTML

When producing standalone HTML, render all paper variables and equations with LaTeX instead of raw text. Use MathJax SVG by default:

<script>
  window.MathJax = {
    tex: { inlineMath: [["\\(", "\\)"]], displayMath: [["\\[", "\\]"]] },
    svg: { fontCache: "global" }
  };
</script>
<script defer src="https://cdn.jsdelivr.net/npm/mathjax@3/es5/tex-svg.js"></script>

Wrap inline variables and equations as <span class="math">\(P_{t+1}\)</span> or use display math for larger equations. Do not put LaTeX inside code or pre, because MathJax will skip it. This applies inside diagram nodes, matrix tables, briefing boards, timelines, and checklist text.

Recommended sections for a Junhao dossier:

1. 一句话结论.
2. 论文任务边界.
3. 输入 / 输出 / 状态定义.
4. 组件拆解矩阵.
5. 论文证据映射.
6. 架构图主流程.
7. 关键实现.
8. 指标、失败场景和交付检查表.

Output Templates

Component table

Module	Responsibility	Input	Output	Key implementation	Paper evidence
Parser / Encoder	Parse intent or encode state	User command, history	Structured state	Prompt schema / encoder	Section X
Planner / Controller	Choose next operation	State, tools, constraints	Tool chain / action plan	Policy / rules / planner	Algorithm Y
Aggregator / Decision	Fuse signals	Scores, verifier labels	Final result	Weighted score / learned head	Eq. Z

SOP timeline

Step	Action	Output
1	Read abstract, intro, method, algorithm, figure, experiments	Task boundary and contribution claim
2	Extract inputs, outputs, states, objectives	I/O/state inventory
3	Group mechanisms into components	Component list
4	Map formulas and algorithm steps	Evidence mapping table
5	Draw top/middle/bottom architecture bands	First diagram draft
6	Add implementation and metrics	Engineering blueprint
7	Check visual and logic consistency	Final Junhao-style dossier

Diagram quality checklist

• Every box has a concrete responsibility.
• Every arrow carries a named artifact or state transition.
• Every persistent state has an update source.
• The paper's claimed contribution is visually central.
• Concepts and chips are explained in-place; there is no unexplained label stacking.
• Inputs, outputs, components, implementation, metrics, and failure modes are all present.
• The diagram can be explained from left to right in under one minute.
• The component table can be traced back to paper sections, algorithms, equations, figures, or experiments.

Verification

Before finishing:

• Check that the architecture is not merely a restyled paper figure; it should expose implementation structure.
• Check that no core paper mechanism disappeared during simplification.
• Check that speculative engineering additions are labeled as assumptions.
• Check that labels like positive, hard, Verifier, Planner, or paper-specific terms have adjacent plain-language definitions when they are first shown.
• For Junhao-style HTML, preview locally when feasible and verify: sticky TOC, warm paper background, readable matrix tables, timeline layout, no overlapping text, and a first viewport that explains the artifact's purpose.
• For HTML with formulas, verify MathJax has rendered variables/equations; there should be no visible raw strings such as P_{t+1}, s_final, or $...$ in user-facing text.