shu/vpp-ai-platform
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
master
vpp-ai-platform/docs/open-questions.md
Thomas Bayes 23fdf49ff2
Some checks are pending
ci / typescript (push) Waiting to run
Details
ci / python (push) Waiting to run
Details
ci / evals (push) Blocked by required conditions
Details
M4: resource agent, envelopes live, review loop, insight cards 
- packages/domain: AwardNotice, DISPATCH_PLAN proposal payload, ExecutionReport,
  MeteringRecord, potential-assessment and dispatch-optimization contracts,
  ReviewFinding (+ typed writebacks), SemanticMemoryEntry,
  EnvelopeChangeRequest, InsightCard — exported with fixtures on both sides.
- skills-py: potential-assessment (certified × rolling fulfilment, evidence
  days) and dispatch-optimization (per-interval LP on HiGHS, shortfall
  reported) skills + routes + tests.
- packages/services: dispatch rules in the policy pack (over-allocation,
  award anchor, lineage integrity for allocations); PowerBalanceSimulator;
  SimulationGateway (permit-only, idempotent, seeded execute → ExecutionReports);
  envelope deviation-streak suspension + apply(); ReviewService (attribution,
  reliability EWMA writeback, semantic memory, envelope recommendations as
  change requests); dispatch assembler; skill client methods.
- packages/runtime: resource agent; award-decomposition, review and
  envelope-review workflows; lifecycle selects simulator/gateway by proposal
  type; trigger hooks for awards, execution reports, metering; decide()
  resumes either lifecycle or envelope-review runs; insight cards API.
- Tests: docs/07 D-1 16:00 and D+1 end to end; reliability score 0.9 → 0.880
  and the next assessment de-rates capacity; envelope suspension on a seeded
  3-day streak; WIDEN request applied only by a human. 184 TS + 80 Python.
- docs/open-questions: B10 (reliability/potential parameters). README and
  CLAUDE.md status → M4 done, M5 next.

Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01UoYoGYzHkFyv3ALenkRPhA
2026-09-02 19:31:12 -04:00

3.6 KiB
Raw Permalink Blame History

Open Questions — 业务参数与待决事项清单

Consolidates every TODO(业务) scattered in docs 03/07/12/13 plus unresolved items from the peer review (brainstorming.md §16). Coding agents: never invent values for items on this list — wire named config with placeholder + an // OPEN-QUESTION: comment (see CLAUDE.md).

A. 湖北市场参数（owner: 运营/交易团队 · blocks M3 policy pack + 07 篇定稿）

# Question Config key (suggested)
A1 日前申报窗口开启/截止时间；出清发布时间 market.da.window
A2 代理购电申报与虚拟电厂申报是否同一通道/分开建模 market.channels
A3 日内市场机制（是否开、频次、截止） market.intraday
A4 偏差考核规则：偏差带、考核价格机制（→ MILP 目标函数与风险口径） market.deviation
A5 中长期持仓对日前申报的约束形式（分解曲线偏差带） ledger.da_bounds
A6 灵活性资源边际成本口径（用户补偿、设备损耗）——报价优化的报价下限；未定前按 0（价格接受者）申报 bidding.marginal_cost

B. 包络与风控参数（owner: 运营团队 · blocks M4 envelopes + M5 breakers）

# Question Config key
B1 申报包络：价格边界的基准（预测值?历史分位?）与初始容差 envelope.bid.*
B2 控制包络：分资源类型的单点削减上限与恢复速率 envelope.control.*
B3 包络审批层级 L1/L2/L3 对应岗位/会签流程 approval.levels
B4 包络挂起条件：连续 N 次偏差超阈的 N 与阈值 envelope.suspension
B5 单日亏损预算（L2 熔断阈值） breaker.daily_loss_budget
B6 承诺缓冲系数 k 初值 bidding.commitment_buffer
B7 极端日协议触发的气象条件 abnormal_day.triggers
B8 各级熔断（L0–L4）授权岗位与恢复条件 breaker.authority
B9 演习样本制度：频率与考核挂钩方式 — (制度非配置)
B10 可靠性评分与可调潜力辨识口径：评分更新权重（EWMA α）、证据窗口与饱和天数、包络放宽所需连续达标天数与放宽步长 review.reliability_alpha / potential.evidence_window / envelope.widen_*

C. KPI 口径（owner: 运营 + 验收双方 · blocks M5 dashboard）

# Question
C1 docs/12 §4 全表口径确认，尤其「综合市场收益提升 15%」的对照基线定义与冻结
C2 预测误差 8% 的统计层级（聚合级?分用户?）与光伏口径（nRMSE?）

D. 外部依赖（owner: PMO/省间协同组 · blocks phase 2, start engagement in phase 1）

# Question
D1 光明电力大模型接口规格：协议、上下文、工具调用、部署位置、网络分区（ADR-0003 假设待证实）
D2 交易平台程序化申报接口协议与联调排期
D3 调度/负荷管理、计量结算接口协议与排期
D4 省级↔聚合单元↔边缘现有协议与时延保证（peer review Q6）
D5 首批转为政策包的湖北规则清单（peer review Q7）

E. 治理决策（owner: 项目领导小组）

# Question
E1 一期验收形态确认：影子运行（推荐，见 ROADMAP M5）vs 受控实报（peer review Q3）
E2 既有 3060 平台各实体的 source-of-truth 矩阵签认（docs/11 §2 表为草案）
E3 边缘断连策略的「安全曲线」定义权与更新流程

Process: when an item is answered, move the value into config/docs, mark the row ✓ resolved <date> → <where recorded>, and keep the row for audit.