AI Requirements Mining / Process Knowledge Extraction Playbook

配对阅读：本手册的原理/架构解读版是 docs/ai-foundations/papers/148-ai-requirements-mining-process-knowledge-extraction-architecture.md。先读 paper 建立机制与取舍，再用本手册落地为模板、RACI 与门禁，两者不需要重复精读。

Requirements mining 不是把文档丢给大模型生成 backlog，而是把多源业务、流程、控制和生产证据转成可追溯、可评估、可验证、可治理、可复用的 requirement and process knowledge assets。AI 可以扩大证据面、发现冲突、聚类噪声和生成候选资产；人类专家负责解释、取舍、授权、治理和上线责任。

在金融零售环境中，PRD、BRD、SOP、政策、工单、会议纪要、通话转写、流程图、API 规格、测试用例、生产日志和控制证据都可能包含需求线索。但这些来源的权威级别、版本、生效日期、权限、隐私、记录保留和业务语义完全不同。高级 requirements mining 的重点，是让系统“广泛挖掘、窄口信任、显式验证、全链路追踪”。

---

1. Source Anchors

Source-to-artifact pattern:

official source anchor
  -> governance principle
  -> mining requirement
  -> architecture control
  -> evidence artifact
  -> owner and metric

---

2. Executive Framing

高管或业务方常见诉求通常像这样：

我们有很多 PRD、SOP 和 ticket，能不能让 AI 自动生成需求？
我们想把会议记录和客服通话转成 backlog。
我们能不能让 AI 看代码和测试用例，反推出系统需求？

这些诉求需要被改写为系统能力：

Build an evidence-grade requirements and process knowledge extraction capability
that mines candidate needs, rules, events, controls, acceptance criteria and impact links
from governed artifacts,
filters by source authority and permissions,
routes ambiguity to SMEs,
and learns from production feedback without turning AI drafts into approved requirements.

Steering questions:

1. 哪些 artifact 是权威来源，哪些只是 pain signal 或 discussion evidence？
2. AI 输出进入 baseline 前由谁验证、用什么 rubric、保留什么证据？
3. 如何防止越权检索、过期政策引用、PII 泄露和记录处置失控？
4. 如何把 mined requirements 连接到 process、API、data、test、control、eval 和 release？
5. 如何从 production logs、QA、complaints、incidents 和 human overrides 回流到 portfolio learning？

---

3. Use Case Boundary

Requirements mining 适合产生候选、冲突、证据和影响分析，不适合直接产生批准结论。

不适合直接交给 AI 的任务：

---

4. Target Operating Model

Business / Product Owner
  owns outcome, priority, scope, baseline decision

Requirements Architect
  owns mining taxonomy, ambiguity workflow, quality rubric, traceability graph

Process Owner / SME
  validates process activities, exceptions, variants and operating feasibility

Architecture / Engineering
  validates API, data, system, security, performance and integration impact

Risk / Compliance / Control Owner
  validates policy/control linkage, risk tier, approval boundary and evidence need

Privacy / Records / Legal
  validates data use, records class, hold propagation, access and retention controls

QA / EvalOps
  converts mined requirements to tests, eval contracts, thresholds and regression gates

AI Platform / Data Engineering
  operates ingestion, retrieval, permission filter, graph, model versioning and monitoring

RACI snapshot:

---

5. Implementation Architecture

Connectors
  Confluence / SharePoint / Docs / Jira / Azure DevOps / Git / API gateway
  Contact center / CRM / case management / log platform / GRC / test management
        |
        v
Governed ingestion
  artifact id | source type | owner | approval status | version | hash
  effective date | data class | record class | permission tag | legal hold flag
        |
        v
Pre-processing
  parsing | OCR/layout | transcript diarization | code/API parsing | test extraction
  log event mapping | PII redaction | chunking | metadata enrichment
        |
        v
Knowledge layer
  domain vocabulary | process ontology | authority ladder | policy/control map
  requirement graph | event graph | system/API graph | test/eval graph
        |
        v
AI extraction and reasoning services
  candidate requirements | ambiguity | conflict | duplicate | process events
  stakeholder concerns | evidence standards | acceptance criteria | impact links
        |
        v
Human validation workbench
  side-by-side source evidence | approve/reject/merge/split/escalate
  reason codes | SME comments | decision record | audit trail
        |
        v
Delivery and governance
  backlog sync | requirement baseline | eval contract | test generation
  architecture review | control evidence | release gate | learning loop

Architecture non-negotiables:

---

6. Source Intake and Authority

No artifact enters the mining corpus without owner, version, permission tag and source class. No restricted source enters AI processing without approved purpose and redaction path.

Authority decision rules:

---

7. Candidate Movement Rules

AI output moves through governed states. It is never approved by generation alone.

Human review level:

---

8. Extraction Prompt Contract

Extraction prompts are controlled product artifacts. They must say what to extract, what not to infer, how to expose uncertainty and how to preserve source authority.

Required output schema:

{
  "candidate_id": "string",
  "candidate_type": "business_requirement | stakeholder_requirement | solution_requirement | transition_requirement | control_requirement | data_requirement | process_rule | acceptance_criterion | risk_issue",
  "statement": "string",
  "source_refs": [
    {
      "artifact_id": "string",
      "location": "section/page/span/event_id",
      "authority_level": "A1|A2|A3|A4|A5|A6",
      "effective_date": "YYYY-MM-DD"
    }
  ],
  "known_facts": ["string"],
  "unknowns": ["string"],
  "ambiguity_flags": ["actor_unknown", "decision_boundary_unknown", "data_scope_unknown", "control_owner_missing"],
  "conflicts": ["string"],
  "quality_score": 0,
  "recommended_acceptance_criteria": ["string"],
  "validation_owner": "role",
  "risk_tier": "low|medium|high|restricted"
}

Prompt rules:

---

9. Requirement Quality Gate

Scoring interpretation:

---

10. Traceability Graph

Graph structure turns mined text into impact analysis capability.

Minimum graph queries:

---

11. Process Variant Discovery

生产日志揭示 work-as-done，但需要业务语义化才能成为流程知识。

Input pattern:

case_id, activity, timestamp, resource, lifecycle, channel, product,
risk_tier, amount_band, status, outcome, source_system

Steps:

1. 定义 case 粒度：application、dispute、alert、ticket、complaint、service request。
2. 标准化 activity：避免把状态码直接当业务活动。
3. 生成 top variants：找覆盖 80% 体量的主要路径和高风险长尾。
4. 标记 rework、waiting、handoff、skip、loop、override。
5. 与 SOP、process map 和 control path 对齐，区分 acceptable exception、control gap、data noise。
6. 生成 AI opportunity candidates：summarize、route、draft、validate、retrieve、recommend、tool action。
7. 将每个机会连接到 requirement、acceptance criteria、control 和 eval。

Variant interpretation:

---

12. Eval Contract for the Mining System

Mining system 本身也必须被评估。否则组织会把未经验证的抽取系统当成事实来源。

Critical failures:

---

13. Evidence and Control Checklist

Pre-launch

Production

---

14. 30 / 60 / 90 Roadmap

First 30 days: controlled discovery

Exit criteria:

The team can show source-backed candidates, rejected examples, ambiguity log,
and at least one requirement-to-test-to-control trace for the selected workflow.

Days 31-60: graph, eval and SME workflow

Exit criteria:

The mining system can pass golden-set eval, route ambiguous outputs to SMEs,
and create backlog items only with source refs, quality score and validation evidence.

Days 61-90: production pilot and portfolio learning

Exit criteria:

The organization can demonstrate faster discovery, better traceability,
measurable SME productivity, controlled risk, and reusable portfolio assets.

---

15. Metrics

---

16. Anti-Patterns and Repairs

---

17. Evidence Artifact Structures

Requirements mining 产物应当以证据字段表达，而不是以可填写表单堆砌。下面三个结构用于约束 intake、candidate review 和 change impact 的最低证据粒度。

17.1 Mining Intake Brief

17.2 Requirement Candidate Review Card

17.3 Change Impact Memo

---

18. Decision Narrative

Requirements mining 的端到端架构从 governed ingestion 开始，对 PRD、SOP、policy、tickets、transcripts、work items、code/API、tests、logs 和 controls 做 source inventory、authority classification、permission filtering 和 versioning。系统用 domain vocabulary 和 process ontology 做结构化抽取，生成 requirement candidate、process event、stakeholder concern、control link、acceptance criteria 和 impact links。所有输出进入 traceability graph，经 quality rubric、eval contract 和 SME validation 后，才进入 backlog 或 baseline。

它不是普通 RAG summarization。RAG 总结回答“这些材料说了什么”，requirements mining 要回答“哪些内容可以成为需求、依据是什么、权威级别如何、哪里冲突、哪里模糊、谁验证、怎么测试、影响哪些系统和控制、上线后怎么监控”。核心资产不是摘要，而是 source-backed graph、quality score、eval contract、SME decision log 和 change impact evidence。

低权威来源应作为 discovery signal，而不是 baseline。通话转写可能错，客户表达可能是情绪或投诉，会议纪要可能不是批准决定，ticket 可能是重复噪声。进入 baseline 需要更高权威来源或 owner 追认。

冲突图是高价值发现。政策和控制是约束，SOP 是 intended process，生产日志是真实行为。系统不应让 AI 平滑合并冲突，因为冲突本身可能代表流程绕行、控制缺口、SOP 过期、系统缺陷或政策解释不清。

生产日志揭示 work-as-done。文档挖掘告诉我们设计意图，日志挖掘告诉我们真实行为。两者结合，才能决定该做 AI assistant、流程重构、数据质量改进、API 集成，还是控制修复。

隐私、records 和权限必须先于检索。raw artifacts、chunks、embeddings、summaries、review notes 和 graph nodes 都可能成为 derived artifacts，必须有 retention、legal hold propagation、purpose limitation 和 audit log。

核心原则：

Mine broadly, trust narrowly, validate explicitly, trace everything,
and let production evidence improve the operating knowledge base.