极点宏观｜Financial Cloud Cloud · 挑战
周末生产力挑战：Fab SPC 漂移同步门户
周末生产力挑战：Fab SPC 漂移同步门户
实时应用程序： Fab SPC Drift Synchronization Portal
公开源代码： GitHub — src/main.tsx
这是一个为半导体量测工程师打造的 AI 驱动生产力应用程序，使用 Kiro 开发，并以 Amazon S3、Amazon CloudFront、Amazon Route 53、AWS Certificate Manager、AWS WAF、Amazon MSK、AWS Lambda、AWS Glue 与 AWS Lake Formation 在 AWS 上实施。
Fab SPC Drift Synchronization Portal 是一套以 AWS 为基础的系统，可协助半导体工程师识别设备漂移、查看佐证数据，并排定最安全的下一步行动优先顺序。 包含 CD-SEM、SPC、FDC、APC、批次路径与良率监控系统在内的制造系统，会将作业事件送往 Amazon MSK，由它提供实时串流骨干。
AWS Lambda 会处理这些事件，包含： 验证并标准化进入的数据 检查时间戳记与数据质量 计算设备健康与漂移特徵 执行以 AI 为基础的风险推论 套用确定性的工程规则 产生排定优先顺序的建议
处理后的数据、AI 结果与审计证据会存储在 Amazon S3 数据湖。AWS Glue 会编目数据集并管理模式，AWS Lake Formation 则管控敏感制造信息的访问权限。 工程师会通过 Amazon Route 53 与 Amazon CloudFront 访问 React 门户。React 应用程序存储在私有 Amazon S3 存储桶，而 AWS WAF 会保护公开进入点，避免不需要的流量。门户会显示风险分数、原因代码、佐证数据，以及 Release、Watch、Run SPC、Golden Wafer、Route Limit、APC Guard 或 Hold Review 等建议行动。 此系统定位为建议型且保留人在流程中：它协助工程师更快做出以证据为基础的决策，但不能直接控制设备、hold lots、变更 routes，或修改 APC settings。[codpayment...epoint.com]
简易数据流程
Manufacturing Systems
↓
Amazon MSK
↓
AWS Lambda Processing and AI
↓
Amazon S3 Data Lake
↓
AWS Glue + AWS Lake Formation
↓
Lambda API
↓
React Portal on S3 and CloudFront
↓
Engineer Reviews Recommendation愿景与应用程序功能
统计工艺管制（SPC）在半导体制造中至关重要，但排程序 SPC 结果只是一个快照。CD-SEM 可能通过最后一次管制检查，接着在生产批次持续流动时开始漂移。电子枪真空退化、发射电流变动、偏转器不稳、载台震动、污染、匹配状态变化，或单纯的量测老化，都可能在排定检查之间出现。在这段期间，工程师可能需要开启多个系统、手动匹配时间戳记、计算机群偏差、追溯产品路径、查看设备症状，并决定是否放行、观察、重新量测、重新派工或暂停。
这种调查同时是制造风险，也是生产力问题。
Fab SPC Drift Synchronization Portal 是一个个人 AI 驱动生产力工作区，能将这类调查压缩成一个已排序且可解释的审查体验。它会把具备生产场景的 SPC 指标与 fault detection and classification（FDC）遥测、量测结果、设备匹配佐证、机群行为与良率监控上下文同步起来。工程师不必手动重建完整场景，门户会提供已排序的风险看板，并让每个建议背后的佐证数据立即可见。
门户回答四个实务问题：
● 哪一台设备最需要优先关注？
● SPC 盲窗期间发生了什么变化？
● 哪些佐证数据支撑这项风险评估？
● 最安全的下一个工程行动是什么？
目前的 React 体验包含六个作业区域：
● Overview 说明控制回路，并显示机群层级的生产力指标。
● Live Risk Board 支持搜索、排序、排名，以及展开个别 CD-SEM 记录。
● FDC Health-Link 将设备症状对应到量测影响与潜在良率曝险。
● Dynamic Matching 比较每台设备与机群行为及稳定参考设备。
● Yield Triage 组合用来区分工艺变动与量测错误所需的佐证数据。
● Runbook 将解决方案转换成从 proof of concept 到 production operation 的可重复工程 workflow。
对每一台设备，门户会评估盲窗时间、设备匹配差距、Mandel slope、机群偏差、残差噪声、趋势行为、layer criticality，以及相关 FDC 信号。接着它会产生受控建议：
● RELEASE
● WATCH
● RUN SPC
● GOLDEN WAFER
● ROUTE LIMIT
● APC GUARD
● HOLD REVIEW
此应用程序刻意设计为 建议型。AI 可以检测模式、排序工作、汇整佐证数据，并建议下一步行动，但它不能指挥制造设备或绕过工程师批准。这个 human-in-the-loop 边界是产品设计的一部分，不是事后补上的限制。
从生产力角度来看，portal 就像专门的 task prioritizer、investigation assistant 与 shift-handoff tool。它减少 context switching，让每项建议都可重现，并协助工程师把时间花在最高风险 tool，而不是手动寻找下一个问题。
我如何构建
Kiro 开发工作流程
我使用 Kiro 作为 AI-assisted development environment，进行需求分析、架构设计、实施规划、代码产生、重构、测试与 production hardening。
我没有从孤立的 UI 代码开始，而是先向 Kiro 描述工程成果：
缩短在排定 SPC checks 之间识别 CD-SEM drift 所需的时间，同时保留人类对每一项制造行动的决策权。
我将该成果转换成一份 Kiro specification，包含三个协同 artifacts：
.kiro/specs/fab-spc-drift-portal/
├── requirements.md
├── design.md
└── tasks.md通过 Kiro 建立的需求
Requirements 被写成可测试的行为：
● 当 normalized tool data 抵达时，application 必须更新受影响 tool 的 risk state。
● 当用户展开一台 tool 时，application 必须显示 value、engineering limit、event time、data-quality state 与 reason code。
● 当必要数据 stale、missing、incompatible，或超出 approved model domain 时，application 必须返回 REVIEW_REQUIRED，而不是推论为安全状态。
● 每一项建议都必须能从 versioned rule set、model artifact、feature set 与 source-event range 重现。
● 没有任何 application component 可以在缺少 independently authenticated human approval process 的情况下启动 equipment command、lot hold、route change 或 APC change。
● 当 AI explanation 无法取得时，user interface 必须通过 deterministic evidence 与 safe fallback message 维持可用。
通过 Kiro 捕捉的设计决策
Kiro 协助将解决方案拆成五个边界：
● React delivery 与 browser security；
● 使用 Amazon MSK 的 streaming ingestion；
● 使用 AWS Lambda 的 validation、normalization、feature calculation 与 inference；
● Amazon S3 中的 immutable evidence storage；以及
● 使用 AWS Glue 与 AWS Lake Formation 的 governed discovery and access。
这种分离避免 front end 变成 system of record。Browser 只显示结果；它不持有 Kafka credentials、不能访问 raw manufacturing data、不能计算 authoritative disposition，也不能调用 equipment interfaces。
Kiro steering 与自动化检查
Project steering files 建立了持续性的工程规则：
.kiro/steering/
├── architecture.md
├── aws-security.md
├── react-typescript.md
├── streaming-contracts.md
├── ai-safety.md
└── testing-standards.mdSteering guidance 要求：
● TypeScript strictness 与明确 domain types；
● accessible labels 与 keyboard-operable controls；
● 使用 private Amazon S3 origins，而不是 public website buckets；
● least-privilege AWS Identity and Access Management policies；
● 每个 Amazon MSK event 都要 schema versioning；
● idempotent AWS Lambda processing；
● React code 中不得有 secrets 或 AWS credentials；
● AI failure 要有 deterministic fallbacks；
● 记录 model 与 rule version；以及
● 对 manufacturing-impacting recommendations 进行明确 human review。
Kiro hooks 将 formatting、linting、unit tests、schema compatibility checks、dependency scanning、infrastructure validation，以及拒绝任何能发出 autonomous equipment command 之 code path 的 safety test 自动化。
React 与 TypeScript 前端
User interface 实施为 React single-page application。提供的 main.tsx 为 tools、actions、FDC mappings、runbook steps、tabs、sort keys 与 risk tones 定义 typed objects。这很重要，因为界面代表的是受控工程状态，而不是任意字符串。
实施依作业责任拆成 components：
● Header 与 Hero 建立目前系统上下文；
● KPIStrip 汇总工程师工作量；
● LiveRiskBoard 筛选并排序 tools；
● Sparkline、LargeLineChart 与 FleetBars 视觉化 evidence；
● FDCHealth 解释 equipment-to-metrology relationships；
● DynamicMatching 显示 fleet comparisons；
● YieldTriage 结构化调查流程；
● Runbook 说明受控 rollout；以及
● Sop 嵌入预期 user procedure。
示范 UI 会更新本机 sample values 以展示互动行为。在 production design 中，这些 fixture updates 会被 Lambda-managed state 产生的 authenticated API responses 取代。Presentation contract 维持稳定：UI 接收 sanitized tool summary、timestamp、risk score、confidence、reason codes、limits、recommendation 与 evidence references。
最重要的实施决策，是分离三个概念：
● Observed facts — 已验证的来源值与时间戳记；
● Analytical decisions — calculated features、engineering rules 与 AI risk scores；以及
● Presentation — 向人类解释结果的 React components。
因此，presentation bug 不能改变 authoritative recommendation，AI-generated explanation 也不能覆写 measured value。
使用的 AWS 服务 / 架构总览
Production architecture 刻意使用以下 service scope：
● Kiro development
● Amazon S3、Amazon CloudFront、Amazon Route 53、AWS Certificate Manager 与 AWS WAF 用于 React delivery
● Amazon MSK 作为 streaming backbone
● AWS Lambda 用于 data massage、feature engineering、AI inference、APIs 与 event processing
● Amazon S3 data lake、AWS Glue 与 AWS Lake Formation 用于 governed evidence
架构概览
ENGINEER
|
v
Amazon Route 53
|
v
Amazon CloudFront ---- AWS WAF
| |
| +-- managed rules, rate control, request filtering
v
Private Amazon S3 bucket
React / TypeScript build artifacts
FAB EVENT PRODUCERS
CD-SEM | FDC | SPC | lot route | APC | yield-watch
|
v
Amazon MSK topics
|
v
AWS Lambda normalization and validation
|
+--> Amazon S3 raw evidence zone
|
v
AWS Lambda feature engineering and AI inference
|
+--> Amazon MSK recommendation topic
+--> Amazon S3 curated, feature, model-output, and audit zones
+--> React query API implemented with AWS Lambda
Amazon S3 data lake
|
v
AWS Glue Data Catalog and schema management
|
v
AWS Lake Formation governed access这是一个 deployment-oriented view，显示 web-delivery boundary、streaming boundary、processing boundary 与 governance boundary。
Amazon S3、CloudFront、Route 53、ACM 与 WAF：React 交付
Production React build 由 CI/CD process 产生，并部署到 private Amazon S3 bucket。该 bucket 不会设置成公开可访问的 S3 website。Amazon S3 Block Public Access 保持启用，Amazon CloudFront 则使用 Origin Access Control 从 bucket 提取 objects。
Deployment package 包含 content-hashed assets：
dist/
├── index.html
├── assets/index.<content-hash>.js
├── assets/index.<content-hash>.css
└── approved static assetsContent hashing 让 JavaScript 与 CSS 可以使用长时间 immutable cache lifetime。index.html 使用较短的 cache lifetime，因为它指向目前 asset versions。Deployment 会先上传 immutable assets，最后才上传 index.html，避免 HTML document 参照到尚未可用的 files。
Amazon CloudFront 设置
Amazon CloudFront 提供全球 HTTPS entry point，并执行：
● React assets 的 edge caching；
● compression；
● TLS termination；
● origin protection；
● security response headers；
● exceptional rollback 期间的 controlled invalidation；以及
● 一致的 application domain。
Response-headers policy 包含：
Strict-Transport-Security
Content-Security-Policy
X-Content-Type-Options
Referrer-Policy
Permissions-Policy
frame-ancestors restrictionContent security policy 将 scripts、styles、images、connections 与 framing 限制在明确批准的 sources。Source maps 不会暴露在一般 production distribution；它们会另外保留供受控 debugging 使用。
Route 53 与 AWS Certificate Manager
Amazon Route 53 代管 application 的 DNS record，并将 application hostname alias 到 CloudFront distribution。AWS Certificate Manager 提供并更新 CloudFront 使用的 TLS certificate。DNS validation 让 certificate renewal 自动化且可审计。
AWS WAF
AWS WAF 与 CloudFront 关联。其 web ACL 包含：
● AWS managed common protections；
● known-bad-input protections；
● IP reputation protections；
● rate-based rules；
● unexpected requests 的 size constraints；以及
● 新 blocking rule promoted 之前的 count-mode validation。
React application 是 static，但 WAF 仍然有价值，因为同一个 CloudFront entry point 可以将受控 API paths route 到 Lambda-backed endpoints。WAF metrics 会在收紧 thresholds 前先被监控，避免合法工程师被未测试规则阻挡。
S3 生产控制
Application bucket 使用：
● S3 Block Public Access；
● object versioning；
● default encryption；
● bucket-owner-enforced object ownership；
● access logging 到另一个受保护的 log bucket；
● superseded build artifacts 的 lifecycle rules；以及
● 只允许指定 CloudFront distribution 读取的 bucket policy。
Release manifest 会记录 source commit、Kiro specification revision、build checksum、asset list 与 deployment time。Rollback 会变更 index.html，让它参照前一组 immutable assets。
Amazon MSK：串流骨干
Amazon Managed Streaming for Apache Kafka 是 durable event backbone。它将高频率 manufacturing producers 与 normalization、AI processing、evidence storage、web presentation 解耦。
Production topic structure 以 domain 为基础：
fab.fdc.telemetry.v1
fab.metrology.measurement.v1
fab.spc.result.v1
fab.lot.route.v1
fab.apc.feedback.v1
fab.yield.watch.v1
fab.tool.recommendation.v1
fab.processing.deadletter.v1事件契约
每个 event 都包含共同 envelope：
{
"event_id": "source-generated-or-content-derived-id",
"event_type": "fdc.telemetry",
"schema_version": "1.2.0",
"event_time": "2026-07-12T10:15:32.481Z",
"ingest_time": "2026-07-12T10:15:33.014Z",
"fab_id": "tokenized-fab-reference",
"tool_id": "tokenized-tool-reference",
"lot_id": "tokenized-lot-reference",
"recipe_id": "approved-recipe-reference",
"sequence": 1845531,
"quality": {
"complete": true,
"clock_status": "synchronized"
},
"payload": {}
}event_time 代表实体或制造事件发生的时间。ingest_time 代表平台收到它的时间。这个差异很重要：risk windows 以 event time 为基础，而 platform latency 则从 ingest time 开始量测。
分割区与排序
Partition keys 依 business ordering requirement 选择：
● tool telemetry 依 tool_id partition；
● lot lifecycle events 依 lot_id partition；
● recommendations 依 tool_id partition；以及
● cross-fleet analytics 使用 curated feature events，而不是假设 global Kafka order。
Ordering 只在单一 partition 内保证。任何需要多个 topics 的 algorithm，都使用 event-time windows、watermarks 与 late-event handling，而不是假设 arrival order 正确。
模式治理
AWS Glue Schema Registry 管理兼容的 Avro 或 JSON schemas。Compatibility policy 允许带有 defaults 的 additive changes，并拒绝 incompatible field reinterpretation。Breaking contract 会建立新的 topic version。Lambda 会记录 writer schema、reader schema 与 compatibility result，让 replay 维持可解释。
可靠性与容量
Partition count 依 peak event rate、average record size、target consumer parallelism、retention 与 expected growth 计算。设计会监控：
● producer error rate；
● broker storage usage；
● bytes in and out；
● under-replicated partitions；
● consumer lag；
● oldest unprocessed event age；以及
● dead-letter volume。
Producers 使用 TLS、authenticated access、符合 durability 的 acknowledgements、带 jitter 的 retries、compression、bounded local buffering，以及明确 failure path。Multi-Availability Zone replication 可保护 event stream 不受单一 zone failure 影响。Recovery testing 包含重启 consumers、replaying offsets，并证明 recommendations 不会重复。
AWS Lambda：数据整理、AI 与事件处理
AWS Lambda 在 Amazon MSK 与 governed S3 data lake 之间执行 serverless processing work。设计会将责任拆成小型 functions，而不是建立一个无法测试的 handler。
msk-normalizer
feature-builder
risk-inference
recommendation-publisher
evidence-writer
portal-query-api
feedback-processorMSK 事件处理
Event source mapping 会 poll 已批准的 MSK topics，并以 bounded batches 调用 normalizer。Function settings 依 event size 与 latency objective 调校，而不是停留在任意 defaults。Reserved concurrency 会保护 downstream storage，而 failure policy 会避免 poison record 无限期阻塞 partition。
对每个 Kafka record，normalizer 会执行：
● payload decoding；
● writer-schema identification；
● schema validation；
● event-envelope validation；
● unit standardization；
● timestamp and clock-quality checks；
● tokenized identity enrichment；
● duplicate detection；
● data-quality classification；
● raw evidence persistence；以及
● normalized event publication。
Malformed records 会写入 dead-letter topic，并包含 original topic、partition、offset、schema version、error code 与 encrypted payload reference。它们绝不会被静默丢弃。
幂等性
Kafka consumers 设计为 at-least-once delivery。因此，每个 side effect 都必须 idempotent。Processing key 由 source identity、partition、offset、schema version 与 canonical event ID 推导。S3 object keys 与 recommendation IDs 都包含这个 identity。Retry 会产生相同结果，而不是第二个 case。
Calculation output 会存储精确的 contributing topic/partition/offset ranges。这让 recommendation 可以在 replay 或 audit 之后，从 source evidence 重现。
特徵工程
Feature Lambda 会计算 point-in-time-correct values，例如：
● validated SPC 后经过的时间；
● blind window 期间的 production exposure volume；
● rolling mean 与 standard deviation；
● exponentially weighted movement；
● trend slope 与 step-change indicators；
● residual three-sigma estimate；
● site-to-site range；
● tool-matching gap；
● Mandel slope distance from one；
● robust fleet deviation；
● 距离 approved master anchors 的距离；
● FDC baseline distance；
● missingness 与 lateness indicators；以及
● layer-criticality 与 route-exposure features。
Features 只会使用 decision timestamp 当下可取得的信息计算。这可避免 production inference 与 offline model evaluation 中的 future-data leakage。
Lambda 中的 AI 推论
为了让实施保持在已定义的 service scope 内，approved AI model 会封装成 versioned Lambda layer 或 container-image dependency。Trained artifact 与 metadata 会存储在 governed S3 model prefix。Cold start 时，function 会加载 approved model version；warm invocations 则重复使用它。
AI output 是 structured，而不是 free-form：
{
"risk_probability": 0.91,
"severity": "HIGH",
"confidence": 0.84,
"model_version": "spc-risk-2026-07-12.3",
"reason_codes": [
"FLEET_DEVIATION_HIGH",
"MANDEL_SLOPE_OUTSIDE_RANGE",
"DEFLECTOR_SIGNAL_UNSTABLE"
],
"domain_status": "IN_DOMAIN"
}Deterministic policy evaluator 会将 model output 与 approved engineering rules 结合。AI 可以提出 early warning，但不能弱化 hard rule，也不能发出 autonomous manufacturing action。
安全决策政策
IF required data is missing, stale, or incompatible
RECOMMEND REVIEW_REQUIRED
ELSE IF a hard engineering limit is breached
AND an independent signal corroborates the breach
RECOMMEND HOLD_REVIEW
ELSE IF the model predicts a near-term breach
AND confidence and domain checks pass
RECOMMEND RUN_SPC or GOLDEN_WAFER
ELSE IF fleet or FDC warning criteria are met
RECOMMEND WATCH
ELSE
RECOMMEND RELEASE可观测性
每次 Lambda invocation 都会送出 structured logs 与 operational metrics：
RecordsProcessed
ValidationFailureCount
DuplicateCount
LateEventCount
FeatureFreshnessSeconds
InferenceDurationMs
OutOfDomainCount
RecommendationCountByType
DeadLetterCount
EndToEndDecisionLatencyMsLogs 包含 correlation ID、model version、rule-set version、source offsets 与 error classification，但排除不必要的敏感制造值。Alarms 聚焦 user impact：MSK lag 增长、stale recommendations、validation spikes、inference failures 与 dead-letter growth。
S3 数据湖、AWS Glue 与 Lake Formation：受治理的佐证数据
Production AI application 需要的不只是一个 model。它需要可重现 evidence、受控 training data、可探索 definitions、lineage 与 access governance。
Amazon S3 data lake 组织成 zones：
s3://fab-spc-data/raw/
s3://fab-spc-data/validated/
s3://fab-spc-data/curated/
s3://fab-spc-data/features/
s3://fab-spc-data/models/
s3://fab-spc-data/predictions/
s3://fab-spc-data/evidence/
s3://fab-spc-data/feedback/
s3://fab-spc-data/quarantine/原始数据区
Raw zone 以最少转换保留 source events。Objects 是 immutable、encrypted、versioned，并依 source domain 与 event date partition。Original Kafka metadata 会保留供 replay 与 audit 使用。
已验证与已策展数据区
Validated zone 包含符合 schema 且带有 quality flags 的 events。Curated zone 包含标准化的 engineering entities，例如 tool state、metrology observations、matching results、route exposure 与 approved outcomes。Columnar files 与实用 partitioning 可降低 scan cost 并改善 analytic performance。
特徵与模型数据区
Feature zone 存储 point-in-time-correct training 与 inference features。每个 dataset 都记录：
● feature definition version；
● source event range；
● generation code version；
● cutoff timestamp；
● quality results；以及
● approved use。
Model zone 存储 model artifact、preprocessing definition、feature order、evaluation report、threshold configuration、model card、approval state、checksum 与 rollback predecessor。Lambda 只允许加载明确批准的 model prefix。
AWS Glue
AWS Glue 提供 technical catalog 与 schema layer。Glue crawlers 会选择性使用；具严格 contracts 的 production tables 会由明确 definitions 管理，避免 unexpected file 静默重新定义 critical column。
Data Catalog 记录：
● database and table definitions；
● file formats and partitions；
● schema versions；
● owners and descriptions；
● data classification；
● quality status；以及
● source-to-curated lineage references。
当 processing 超过合适的 Lambda execution profile 时，AWS Glue jobs 支持较大型的 offline transformations。Glue-generated training datasets 使用与 Lambda inference path 相同的 feature definitions 与 event-time rules，降低 training-serving skew。
AWS Lake Formation
AWS Lake Formation 管理 cataloged S3 data 的访问权限。Permissions 依 role 与 data purpose 授予，而不是 broad bucket access。LF-tags 会分类 fab、tool family、product sensitivity、evidence type 与 approved use 等 domains。
Access boundaries 示例包含：
● front-end delivery roles 不能访问 data lake；
● Lambda normalization 可以写入 raw 与 validated data，但不能 approve models；
● inference Lambda 只能读取 approved feature definitions 与 model artifacts；
● engineering analysts 可以 query authorized curated data；
● model-development roles 可以读取 approved training data，但不能读取 unrestricted raw identifiers；以及
● auditors 可以读取 evidence 与 lineage，但不能修改 operational datasets。
Column- and row-level controls 可避免不必要的暴露。Cross-account sharing 使用 governed catalog permissions，而不是复制 uncontrolled datasets。
保留期限与佐证完整性
Lifecycle rules 会依 business 与 regulatory requirements，将 historical evidence 移至较低成本的 S3 storage classes。Quarantine retention 刻意限制。Model、recommendation 与 approval evidence 则会保留到必要审计期间。
Checksums、object versioning、protected access logs 与 separation of duties 让 evidence chain 具备 tamper-evident 特性。Recommendation 可以从 UI 追溯到 Lambda output、model version、feature record、curated dataset 与 original MSK offsets。
完整 AI 开发生命周期
AI development 涵盖的范围远超过训练 algorithm。对这个 application 而言，完整 lifecycle 是围绕 AWS service scope 实施。
1. 问题定义
Model 预测 tool 是否可能在下一次 scheduled SPC opportunity 之前产生不可接受的量测行为。目标不是「预测每一个 anomaly」。目标是在控制不必要 investigations 的同时，提供足够 lead time 让人类进行有用的 review。
2. 标签定义
Labels 来自 approved engineering outcomes：
● confirmed SPC out-of-control events；
● golden-wafer results；
● confirmed equipment findings；
● matching or linearity failures；
● approved route or hold decisions；
● false-alarm dispositions；以及
● yield backtrace conclusions。
工程师的初始建议不会自动被视为 truth。Final approved disposition 与 investigation outcome 会分开存储，以避免 self-reinforcing labels。
3. 数据准备
Amazon MSK 捕捉 operational events，Lambda 验证并对齐它们，S3 存储 immutable history，AWS Glue 建立可重现 datasets，而 Lake Formation 控制谁可以使用每个 dataset。Training examples 使用 event-time cutoffs，确保它们不包含 prediction point 之后才可取得的信息。
4. 数据集切分
Random row splitting 会让重复 tool behavior 泄漏到 train 与 test data。Production process 因此套用 chronological splits，并在适当时依 tool 或 tool family 分组。最后保留一段 untouched time period，用来量测 realistic forward performance。
5. 特徵开发
Features 会记录 purpose、unit、source、expected range、missing-value behavior、owner 与 leakage risk。Offline datasets 与 Lambda inference 使用相同的 versioned transformations。
6. 模型选择
第一个 production candidate 偏好 compact、interpretable model，且能在 Lambda 中高效率执行。Candidate models 会与 deterministic baselines 比较。只有在改善 operational metrics，且没有不可接受的 latency、instability 或 explainability loss 时，才会接受更复杂的 model。
7. 评估
因为真正的 drift events 并不常见，accuracy 不是主要 metric。Evaluation 包含：
● precision and recall；
● precision-recall area；
● false-negative cost；
● recall at available engineer review capacity；
● probability calibration；
● average warning lead time；
● 依 tool family、layer、recipe 与 event-quality state 的 performance；
● out-of-domain detection；以及
● 与 existing deterministic process 的 comparison。
Threshold selection 是由 engineering owners 共同参与的制造决策。它会平衡 missed-drift risk 与 review workload。
8. 可解释性
Model 会返回稳定的 reason codes 与 contributing feature values。UI 会将它们与 approved limits 和 source time 并列呈现。Explanation 被限制在 observed evidence；它不会发明 root cause。
9. 偏差与覆盖率评估
Evaluation 会检查 model 在 tool families、layers、recipes、maintenance states 与 data-quality conditions 之间是否表现一致。在这种 industrial context 中，unfairness 可能呈现为对较少见 tool 或 process family 的检测系统性较差。不受支持的 groups 会标记为 out of domain，并导向 human review。
10. 模型批准与版本管控
每个 approved model package 包含：
model artifact
preprocessor artifact
feature specification
training-data snapshot reference
evaluation report
slice metrics
threshold configuration
model card
known limitations
approval record
rollback model
artifact checksums只有 approved S3 model prefix 可以被 inference Lambda 加载。Model promotion 会通过 Lake Formation permissions 与 deployment controls，与 model development 分离。
11. 部署
Candidate 会从 shadow mode 开始。它接收 production features，但不能影响显示的 recommendation。Predictions 会与 current rule set 及后续 outcomes 比较。Approval 后，少量受控 requests 会使用 candidate，同时 previous model 仍可立即 rollback。
12. 监控
Production monitoring 涵盖四类：
● service health: Lambda errors、duration、throttles、cold starts、MSK lag；
● data health: missing fields、schema changes、late events、range violations；
● model health: feature drift、score distribution、out-of-domain rate、calibration；
● business health: warning lead time、accepted recommendations、false alarms、prevented exposure 与 engineer review time。
当 labels 之后抵达时，feedback processor 会将 predictions 与 approved outcomes join 起来，并计算 delayed quality metrics。
13. 重新训练
Retraining 由 approved schedule、足够的新 labels、feature drift、performance degradation，或有意义的 equipment/process change 触发。Retraining 绝不会自动 promote model。完整 evaluation 与 approval gate 会再次执行。
14. 负责任 AI 与安全性
Application 套用下列 controls：
● AI 仅供建议。
● 每项 recommendation 都会显示 uncertainty 与 source freshness。
● Missing 或 stale evidence 会导向 review，而不是 release。
● Hard engineering limits 不能被 model 覆写。
● Sensitive identifiers 会被最小化并 tokenized。
● Training 与 inference access 通过 Lake Formation 与 IAM 治理。
● Model artifacts、datasets、rules 与 outputs 会 versioned。
● 工程师可以 accept、reject 或 correct recommendations。
● AI failure 会 fallback 到 deterministic rules 与 evidence。
● Autonomous equipment commands 不在 application 的 IAM permissions 与 network path 内。
生产测试与发布策略
Kiro-generated tasks 包含 UI、streams、Lambda processing、data governance 与 AI behavior 的 tests。
React 测试
● component rendering；
● search and sort behavior；
● keyboard navigation；
● accessible names and contrast；
● stale-data and AI-unavailable states；
● threshold-boundary display；以及
● mobile layout behavior。
MSK 与 Lambda 测试
● compatible and incompatible schemas；
● duplicate delivery；
● reordered events；
● late arrivals；
● partial batch failure；
● poison messages；
● replay from earlier offsets；
● large batches；
● downstream timeout；以及
● 证明 retry 不会 duplicate recommendation。
数据湖与治理测试
● S3 public-access denial；
● encryption and versioning；
● partition and schema validation；
● Glue catalog consistency；
● Lake Formation positive and negative authorization tests；
● lineage completeness；以及
● retention-policy validation。
AI 测试
● future-data leakage checks；
● feature parity between training and inference；
● model serialization and cold-start loading；
● boundary and missing-value behavior；
● probability calibration；
● slice evaluation；
● out-of-domain handling；
● reason-code stability；
● safe fallback；以及
● model rollback。
Release pipeline 会将 immutable artifacts 依序 promote 到 development、staging 与 production。Production release 会记录 Git commit、Kiro spec revision、React manifest、infrastructure revision、schema versions、Lambda versions、rule-set version 与 approved model version。
我学到的事
第一个教训是，industrial productivity application 应该减少工程师必须重建的决策数量，而不是单纯增加另一个 dashboard。有用的输出，是一个包含 fresh evidence、explicit limits、uncertainty 与最小安全下一步行动的 prioritized case。
第二个教训是，streaming correctness 就是 operational correctness。如果使用 arrival time 而不是 event time、假设 global ordering、retry 后重复 side effect，或评估 stale evidence，即使公式正确，也可能产生错误决策。Amazon MSK 与 idempotent Lambda processing 让 replay、traceability 与 failure recovery 成为设计的一部分。
第三个教训是，AI development 从 data contracts 开始，并以受监控的人类 outcomes 结束。Model 本身只是其中一个 artifact。S3 evidence zones、Glue metadata、Lake Formation controls、point-in-time feature construction、approval records、reason codes、feedback、drift monitoring 与 rollback 一样重要。
第四个教训来自 Kiro。当 requirements、architecture、security rules 与 tests 约束 generation 时，AI-assisted coding 最有效。Kiro specs 维持了从 productivity problem 到 implementation tasks 的 traceability。Steering 保留 AWS 与 safety conventions。Hooks 则把重复性的质量检查直接放进 engineering workflow。
最后，我学到 production-ready AI system 必须为 uncertainty 而设计。Portal 绝不把 missing data 视为 healthy data，不把 probability 视为 equipment command，也不隐藏 observed evidence、deterministic rules 与 AI prediction 之间的差异。
结果是一个 AWS-focused productivity tool，协助工程师理解 什么需要注意、为什么重要、哪些 evidence 支撑决策，以及下一步该 review 什么。
应用程序 SOP — 日常 Fab 值班操作与商业价值
只有当 portal 的 risk indicators 引导出一致的工程 routine 时，它才真正创造价值。这份 standard operating procedure 说明 metrology engineers、equipment engineers、process engineers、process-integration engineers 与 yield engineers 如何在一般班别中使用 application。它也让 challenge reviewer 看见 productivity benefit：application 不只是显示 charts；它把分散的 evidence 转成有优先顺序、可重复的工作流程。
Safety boundary: Portal 是 advisory decision-support application。Public demonstration 显示的 limits 是 learning baselines。Production limits 必须依适用的 node、product、layer、customer 与 module 批准。Final release、route-limit、APC、maintenance 与 hold decisions 仍由授权 fab personnel 负责。
预期受众与各角色价值
Metrology engineer or CD-SEM owner
Metrology owner 使用 portal 在 scheduled SPC checks 之间检测 drift、评估 tool matching、比较 suspect tool 与 fleet，并判断是否需要 physical confirmation。Productivity value 是 TMG、Mandel slope、residual noise、blind-window age、fleet deviation 与 recent movement 的单一 evidence view，而不是跨多个无关系统的手动调查。
Equipment engineer
Equipment engineer 从 hardware-health 角度工作：CD-SEM 是否健康到足以继续量测 production lots、是哪个 FDC signal 导致 measurement credibility 下降，以及需要什么 containment？FDC Health-Link panel 会将调查导向 gun vacuum、emission current、deflector DAC 或 stage vibration，并将该路径连接到可观察的 metrology effect。
Process or process-integration engineer
PE 与 PIE 在变更 lithography 或 etch settings 之前使用 portal。如果 measurement 本身可疑，process correction 可能把工艺推向错误方向。Portal 提供 route history、metrology credibility indicators、APC-guard status 与 engineering recommendation，用来判断 process action 是否应等待 verification。
Yield engineer
Yield engineer 使用 portal 将 yield-watch lot 回溯到 measuring CD-SEM、FDC state、last trusted SPC point、fleet comparison 与 APC exposure window。这能加速区分真实 process excursion、metrology false alarm，以及由 suspect feedback 造成的 process movement。
为什么 SOP 重要
Scheduled SPC result 可能仍是 green，但实体 tool 已在接下来几小时内发生变化。这段间隔就是 SPC blind window。Portal 通过连结 last trusted qualification point 与 current production exposure、FDC movement、fleet behavior、matching quality 与 yield context，补上 operational gap。
预期的 productivity chain 是：
Scattered tool, lot, SPC, FDC, matching, and yield evidence
↓
One ranked Live Risk Board
↓
One expandable evidence view with reason codes
↓
One controlled recommendation and named owner
↓
Faster verification, containment, passdown, and closure预期的 manufacturing defense 是：
Detect hidden CD-SEM drift
↓
Protect measurement credibility
↓
Prevent suspect data from entering APC decisions
↓
Reduce unnecessary process changes and lot exposure
↓
Improve investigation speed and shift-to-shift continuity操作者必须理解的门户概念
● Blind window: last trusted SPC 或 golden-wafer result 与 current production measurement 之间经过的时间。
● TMG: tool-matching gap。示范 baseline 是不超过 target CD 的 10%；approved production percentage 可能更严格。
● Mandel slope: multi-CD linearity indicator。示范 learning range 是 0.98–1.02。
● Residual 3σ: fitted trend 移除后的 random uncertainty。上升的 residual 可能比单纯 mean offset 更危险，因为量测变得较不可重复。
● Fleet σ: 与 governed fleet baseline 的距离。超过 2σ 是 early warning；在示范逻辑中，超过 3σ 是 hold-review candidate。
● Site-to-site delta: 用来识别 stage、vibration、scan-linearity 或 center-edge artifacts 的 spatial measurement range。
● FDC health link: hardware signal 与 observed metrology effect 之间的关系。
● Action label: 需要 human review 的 advisory next step。
Production 中所有显示 metrics 都必须包含目前 timestamp 与 quality state。Stale green value 不是健康证据。
轮班开始 SOP — 前十分钟
● 通过 approved application URL 登录，并确认显示的 data-freshness timestamp 是最新的。
● 查看 KPI strip：tools watched、average SPC blind window、fleet out-of-control count、FDC health links、dynamic-limit state 与 yield-watch workload。
● 开启 LIVE RISK BOARD。
● 依 RISK 排序，并展开每一台 high-risk tool，示范 review threshold 使用 75。
● 阅读完整 evidence，而不只看颜色：layer、symptom、TMG、slope、fleet σ、residual、blind window、trajectory、reason codes、model version 与 recommendation。
● 依 BLIND WINDOW 排序，找出 last physical confidence point 已过久的 tools。
● 依 FLEET σ 排序，找出即使最新 SPC result 仍为 green、却已和 peers 分离的 tool。
● 依 RESIDUAL 排序，找出正在形成的 repeatability、vacuum、vibration、charging 或 beam-stability risk。
● 为每一台 high-risk tool 开启 FDC HEALTH-LINK，并识别最可能的 hardware investigation path。
● 在 shift passdown 中记录 high-risk tool、affected layer、owner、current containment、exposed-lot window 与 required exit criterion。
Yellow trends 是可行动信息。SOP 不要求工程师等到 red alarm 或传统 three-sigma failure 才 review developing risk。
放行关键层批次之前
在 Gate、Fin、tight Contact/Via、risk-ramp 或 yield-watch lots 被量测或 release 之前，负责工程师要确认：
● tool 不在 HOLD REVIEW；
● last trusted SPC 或 golden-wafer result 对该 layer 仍够新；
● TMG 维持在 approved layer-specific budget 内；
● Mandel slope 维持在 approved linearity range 内；
● residual 3σ 维持在 approved repeatability limit 内；
● site-to-site delta 维持在 approved spatial limit 内；
● fleet deviation 不是 hold candidate；
● FDC fingerprint 稳定或有 accepted explanation；
● prediction 在 domain 内，且其必要 inputs 完整；以及
● 没有 unresolved APC guard 套用到 measurement window。
如果任何条件不确定，recommendation 必须变得更保守。可用 containment 包含 running SPC、running a golden wafer、routing to a master tool、将 suspect tool 限制在 approved non-critical layers、guarding APC feedback，或 calling a hold review。
如何解读每个门户 action
RELEASE
目前 evidence 未显示对 measurement credibility 有实质 tool-health threat。继续 approved production use 与 trend monitoring。Release 不会取消正常 qualification requirements，也不代表可以忽略新的 FDC movement。
WATCH
Tool 有 early drift signature，但尚未建立 confirmed failure。Review 前 8–24 小时的 FDC behavior、比较最新 golden-wafer result、检查 maintenance 与 event logs、提高 monitoring frequency，并在 trend 持续时准备 physical verification。
RUN SPC
Tool 可能没有严重异常，但它的 physical confidence point 对目前 exposure 来说太旧。在更多 critical lots 前执行 approved SPC 或 golden-wafer check。如果必须 constrained operation，只有 authorized owner 可以批准明确受限的使用。
GOLDEN WAFER
Virtual evidence 足够可疑，需要 physical standard-wafer confirmation。暂停 critical-layer measurement、使用 approved recipe，并将 mean、three-sigma、TMG、slope、residual、site-to-site delta 与 measurement profile 与 governed baseline 比较。Failed result 会升级为 hold review。
ROUTE LIMIT
Tool 可能仍可用于特别批准、敏感度较低的 layers，但不适合 critical work。通知 dispatcher 与 module owner、限制 affected layers、定义 owner，并在回到 full release 前记录 measurable exit criteria。
APC GUARD
Measurement bias 或 noise 可能污染 feedback。识别 suspect window 期间量测的 lots、通知 APC owner，并决定 affected measurements 是否必须 paused、excluded、reviewed，或在 trusted tool 上 repeated。Portal 不能自行修改 APC。
HOLD REVIEW
Tool 是等待 cross-functional review 前从 critical measurement 移除的强候选。Freeze affected exposure window、检查 FDC、执行 physical confirmation、检查 image 或 waveform quality、与 master 和 fleet 比较、判断 affected lots，并通过 authorized procedures 选择 release、route limit、maintenance、calibration 或 requalification。
FDC 优先诊断 SOP
当 portal 变更为 WATCH、GOLDEN WAFER、ROUTE LIMIT、APC GUARD 或 HOLD REVIEW 时，使用 FDC Health-Link panel 选择第一个 diagnostic branch。
Gun-vacuum branch
Typical portal evidence 包含 rising residual 3σ、worsening matching precision、random false alarms、apparent blur 或 reduced peak-to-base ratio。Review chamber-vacuum trends、pump events、pressure spikes、recent venting or recovery、contamination indicators 与 profile stability。Physical confirmation 与 stabilization 优先于 re-baselining。
Emission-current branch
Typical evidence 包含 mean-offset step、center line 同侧的 consecutive values、emission ramp，或 biased CD 进入 APC 的疑虑。Review emission current、extraction voltage、probe-current stability、gun age、approved recovery history 与 intervention 后的变化。Guard affected feedback window，直到 credibility 恢复。
Deflector-DAC branch
Typical evidence 包含 Mandel slope 超出 approved range、dense/isolated bias、multi-CD mismatch 或 site-to-site movement。Review deflector stability、scan-linearity calibration、image-shift correction、measurement-box placement、edge-algorithm configuration 与 multi-CD standard-wafer behavior。Critical layers 会维持 restricted，直到 linearity exit criterion 通过。
Stage-vibration branch
Typical evidence 包含 widening residual、increasing site-to-site range、random site instability，或 false center-edge signature。Review stage-vibration sensor、facility events、settling time、positioning logs、interferometer behavior，以及同一 site 的 repeated measurement。Full release 前，repeatability 与 spatial stability 必须恢复。
指标驱动响应 SOP
High blind window
Review last trusted qualification point 之后所有 tool 与 facility events。特别注意 venting、beam restart、aperture work、preventive maintenance、vibration、temperature 与 facility alarms。当超过 approved freshness boundary 时，在 critical work 前执行 physical verification。
TMG 高于 approved limit
将 suspect tool 与 approved master 比较、判断变化是 simple offset 还是包含 wider residual error、确认 recipe 与 correction-table versions，并执行 multi-site 或 multi-CD standard wafer。Matching 回到 approved rule 内之前，限制 cross-tool dispatch。
Mandel slope 超出 approved range
执行 multi-CD linearity check、检查 deflector 与 scan calibration evidence、比较 dense 与 isolated features，并 review edge-detection configuration。只在单一 CD 一致、却跨 CD sizes 失败的 tool，不得被视为 critical layers 的 matched tool。
Residual 3σ 高于 approved limit
在 standard wafer 上执行 repeatability check、检查 measurement profiles、review vacuum 与 emission stability、检查 facility 与 stage vibration，并确认 focus 与 stigmator behavior。如果 noisy measurements 可能已进入 feedback，需 guard APC。
Fleet deviation 高于 approved threshold
依 tool 比较 product-lot means、判断量测相同 product 与 layer 的 peers 是否仍稳定、以 master 验证 suspect tool，并 backtrace deviation window 期间量测的 lots。Fleet comparison 专门用来在 traditional SPC failure 之前揭露 hidden inline drift。
Site-to-site delta 高于 approved limit
Review site-level data，而不只看 wafer mean。检查 stage positioning、vibration、image-shift correction、interferometer evidence 与 multi-site standard-wafer result。在排除 metrology artifact 前，不要做 center-edge process disposition。
HOLD REVIEW 围堵与复原程序
● 确认 signal。 确认 freshness、quality、risk、TMG、slope、fleet σ、residual、blind window 与 reason codes。
● Freeze additional exposure。 停止未批准的 critical-layer measurement，并识别 last trusted state 后量测的 lots。
● 选择 FDC path。 Review vacuum、emission/extraction、deflector、vibration，以及适用的 facility 或 thermal evidence。
● 执行 physical confirmation。 使用 approved golden wafer、standard wafer、处理 slope concerns 的 multi-CD wafer，或处理 spatial concerns 的 multi-site wafer。
● Review image and waveform evidence。 在可取得时，检查 peak-to-base ratio、edge slope、baseline movement、X/Y asymmetry、blur 与 tailing。
● 与 trusted peers 比较。 使用 master tool、governed fleet baseline 与 comparable product distribution。
● 决定 disposition。 通过 authorized review 选择 release、watch、route limit、APC guard、calibration、preventive maintenance 或 continued hold。
● Document and hand over。 记录 hypothesis、evidence、affected-lot window、owner、due time、action 与 exit criteria。
回到完整放行的退出标准
Tool 不会只因 alarm cleared 就从 route limit 或 hold review 回到 release。Owner 需要确认：
● approved standard 或 golden wafer 通过；
● TMG 在 approved rule 内；
● Mandel slope 在 approved range 内；
● residual 3σ 与 site-to-site delta 在 limits 内；
● fleet deviation 已回到 approved threshold 以下；
● abnormal FDC signal 已回到 baseline 或 accepted stable state；
● image 或 waveform quality 在适用时已恢复；
● suspect APC feedback 已 dispositioned；
● exposed lots 已由 responsible functions review；以及
● shift records 包含 recovery evidence 与 exit criteria。
良率损失审查佐证包
当 yield engineer、process engineer 或 process-integration engineer 开启 case 时，portal 应该产生 governed evidence pack，而不是非正式的 screenshots 集合：
case and request identifier
product, layer, recipe, lot and wafer references
tool route and ADI/AEI tool pairing
last trusted SPC or golden-wafer timestamp
blind-window duration and exposed-lot window
TMG and matching history
Mandel slope and multi-CD evidence
residual 3σ and site-to-site delta
fleet deviation and peer distribution
FDC changes relative to baseline
maintenance and equipment-event history
APC feedback status
model and rule-set versions
reason codes and confidence
current containment, owner and due time
review disposition and exit criteriaEvidence pack 支持五个简洁的 engineering conclusions 之一：
● tool 可信，process cause 较可能；
● tool 异常，metrology false alarm 可能存在；
● tool 异常，APC feedback contamination 可能存在；
● evidence 混合，需要 master-tool remeasurement；或
● evidence 混合，需要 standard-wafer verification。
轮班结束交接 SOP
Passdown 必须描述 measurement credibility，而不只是「tool OK」或「tool NG」。Shift record 包含：
Date and shift:
Engineer:
Tool-health summary:
High-risk CD-SEM tools:
Affected layers and lots:
FDC abnormal signals:
TMG / Mandel slope / residual 3σ / site delta / fleet σ:
Last trusted qualification time:
Current containment:
Golden-wafer or standard-wafer result:
APC guard status:
Maintenance or calibration action:
Owner and next action:
Due time:
Exit criteria for release:这种 structured handoff 是 application 最重要的 productivity benefits 之一。它避免下一班重复同样搜索，并保留 alert、evidence、action 与 outcome 之间可审计的连结。
操作示例 — CDSEM-05
假设 portal 显示：
Tool: CDSEM-05
Layer: Contact/Via
Action: GOLDEN WAFER
Symptom: Vacuum degradation with rising residual
Blind window: 6.9 hours
TMG: 0.19 nm
Mandel slope: 1.006
Fleet deviation: 2.4 sigma
Residual 3σ: 0.21 nmSlope 仍在示范范围内，因此 multi-CD linearity 不是最强 signal。Residual 高于 learning baseline，且 tool 正与 peers 分离，同时 vacuum trend 提供合理 hardware path。因为 Contact/Via 可能是 critical，operator 不会盲目 release。
工程师限制 critical use、执行 approved golden wafer、review 前 24 小时 vacuum behavior、检查 measurement-profile stability、执行 repeatability test，并与 master 比较结果。如果 residual 仍然偏高，owner 会开启 approved vacuum-recovery、contamination 或 maintenance procedure。PE/PIE 会收到 residual limit 被跨越后量测 lots 的通知，APC owner 则 review 其 feedback 是否必须 excluded。
这个例子清楚显示 application 的价值：一个 ranked case 会直接导向正确 evidence、responsible roles、containment 与 measurable exit criteria。
应用程序必须防止的 actions
● 不要只因为最后 SPC result 是 green，就在后续 FDC 已变化时 release critical lot。
● 当 residual uncertainty 正在扩大时，不要把 mean-offset correction 视为足够。
● 在调查 physical cause 之前，不要 re-baseline。
● 不要只因 conventional SPC 尚未 fail，就忽略 emerging fleet outlier。
● 不要在缺少 owner review 的情况下，让 suspect CD data 影响 APC。
● 不要把单一 standard-wafer site 视为永久稳定；重复 exposure 可能让 reference aging。
● 没有 documented exit criteria 时，不要 close hold review。
● 不要允许 AI score 单独做出 hold 或 release decision。
SOP 成功指标
Production team 量测 portal 是否改善工作，而不只是产生 alerts：
● formal SPC failure 之前检测到的 drift cases；
● 已 prevent 或 review 的 suspect APC feedback events；
● 通过 route limit 或 APC guard 保护的 lots；
● repeated CD-SEM false alarms 的减少；
● assemble yield-review evidence pack 所需时间的减少；
● high-risk cases 中具完整 evidence 与 named owners 的比例；
● alert-to-standard-wafer confirmation time；
● hold-review-to-disposition time；
● shift-passdown completeness；
● recommendation acceptance、rejection 与 correction rates；以及
● tool recovery 后的 recurrence。
这些 outcomes 会写入 governed S3 feedback zone。AWS Lambda 会将它们与 original recommendation 对齐，AWS Glue 则建立用于 operational reporting 与 future model evaluation 的 quality dataset。Lake Formation 确保只有 approved roles 可以将该 feedback 用于 model development。
一页式日常操作摘要
● Start shift 并确认 data freshness。
● 开启 LIVE RISK BOARD 并依 risk 排序。
● 展开 high-risk tools，检查 TMG、slope、fleet σ、residual、blind window、trajectory 与 reason codes。
● 依 blind window、fleet deviation 与 residual 排序，找出 hidden exposure。
● 开启 FDC HEALTH-LINK，并选择 hardware investigation path。
● 在 critical-lot release 前，确认没有 hold、matching、linearity、repeatability、spatial、FDC 或 APC concern 仍未解决。
● 如果 evidence 可疑，执行 physical confirmation 或 route 到 approved master。
● 如果 feedback 有风险，通知 APC owner 并 guard affected window。
● 如果 yield-watch lots 已 exposure，产生 governed evidence pack。
● End shift 时记录 credibility、affected lots、containment、owner、due time 与 exit criteria。
这份 SOP 将 portal 从 visual demonstration 转成 production-oriented productivity system：它缩短 investigation time、标准化 daily decisions、改善 cross-functional communication、保留 evidence chain，并让每个 manufacturing action 都维持在人类 authority 之下。