Back to Details

morphiq-rank

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Pipeline Position

流水线位置

Step 2 of 4 — consumes morphiq-scan output.
  • Input: Scan Report (JSON) from morphiq-scan.
  • Output: Prioritized Roadmap (JSON) → consumed by morphiq-build.
  • Data contract: See 
    PIPELINE.md
    §2 for the Prioritized Roadmap schema.
4步中的第2步 — 接收morphiq-scan的输出。
  • 输入： 来自morphiq-scan的扫描报告（JSON格式）
  • 输出： 优先级排序的路线图（JSON格式）→ 供morphiq-build使用
  • 数据契约： 优先级路线图的Schema请参考
    PIPELINE.md
    第2节

Purpose

用途

Morphiq Rank transforms raw scan findings into an actionable, prioritized roadmap. It determines severity, assigns progressive discovery tiers, calculates priority scores, and controls how many issues are revealed. The output tells morphiq-build what to fix and in what order.
Morphiq Rank将原始扫描结果转化为可执行的、按优先级排序的路线图。它会确定严重程度、分配递进的发现层级、计算优先级分数，并控制要披露的问题数量。输出内容会告知morphiq-build需要修复什么、按什么顺序修复。

Workflow

工作流程

Step 1: Ingest Scan Report

步骤1：读取扫描报告

Parse the Scan Report JSON. Extract per-page scores, domain-level scores, all identified issues, and the overall pipeline score (0–100).
解析扫描报告JSON，提取单页得分、域名层级得分、所有识别到的问题，以及整体流水线得分（0–100）。

Step 2: Create Issues

步骤2：创建问题

For each finding, create a formal issue:
FieldDescription
id
Pattern: 
{category}-{specific-problem}
category
agentic_readiness
, 
content_quality
, 
chunking_retrieval
, 
query_fanout
, 
policy_files
, 
ai_visibility
severity
From issue catalog + escalation rules
summary
One-line description
detail
Full explanation with AI visibility impact
affected_urls
URLs where the issue appears
remediation_hint
Actionable fix instruction
For fanout issues, severity depends on parent prompt type fan-out depth. 
site:
and citation-producing sub-queries escalate one level.
For 
fanout-*
issues, populate 
fanout_context
from the scan report's 
query_fanout.simulated_queries[]
and 
query_fanout.suggested_content[]
. Each simulated query mapping to this issue becomes a 
triggering_sub_queries
entry:
  • query
    ← from 
    simulated_queries[].query
  • model_origin
    ← from 
    simulated_queries[].model
    (rename 
    model
    → 
    model_origin
    )
  • prompt_type
    ← from 
    simulated_queries[].prompt_type
  • citation_weight
    ← from 
    simulated_queries[].citation_weight
  • parent_prompt
    ← for simulated queries, set to 
    "(simulated)"
    ; for 
    suggested_content[]
    entries, use the 
    suggestion
    field
If the Delta Report's 
content_creation_queue
has entries matching this issue, include their 
competitor_sources
in 
fanout_context.competitor_sources[]
.
Deduplication: Technical issues hash by 
brandId + checkCode + pageUrl
. AI visibility issues hash by 
brandId + category + title
.
For all issue types and severity logic, read 
references/issue-catalog.md
.
针对每个发现的问题，创建正式的问题记录：
字段描述
id
格式：
{category}-{specific-problem}
category
agentic_readiness
, 
content_quality
, 
chunking_retrieval
, 
query_fanout
, 
policy_files
, 
ai_visibility
severity
来自问题目录 + 升级规则
summary
单行描述
detail
包含AI可见性影响的完整说明
affected_urls
问题出现的URL列表
remediation_hint
可执行的修复指导
针对扇出问题，严重程度取决于父提示类型的扇出深度。
site:
类查询和生成引用的子查询会提升一级严重程度。
针对
fanout-*
类问题，从扫描报告的
query_fanout.simulated_queries[]
和
query_fanout.suggested_content[]
中填充
fanout_context
。每个映射到该问题的模拟查询都会成为
triggering_sub_queries
的条目：
  • query
    ← 来自
    simulated_queries[].query
  • model_origin
    ← 来自
    simulated_queries[].model
    （将
    model
    重命名为
    model_origin
    ）
  • prompt_type
    ← 来自
    simulated_queries[].prompt_type
  • citation_weight
    ← 来自
    simulated_queries[].citation_weight
  • parent_prompt
    ← 模拟查询设置为
    "(simulated)"
    ；
    suggested_content[]
    条目使用
    suggestion
    字段值
如果Delta报告的
content_creation_queue
中有匹配该问题的条目，将其
competitor_sources
加入
fanout_context.competitor_sources[]
。
去重规则： 技术问题按
brandId + checkCode + pageUrl
哈希去重。AI可见性问题按
brandId + category + title
哈希去重。
所有问题类型和严重程度逻辑请查阅
references/issue-catalog.md
。

Step 3: Assign Tiers

步骤3：分配层级

TierNamePrimary Categories
1Foundation — Crawlability & Policy
policy-*
2Structure — Schema & Metadata
agentic-*
3Content — Depth & Coverage
content-*
, 
fanout-*
, 
visibility-*
4Optimization — Retrieval Quality
chunking-*
Edge cases: 
fanout-wrong-page-type
→ Tier 2. Multi-tier issues → lowest applicable tier.
For tier definitions and dependency logic, read 
references/tier-progression.md
.
层级名称主要分类
1基础层 — 可爬取性与政策
policy-*
2结构层 — 模式与元数据
agentic-*
3内容层 — 深度与覆盖度
content-*
, 
fanout-*
, 
visibility-*
4优化层 — 检索质量
chunking-*
边缘情况：
fanout-wrong-page-type
→ 层级2。跨层级问题 → 适用的最低层级。
层级定义和依赖逻辑请查阅
references/tier-progression.md
。

Step 4: Calculate Priority Scores

步骤4：计算优先级分数

priority = (severity_weight × 0.4) + (page_impact × 0.3) + (citation_potential × 0.2) + (effort_inverse × 0.1)
severity: critical=100, high=75, medium=50, low=25. page_impact: % pages affected. effort_inverse: low=100, medium=50, high=25.
priority = (severity_weight × 0.4) + (page_impact × 0.3) + (citation_potential × 0.2) + (effort_inverse × 0.1)
严重程度权重：critical=100, high=75, medium=50, low=25。page_impact：受影响页面占比。effort_inverse：低工作量=100, 中工作量=50, 高工作量=25。

Step 5: Apply Progressive Reveal

步骤5：应用递进披露规则

Score-based: <30 → fundamental only, ≥30 → +intermediate, ≥60 → +advanced, ≥80 → all tiers.
Page-based: First run = homepage only. Each subsequent run unlocks one more page (home → pricing → features → product → solutions → about → blog → other → docs).
Backlog cap: Max 10 issues in 
identified
state.
基于分数： <30 → 仅披露基础问题，≥30 → 增加中级问题，≥60 → 增加高级问题，≥80 → 披露所有层级问题。
基于页面： 首次运行 = 仅披露首页问题。后续每次运行解锁一个更多页面（首页 → 定价页 → 功能页 → 产品页 → 解决方案页 → 关于页 → 博客 → 其他 → 文档）。
待办上限： 
identified
状态的问题最多保留10个。

Step 6: Set Dependencies

步骤6：设置依赖关系

Cross-tier: 
T1 → T2 → T3 → T4
. Higher-tier issues on same URLs only become actionable when lower-tier issues are resolved. Within-tier explicit dependencies also apply.
跨层级依赖：
T1 → T2 → T3 → T4
。相同URL上的更高层级问题，只有在更低层级问题解决后才会变为可执行状态。同层级内的显式依赖也适用。

Step 7: Produce Prioritized Roadmap

步骤7：生成优先级路线图

Assemble JSON (
PIPELINE.md
§2): issues by tier, sorted by priority, with severity, remediation hints, affected URLs, dependencies, and reveal state metadata.
组装JSON（符合
PIPELINE.md
第2节规范）：按层级分组的问题，按优先级排序，包含严重程度、修复提示、受影响URL、依赖关系和披露状态元数据。

Reconciliation (Re-runs)

对账（重复运行）

On subsequent scans with existing issues:
  1. Auto-close issues where the check now passes (unless PR-linked)
  2. Escalate worsened issues
  3. Create new issues for new findings
  4. Detect regressions (previously completed issues re-appearing)
For issue lifecycle and auto-close logic, read 
references/tier-progression.md
.
后续扫描存在已有问题时：
  1. 自动关闭当前检查已通过的问题（除非关联了PR）
  2. 升级恶化的问题严重程度
  3. 为新发现的问题创建新记录
  4. 检测回归问题（之前已完成的问题再次出现）
问题生命周期和自动关闭逻辑请查阅
references/tier-progression.md
。

Reference Files

参考文件

FilePurpose
references/issue-catalog.md
All issue types (50+), severity logic, deduplication, check code mapping
references/tier-progression.md
4-tier model, dependencies, priority formula, reveal thresholds, lifecycle
文件用途
references/issue-catalog.md
所有问题类型（50+）、严重程度逻辑、去重规则、检查代码映射
references/tier-progression.md
4层级模型、依赖关系、优先级公式、披露阈值、生命周期