AntFleet

Disagreement · 7739d5f2-openai-1

Ambiguous units in modeThresholds for rate vs total

mismatch
repo 53606958·PR #2·reviewed 1 week ago

Primary finding

Ambiguous units in modeThresholds for rate vs total

mediumapi-contracthigh
  • memory/goals.json:32-35
buildModeOnDailyRate implies a rate (DIEM/day), while a single unit field of "DIEM" can be misinterpreted. Mixing a rate and a total under one shared unit creates ambiguity for downstream logic and increases the likelihood of incorrect threshold evaluation.

Recommendation

Disambiguate by providing explicit units per threshold (e.g., rateUnit: "DIEM/day", totalUnit: "DIEM") or encode each threshold as an object with value and unit fields. Document the expected semantics clearly and validate with a schema.

Counterpart finding

Mode field inconsistent with documented threshold semantics

lowapi-contractmedium
  • memory/goals.json:5-6
  • memory/goals.json:24-29
The milestone description says build mode triggers at 100 DIEM total, but modeThresholds also exposes buildModeOnDailyRate: 5 with no documented unit/window (per-day? in DIEM?) and no precedence rule between the two thresholds. A consumer that evaluates daily rate could flip to build mode well before the 100 DIEM milestone is met, contradicting the milestone description. The contract between mode, milestones[*].status, and the two thresholds is ambiguous.

Recommendation

Document in the file (or in an adjacent schema/spec) the precedence: e.g., 'mode becomes build when EITHER threshold is satisfied' vs. 'AND', and specify the time window/unit for buildModeOnDailyRate. Alternatively collapse to a single canonical trigger to avoid drift between mode and milestone.status.

Why this didn't post

This finding didn't meet AntFleet's unanimous agreement threshold. Both frontier models review every PR independently; only findings they both flag with the same severity and category are posted to the PR. This one fell through.

read the methodology →