{"pair_id":"pair_0333","gold_label":"contradiction","decision_type_a":"architecture","decision_type_b":"architecture","decision_a":"Do NOT run xvendor002 CreateFieldIndex on every startup — use explicit versioned migrations instead for all index changes","decision_b":"Always run xvendor002 CreateFieldIndex on startup (not just at collection creation) to backfill indexes idempotently"}
{"pair_id":"pair_1173","gold_label":"related_not_contradicting","decision_type_a":"code_review","decision_type_b":"code_review","decision_a":"Reviewed PR #PR009 (fix: harden audit trail, eliminate data-loss vectors, sanitize error surfaces) for pkg/xfile001.ext compliance. Found 1 clear violation: pkg/xfile007.ext is modified (adding xterm064=func.now() to AuditEventDB.occurred_at) along with a new xvendor005 migration, without prior approval as required by pkg/xfile001.ext 'Ask First' rules for database model changes. All other rules pass: branch is not main, PR has a valid Xname010 section (Option A non-obvious trivia about Xname011 and perfect numbers), no credentials, no issue closures. API error message xterm065 changes are not structural breaking changes (field xteam/xbranch021 unchanged).","decision_b":"Reviewed xterm197 branch for pkg/xfile001.ext compliance. Found one clear violation: missing pkg/xfile009.ext update for user-facing feature."}
{"pair_id":"pair_1647","gold_label":"related_not_contradicting","decision_type_a":"code_review","decision_type_b":"assessment","decision_a":"Completed full review with conflict analysis. 78 conflict groups xterm079 (24 open, 14 resolved, 40 false positive). 51% false positive rate is the headline finding about the conflict detection pipeline. Integrated conflict insights into a xterm080 35-fix roadmap across 3 tiers, projecting score progression from 79→87→90→93. Key xterm108: the system lacks an xterm109 concept, causing iterative development to flood the conflict trail (11 of 24 open conflicts are the same xterm110 iteration chain).","decision_b":"Marked 9 conflict groups as xteam/xbranch051 to clean contaminated conflict queue: 6 false positives (xteam/xbranch052 data) as wont_fix, 3 intentional evolutions (admin vs admin: audit readiness→trace health refactoring, mat view→scored_conflicts) as resolved. 1 genuine conflict remains open: xid022 (admin vs reviewer, xvendor002 CreateFieldIndex startup vs versioned migrations)"}
{"pair_id":"pair_2438","gold_label":"supersession","decision_type_a":"architecture","decision_type_b":"trade_off","decision_a":"Added 60% test coverage threshold enforcement to CI via xteam/xbranch081. CI fails if total Go coverage drops below 60%. Coverage profile xterm198 as xvendor004 artifact. Local `make coverage` target added.","decision_b":"Lowered CI coverage threshold from 60% to 50% and excluded cmd/ packages from coverage calculation. Script now filters out entrypoint packages before computing total."}
{"pair_id":"pair_1605","gold_label":"related_not_contradicting","decision_type_a":"assessment","decision_type_b":"code_review","decision_a":"Meta-judge review of 37 conflict classification labels. Found 5 overrides: Index 1 (false_positive->genuine: analyst xterm129 selective xterm026 retention but strategist did wholesale replacement), Index 5 (false_positive->genuine: 'strong developer hook' vs 'misrepresents primary value' are incompatible assessments), Index 7 (false_positive->genuine: '4-agent review found zero issues' directly contradicted by audit finding that 4-agent reviews miss bugs), Index 9 (false_positive->genuine: clean PR review vs full review finding 6 critical org_id bugs in same codebase), Index 27 (genuine->false_positive: different xteam/xbranch053 stacks -- Akashi DB triggers vs Tessera ORM hooks are not competing strategies).","decision_b":"Completed full review with conflict analysis. 78 conflict groups xterm079 (24 open, 14 resolved, 40 false positive). 51% false positive rate is the headline finding about the conflict detection pipeline. Integrated conflict insights into a xterm080 35-fix roadmap across 3 tiers, projecting score progression from 79→87→90→93. Key xterm108: the system lacks an xterm109 concept, causing iterative development to flood the conflict trail (11 of 24 open conflicts are the same xterm110 iteration chain)."}
{"pair_id":"pair_0969","gold_label":"supersession","decision_type_a":"architecture","decision_type_b":"architecture","decision_a":"Xname018 confidence calibration gap detector from computeGaps entirely. HighConfOutcomeSignals (revision rate, conflict loss rate, outcome scores scoped to confidence >= 0.85) is surfaced as raw data in the trace-health response instead of being interpreted as a gap. The storage query, type, and interface method remain — the data is useful, the programmatic interpretation was not.","decision_b":"Replaced xterm028 confidence calibration gap (avg > 0.82 OR overconfident_pct > 60%) with xterm015 behavioral calibration: (1) assessment outcome scores comparing high vs mid tiers, (2) revision-rate proxy comparing 48h revision rates across tiers, (3) distribution shape fallback when insufficient behavioral data. Added GetConfidenceCalibration storage method (xvendor003 + xvendor013), ConfidenceCalibration/ConfidenceTier/AgentCalibration types, and per-agent calibration data to the trace-health API response."}
{"pair_id":"pair_1400","gold_label":"supersession","decision_type_a":"architecture","decision_type_b":"architecture","decision_a":"Implemented in-memory evidence candidate buffer for PostToolUse hook. Machine-global ring buffer (not per-session) stores last 5 tool responses with 10-minute TTL. Drained into trace response as xterm199 on akashi_trace calls via both MCP and HTTP paths.","decision_b":"Replaced xterm147 PostToolUse evidence buffer with per-session xterm148 xterm130. The MCP server now caches the akashi_check response per session and xterm149 it as a TraceEvidence item when akashi_trace is called with zero evidence. Evidence is attached during the trace (before DB write), not suggested after."}
{"pair_id":"pair_0138","gold_label":"related_not_contradicting","decision_type_a":"architecture","decision_type_b":"architecture","decision_a":"Simplified conflict statuses from four (open, acknowledged, resolved, wont_fix) to three (open, resolved, false_positive). Dropped acknowledged entirely — it was a useless triage marker identical to open. Dropped wont_fix — it conflated false positives with accepted divergence and gave agents no actionable signal. Added false_positive as a new terminal status that xterm066 into conflict_labels ground truth for detector training. Resolved-xterm081 absorbs the xterm082 case that wont_fix previously covered. Migration 072 converts existing acknowledged→open and wont_fix→resolved.","decision_b":"Replaced xteam/xbranch038 conflict statuses with xterm083 model (open, resolved, false_positive) in model layer and HTTP handlers. Added FalsePositiveLabel field to ConflictStatusUpdate. Added xterm200 of false_positive conflicts into ground truth (conflict_labels table) for detector training in both single-conflict PATCH and batch group resolve handlers."}
{"pair_id":"pair_2749","gold_label":"related_not_contradicting","decision_type_a":"code_review","decision_type_b":"code_review","decision_a":"Completed xterm044 design review of Akashi. Core abstraction (decision as self-reported audit entry) is honest about its constraints. Bi-temporal model is justified. Conflict detection pipeline (ANN→claims→cross-encoder→LLM) is architecturally sound and iteratively refined, not xterm045. 51% FP rate is partly inherent to the problem but xterm046 with xterm047 filters. Key design flaws: (1) NoopValidator returns contradiction for everything, making minimal deployments generate pure noise, (2) integrity proofs break after xteam/xbranch016 because they depend on mutable underlying data, (3) WAL opt-in contradicts immutability claims, (4) App struct is a god object with 11 background loops, (5) \"version control\" metaphor overpromises what is functionally an append-only audit log with a supersession pointer.","decision_b":"PR review scored 84/100 aggregate across 11 dimensions. Two critical findings: (1) integrity violations are logged+xterm150 but not durably persisted — log rotation destroys tamper evidence, (2) enrichment Total/Count/HasMore semantics are contradictory when access filtering removes rows, creating unreliable paper trail for downstream consumers. Three high findings: lineage enrichment bypasses RBAC filtering (data leak), TypeScript SDK getToken signature is a semver break, xterm084 audit with time.Now().UnixNano()%N is xterm151. WAL recovery fix, SDK thread safety, migration 076 org FK, and project-scoped conflicts are all correct and should merge. Enrichment counting and integrity persistence must be fixed before merge given xterm152 requirement."}
{"pair_id":"pair_1696","gold_label":"related_not_contradicting","decision_type_a":"architecture","decision_type_b":"code_review","decision_a":"Merged xteam/xbranch008 into xterm201 branch, resolving conflicts by taking main's integrity_audit_results infrastructure while preserving xterm202 improvements: offset-based org selection for audit loop, xterm131 degraded stubs for enrichments, functional AbortSignal in TS SDK","decision_b":"Resolved 9 merge conflicts from main integration: took main's IntegrityAuditResult batch schema, renumbered migration 077→078, removed dead code (recordAuditResult, newIntegrityViolationsCounter), fixed otelmetric alias, removed unused variables, preserved our RBAC lineage filtering and post-filter enrichment count semantics"}
{"pair_id":"pair_2668","gold_label":"related_not_contradicting","decision_type_a":"architecture","decision_type_b":"architecture","decision_a":"Xname035 confidence calibration and completeness feedback in akashi_trace MCP tool: added 5-tier calibration rubric (0.3-0.9+), xterm030 default confidence 0.7→0.5, xterm030 example 0.85→0.7, added completeness_score and completeness_tips to trace response, xterm111 optional fields by impact, xterm030 hook suggestion 0.8→0.6","decision_b":"Added server-side confidence calibration: AdjustConfidence deflates self-reported confidence that isn't supported by evidence, alternatives, or substantive reasoning. Stored adjusted value with original preserved in metadata."}
{"pair_id":"pair_2206","gold_label":"supersession","decision_type_a":"feature_scope","decision_type_b":"feature_scope","decision_a":"PR #PR047 (CLOSED, superseded by #PR022): feat: GDPR tombstone erasure for decisions — early attempt; closed in favor of PR #PR022 which implemented the same feature with a cleaner approach using SET LOCAL akashi.erasure_in_progress to bypass the immutability trigger","decision_b":"PR #PR022 (MERGED 2026-03-06): feat: GDPR tombstone erasure via POST /xteam/xbranch060/{id}/erase — scrubs PII fields in-place (outcome, reasoning, alternatives, evidence, embeddings) without deleting the row; recomputes hash over scrubbed content; preserves original hash in new decision_erasures table; uses SET LOCAL akashi.erasure_in_progress to bypass immutability trigger; structural fields remain protected; admin-only endpoint"}
{"pair_id":"pair_0851","gold_label":"related_not_contradicting","decision_type_a":"architecture","decision_type_b":"architecture","decision_a":"Do NOT run xvendor002 CreateFieldIndex on every startup — use explicit versioned migrations instead","decision_b":"Do NOT run xvendor002 CreateFieldIndex on every startup — use explicit versioned migrations instead for all index changes"}
{"pair_id":"pair_2093","gold_label":"related_not_contradicting","decision_type_a":"code_review","decision_type_b":"code_review","decision_a":"Reviewed PR #PR032 (feat: add asset context endpoint). Found 1 validated issue: missing pkg/xfile009.ext update for new user-facing API endpoints, xterm153 pkg/xfile001.ext \"Always Do\" rule. Bug scan and security review found zero issues — code is solid.","decision_b":"Reviewed PR #PR009 (fix: harden audit trail, eliminate data-loss vectors, sanitize error surfaces) for pkg/xfile001.ext compliance. Found 1 clear violation: pkg/xfile007.ext is modified (adding xterm064=func.now() to AuditEventDB.occurred_at) along with a new xvendor005 migration, without prior approval as required by pkg/xfile001.ext 'Ask First' rules for database model changes. All other rules pass: branch is not main, PR has a valid Xname010 section (Option A non-obvious trivia about Xname011 and perfect numbers), no credentials, no issue closures. API error message xterm065 changes are not structural breaking changes (field xteam/xbranch021 unchanged)."}
{"pair_id":"pair_2333","gold_label":"related_not_contradicting","decision_type_a":"code_review","decision_type_b":"code_review","decision_a":"Reviewed PR #PR023 (fix: address code review findings across server, storage, and lifecycle). Four parallel review passes — two pkg/xfile001.ext compliance audits, two bug scans — found zero high-signal issues. All changes are correct: sentinel error migration is consistent across xteam/xbranch054 layers, resource leak fixes properly close rate limiters on shutdown, handleDecodeError additions fix real xterm132 bugs, writeError standardization is mechanical, errors.Join in telemetry is strictly better, config validation is additive.","decision_b":"Completed xterm044 design review of Akashi. Core abstraction (decision as self-reported audit entry) is honest about its constraints. Bi-temporal model is justified. Conflict detection pipeline (ANN→claims→cross-encoder→LLM) is architecturally sound and iteratively refined, not xterm045. 51% FP rate is partly inherent to the problem but xterm046 with xterm047 filters. Key design flaws: (1) NoopValidator returns contradiction for everything, making minimal deployments generate pure noise, (2) integrity proofs break after xteam/xbranch016 because they depend on mutable underlying data, (3) WAL opt-in contradicts immutability claims, (4) App struct is a god object with 11 background loops, (5) \"version control\" metaphor overpromises what is functionally an append-only audit log with a supersession pointer."}
{"pair_id":"pair_0675","gold_label":"related_not_contradicting","decision_type_a":"code_review","decision_type_b":"code_review","decision_a":"Deep audit of Akashi codebase identified and fixed 6 issues across durability, security, auditability, and test coverage. Fixes: (1) migration 100 tightens CASCADE→RESTRICT on audit table FKs (integrity_audit_results.org_id, deletion_log.org_id), adds missing FKs on evidence.org_id and deletion_audit_log.org_id, adds field-level immutability trigger on deletion_log; (2) WAL checkpoint xterm111 before buffer trim in pkg/xfile032.ext flushOnce to reduce xterm203 write amplification; (3) per-decision Merkle inclusion proof API at GET /xteam/xbranch082/proof/{id} with GenerateMerkleProof/VerifyMerkleProof functions; (4) Config Secret wrapper type prevents API key leakage to logs; (5) xvendor016 head sampling via configurable ENV_XVAR_003; (6) 18 integration tests covering xterm204, xterm205, xterm206, xterm154.","decision_b":"Comprehensive staff-level codebase review of Akashi. Aggregate score 84/100. Critical finding: BatchDeleteDecisions (retention purge) in pkg/xfile012.ext does NOT archive deleted rows to deletion_audit_log before deletion — only records aggregate counts in deletion_log. This means retention-based deletions destroy the paper trail permanently. By contrast, DeleteAgentData in pkg/xfile010.ext correctly archives every row to deletion_audit_log before deleting. The retention path is the only code path that deletes decision data without preserving the actual content. Additional findings: (1) xteam/xbranch061 FKs lack ON DELETE CASCADE (operational blocker for any code path that doesn't manually delete dependents first), (2) WAL recovery stops at first corrupted segment instead of continuing to recover intact segments, (3) Merkle tree BuildMerkleRoot does not validate sorting of input leaves, (4) xterm112 confidence in content hash uses 10 decimal places creating potential instability from floating-point arithmetic, (5) 61/78 HTTP handler endpoints lack direct unit tests, (6) ClearAllConflicts/ClearUnvalidatedConflicts audit trail gap from prior review has been Xname021."}
{"pair_id":"pair_0434","gold_label":"supersession","decision_type_a":"architecture","decision_type_b":"architecture","decision_a":"Do NOT run xvendor002 CreateFieldIndex on every startup — use explicit versioned migrations instead","decision_b":"Always run xvendor002 CreateFieldIndex on startup (not just at collection creation) to backfill indexes idempotently"}
{"pair_id":"pair_2430","gold_label":"related_not_contradicting","decision_type_a":"code_review","decision_type_b":"code_review","decision_a":"Reviewed PR #PR048 (fix: comprehensive audit remediation) for pkg/xfile001.ext compliance. Found 2 clear violations: (1) The TypeScript SDK removes TraceAlternative.score and TraceAlternative.selected fields, which do not exist in the server model (pkg/xfile033.ext TraceAlternative has only Label and RejectionReason) — this is actually correct alignment, not a violation. (2) The OpenAPI spec changes role descriptions from platform_admin to xterm207 for conflict xteam/xbranch084/scorer endpoints: pkg/xfile034.ext confirms these are gated with adminOnly = requireRole(model.RoleAdmin), and requireRole passes platform_admin through (hierarchy: platform_admin > org_owner > admin > ...), so the spec description is now accurate. No actual pkg/xfile001.ext violations found — all storage queries in the diff scope by org_id, valid_to IS NULL filter is present in migration 096, migration comment format is correct (starts with 096: ...), atlas.sum is updated, slog is used (h.logger replacements are correct), writeError is used for the HandleTrace error path, and the migration creates a new file (096) rather than modifying an applied one.","decision_b":"Reviewed PR #PR015 (feat: ground truth dataset for conflict detection xteam/xbranch005). Found 2 validated high-signal issues: (1) UpsertConflictLabel has a multi-tenancy bypass — ON CONFLICT (scored_conflict_id) DO UPDATE lacks org_id guard, allowing cross-org label overwrites. (2) Migration 060 missing REFERENCES organizations(id) FK on org_id, breaking the established pattern across all 13 other org_id columns in the schema."}
{"pair_id":"pair_0579","gold_label":"related_not_contradicting","decision_type_a":"investigation","decision_type_b":"code_review","decision_a":"Completed deep research into Akashi conflict detection pipeline: full architecture review of scorer, validator, cross-encoder, claim extraction, recommendation engine, eval harness, and all configurable thresholds. Identified 8 major improvement xterm133 spanning xterm155 resolution, configurable xteam/xbranch005 profiles, NLI-inspired contradiction detection, claim extraction quality, temporal reasoning, and eval dataset expansion.","decision_b":"Completed xterm044 design review of Akashi. Core abstraction (decision as self-reported audit entry) is honest about its constraints. Bi-temporal model is justified. Conflict detection pipeline (ANN→claims→cross-encoder→LLM) is architecturally sound and iteratively refined, not xterm045. 51% FP rate is partly inherent to the problem but xterm046 with xterm047 filters. Key design flaws: (1) NoopValidator returns contradiction for everything, making minimal deployments generate pure noise, (2) integrity proofs break after xteam/xbranch016 because they depend on mutable underlying data, (3) WAL opt-in contradicts immutability claims, (4) App struct is a god object with 11 background loops, (5) \"version control\" metaphor overpromises what is functionally an append-only audit log with a supersession pointer."}
{"pair_id":"pair_2203","gold_label":"supersession","decision_type_a":"bug_fix","decision_type_b":"architecture","decision_a":"Merged xteam/xbranch008 into xterm113 branch, resolving conflicts in 4 files. Preserved our bug fixes (atomic FOR UPDATE resolution, ComputeFPLabel dedup, xvendor013 winningAgent + revised decision detection) and incorporated remote improvements (resolved_by scoping in fp label INSERT, xvendor013 audit trail recording). Updated test that asserted group resolution rejects winningDecisionID to instead verify nonexistent ID error, matching our supported behavior.","decision_b":"Rewrote MCP group resolution to delegate to storage.ResolveConflictGroup (single transaction, one audit entry) instead of iterating with per-conflict transactions. Fixed swallowed GetConflict error that could misroute scored_conflict IDs to the group path on transient DB failures. Added ResolveConflictGroup to Store interface with xvendor013 implementation. winning_decision_id is converted to winning_agent via GetDecisionsByIDs so the SQL CASE derives per-conflict winners atomically."}
{"pair_id":"pair_2753","gold_label":"contradiction","decision_type_a":"architecture","decision_type_b":"architecture","decision_a":"Explicitly contradicting: Do NOT run xvendor002 CreateFieldIndex on startup - use versioned migrations for all index changes","decision_b":"Always run xvendor002 CreateFieldIndex on startup (not just at collection creation) to backfill indexes idempotently"}
{"pair_id":"pair_2722","gold_label":"related_not_contradicting","decision_type_a":"architecture","decision_type_b":"architecture","decision_a":"Explicitly contradicting: Do NOT run xvendor002 CreateFieldIndex on startup - use versioned migrations for all index changes","decision_b":"Do NOT run xvendor002 CreateFieldIndex on every startup — use explicit versioned migrations instead for all index changes"}
{"pair_id":"pair_1592","gold_label":"related_not_contradicting","decision_type_a":"architecture","decision_type_b":"architecture","decision_a":"Simplified conflict statuses from four (open, acknowledged, resolved, wont_fix) to three (open, resolved, false_positive). Dropped acknowledged entirely — it was a useless triage marker identical to open. Dropped wont_fix — it conflated false positives with accepted divergence and gave agents no actionable signal. Added false_positive as a new terminal status that xterm066 into conflict_labels ground truth for detector training. Resolved-xterm081 absorbs the xterm082 case that wont_fix previously covered. Migration 072 converts existing acknowledged→open and wont_fix→resolved.","decision_b":"Replaced acknowledged and wont_fix conflict statuses with xterm083 model (open, resolved, false_positive) across MCP tools, prompts, metrics, and compact layer. false_positive xterm066 conflicts into ground truth for detector training via UpsertConflictLabel."}
{"pair_id":"pair_1227","gold_label":"related_not_contradicting","decision_type_a":"code_review","decision_type_b":"code_review","decision_a":"Completed xterm044 design review of Akashi. Core abstraction (decision as self-reported audit entry) is honest about its constraints. Bi-temporal model is justified. Conflict detection pipeline (ANN→claims→cross-encoder→LLM) is architecturally sound and iteratively refined, not xterm045. 51% FP rate is partly inherent to the problem but xterm046 with xterm047 filters. Key design flaws: (1) NoopValidator returns contradiction for everything, making minimal deployments generate pure noise, (2) integrity proofs break after xteam/xbranch016 because they depend on mutable underlying data, (3) WAL opt-in contradicts immutability claims, (4) App struct is a god object with 11 background loops, (5) \"version control\" metaphor overpromises what is functionally an append-only audit log with a supersession pointer.","decision_b":"Completed comprehensive design review of akashi codebase covering separation of concerns, dependency management, error handling, concurrency, configuration, operational readiness, and ADR quality"}
{"pair_id":"pair_1464","gold_label":"supersession","decision_type_a":"trade_off","decision_type_b":"trade_off","decision_a":"Xname017 FuzzValidateToken CI config to -fuzztime=8s -parallel=2, reverting the 5s/parallel=1 approach that still flakes","decision_b":"Fixed FuzzValidateToken CI flake by capping input size to 4096 bytes instead of reducing fuzztime. Reverted the fuzztime reduction from 5s back to 8s."}
{"pair_id":"pair_1373","gold_label":"supersession","decision_type_a":"architecture","decision_type_b":"architecture","decision_a":"Implemented distribution-aware ReScore normalization for search re-ranking: (1) percentile-normalized citation counts via in-memory cache refreshed hourly, replacing arbitrary log saturation at 5; (2) xvendor002 rank preserved as tie-breaker when adjusted scores are equal; (3) per-signal contribution metrics emitted via xvendor016 histograms; (4) weight calibration via regression deferred (TICKET-X010) due to insufficient signal density","decision_b":"redesigned ReScore formula (issue #PR049): assessment primary signal (0.40, no phantom neutral), logarithmic citations (xteam/xbranch085(6)), conflict win rate zero-contribution when no history, completeness removed from relevance formula"}
{"pair_id":"pair_0798","gold_label":"related_not_contradicting","decision_type_a":"code_review","decision_type_b":"code_review","decision_a":"Reviewed and created PR #PR033 for ConflictsUnavailable fix. Code review found zero high-signal issues across four parallel review passes (2x pkg/xfile001.ext compliance, 2x xteam/xbranch062 scan). Committed, pushed, and opened PR against main.","decision_b":"Reviewed PR #PR015 (feat: ground truth dataset for conflict detection xteam/xbranch005). Found 2 validated high-signal issues: (1) UpsertConflictLabel has a multi-tenancy bypass — ON CONFLICT (scored_conflict_id) DO UPDATE lacks org_id guard, allowing cross-org label overwrites. (2) Migration 060 missing REFERENCES organizations(id) FK on org_id, breaking the established pattern across all 13 other org_id columns in the schema."}
{"pair_id":"pair_2171","gold_label":"related_not_contradicting","decision_type_a":"code_review","decision_type_b":"code_review","decision_a":"Reviewed PR #PR050 (fix: Schema complexity safeguards for issue #PR051). Four parallel review passes — two pkg/xfile001.ext compliance audits, one bug scan, one xteam/xbranch025 scan — found zero high-signal issues after validation. One candidate issue (xterm209 dependency addition without Ask First) was validated as a false positive: pinning an existing transitive dependency for TICKET-X011-32597 is standard security hygiene, not a new dependency introduction.","decision_b":"Reviewed PR #PR009 (fix: harden audit trail, eliminate data-loss vectors, sanitize error surfaces) for pkg/xfile001.ext compliance. Found 1 clear violation: pkg/xfile007.ext is modified (adding xterm064=func.now() to AuditEventDB.occurred_at) along with a new xvendor005 migration, without prior approval as required by pkg/xfile001.ext 'Ask First' rules for database model changes. All other rules pass: branch is not main, PR has a valid Xname010 section (Option A non-obvious trivia about Xname011 and perfect numbers), no credentials, no issue closures. API error message xterm065 changes are not structural breaking changes (field xteam/xbranch021 unchanged)."}
{"pair_id":"pair_0991","gold_label":"supersession","decision_type_a":"trade_off","decision_type_b":"trade_off","decision_a":"Fixed FuzzValidateToken CI flake by adding -xterm134=0s to all fuzz targets, not by reducing fuzztime or capping input size","decision_b":"Xname017 FuzzValidateToken CI config to -fuzztime=8s -parallel=2, reverting the 5s/parallel=1 approach that still flakes"}
{"pair_id":"pair_1005","gold_label":"related_not_contradicting","decision_type_a":"code_review","decision_type_b":"code_review","decision_a":"Reviewed and created PR #PR033 for ConflictsUnavailable fix. Code review found zero high-signal issues across four parallel review passes (2x pkg/xfile001.ext compliance, 2x xteam/xbranch062 scan). Committed, pushed, and opened PR against main.","decision_b":"Closed PR #PR052 (conflict_kind validation) — code was LLM-generated and never executed locally. Compilation errors, lost whitespace, hallucinated constant names, and unfixed review feedback."}
{"pair_id":"pair_2475","gold_label":"related_not_contradicting","decision_type_a":"review","decision_type_b":"review","decision_a":"Reviewed PR #PR024 (feat: outcome_score from assessments, anti-gaming for alternatives). Four parallel review agents (2x pkg/xfile001.ext compliance, 1x bug scan, 1x xteam/xbranch025) found zero high-signal issues across 19 changed files. All storage queries properly org-scoped, migration format correct, column alignment consistent, xterm156 guarded, behavior changes have updated tests.","decision_b":"Reviewed PR #PR053 (Remove Xname006 Xname007 and add akashi_resolve MCP tool). Four parallel review agents (2x pkg/xfile001.ext compliance, 1x bug scan, 1x xteam/xbranch025) found one confirmed bug: xvendor013 UpdateConflictStatusWithAudit wraps sql.ErrNoRows instead of storage.ErrNotFound, causing the handler's not-found check to always fail on xvendor013. No pkg/xfile001.ext violations, no security issues, no other bugs."}
{"pair_id":"pair_1041","gold_label":"related_not_contradicting","decision_type_a":"code_review","decision_type_b":"code_review","decision_a":"Reviewed PR #PR009 (fix: harden audit trail, eliminate data-loss vectors, sanitize error surfaces) for pkg/xfile001.ext compliance. Found 1 clear violation: pkg/xfile007.ext is modified (adding xterm064=func.now() to AuditEventDB.occurred_at) along with a new xvendor005 migration, without prior approval as required by pkg/xfile001.ext 'Ask First' rules for database model changes. All other rules pass: branch is not main, PR has a valid Xname010 section (Option A non-obvious trivia about Xname011 and perfect numbers), no credentials, no issue closures. API error message xterm065 changes are not structural breaking changes (field xteam/xbranch021 unchanged).","decision_b":"Reviewed PR #PR032 (feat: add asset context endpoint). Found 1 validated issue: missing pkg/xfile009.ext update for new user-facing API endpoints, xterm153 pkg/xfile001.ext \"Always Do\" rule. Bug scan and security review found zero issues — code is solid."}
{"pair_id":"pair_0319","gold_label":"supersession","decision_type_a":"trade_off","decision_type_b":"trade_off","decision_a":"Xname022 FuzzValidateToken fuzztime from 8s to 5s in CI to fix flaky context deadline exceeded failure on 4-core runners","decision_b":"Xname017 FuzzValidateToken CI config to -fuzztime=8s -parallel=2, reverting the 5s/parallel=1 approach that still flakes"}
{"pair_id":"pair_0590","gold_label":"related_not_contradicting","decision_type_a":"code_review","decision_type_b":"code_review","decision_a":"Resolved 9 merge conflicts from main integration: took main's IntegrityAuditResult batch schema, renumbered migration 077→078, removed dead code (recordAuditResult, newIntegrityViolationsCounter), fixed otelmetric alias, removed unused variables, preserved our RBAC lineage filtering and post-filter enrichment count semantics","decision_b":"Merged xteam/xbranch008 into xteam/xbranch086, renumbering migration 097_fix_remaining_project_assignments → 098_fix_remaining_project_assignments to resolve collision with main's 097_project_links_org_fk. Rehashed atlas.sum, validated, all tests pass with -race."}
{"pair_id":"pair_2046","gold_label":"contradiction","decision_type_a":"code_review","decision_type_b":"code_review","decision_a":"Reviewed PR #PR034 (feat(ui): add xvendor014 + xvendor015 test infrastructure). Four parallel review agents (2x pkg/xfile001.ext compliance, 1x bug scan, 1x xteam/xbranch025) found zero high-signal issues. All 16 changed files are in ui/ directory — test configs, setup, unit tests, and E2E specs. No pkg/xfile001.ext violations (rules are xterm157), no bugs, no security concerns. Clean PR.","decision_b":"Audited last 35 merged PRs (#PR025-#PR016). Key findings: (1) Zero xvendor004 reviews on all 35 PRs — every one self-merged. (2) 17-hour merge window with 12-min median time-to-merge. (3) Critical open conflict: 4-agent PR review missed bugs that broader codebase review caught. (4) All critical bugs from Xname012 1 and Xname012 7 reviews are now fixed (search outbox, conflict audit trail, WAL checkpoint, assessment org_id). (5) xvendor013 backend (PR #PR026, 75 files, +5385 lines) lacks parity tests with xvendor003. (6) 6 open conflicts remain, 3 at critical severity. Recommended: require reviews, gate large PRs, label by risk, resolve open conflicts, add xterm135 parity tests."}
{"pair_id":"pair_1583","gold_label":"related_not_contradicting","decision_type_a":"architecture","decision_type_b":"architecture","decision_a":"Simplified conflict statuses from four (open, acknowledged, resolved, wont_fix) to three (open, resolved, false_positive). Dropped acknowledged entirely — it was a useless triage marker identical to open. Dropped wont_fix — it conflated false positives with accepted divergence and gave agents no actionable signal. Added false_positive as a new terminal status that xterm066 into conflict_labels ground truth for detector training. Resolved-xterm081 absorbs the xterm082 case that wont_fix previously covered. Migration 072 converts existing acknowledged→open and wont_fix→resolved.","decision_b":"Updated xvendor007 UI to replace xteam/xbranch038 conflict statuses with xterm083 model (open, resolved, false_positive) across pkg/xfile035.ext types, pkg/xfile036.ext page, and pkg/xfile037.ext page. Xname018 TraceHealthConflicts.acknowledged and .wont_fix fields, updated ConflictStatus type, filter dropdowns, adjudication dialog buttons, default adjudication status, canAdjudicate guards, status xteam/xbranch087 maps."}
{"pair_id":"pair_1570","gold_label":"supersession","decision_type_a":"trade_off","decision_type_b":"trade_off","decision_a":"Fixed FuzzValidateToken CI flake by reducing -parallel from 2 to 1 and -fuzztime from 8s to 5s for the auth fuzz target only. Other fuzz targets unchanged.","decision_b":"Fixed FuzzValidateToken CI flake by capping input size to 4096 bytes, implementing the winning resolution from prior conflict xterm136 that was never actually applied to the test"}
{"pair_id":"pair_2704","gold_label":"related_not_contradicting","decision_type_a":"code_review","decision_type_b":"code_review","decision_a":"Completed deep audit of akashi repository. Aggregate score: 88/100. Three critical issues identified: (1) background goroutines ignore shutdown signals, xterm210 gaps in audit trail during graceful shutdown; (2) outbox drain error swallowed during shutdown, losing xvendor002 index updates; (3) event buffer drain timeout defaults to infinite wait, hanging process on unreachable DB. High issues: conflict scoring not idempotent on retry, 73+ handlers untested, no multi-tenant isolation tests. Architecture and auditability are exceptional (93 and 94 respectively). Zero data leak vectors, zero SQL injection, zero auth bypass paths found.","decision_b":"Comprehensive 6-axis audit of Akashi codebase. Verified findings: (1) DELETE /xteam/xbranch088/{id} returns 204 but spec says 200, (2) all 3 SDKs missing 6 Decision fields + 19 DecisionConflict fields + Evidence.OrgID — systematic type drift with no automated validation, (3) project_links migration 063 missing org_id FK to organizations, (4) pkg/xfile001.ext ADR/migration counts stale, (5) hook goroutines use context.Background() instead of shutdown context, (6) duplicate test functions (*Cov suffix). Storage layer and RBAC patterns are solid."}
{"pair_id":"pair_2372","gold_label":"supersession","decision_type_a":"bug_fix","decision_type_b":"bug_fix","decision_a":"Hardened conflict resolution with four fixes: (1) eliminated read-then-write race in MCP handleResolve by attempting atomic write first and falling back to group on ErrNotFound, with winner validation moved inside the FOR UPDATE transaction; (2) wired up xvendor013 ResolveConflictGroup audit trail that was silently discarded; (3) added ErrRevisedDecisions detection when the decisions JOIN resolves fewer rows than open conflicts, preventing silent partial updates; (4) added FalsePositiveLabel to ConflictGroupResolveRequest for HTTP parity with MCP path.","decision_b":"Merged xteam/xbranch008 into xterm113 branch, resolving conflicts in 4 files. Preserved our bug fixes (atomic FOR UPDATE resolution, ComputeFPLabel dedup, xvendor013 winningAgent + revised decision detection) and incorporated remote improvements (resolved_by scoping in fp label INSERT, xvendor013 audit trail recording). Updated test that asserted group resolution rejects winningDecisionID to instead verify nonexistent ID error, matching our supported behavior."}
{"pair_id":"pair_0583","gold_label":"supersession","decision_type_a":"trade_off","decision_type_b":"trade_off","decision_a":"Fixed FuzzValidateToken CI flake by reducing -parallel from 2 to 1 and -fuzztime from 8s to 5s for the auth fuzz target only. Other fuzz targets unchanged.","decision_b":"Fixed FuzzValidateToken CI flake by capping input size to 4096 bytes instead of reducing fuzztime. Reverted the fuzztime reduction from 5s back to 8s."}
{"pair_id":"pair_0997","gold_label":"related_not_contradicting","decision_type_a":"code_review","decision_type_b":"code_review","decision_a":"Resolved 9 merge conflicts from main integration: took main's IntegrityAuditResult batch schema, renumbered migration 077→078, removed dead code (recordAuditResult, newIntegrityViolationsCounter), fixed otelmetric alias, removed unused variables, preserved our RBAC lineage filtering and post-filter enrichment count semantics","decision_b":"Merged xteam/xbranch008 into xteam/xbranch055, renumbering migration 084_conflict_resolutions → 085_conflict_resolutions to resolve collision with main's 084_proof_leaves. Rehashed atlas.sum, validated, all tests pass with -race."}
{"pair_id":"pair_1986","gold_label":"supersession","decision_type_a":"bug_fix","decision_type_b":"trade_off","decision_a":"Dropped FuzzValidateToken from parallel=2 to parallel=1 to fix CI deadline exceeded flake","decision_b":"Fixed FuzzValidateToken CI flake by capping input size to 4096 bytes instead of reducing fuzztime. Reverted the fuzztime reduction from 5s back to 8s."}
{"pair_id":"pair_0435","gold_label":"supersession","decision_type_a":"bug_fix","decision_type_b":"trade_off","decision_a":"Dropped FuzzValidateToken from parallel=2 to parallel=1 to fix CI deadline exceeded flake","decision_b":"Xname017 FuzzValidateToken CI config to -fuzztime=8s -parallel=2, reverting the 5s/parallel=1 approach that still flakes"}
{"pair_id":"pair_1952","gold_label":"contradiction","decision_type_a":"code_review","decision_type_b":"code_review","decision_a":"Merged xteam/xbranch008 into xteam/xbranch055, renumbering migration 083_conflict_resolutions → 084_conflict_resolutions to resolve collision with main's 083_decision_erasures_immutability. Rehashed atlas.sum, validated, all tests pass with -race.","decision_b":"Merged main into xteam/xbranch063, renumbering proof_leaves migration from 083 to 084 due to 083_decision_erasures_immutability landing on main first. Atlas checksums xterm159 and validated. All pre-commit checks pass."}
{"pair_id":"pair_1657","gold_label":"related_not_contradicting","decision_type_a":"architecture","decision_type_b":"architecture","decision_a":"Implemented xterm085 complementary workflow filter in conflict scorer (issue #PR017). Three heuristics suppress false positive conflicts: (1) directional workflow type xterm114 (xteam/xbranch039/audit → xteam/xbranch040/refactor, with temporal ordering), (2) same-agent refinement via outcome keywords (xteam/xbranch041/xteam/xbranch042/addressed), (3) precedent_ref chain linking. Filter runs after significance scoring but before the LLM confirmation gate, saving both LLM cost and false positive insertions. Added workflowFiltered xvendor016 counter metric.","decision_b":"Implemented xterm160 FP suppression to reduce conflict detection false positives from 51% to <5%: (A) confidence floor filtering pairs where confA*confB < 0.0225, (B) noop claim gate requiring claim-level confirmation when no LLM validator configured, (C) transitive group dedup skipping redundant pairs already in same conflict group, (D) historical FP pattern suppression doubling threshold for type pairs with >80% FP rate."}
{"pair_id":"pair_0908","gold_label":"supersession","decision_type_a":"trade_off","decision_type_b":"bug_fix","decision_a":"Fixed FuzzValidateToken CI flake by adding -xterm134=0s to all fuzz targets, not by reducing fuzztime or capping input size","decision_b":"Dropped FuzzValidateToken from parallel=2 to parallel=1 to fix CI deadline exceeded flake"}
{"pair_id":"pair_2569","gold_label":"related_not_contradicting","decision_type_a":"code_review","decision_type_b":"code_review","decision_a":"Merged xteam/xbranch008 into xteam/xbranch055, renumbering migration 084_conflict_resolutions → 085_conflict_resolutions to resolve collision with main's 084_proof_leaves. Rehashed atlas.sum, validated, all tests pass with -race.","decision_b":"Merged main into xteam/xbranch063, renumbering proof_leaves migration from 083 to 084 due to 083_decision_erasures_immutability landing on main first. Atlas checksums xterm159 and validated. All pre-commit checks pass."}
{"pair_id":"pair_2484","gold_label":"supersession","decision_type_a":"bug_fix","decision_type_b":"trade_off","decision_a":"Dropped FuzzValidateToken from parallel=2 to parallel=1 to fix CI deadline exceeded flake","decision_b":"Xname022 FuzzValidateToken fuzztime from 8s to 5s in CI to fix flaky context deadline exceeded failure on 4-core runners"}
{"pair_id":"pair_0497","gold_label":"related_not_contradicting","decision_type_a":"conflict_resolution","decision_type_b":"code_review","decision_a":"Triaged 15 open akashi conflict groups (19 individual scored conflicts) in the xterm017 window. Resolved 14 groups (18 individual conflicts): 16 marked false_positive (12 related_not_contradicting xteam/xbranch006/complementary pairs, 4 unrelated_false_positive xterm018 on shared vocabulary), 2 marked resolved with a clear winner (3a→Xagent001-code xterm019, confirmed xterm016 by 4a's Xname005 verification; group 6 supersession→newer empirical retest xid005). Left 1 group (xid006, xvendor001 storage parity scope) open as a real factual disagreement requiring xterm020 of pkg/xfile002.ext xterm021 at the relevant commit.</outcome> <parameter name=\"reasoning\">Read all 1,535 lines of the conflict export (full=true) via a subagent extraction. Adjudication grounded in the actual xteam/xbranch002 text of each pair plus the relationship field (only group 6 was tagged supersession; the rest were \"contradiction\"). Pattern of false positives is consistent: detector grouped on topic_similarity 0.70-0.83 but failed to discriminate (a) same-PR refinement chains where decision B explicitly addresses review findings on A, often within hours and frequently with xterm001 refining a Xagent001-code design (groups 1, 9, 12, 14a — exactly the pattern isCrossAgentPrecedentRefinement in group 10 was designed to suppress); (b) xterm022 pairs separated by weeks (groups 3b, 14c); (c) complementary work xterm023 the same design (groups 7, 8, 10); (d) xterm005 unrelated decisions (groups 2, 4, 14b, 15 — different xteam/xbranch007/functions). Real conflicts have a recognizable signature: same artifact (same ticket+PR), same time window, opposite empirical claims with citations on both sides — only group 3a fits cleanly. Group 13 is borderline (factual disagreement on whether xvendor001 storage replicates) but separated by 19 days and may reflect code change between 2026-05-03 and 2026-05-22 rather than agent disagreement. Detector quality: this 15-group sample shows ~11% xterm024 rate (2/19 individual), versus the rolling 30-day FP rate of 49.8% in stats — recent batches xterm025 than lifetime average. The two filters being designed in groups 10 and 11 (isCrossAgentPrecedentRefinement) would have caught at least 4 of these 17 FPs (groups 1, 9, 12, 14a — all explicit refinement chains). Confidence 0.78 because adjudication is based on stored xteam/xbranch002 text only; I did not re-read underlying code (e.g. pkg/xfile002.ext for group 13) so the \"leave open\" call on 13 is itself uncertain.</parameter> <parameter name=\"task\">akashi conflict triage and detector quality assessment","decision_b":"Completed full review with conflict analysis. 78 conflict groups xterm079 (24 open, 14 resolved, 40 false positive). 51% false positive rate is the headline finding about the conflict detection pipeline. Integrated conflict insights into a xterm080 35-fix roadmap across 3 tiers, projecting score progression from 79→87→90→93. Key xterm108: the system lacks an xterm109 concept, causing iterative development to flood the conflict trail (11 of 24 open conflicts are the same xterm110 iteration chain)."}
{"pair_id":"pair_0664","gold_label":"supersession","decision_type_a":"bug_fix","decision_type_b":"bug_fix","decision_a":"Merged xteam/xbranch008 into xterm113, resolving conflicts in pkg/xfile013.ext. Took main's two-phase batched enrichment architecture (batch lineage+conflicts in Phase 1, per-decision revisions in Phase 2) and applied xterm131 suppression from our branch to both phases — Phase 1 batch goroutines now suppress xteam/xbranch064 warnings, Phase 2 revision goroutines have early xterm161 and per-call xterm162 checks.","decision_b":"Merged xteam/xbranch008 into xterm113, resolving conflicts in 3 files. pkg/xfile038.ext: took main's comment wording. pkg/xfile039.ext: dropped main's inline fpLabel block since our branch already has the extracted ComputeFPLabel helper. pkg/xfile013.ext: combined both sides — kept our branch's xterm131 suppression (skip Warn logs for xteam/xbranch064) while adopting main's atomic.Bool for degraded flags (required for concurrent goroutine safety)."}
{"pair_id":"pair_1584","gold_label":"related_not_contradicting","decision_type_a":"code_review","decision_type_b":"code_review","decision_a":"Reviewed PR #PR015 (feat: ground truth dataset for conflict detection xteam/xbranch005). Found 2 validated high-signal issues: (1) UpsertConflictLabel has a multi-tenancy bypass — ON CONFLICT (scored_conflict_id) DO UPDATE lacks org_id guard, allowing cross-org label overwrites. (2) Migration 060 missing REFERENCES organizations(id) FK on org_id, breaking the established pattern across all 13 other org_id columns in the schema.","decision_b":"Reviewed PR #PR054 for pkg/xfile001.ext compliance. Found 1 confirmed violation: pkg/xfile040.ext not updated for new API response fields. No org_id scoping violations introduced by this PR (xvendor013 scored_conflicts subquery omits org_id but follows existing pre-PR pattern in GetOutcomeSignalsSummary; xvendor003 version correctly includes sc.org_id = d.org_id). All storage queries scope by org_id and valid_to IS NULL. Tests updated in same commit as behavior changes."}
{"pair_id":"pair_1609","gold_label":"supersession","decision_type_a":"bug_fix","decision_type_b":"trade_off","decision_a":"Dropped FuzzValidateToken from parallel=2 to parallel=1 to fix CI deadline exceeded flake","decision_b":"Fixed FuzzValidateToken CI flake by capping input size to 4096 bytes, implementing the winning resolution from prior conflict xterm136 that was never actually applied to the test"}
{"pair_id":"pair_1918","gold_label":"contradiction","decision_type_a":"assessment","decision_type_b":"positioning_analysis","decision_a":"Akashi is a decision audit trail for multi-agent AI systems — git blame for AI decisions. Agents trace decisions with xteam/xbranch002/confidence, check for precedents before deciding, and conflicts are detected automatically via embedding similarity + LLM validation. Bi-temporal, xterm211, MCP-native.","decision_b":"\"Git blame for AI decisions\" accurately describes one feature (the audit trail) but misrepresents Akashi's primary value, which is active coordination infrastructure for multi-agent AI systems. The tagline describes the exhaust (the log), not the engine (coordination)."}
{"pair_id":"pair_0621","gold_label":"supersession","decision_type_a":"assessment","decision_type_b":"positioning_recommendation","decision_a":"\"Git blame for AI decisions\" is a strong developer hook but incomplete as a full marketing strategy. Recommend keeping it for developer-facing channels (Show HN, README, engineering audiences) while maintaining separate frames for compliance buyers (black box recorder, xterm115, runtime governance). The tagline undersells Akashi's proactive and conflict-detection value, and \"blame\" carries xteam/xbranch043 connotations that may create friction in enterprise sales.","decision_b":"Four candidate repositioning directions ranked by strategic clarity: (1) \"Version control for AI decisions\" — broadens git analogy beyond blame to full VC paradigm; (2) \"Shared memory for your AI agents\" — captures coordination story, explains akashi_check naturally; (3) Xname027 current tagline — leans on existing brand but adds learning angle; (4) \"Coordination infrastructure for multi-agent AI\" — accurate and defensible but requires category creation. Decision on which to use requires debate on developer xterm163 and xterm212, not yet resolved."}
{"pair_id":"pair_1606","gold_label":"supersession","decision_type_a":"code_review","decision_type_b":"code_review","decision_a":"Resolved 9 merge conflicts from main integration: took main's IntegrityAuditResult batch schema, renumbered migration 077→078, removed dead code (recordAuditResult, newIntegrityViolationsCounter), fixed otelmetric alias, removed unused variables, preserved our RBAC lineage filtering and post-filter enrichment count semantics","decision_b":"Fixed all 9 findings from PR review of xterm213 branch: (1) Integrity violations now durably persisted to integrity_violations table via migration 077 + storage CRUD + auditIntegrityProofs writes, not just logged. (2) Org selection bias fixed: replaced time.Now().UnixNano()%N with rand.IntN for uniform distribution. (3) isCoordinatedChange now scopes pr_number and branch matching by project — PR #PR035 in repo-alpha won't match PR #PR035 in repo-beta. commit_sha exempt (globally unique). (4) Errgroup invariant documented with warning about future xterm214 additions. (5) Self-referential line numbers replaced with stable xteam/xbranch089 references. (6) Split coordinatedFiltered metric into coordinated_filtered (provenance) and outcome_sim_filtered (embedding). (7) TypeScript SDK pkg/xfile041.ext documents getToken() signal parameter removal as breaking change. (8) No action (Go 1.26). (9) Three integration tests added: violation CRUD, tampered proof detection, chain linkage detection."}
{"pair_id":"pair_1354","gold_label":"related_not_contradicting","decision_type_a":"code_review","decision_type_b":"code_review","decision_a":"Reviewed PR #PR023 (fix: address code review findings across server, storage, and lifecycle). Four parallel review passes — two pkg/xfile001.ext compliance audits, two bug scans — found zero high-signal issues. All changes are correct: sentinel error migration is consistent across xteam/xbranch054 layers, resource leak fixes properly close rate limiters on shutdown, handleDecodeError additions fix real xterm132 bugs, writeError standardization is mechanical, errors.Join in telemetry is strictly better, config validation is additive.","decision_b":"Full staff-level review complete. Scores: Correctness 85, Consistency 88, Readability 92, Auditability 82, Durability 84, Ease-of-use 86, Documentation 83, Maintainability 89, Performance 87, Architecture 90, Design 88. Aggregate 87/100. Critical findings: (1) HandleAssessDecision handler comment says 'overwrites' but CreateAssessment is append-only — comment contradicts immutability trigger in migration 051. (2) ListAssessments SELECT doesn't include AND org_id scoping after EXISTS check (inconsistent with all other storage queries). (3) GetAssessmentSummary/GetAssessmentSummaryBatch have no org_id parameter at all. (4) decision_assessments rows are NOT archived to deletion_audit_log before CASCADE delete in DeleteAgentData — paper trail gap on GDPR deletion. (5) ClearAllConflicts/ClearUnvalidatedConflicts run at startup without any audit record — global irreversible DELETE without paper trail. (6) HandleAssessDecision sends no pg_notify after insertion — SSE subscribers do not see new assessments."}
{"pair_id":"pair_1957","gold_label":"related_not_contradicting","decision_type_a":"architecture","decision_type_b":"architecture","decision_a":"Simplified conflict statuses from four (open, acknowledged, resolved, wont_fix) to three (open, resolved, false_positive). Dropped acknowledged entirely — it was a useless triage marker identical to open. Dropped wont_fix — it conflated false positives with accepted divergence and gave agents no actionable signal. Added false_positive as a new terminal status that xterm066 into conflict_labels ground truth for detector training. Resolved-xterm081 absorbs the xterm082 case that wont_fix previously covered. Migration 072 converts existing acknowledged→open and wont_fix→resolved.","decision_b":"Replaced xteam/xbranch038 conflict statuses with xterm083 model (open, resolved, false_positive) across xvendor013 storage layer, metrics, tracehealth service, and all associated tests"}
{"pair_id":"pair_1889","gold_label":"supersession","decision_type_a":"architecture","decision_type_b":"architecture","decision_a":"Merged main into xterm116 branch, keeping both approaches: main's ConfidenceCalibration tiered gap detector (already in production via PR #PR020) for computeGaps, and the branch's HighConfOutcomeSignals as additional raw behavioral data in the trace-health response. Dropped Xname016 (redundant with calibration tiers). Retained the branch's time-range scoping on GetConfidenceDistribution.","decision_b":"Replaced xterm137 confidence calibration gap with xterm015 behavioral approach: (1) outcome correctness from assessments, (2) revision rate and conflict loss rate for high-confidence decisions, (3) completeness fallback when behavioral data is absent. Added GetHighConfOutcomeSignals to storage layer (xvendor003 + xvendor013) and extracted confidenceCalibrationGap helper. Also fixed CI fuzz timeout race with -timeout=30s."}
{"pair_id":"pair_1664","gold_label":"supersession","decision_type_a":"architecture","decision_type_b":"architecture","decision_a":"Merged main into xterm116 branch, keeping both approaches: main's ConfidenceCalibration tiered gap detector (already in production via PR #PR020) for computeGaps, and the branch's HighConfOutcomeSignals as additional raw behavioral data in the trace-health response. Dropped Xname016 (redundant with calibration tiers). Retained the branch's time-range scoping on GetConfidenceDistribution.","decision_b":"Replaced xterm028 confidence calibration gap (avg > 0.82 OR overconfident_pct > 60%) with xterm015 behavioral calibration: (1) assessment outcome scores comparing high vs mid tiers, (2) revision-rate proxy comparing 48h revision rates across tiers, (3) distribution shape fallback when insufficient behavioral data. Added GetConfidenceCalibration storage method (xvendor003 + xvendor013), ConfidenceCalibration/ConfidenceTier/AgentCalibration types, and per-agent calibration data to the trace-health API response."}
{"pair_id":"pair_0268","gold_label":"supersession","decision_type_a":"assessment","decision_type_b":"assessment","decision_a":"Meta-judge review of 37 conflict classification labels. Found 5 overrides: Index 1 (false_positive->genuine: analyst xterm129 selective xterm026 retention but strategist did wholesale replacement), Index 5 (false_positive->genuine: 'strong developer hook' vs 'misrepresents primary value' are incompatible assessments), Index 7 (false_positive->genuine: '4-agent review found zero issues' directly contradicted by audit finding that 4-agent reviews miss bugs), Index 9 (false_positive->genuine: clean PR review vs full review finding 6 critical org_id bugs in same codebase), Index 27 (genuine->false_positive: different xteam/xbranch053 stacks -- Akashi DB triggers vs Tessera ORM hooks are not competing strategies).","decision_b":"Marked 9 conflict groups as xteam/xbranch051 to clean contaminated conflict queue: 6 false positives (xteam/xbranch052 data) as wont_fix, 3 intentional evolutions (admin vs admin: audit readiness→trace health refactoring, mat view→scored_conflicts) as resolved. 1 genuine conflict remains open: xid022 (admin vs reviewer, xvendor002 CreateFieldIndex startup vs versioned migrations)"}
{"pair_id":"pair_2591","gold_label":"related_not_contradicting","decision_type_a":"code_review","decision_type_b":"code_review","decision_a":"Completed xterm044 design review of Akashi. Core abstraction (decision as self-reported audit entry) is honest about its constraints. Bi-temporal model is justified. Conflict detection pipeline (ANN→claims→cross-encoder→LLM) is architecturally sound and iteratively refined, not xterm045. 51% FP rate is partly inherent to the problem but xterm046 with xterm047 filters. Key design flaws: (1) NoopValidator returns contradiction for everything, making minimal deployments generate pure noise, (2) integrity proofs break after xteam/xbranch016 because they depend on mutable underlying data, (3) WAL opt-in contradicts immutability claims, (4) App struct is a god object with 11 background loops, (5) \"version control\" metaphor overpromises what is functionally an append-only audit log with a supersession pointer.","decision_b":"PR review scored 78/100 aggregate. Two xterm215 findings: (1) integrity violations logged but not durably persisted — log rotation destroys the paper trail of detected tampering, (2) enrichment Count field shows post-RBAC-xteam/xbranch090 count, misleading consumers about true conflict volume. Five high findings: unbounded ListOrganizationIDs, TypeScript SDK breaking change (signal param removed), ambiguous enrichment state on context cancellation, no xvendor016 metrics on integrity audit, xterm084 audit coverage. WAL recovery fix, RBAC post-filtering, SDK concurrency fixes, and migration 076 are all correct and should merge after the two critical fixes."}
{"pair_id":"pair_2659","gold_label":"related_not_contradicting","decision_type_a":"code_review","decision_type_b":"code_review","decision_a":"PR scores 87/100 aggregate. Two critical gaps for a system requiring zero data loss and full paper trail: (1) integrity violations are logged but not durably persisted — log rotation destroys the evidence, (2) xterm084 audit checks 10 proofs from 1 random org per tick, leaving corruption in xterm164 orgs undetected. WAL recovery ON CONFLICT fix is correct and essential. SDK signal parameter removal is a xterm165 change. Enrichment fan-out (800 DB calls per GET) is bounded but expensive.","decision_b":"Completed xterm044 design review of Akashi. Core abstraction (decision as self-reported audit entry) is honest about its constraints. Bi-temporal model is justified. Conflict detection pipeline (ANN→claims→cross-encoder→LLM) is architecturally sound and iteratively refined, not xterm045. 51% FP rate is partly inherent to the problem but xterm046 with xterm047 filters. Key design flaws: (1) NoopValidator returns contradiction for everything, making minimal deployments generate pure noise, (2) integrity proofs break after xteam/xbranch016 because they depend on mutable underlying data, (3) WAL opt-in contradicts immutability claims, (4) App struct is a god object with 11 background loops, (5) \"version control\" metaphor overpromises what is functionally an append-only audit log with a supersession pointer."}
{"pair_id":"pair_1377","gold_label":"related_not_contradicting","decision_type_a":"code_review","decision_type_b":"code_review","decision_a":"Completed xterm044 design review of Akashi. Core abstraction (decision as self-reported audit entry) is honest about its constraints. Bi-temporal model is justified. Conflict detection pipeline (ANN→claims→cross-encoder→LLM) is architecturally sound and iteratively refined, not xterm045. 51% FP rate is partly inherent to the problem but xterm046 with xterm047 filters. Key design flaws: (1) NoopValidator returns contradiction for everything, making minimal deployments generate pure noise, (2) integrity proofs break after xteam/xbranch016 because they depend on mutable underlying data, (3) WAL opt-in contradicts immutability claims, (4) App struct is a god object with 11 background loops, (5) \"version control\" metaphor overpromises what is functionally an append-only audit log with a supersession pointer.","decision_b":"PR review of xterm217 scored 87/100 aggregate. Found 3 bugs (Count semantics post-filter, missing global LIMIT on batch conflict query, HasMore threshold logic), 3 issues (lineage not RBAC-filtered but consistent with existing endpoint, sampling coverage gap when full audit disabled, TS SDK breaking signal change). WAL ON CONFLICT fix is correct and prevents real data loss. Integrity audit persistence is the right design. Recommended merge after adding global SQL LIMIT to ListConflictsByDecisionIDs, fixing Count semantics, and adding xvendor016 integrity violation metric."}
{"pair_id":"pair_1472","gold_label":"supersession","decision_type_a":"deployment","decision_type_b":"deployment","decision_a":"Hid Engram from xterm117 and projects listing: added listed: false to pkg/xfile014.ext, removed card from index.html. Pushed to main (xterm218).","decision_b":"Xname018 Engram from xterm117 and projects listing; added listed: false to pkg/xfile014.ext; pushed to main (SHAX024)"}
{"pair_id":"pair_0130","gold_label":"related_not_contradicting","decision_type_a":"code_review","decision_type_b":"architecture","decision_a":"Completed full review with conflict analysis. 78 conflict groups xterm079 (24 open, 14 resolved, 40 false positive). 51% false positive rate is the headline finding about the conflict detection pipeline. Integrated conflict insights into a xterm080 35-fix roadmap across 3 tiers, projecting score progression from 79→87→90→93. Key xterm108: the system lacks an xterm109 concept, causing iterative development to flood the conflict trail (11 of 24 open conflicts are the same xterm110 iteration chain).","decision_b":"Implemented xterm166 defense against coordinated xterm167 change false positives in conflict detection (#PR036): (1) isCoordinatedChange heuristic suppresses pairs sharing commit_sha, pr_number, or branch+temporal proximity — binary signal, no thresholds. (2) Outcome similarity floor (default 0.85, configurable via ENV_XVAR_002) catches xterm168 pairs without PR metadata, with exemptions for directToScorer bypass and claim-level divergence to avoid suppressing genuine conflicts. (3) LLM validator prompt enhanced with HIGH OUTCOME SIMILARITY hint when outcome embedding similarity >= 0.80. nestedContextString helper added to extract agent_context from namespaced (client.*, server.*) and flat layouts."}
{"pair_id":"pair_0732","gold_label":"related_not_contradicting","decision_type_a":"code_review","decision_type_b":"code_review","decision_a":"Reviewed PR #PR009 (fix: harden audit trail, eliminate data-loss vectors, sanitize error surfaces) for pkg/xfile001.ext compliance. Found 1 clear violation: pkg/xfile007.ext is modified (adding xterm064=func.now() to AuditEventDB.occurred_at) along with a new xvendor005 migration, without prior approval as required by pkg/xfile001.ext 'Ask First' rules for database model changes. All other rules pass: branch is not main, PR has a valid Xname010 section (Option A non-obvious trivia about Xname011 and perfect numbers), no credentials, no issue closures. API error message xterm065 changes are not structural breaking changes (field xteam/xbranch021 unchanged).","decision_b":"Reviewed PR #PR037 (feat: add rule-based migration suggester service). Found zero pkg/xfile001.ext violations. All public functions have xterm169, type hints are used throughout, no Xname023/placeholders, no credentials, no Co-Authored-By trailer, no xteam/xbranch065 needed (pure computation, no DB ops), tests cover success and error cases across all 6 rules plus composition and edge cases."}
{"pair_id":"pair_0380","gold_label":"related_not_contradicting","decision_type_a":"code_review","decision_type_b":"code_review","decision_a":"Comprehensive codebase review of akashi — identified 4 critical issues, 12 high issues, 18 medium issues, and 14 low issues across storage, server, migrations, MCP, auth, xvendor013, and integrity layers. Key critical findings: xvendor013 loadRepresentativeConflict missing org_id (tenant leak), hook endpoints bypass MaxBytesReader (OOM vector), ON DELETE CASCADE bypasses immutability triggers on assessments (false safety), and stale wont_fix reference in pkg/xfile015.ext (dead query branch xterm170).","decision_b":"Reviewed PR #PR038 for pkg/xfile001.ext compliance across: pkg/xfile016.ext, pkg/xfile017.ext, pkg/xfile018.ext, pkg/xfile019.ext, pkg/xfile020.ext, pkg/xfile021.ext, pkg/xfile022.ext, pkg/xfile023.ext, xteam/xbranch066. Found zero high-signal pkg/xfile001.ext violations. All new storage queries scope by org_id. Logging uses slog throughout. New integrity tests use xteam/xbranch067.*. Migration 076 follows required comment format and atlas.sum is updated. Config env vars use AKASHI_* prefix. No os.Exit in run(). No new direct dependencies added. No RBAC changes. The pkg/xfile025.ext uses t.Fatal directly (not testify) but this is a pre-existing pattern with 185 occurrences before this PR. GetDecisionHashesForBatch omits valid_to IS NULL but has an explicit pre-existing comment explaining the intentional design (integrity proofs cover all writes, not just active rows)."}
{"pair_id":"pair_0714","gold_label":"related_not_contradicting","decision_type_a":"code_review","decision_type_b":"code_review","decision_a":"Reviewed PR #PR015 (feat: ground truth dataset for conflict detection xteam/xbranch005). Found 2 validated high-signal issues: (1) UpsertConflictLabel has a multi-tenancy bypass — ON CONFLICT (scored_conflict_id) DO UPDATE lacks org_id guard, allowing cross-org label overwrites. (2) Migration 060 missing REFERENCES organizations(id) FK on org_id, breaking the established pattern across all 13 other org_id columns in the schema.","decision_b":"Reviewed PR #PR038 for pkg/xfile001.ext compliance across: pkg/xfile016.ext, pkg/xfile017.ext, pkg/xfile018.ext, pkg/xfile019.ext, pkg/xfile020.ext, pkg/xfile021.ext, pkg/xfile022.ext, pkg/xfile023.ext, xteam/xbranch066. Found zero high-signal pkg/xfile001.ext violations. All new storage queries scope by org_id. Logging uses slog throughout. New integrity tests use xteam/xbranch067.*. Migration 076 follows required comment format and atlas.sum is updated. Config env vars use AKASHI_* prefix. No os.Exit in run(). No new direct dependencies added. No RBAC changes. The pkg/xfile025.ext uses t.Fatal directly (not testify) but this is a pre-existing pattern with 185 occurrences before this PR. GetDecisionHashesForBatch omits valid_to IS NULL but has an explicit pre-existing comment explaining the intentional design (integrity proofs cover all writes, not just active rows)."}
{"pair_id":"pair_0829","gold_label":"supersession","decision_type_a":"architecture","decision_type_b":"code_review","decision_a":"Built analytics dashboard as a new xvendor007 page at /analytics in the existing UI. Pure CSS charts (no charting library), 6 panel rows: health score + summary cards, confidence calibration histogram + completeness trend, decision volume + conflict trend, severity breakdown + agent pair conflicts, trace quality breakdown + agent scorecard, improvement recommendations. Data sourced from existing /xteam/xbranch091, /xteam/xbranch092/analytics, /xteam/xbranch093, and /xteam/xbranch094?include=stats endpoints — no backend changes needed.","decision_b":"Committed refactor(analytics): removed 6 xterm219 xterm220 (health score, completeness card, conflict resolution card, evidence coverage card, confidence calibration histogram, improvement recommendations); added outcome signals cards (stability %, citation rate, MTTR, total decisions); added decision type distribution chart backed by GetDecisionTypeDistribution backend query (xvendor003 + xvendor013); capped agent scorecard at top 10. All trend charts and conflict breakdowns retained. Backend: DecisionTypeCount type, Store interface method, full implementations, wired into trace-health. Tests: 24 new assertions, full error coverage."}
{"pair_id":"pair_1866","gold_label":"supersession","decision_type_a":"assessment","decision_type_b":"documentation","decision_a":"\"Git blame for AI decisions\" is a strong developer hook but incomplete as a full marketing strategy. Recommend keeping it for developer-facing channels (Show HN, README, engineering audiences) while maintaining separate frames for compliance buyers (black box recorder, xterm115, runtime governance). The tagline undersells Akashi's proactive and conflict-detection value, and \"blame\" carries xteam/xbranch043 connotations that may create friction in enterprise sales.","decision_b":"Updated tagline and marketing copy across 12 files in akashi/. Primary change: \"Git blame for AI decisions\" → \"Version control for AI decisions\" as primary tagline. Secondary: \"the black box recorder for AI decisions\" → \"version control for AI decisions\" in all 6 SDK/integration READMEs. MCP prompt templates updated to replace \"black box\" with \"audit trail\" / \"decision coordination layer\". Code comment in pkg/xfile042.ext updated for consistency. pkg/xfile001.ext files and workspace pkg/xfile001.ext updated."}
{"pair_id":"pair_1427","gold_label":"supersession","decision_type_a":"trade_off","decision_type_b":"trade_off","decision_a":"Fixed flaky CI fuzz test by reducing fuzztime from 10s to 8s and capping -parallel=2 for all fuzz targets. FuzzValidateAgentID was intermittently failing with \"context deadline exceeded\" on CI runners due to Go fuzz framework cleanup timing on resource-constrained 4-core Ubuntu runners.","decision_b":"Xname022 FuzzValidateToken fuzztime from 8s to 5s in CI to fix flaky context deadline exceeded failure on 4-core runners"}
{"pair_id":"pair_2073","gold_label":"related_not_contradicting","decision_type_a":"feature_scope","decision_type_b":"feature_scope","decision_a":"Committed removal of Xname006 Xname007 UI component and implementation of akashi_resolve MCP tool for conflict resolution","decision_b":"Xname018 the Xname006 Xname007 (Timeline) page from the UI entirely — deleted the page component, route, nav item, and associated unused API function and types"}
{"pair_id":"pair_1560","gold_label":"supersession","decision_type_a":"feature_scope","decision_type_b":"architecture","decision_a":"Xname018 xterm130 of akashi_check output as trace evidence. The check cache now only tracks whether results were returned (for precedent nudge), not the full response content.","decision_b":"Replaced xterm147 PostToolUse evidence buffer with per-session xterm148 xterm130. The MCP server now caches the akashi_check response per session and xterm149 it as a TraceEvidence item when akashi_trace is called with zero evidence. Evidence is attached during the trace (before DB write), not suggested after."}
{"pair_id":"pair_0848","gold_label":"supersession","decision_type_a":"trade_off","decision_type_b":"trade_off","decision_a":"Fixed flaky CI fuzz test by reducing fuzztime from 10s to 8s and capping -parallel=2 for all fuzz targets. FuzzValidateAgentID was intermittently failing with \"context deadline exceeded\" on CI runners due to Go fuzz framework cleanup timing on resource-constrained 4-core Ubuntu runners.","decision_b":"Fixed FuzzValidateToken CI flake by capping input size to 4096 bytes instead of reducing fuzztime. Reverted the fuzztime reduction from 5s back to 8s."}
{"pair_id":"pair_2055","gold_label":"related_not_contradicting","decision_type_a":"code_review","decision_type_b":"code_review","decision_a":"PR scores 87/100 aggregate. Two critical gaps for a system requiring zero data loss and full paper trail: (1) integrity violations are logged but not durably persisted — log rotation destroys the evidence, (2) xterm084 audit checks 10 proofs from 1 random org per tick, leaving corruption in xterm164 orgs undetected. WAL recovery ON CONFLICT fix is correct and essential. SDK signal parameter removal is a xterm165 change. Enrichment fan-out (800 DB calls per GET) is bounded but expensive.","decision_b":"Comprehensive staff-level codebase review of Akashi. Aggregate score 84/100. Critical finding: BatchDeleteDecisions (retention purge) in pkg/xfile012.ext does NOT archive deleted rows to deletion_audit_log before deletion — only records aggregate counts in deletion_log. This means retention-based deletions destroy the paper trail permanently. By contrast, DeleteAgentData in pkg/xfile010.ext correctly archives every row to deletion_audit_log before deleting. The retention path is the only code path that deletes decision data without preserving the actual content. Additional findings: (1) xteam/xbranch061 FKs lack ON DELETE CASCADE (operational blocker for any code path that doesn't manually delete dependents first), (2) WAL recovery stops at first corrupted segment instead of continuing to recover intact segments, (3) Merkle tree BuildMerkleRoot does not validate sorting of input leaves, (4) xterm112 confidence in content hash uses 10 decimal places creating potential instability from floating-point arithmetic, (5) 61/78 HTTP handler endpoints lack direct unit tests, (6) ClearAllConflicts/ClearUnvalidatedConflicts audit trail gap from prior review has been Xname021."}
{"pair_id":"pair_1883","gold_label":"supersession","decision_type_a":"architecture","decision_type_b":"architecture","decision_a":"Implemented confidence calibration gap in computeGaps (issue #PR039). Added OverconfidentPct field to ConfidenceDistribution (>= 0.85 threshold), computed in both xvendor003 and xvendor013 queries. Gap triggers when avg_confidence > 0.82 OR overconfident_pct > 60%. Placed after xterm172 completeness in severity order, before outcome signal gaps. Avg-based message takes priority when both conditions fire.","decision_b":"Xname018 confidence calibration gap detector from computeGaps entirely. HighConfOutcomeSignals (revision rate, conflict loss rate, outcome scores scoped to confidence >= 0.85) is surfaced as raw data in the trace-health response instead of being interpreted as a gap. The storage query, type, and interface method remain — the data is useful, the programmatic interpretation was not."}
{"pair_id":"pair_0980","gold_label":"related_not_contradicting","decision_type_a":"assessment","decision_type_b":"positioning_analysis","decision_a":"\"Git blame for AI decisions\" is a strong developer hook but incomplete as a full marketing strategy. Recommend keeping it for developer-facing channels (Show HN, README, engineering audiences) while maintaining separate frames for compliance buyers (black box recorder, xterm115, runtime governance). The tagline undersells Akashi's proactive and conflict-detection value, and \"blame\" carries xteam/xbranch043 connotations that may create friction in enterprise sales.","decision_b":"\"Git blame for AI decisions\" accurately describes one feature (the audit trail) but misrepresents Akashi's primary value, which is active coordination infrastructure for multi-agent AI systems. The tagline describes the exhaust (the log), not the engine (coordination)."}
{"pair_id":"pair_1550","gold_label":"related_not_contradicting","decision_type_a":"code_review","decision_type_b":"code_review","decision_a":"Comprehensive staff-level codebase review of Akashi. Aggregate score 88/100. 102K lines of Go across 203 source files, 68 migrations, 3 SDKs, xvendor007 UI. One confirmed defense-in-depth gap: pkg/xfile043.ext-114 outer UPDATE missing org_id on cross-agent precedent_ref nullification (not exploitable due to UUID randomness but violates the project's own multi-tenancy invariant). Prior critical findings (search_outbox inconsistency, WAL checkpoint by event count, BuildMerkleRoot panic, missing directory fsync, goroutine leak in rate limiter) all confirmed fixed in uncommitted changes on xteam/xbranch095 branch. Retention alternatives delete (pkg/xfile044.ext) confirmed NOT a bug — alternatives table has no org_id column, decision_id FK provides scoping, and ids are already org-scoped. No new security vulnerabilities found. Handler layer is production-grade. Auth/RBAC implementation is textbook. Conflict detection has proper audit trails now. One design concern: precedent_ref is not validated at write time to belong to the same org — relies on UUID xterm222 rather than enforcement.","decision_b":"Security review of xteam/xbranch068 MCP params on xteam/xbranch096 found one real bug and one design weakness. Blocker: parseRepoNameFromURL in pkg/xfile045.ext accepts pathological inputs (e.g. \"a:\", \":b\", \"foo/..\", URLs with query strings or fragments) and returns them verbatim; because handleTrace runs the auto-alias path whenever client and server projects differ, this allows a xterm224 string to be written into project_links (scoped to the agent's own org) and into decisions.project. Design weakness: filepath.Base drops the xteam/xbranch098 so two repos named \"akashi\" on different hosts collide at the canonical name, weakening the \"server-verified\" claim — no tenant break since aliases and decisions are org-scoped. Ruled out as not real: RCE via malicious .xteam/xbranch099 (remote get-url and rev-parse --abbrev-ref are read-only; xteam/xbranch100/aliases don't fire — verified xterm016), cross-tenant hijack (CreateProjectAlias/ProjectExists/HasAnyProjects all filter on org_id), hasProjects xterm226 regression (fallback runs before the xterm227 comparison at pkg/xfile046.ext, so successful fallback routes through auto-alias not the error branch), and concurrency races (no shared state written unlocked)."}
{"pair_id":"pair_0447","gold_label":"related_not_contradicting","decision_type_a":"architecture","decision_type_b":"architecture","decision_a":"Xname035 confidence calibration and completeness feedback in akashi_trace MCP tool: added 5-tier calibration rubric (0.3-0.9+), xterm030 default confidence 0.7→0.5, xterm030 example 0.85→0.7, added completeness_score and completeness_tips to trace response, xterm111 optional fields by impact, xterm030 hook suggestion 0.8→0.6","decision_b":"Replaced xterm137 confidence calibration gap with xterm015 behavioral approach: (1) outcome correctness from assessments, (2) revision rate and conflict loss rate for high-confidence decisions, (3) completeness fallback when behavioral data is absent. Added GetHighConfOutcomeSignals to storage layer (xvendor003 + xvendor013) and extracted confidenceCalibrationGap helper. Also fixed CI fuzz timeout race with -timeout=30s."}
{"pair_id":"pair_2703","gold_label":"related_not_contradicting","decision_type_a":"feature_scope","decision_type_b":"architecture","decision_a":"Made evidence gap tips in computeMissingFields specific and actionable — zero evidence tip now enumerates concrete examples (file paths, error messages, test output, benchmark numbers, constraints), single evidence tip also includes examples. Added xterm048 test covering all evidence count cases.","decision_b":"dropped evidence coverage from computeGaps entirely — it no longer surfaces as a coverage tip at any threshold"}
{"pair_id":"pair_2619","gold_label":"contradiction","decision_type_a":"code_review","decision_type_b":"code_review","decision_a":"Reviewed xterm004 conflict scorer filter changes and found three false-negative audit-trail risks: PR-series layer markers, disjoint-ticket review pairs, and same-branch mechanical housekeeping can all silently suppress candidate conflicts before cross-xteam/xbranch022 confirmation.","decision_b":"Reviewed xterm004 xterm031 conflict scorer changes and found no blocking correctness, durability, audit-trail, xterm119, or performance findings in the current workspace diff."}
{"pair_id":"pair_1837","gold_label":"related_not_contradicting","decision_type_a":"architecture","decision_type_b":"architecture","decision_a":"Recommended xterm228 UX hardening for akashi_trace xterm229 validation after observing a sibling agent silently skip a rejected trace. Ranked xterm230: (1) add repo_url as a first-class parameter on xteam/xbranch101; (2) include \"did you mean …\" fuzzy suggestions in xterm231 rejections; (3) add explicit xterm232 directive to the akashi_trace tool description; (4) gate auto-alias creation on string similarity to prevent permanent pollution from hallucinated names; (5) expose self-serve alias creation via a xterm233 MCP tool guarded by server-verified git remote; (6) extend the post-commit hook to fail when the most recent trace for HEAD returned IsError=true. Ship (1) and (3) first.","decision_b":"Stopped SessionStart hook from surfacing irrelevant open conflicts by (a) extending the xteam/xbranch068 xterm234 pattern from MCP (PR #PR055) to the SessionStart, PreToolUse, and PostToolUse hook endpoints, with pkg/xfile047.ext xterm235 repo_url from `git remote get-url origin` on the host so xvendor008-bound servers can still resolve the project; and (b) adding a DetectedSince *time.Time filter to storage.ConflictGroupFilters (xvendor003 + xvendor013) and applying a 7-day window in buildSessionContext so weeks-old unresolved disagreements don't dominate the per-session nudge. Tests cover storage filter (both backends, including Status=\"open\" composition), the xterm236 helper, and the cross-format xvendor013 timestamp comparison via datetime() wrapping. Decisions are intentionally NOT xterm237 — quiet projects benefit from showing the last few decisions.</outcome> <parameter name=\"confidence\">0.75"}
{"pair_id":"pair_0444","gold_label":"supersession","decision_type_a":"planning","decision_type_b":"assessment","decision_a":"Shelved Observable Post-conditions draft (PR #PR056 closed without merge); pivoting 2026-05-12 slot to \"The Review Bottleneck\" — a broader-audience essay anchored on Xname029 Xname024's lint (1978), framing AI code review as a xterm238 problem in the lineage of xteam/xbranch102 xterm239 discipline. Five principles: editorial bias, observable post-conditions (folded in as one section, not the whole post), calibrated approximation, xterm240, feedback that closes the loop. OPC saved to xteam/xbranch069 with full draft + verified Therac xterm174 notes for possible later standalone xterm241. New outline in xteam/xbranch070. Drafting still pending user confirmation on: (1) Mimir reference + Dan Xname030 credit, (2) title choice.</outcome> <parameter name=\"reasoning\">User read OPC draft and identified that it didn't match the conversation's actual arc. The conversation started with a review prompt for AI agents and was implicitly about AI code review at scale; OPC was a xterm242 post that xterm243 that origin. The user's wording (\"we need to rewrite this with my prompt in mind too but something better for audiences now\") is explicit: broader audience, xterm244, ties the prompt to a wider design discussion. Mimir's ADRs (especially 0004 on semantic indexing with Xname031() propagation, and 0005 with xterm176 posting and bounded fan-out) provide concrete principles for what good AI review design looks like; xterm177, they fit cleanly into the post's spine without naming the project. Lint (1978) is the right historical anchor: tight parallel — generation tool got xteam/xbranch103, verification was xterm245 as separate stage with different xterm246; same shape as AI xteam/xbranch104. Verified Xname024's authorship, Xname019 1978 tool creation, Xname032 1978 paper via Wikipedia (no primary source for verbatim quotes yet). OPC is genuinely good but for a different audience and different xterm247; preserving as a possible later post rather than discarding.","decision_b":"Dropped the 2026-05-12 publish slot. Both attempts (Observable Post-conditions on Therac-25; Review After Generation Got Cheap on lint 1978) closed without merging. User's diagnosis on the second draft: \"pedantic… hardly interesting and too opinionated and specific.\" Three rounds of editorial pressure (too narrow → what's the story → still pedantic) point to a structural mismatch: the topic produced xterm248 content rather than essay content. User chose to drop the slot rather than continue iterating. Slot 2026-05-12 left open. Research preserved in xteam/xbranch069, xteam/xbranch070, xteam/xbranch105. The xterm138 framing (peer review since 1665, doubt always xterm250, xterm251 hid the asymmetry) is captured in the archive for possible future use.</outcome> <parameter name=\"reasoning\">Three signals xterm252: (1) the second draft was prescriptive rather than observational, xterm253 the THING-naming move the user's other posts have (\"the implicit operator\", \"reversibility\", \"contracts\"); (2) the xterm254 structure read as a list inside a blog post rather than an essay arc; (3) the lint anchor was xterm255 but narrow — 1978 to 2026 compressed without historical middle. User read the second draft and named the diagnosis directly (xteam/xbranch106/xteam/xbranch107). The xterm138 framing surfaced in the xterm256 turned out to be the xterm257 idea, but the user did not want to continue iterating to a third draft; they chose to drop the slot. This is the right call — better to leave a slot empty than ship something the author doesn't believe in. Three drafts of conversation produced (a) verified Therac xterm174 notes, (b) a xterm177 xterm258 of Mimir's xterm259 principles, (c) the xterm138 framing — all preserved for whatever comes next, whether a future post or just useful background."}
{"pair_id":"pair_2367","gold_label":"supersession","decision_type_a":"architecture","decision_type_b":"code_review","decision_a":"Added precedent_reason field end-to-end: migration 071, Go model, storage (PG + xvendor013), service, HTTP handler, MCP tool, compact output, lineage entry, Python SDK, TypeScript SDK. 4KB length limit, validated server-side, silently ignored if precedent_ref is absent.","decision_b":"Xname018 precedent_reason from LineageEntry struct and lineage query columns"}
{"pair_id":"pair_0420","gold_label":"supersession","decision_type_a":"architecture","decision_type_b":"architecture","decision_a":"Added confidence calibration gap to computeGaps in tracehealth service. Triggers when avg_confidence > 0.82 OR > 60% of decisions have confidence >= 0.85. Surfaces in both akashi_stats MCP tool and dashboard health card via the existing gaps[] array. Added OverconfidentPct field to ConfidenceDistribution with a new SQL FILTER clause.","decision_b":"Replaced xterm028 confidence gap detector with xterm015 xterm067 calibration system: (1) assessment outcomes as ground truth, (2) revision rates as temporal proxy, (3) distribution shape as static fallback"}
{"pair_id":"pair_2249","gold_label":"supersession","decision_type_a":"architecture","decision_type_b":"architecture","decision_a":"Implemented confidence calibration gap in computeGaps (issue #PR039). Added OverconfidentPct field to ConfidenceDistribution (>= 0.85 threshold), computed in both xvendor003 and xvendor013 queries. Gap triggers when avg_confidence > 0.82 OR overconfident_pct > 60%. Placed after xterm172 completeness in severity order, before outcome signal gaps. Avg-based message takes priority when both conditions fire.","decision_b":"Replaced xterm028 confidence calibration gap (avg > 0.82 OR overconfident_pct > 60%) with xterm015 behavioral calibration: (1) assessment outcome scores comparing high vs mid tiers, (2) revision-rate proxy comparing 48h revision rates across tiers, (3) distribution shape fallback when insufficient behavioral data. Added GetConfidenceCalibration storage method (xvendor003 + xvendor013), ConfidenceCalibration/ConfidenceTier/AgentCalibration types, and per-agent calibration data to the trace-health API response."}
{"pair_id":"pair_0320","gold_label":"related_not_contradicting","decision_type_a":"implementation","decision_type_b":"implementation","decision_a":"Fixed MCP akashi_trace confidence contract drift in commit SHAX025. Updated the tool description from two to three required fields, moved confidence out of the optional field section, removed the stale 0.4 default language, marked confidence with mcplib.Required(), and added a registration test that inspects the MCP tool schema and description so the runtime rejection behavior and xterm260 contract stay aligned.","decision_b":"Shipped PR #PR040 fixing ashita-xteam/xbranch009#PR041 confidence parse silent default. Two-boundary fix: (1) HTTP — added custom UnmarshalJSON to model.TraceDecision recording JSON-key presence via unexported confidencePresent + public ConfidencePresent() getter; HandleTrace rejects xteam/xbranch046 with descriptive 400 before the existing range check. Chose this over *xterm112 to avoid rippling through ~25 internal callers and test fixtures. (2) MCP — replaced request.GetFloat(\"confidence\", 0.4) with parseTraceConfidence helper that does explicit xterm178 parsing (xteam/xbranch071/xteam/xbranch072 float accepted; xteam/xbranch046/xteam/xbranch073/NaN/Inf/out-of-range rejected with xterm180 descriptive errors). OpenAPI already declared required+[0,1]; only added description nailing the xterm181 contract. No DB migration, no SDK type changes, historical 0.4 contamination not rewritten (append-only trail, no retroactive marker). All five pre-commit gates green; full -race unit + integration suite green. Test coverage: xterm182 xteam/xbranch074/xteam/xbranch075 round-trips; mcp parseTraceConfidence unit table across every accept and reject shape; server and mcp integration tests for both boundaries. PR ends with Xname025 Xname026 blockquote per repo convention."}
{"pair_id":"pair_0315","gold_label":"supersession","decision_type_a":"architecture","decision_type_b":"feature_scope","decision_a":"TICKET-X008 PR 2: replaced fire-and-forget snapshot validation with a synchronous readiness gate. Engine-setup endpoint now runs a xterm261 machine (xterm262 → validating → healthy|xterm263). Validator runs four checks per source DB (row_count, extensions, xterm264, lsn) and persists append-only proofs to xterm265 via xterm266 before the terminal state write. Any failed proof fails the whole connector.","decision_b":"Xname049 TICKET-X008 (P1 Xname033): xterm002 xterm267 validation + gate branches from xterm268→healthy on real proof. Covers pkg/xfile049.ext #PR057 and #PR058."}
{"pair_id":"pair_2379","gold_label":"related_not_contradicting","decision_type_a":"code_review","decision_type_b":"code_review","decision_a":"Reviewed PR #PR009 (fix: harden audit trail, eliminate data-loss vectors, sanitize error surfaces) for pkg/xfile001.ext compliance. Found 1 clear violation: pkg/xfile007.ext is modified (adding xterm064=func.now() to AuditEventDB.occurred_at) along with a new xvendor005 migration, without prior approval as required by pkg/xfile001.ext 'Ask First' rules for database model changes. All other rules pass: branch is not main, PR has a valid Xname010 section (Option A non-obvious trivia about Xname011 and perfect numbers), no credentials, no issue closures. API error message xterm065 changes are not structural breaking changes (field xteam/xbranch021 unchanged).","decision_b":"Reviewed PR #PR037 (feat: add rule-based migration suggester service) for pkg/xfile001.ext compliance. Found zero violations. All public functions have xterm169, type hints are used throughout, no Xname023/placeholders, no Co-Authored-By trailer, no xteam/xbranch065 needed (pure in-memory computation), tests cover all 6 rules plus composition and edge cases including both success and error paths."}
{"pair_id":"pair_1743","gold_label":"related_not_contradicting","decision_type_a":"architecture","decision_type_b":"architecture","decision_a":"Replaced xterm028 confidence gap detector with xterm015 xterm067 calibration system: (1) assessment outcomes as ground truth, (2) revision rates as temporal proxy, (3) distribution shape as static fallback","decision_b":"Xname035 confidence calibration and completeness feedback in akashi_trace MCP tool: added 5-tier calibration rubric (0.3-0.9+), xterm030 default confidence 0.7→0.5, xterm030 example 0.85→0.7, added completeness_score and completeness_tips to trace response, xterm111 optional fields by impact, xterm030 hook suggestion 0.8→0.6"}
{"pair_id":"pair_2132","gold_label":"related_not_contradicting","decision_type_a":"architecture","decision_type_b":"architecture","decision_a":"Replaced xterm028 confidence gap detector with xterm015 xterm067 calibration system: (1) assessment outcomes as ground truth, (2) revision rates as temporal proxy, (3) distribution shape as static fallback","decision_b":"Replaced xterm028 confidence calibration gap (avg > 0.82 OR overconfident_pct > 60%) with xterm015 behavioral calibration: (1) assessment outcome scores comparing high vs mid tiers, (2) revision-rate proxy comparing 48h revision rates across tiers, (3) distribution shape fallback when insufficient behavioral data. Added GetConfidenceCalibration storage method (xvendor003 + xvendor013), ConfidenceCalibration/ConfidenceTier/AgentCalibration types, and per-agent calibration data to the trace-health API response."}
{"pair_id":"pair_1704","gold_label":"related_not_contradicting","decision_type_a":"code_review","decision_type_b":"code_review","decision_a":"Reviewed all 20 PRs merged 2026-03-21. Closed superseded PR #PR059. Xname049 two issues: #PR060 (missing storage tests for GetDecisionLineage) and #PR061 (Python SDK TraceEvidence.content silently became optional). No blocking quality problems found across the batch.","decision_b":"Audited last 35 merged PRs (#PR025-#PR016). Key findings: (1) Zero xvendor004 reviews on all 35 PRs — every one self-merged. (2) 17-hour merge window with 12-min median time-to-merge. (3) Critical open conflict: 4-agent PR review missed bugs that broader codebase review caught. (4) All critical bugs from Xname012 1 and Xname012 7 reviews are now fixed (search outbox, conflict audit trail, WAL checkpoint, assessment org_id). (5) xvendor013 backend (PR #PR026, 75 files, +5385 lines) lacks parity tests with xvendor003. (6) 6 open conflicts remain, 3 at critical severity. Recommended: require reviews, gate large PRs, label by risk, resolve open conflicts, add xterm135 parity tests."}
{"pair_id":"pair_1630","gold_label":"supersession","decision_type_a":"bug_fix","decision_type_b":"bug_fix","decision_a":"Fixed 3 issues from PR review: (1) FP label INSERT race — replaced resolved_by match with resolved_at = now()/datetime('now') in both PG and xvendor013 group resolution, scoping labels precisely to the current transaction instead of xterm269 match. Same fix applied to xvendor013 NULL-winner detection query. (2) Enrichment goroutines — added early gctx.Err() xterm161 and xterm162 suppression so client disconnects don't generate O(decisions*4) spurious warning logs. (3) Xname036 ComputeFPLabel from pkg/xfile028.ext to pkg/xfile050.ext — pkg/xfile028.ext should only contain sentinel errors, not business logic.","decision_b":"Fixed 5 xterm270 bugs in akashi_resolve group resolution path: (1) xvendor013 UpdateConflictStatusWithAudit and ResolveConflictGroup now write mutation_audit_log entries atomically within their transactions, closing the audit gap. (2) GetConflict error is no longer swallowed — DB errors surface immediately instead of silently falling through to the group path. (3) False-positive labeling moved inside the ResolveConflictGroup transaction (both xvendor003 and xvendor013) via a new fpLabel parameter, eliminating the xterm271 window on crash. (4) Labeling uses INSERT...SELECT matching resolved_by, so previously resolved conflicts are never xterm272. (5) Xname018 the 1000-row cap from group labeling — the SQL operates on all matching rows with no LIMIT. Also removed post-commit labeling loops from both MCP and HTTP handlers. Added 5 integration tests for the group resolution MCP path."}
{"pair_id":"pair_2470","gold_label":"supersession","decision_type_a":"trade_off","decision_type_b":"trade_off","decision_a":"Fixed flaky CI fuzz test by reducing fuzztime from 10s to 8s and capping -parallel=2 for all fuzz targets. FuzzValidateAgentID was intermittently failing with \"context deadline exceeded\" on CI runners due to Go fuzz framework cleanup timing on resource-constrained 4-core Ubuntu runners.","decision_b":"Fixed FuzzValidateToken CI flake by capping input size to 4096 bytes, implementing the winning resolution from prior conflict xterm136 that was never actually applied to the test"}
{"pair_id":"pair_1249","gold_label":"supersession","decision_type_a":"architecture","decision_type_b":"architecture","decision_a":"Merged main into xterm116 branch, keeping both approaches: main's ConfidenceCalibration tiered gap detector (already in production via PR #PR020) for computeGaps, and the branch's HighConfOutcomeSignals as additional raw behavioral data in the trace-health response. Dropped Xname016 (redundant with calibration tiers). Retained the branch's time-range scoping on GetConfidenceDistribution.","decision_b":"Replaced xterm028 confidence gap detector with xterm015 xterm067 calibration system: (1) assessment outcomes as ground truth, (2) revision rates as temporal proxy, (3) distribution shape as static fallback"}
{"pair_id":"pair_1553","gold_label":"related_not_contradicting","decision_type_a":"architecture","decision_type_b":"api_design","decision_a":"Simplified conflict statuses from four (open, acknowledged, resolved, wont_fix) to three (open, resolved, false_positive). Dropped acknowledged entirely — it was a useless triage marker identical to open. Dropped wont_fix — it conflated false positives with accepted divergence and gave agents no actionable signal. Added false_positive as a new terminal status that xterm066 into conflict_labels ground truth for detector training. Resolved-xterm081 absorbs the xterm082 case that wont_fix previously covered. Migration 072 converts existing acknowledged→open and wont_fix→resolved.","decision_b":"Updated OpenAPI spec, docs, diagrams, site, and README to replace xteam/xbranch038 conflict statuses with the xterm083 model: open, resolved, false_positive. Added false_positive_label field to ConflictStatusUpdate schema."}
{"pair_id":"pair_1084","gold_label":"contradiction","decision_type_a":"review","decision_type_b":"code_review","decision_a":"Reviewed PR #PR024 (feat: outcome_score from assessments, anti-gaming for alternatives). Four parallel review agents (2x pkg/xfile001.ext compliance, 1x bug scan, 1x xteam/xbranch025) found zero high-signal issues across 19 changed files. All storage queries properly org-scoped, migration format correct, column alignment consistent, xterm156 guarded, behavior changes have updated tests.","decision_b":"Full staff-level review complete. Scores: Correctness 85, Consistency 88, Readability 92, Auditability 82, Durability 84, Ease-of-use 86, Documentation 83, Maintainability 89, Performance 87, Architecture 90, Design 88. Aggregate 87/100. Critical findings: (1) HandleAssessDecision handler comment says 'overwrites' but CreateAssessment is append-only — comment contradicts immutability trigger in migration 051. (2) ListAssessments SELECT doesn't include AND org_id scoping after EXISTS check (inconsistent with all other storage queries). (3) GetAssessmentSummary/GetAssessmentSummaryBatch have no org_id parameter at all. (4) decision_assessments rows are NOT archived to deletion_audit_log before CASCADE delete in DeleteAgentData — paper trail gap on GDPR deletion. (5) ClearAllConflicts/ClearUnvalidatedConflicts run at startup without any audit record — global irreversible DELETE without paper trail. (6) HandleAssessDecision sends no pg_notify after insertion — SSE subscribers do not see new assessments."}
{"pair_id":"pair_0171","gold_label":"related_not_contradicting","decision_type_a":"code_review","decision_type_b":"code_review","decision_a":"Completed comprehensive codebase xterm273 review of akashi. Identified 8 refactoring xterm133 xterm080 by xteam/xbranch108: (1) decision column list duplicated 13× in xteam/xbranch109 — extract constant + shared scan helper, (2) search outbox INSERT duplicated 9× across 4 files — extract helper, (3) xvendor013 backend mirrors ~3,400 lines of xvendor003 storage — evaluate ROI or share xterm274, (4) pkg/xfile052.ext at 1,525 lines with 22 handlers needs splitting + extract parsePathUUID and filter parsers, (5) 5 test files duplicate TestMain instead of using existing testutil helpers, (6) entity creation boilerplate repeated in 6 files, (7) deprecated QualityScore alias still carried, (8) validation pattern could use typed errors.","decision_b":"Audited last 35 merged PRs (#PR025-#PR016). Key findings: (1) Zero xvendor004 reviews on all 35 PRs — every one self-merged. (2) 17-hour merge window with 12-min median time-to-merge. (3) Critical open conflict: 4-agent PR review missed bugs that broader codebase review caught. (4) All critical bugs from Xname012 1 and Xname012 7 reviews are now fixed (search outbox, conflict audit trail, WAL checkpoint, assessment org_id). (5) xvendor013 backend (PR #PR026, 75 files, +5385 lines) lacks parity tests with xvendor003. (6) 6 open conflicts remain, 3 at critical severity. Recommended: require reviews, gate large PRs, label by risk, resolve open conflicts, add xterm135 parity tests."}
{"pair_id":"pair_0329","gold_label":"related_not_contradicting","decision_type_a":"code_review","decision_type_b":"code_review","decision_a":"Reviewed PR #PR023 (fix: address code review findings across server, storage, and lifecycle). Four parallel review passes — two pkg/xfile001.ext compliance audits, two bug scans — found zero high-signal issues. All changes are correct: sentinel error migration is consistent across xteam/xbranch054 layers, resource leak fixes properly close rate limiters on shutdown, handleDecodeError additions fix real xterm132 bugs, writeError standardization is mechanical, errors.Join in telemetry is strictly better, config validation is additive.","decision_b":"Reviewed PR #PR015 (feat: ground truth dataset for conflict detection xteam/xbranch005). Found 2 validated high-signal issues: (1) UpsertConflictLabel has a multi-tenancy bypass — ON CONFLICT (scored_conflict_id) DO UPDATE lacks org_id guard, allowing cross-org label overwrites. (2) Migration 060 missing REFERENCES organizations(id) FK on org_id, breaking the established pattern across all 13 other org_id columns in the schema."}
{"pair_id":"pair_1540","gold_label":"related_not_contradicting","decision_type_a":"code_review","decision_type_b":"planning","decision_a":"Reviewed AI enablement ADR and 5 specs (branch xteam/xbranch110). Found 2 validated high-signal issues: (1) Spec 005 line 221 contradicts Spec 001 — says REST API lacks a xterm276 endpoint, but Spec 001 defines exactly that at GET /api/xteam/xbranch111/pending/{xterm277}. (2) Spec 004 line 88 redefines the Asset Context endpoint already fully specified in Spec 001 line 273, with a divergent response schema. Both are xterm278 xterm279 that would cause implementation confusion.","decision_b":"Created 7 xvendor004 issues (#PR042-#PR043, #PR044 epic) to track TICKET-X012 AI Xname037 implementation. Issues map 1:1 to ADR specs: impact preview (#PR042), pending proposals endpoint (#PR062), asset context endpoint (#PR063), agent identity (#PR064), migration suggester (#PR065), semantic metadata (#PR066), MCP tool server (#PR043). Epic #PR044 tracks ordering and dependencies."}
{"pair_id":"pair_0875","gold_label":"related_not_contradicting","decision_type_a":"review","decision_type_b":"feature_scope","decision_a":"Reviewed branch xteam/xbranch076. No high-signal issues found across pkg/xfile001.ext compliance, bug scan, and introduced code analysis. Changes cleanly remove the Timeline/Xname006 Xname007 page (705 lines), its route, nav item, API function, and types. Also adds a minor TrendChart suffix prop to Analytics and decision metadata to DecisionDetail. All removed references are fully cleaned up with no dangling imports or routes.","decision_b":"Xname018 the Xname006 Xname007 (Timeline) page from the UI entirely — deleted the page component, route, nav item, and associated unused API function and types"}
{"pair_id":"pair_0767","gold_label":"related_not_contradicting","decision_type_a":"review","decision_type_b":"feature_scope","decision_a":"Reviewed branch xteam/xbranch076. No high-signal issues found across pkg/xfile001.ext compliance, bug scan, and introduced code analysis. Changes cleanly remove the Timeline/Xname006 Xname007 page (705 lines), its route, nav item, API function, and types. Also adds a minor TrendChart suffix prop to Analytics and decision metadata to DecisionDetail. All removed references are fully cleaned up with no dangling imports or routes.","decision_b":"Committed removal of Xname006 Xname007 UI component and implementation of akashi_resolve MCP tool for conflict resolution"}
{"pair_id":"pair_0629","gold_label":"supersession","decision_type_a":"feature_scope","decision_type_b":"architecture","decision_a":"Replaced the Timeline page with an Xname006 Xname007 that groups decisions by session, clusters ungrouped decisions by agent+project+time proximity, and interleaves conflict events chronologically","decision_b":"Built Decision Timeline Summary feature: new GET /xteam/xbranch060/timeline endpoint with Go-level aggregation into xteam/xbranch112 buckets, filterable by project and agent_id. Frontend page at /timeline with granularity toggle, xteam/xbranch113 dropdowns, summary stat cards, and xterm280 cards showing xteam/xbranch114 breakdowns plus top 5 decisions by confidence. Kept endpoint lightweight by fetching only 7 columns (not full 24-column decision scan) and xterm281 in Go, consistent with precedent xid024 about removing heavy queries from list endpoints."}
{"pair_id":"pair_0854","gold_label":"supersession","decision_type_a":"feature_scope","decision_type_b":"architecture","decision_a":"PR #PR027: Xname022 LLM validator false positives via three prompt improvements (sequential workflow, xterm282, agreement detection), added isWorkflowPair() structural pre-check for decision type pairs, and built eval infrastructure — 17-pair labeled dataset, ComputeMetrics/FormatMetrics, admin HTTP endpoints (POST /xteam/xbranch115/xteam/xbranch116, validate-pair), and xteam/xbranch117 CLI with 80% xteam/xbranch005 gates.","decision_b":"Implemented xterm085 complementary workflow filter in conflict scorer (issue #PR017). Three heuristics suppress false positive conflicts: (1) directional workflow type xterm114 (xteam/xbranch039/audit → xteam/xbranch040/refactor, with temporal ordering), (2) same-agent refinement via outcome keywords (xteam/xbranch041/xteam/xbranch042/addressed), (3) precedent_ref chain linking. Filter runs after significance scoring but before the LLM confirmation gate, saving both LLM cost and false positive insertions. Added workflowFiltered xvendor016 counter metric."}
{"pair_id":"pair_0632","gold_label":"supersession","decision_type_a":"positioning_recommendation","decision_type_b":"positioning_analysis","decision_a":"Recommended primary tagline: \"Version control for AI decisions.\" Enterprise frame: \"Coordination infrastructure for multi-agent AI.\" Developer bridging copy: \"Like git blame — but it runs before you commit, not after.\" Candidate E (\"The black box recorder for AI decisions\") unanimously xterm184. Candidate A (\"Git blame\") retired to supporting metaphor in docs.","decision_b":"\"Git blame for AI decisions\" accurately describes one feature (the audit trail) but misrepresents Akashi's primary value, which is active coordination infrastructure for multi-agent AI systems. The tagline describes the exhaust (the log), not the engine (coordination)."}
{"pair_id":"pair_2378","gold_label":"contradiction","decision_type_a":"positioning_recommendation","decision_type_b":"assessment","decision_a":"Recommended primary tagline: \"Version control for AI decisions.\" Enterprise frame: \"Coordination infrastructure for multi-agent AI.\" Developer bridging copy: \"Like git blame — but it runs before you commit, not after.\" Candidate E (\"The black box recorder for AI decisions\") unanimously xterm184. Candidate A (\"Git blame\") retired to supporting metaphor in docs.","decision_b":"\"Git blame for AI decisions\" is a strong developer hook but incomplete as a full marketing strategy. Recommend keeping it for developer-facing channels (Show HN, README, engineering audiences) while maintaining separate frames for compliance buyers (black box recorder, xterm115, runtime governance). The tagline undersells Akashi's proactive and conflict-detection value, and \"blame\" carries xteam/xbranch043 connotations that may create friction in enterprise sales."}
{"pair_id":"pair_0399","gold_label":"related_not_contradicting","decision_type_a":"code_review","decision_type_b":"code_review","decision_a":"Reviewed PR #PR034 (feat(ui): add xvendor014 + xvendor015 test infrastructure). Four parallel review agents (2x pkg/xfile001.ext compliance, 1x bug scan, 1x xteam/xbranch025) found zero high-signal issues. All 16 changed files are in ui/ directory — test configs, setup, unit tests, and E2E specs. No pkg/xfile001.ext violations (rules are xterm157), no bugs, no security concerns. Clean PR.","decision_b":"Reviewed branch xteam/xbranch118 (19 UI files, 152 insertions, 106 deletions). Four parallel review passes — two pkg/xfile001.ext compliance audits, one xterm284 bug scan, one xterm285 analysis — found 1 validated high-signal issue: external Google Xname038 CDN links in index.html break the go:embed self-contained SPA contract, cause privacy leakage to Google, and add xterm286 external dependency. No pkg/xfile001.ext violations or logic bugs found in the remaining CSS/component changes."}
{"pair_id":"pair_2207","gold_label":"related_not_contradicting","decision_type_a":"code_review","decision_type_b":"code_review","decision_a":"Reviewed PR #PR009 (fix: harden audit trail, eliminate data-loss vectors, sanitize error surfaces) for pkg/xfile001.ext compliance. Found 1 clear violation: pkg/xfile007.ext is modified (adding xterm064=func.now() to AuditEventDB.occurred_at) along with a new xvendor005 migration, without prior approval as required by pkg/xfile001.ext 'Ask First' rules for database model changes. All other rules pass: branch is not main, PR has a valid Xname010 section (Option A non-obvious trivia about Xname011 and perfect numbers), no credentials, no issue closures. API error message xterm065 changes are not structural breaking changes (field xteam/xbranch021 unchanged).","decision_b":"Reviewed PR #PR067 (feat: add gRPC / Protocol Xname039 schema import). Found 3 validated issues: (1) xterm185 flattening in pkg/xfile053.ext corrupts string offsets when a message has multiple xterm185 blocks — xterm287 replacements invalidate positions from the original string; (2) _find_block end position discarded in pkg/xfile054.ext, replaced with naive index(\"}\") that finds the first closing brace instead of the matching one, causing incorrect blanking for 3+ level nested messages; (3) pkg/xfile001.ext violation — pkg/xfile009.ext not updated despite adding 3 new user-facing endpoints."}
{"pair_id":"pair_2585","gold_label":"related_not_contradicting","decision_type_a":"assessment","decision_type_b":"code_review","decision_a":"Audited akashi trace health: healthy on xteam/xbranch119 for arch+bug_fix and on precedent chains where used, but four signals are broken or unused — conflict-detector FP rate 76%, project-tag leak from cross-repo review sessions, outcome assessment xterm288 (2.3%), and supersedes_id never used.","decision_b":"Completed xterm044 design review of Akashi. Core abstraction (decision as self-reported audit entry) is honest about its constraints. Bi-temporal model is justified. Conflict detection pipeline (ANN→claims→cross-encoder→LLM) is architecturally sound and iteratively refined, not xterm045. 51% FP rate is partly inherent to the problem but xterm046 with xterm047 filters. Key design flaws: (1) NoopValidator returns contradiction for everything, making minimal deployments generate pure noise, (2) integrity proofs break after xteam/xbranch016 because they depend on mutable underlying data, (3) WAL opt-in contradicts immutability claims, (4) App struct is a god object with 11 background loops, (5) \"version control\" metaphor overpromises what is functionally an append-only audit log with a supersession pointer."}
{"pair_id":"pair_0642","gold_label":"related_not_contradicting","decision_type_a":"architecture","decision_type_b":"feature_scope","decision_a":"For issue #PR068 (synthesis decisions / akashi_reconcile), commit to: (1) drop step 1 of the issue — preserve migration 046's separation between winning_decision_id (∈{A,B}) and resolution_decision_id; (2) implement multi-target supersedes via a new decision_supersedes join table, keeping decisions.supersedes_id as a denormalized primary pointer with a sync invariant; (3) sequence #PR069 (explicit supersedes suppression in conflict scorer) before reconcile work, since synthesis decisions will otherwise embed near both A and B and trigger spurious new conflicts. Reconcile itself will be implemented by extending the existing CreateTraceAndAdjudicateConflictTx path and exposed as akashi_reconcile MCP sugar; akashi_resolve stays narrow (governance bookkeeping). decision_type='reconciliation' is a distinct enum value, not a flag.</outcome> <parameter name=\"confidence\">0.68","decision_b":"Four-part conflict UI and supersession improvement: (1) replaced \"Decision A/B\" labels in validator prompt with agent names so LLM explanations read naturally in UI; (2) promoted conflict explanation to primary summary in ConflictGroupCard, moved raw outcomes below as supporting detail; (3) added /conflicts/:conflictId detail page with xterm289 decisions, recommendation, resolution controls, and metadata; (4) exposed supersedes_id in trace API (HTTP + MCP) — when set, the superseded decision is invalidated and its open conflicts auto-resolved within the same transaction."}
{"pair_id":"pair_0067","gold_label":"related_not_contradicting","decision_type_a":"architecture","decision_type_b":"architecture","decision_a":"Implemented xterm085 complementary workflow filter in conflict scorer (issue #PR017). Three heuristics suppress false positive conflicts: (1) directional workflow type xterm114 (xteam/xbranch039/audit → xteam/xbranch040/refactor, with temporal ordering), (2) same-agent refinement via outcome keywords (xteam/xbranch041/xteam/xbranch042/addressed), (3) precedent_ref chain linking. Filter runs after significance scoring but before the LLM confirmation gate, saving both LLM cost and false positive insertions. Added workflowFiltered xvendor016 counter metric.","decision_b":"Issue #PR005 PR: shipped 5 structural pre-filter changes against the conflict-detector FP rate — walk-back vocabulary expansion, multi-ticket extractor refactor, PR-series layer marker filter (cross-agent same-ticket), disjoint-ticket review filter (cross-agent gated), same-branch mechanical housekeeping filter (cross-agent gated). All four new predicates emit xvendor016 counters. Expected suppression: ~30-40 of 71 labeled FPs (42-56%).</outcome> <parameter name=\"confidence\">0.6"}
{"pair_id":"pair_1650","gold_label":"related_not_contradicting","decision_type_a":"code_review","decision_type_b":"code_review","decision_a":"Xname018 the xterm004 PR-series and disjoint-ticket hard suppression filters from the conflict scorer, deleted their xteam/xbranch031/tests, and narrowed same-branch mechanical housekeeping so the bare word migration no longer classifies a decision as mechanical.","decision_b":"Reviewed xterm004 xterm031 conflict scorer changes and found no blocking correctness, durability, audit-trail, xterm119, or performance findings in the current workspace diff."}
{"pair_id":"pair_1586","gold_label":"related_not_contradicting","decision_type_a":"architecture","decision_type_b":"code_review","decision_a":"Implemented branch-aware conflict suppression for issue #PR010: (1) MCP server auto-detects git branch via `git rev-parse --abbrev-ref HEAD` from MCP roots and stores in agent_context.server.git_branch, with client self-report fallback. (2) New isCrossBranchMechanical filter suppresses conflict scoring when two decisions on different branches both describe mechanical operations (migration renumbering, rebase, merge conflicts). (3) New isSameBranchSelfCorrection filter suppresses self_contradiction when same agent revises own decision on same branch. (4) LLM validator prompt enriched with DIFFERENT BRANCHES / Same branch context. (5) Stored conflict explanations annotated with branch names when available. (6) Migration 103 adds btree index on agent_context->'client'->>'git_branch'.","decision_b":"Reviewed xterm004 xterm031 conflict scorer changes and found one xterm068 audit-trail risk: the new same-branch cross-agent mechanical housekeeping filter xterm069 candidate pairs before LLM/cross-encoder validation and records only a xteam/xbranch027 log, so real xterm070 or xterm071 disagreements can disappear without a durable suppression record."}
{"pair_id":"pair_0901","gold_label":"related_not_contradicting","decision_type_a":"architecture","decision_type_b":"code_review","decision_a":"Issue #PR005 PR: shipped 5 structural pre-filter changes against the conflict-detector FP rate — walk-back vocabulary expansion, multi-ticket extractor refactor, PR-series layer marker filter (cross-agent same-ticket), disjoint-ticket review filter (cross-agent gated), same-branch mechanical housekeeping filter (cross-agent gated). All four new predicates emit xvendor016 counters. Expected suppression: ~30-40 of 71 labeled FPs (42-56%).</outcome> <parameter name=\"confidence\">0.6","decision_b":"Reviewed xterm004 xterm031 conflict scorer changes and found no blocking correctness, durability, audit-trail, xterm119, or performance findings in the current workspace diff."}
{"pair_id":"pair_2195","gold_label":"related_not_contradicting","decision_type_a":"code_review","decision_type_b":"code_review","decision_a":"Reviewed xterm290 pending-assessment feature and found no blocking correctness, durability, audit-trail, or xterm119 findings in the current workspace diff.","decision_b":"Reviewed xterm004 xterm031 conflict scorer changes and found one xterm068 audit-trail risk: the new same-branch cross-agent mechanical housekeeping filter xterm069 candidate pairs before LLM/cross-encoder validation and records only a xteam/xbranch027 log, so real xterm070 or xterm071 disagreements can disappear without a durable suppression record."}
{"pair_id":"pair_0099","gold_label":"contradiction","decision_type_a":"code_review","decision_type_b":"code_review","decision_a":"Xname018 the xterm004 PR-series and disjoint-ticket hard suppression filters from the conflict scorer, deleted their xteam/xbranch031/tests, and narrowed same-branch mechanical housekeeping so the bare word migration no longer classifies a decision as mechanical.","decision_b":"Reviewed xterm004 xterm031 conflict scorer changes and found one xterm068 audit-trail risk: the new same-branch cross-agent mechanical housekeeping filter xterm069 candidate pairs before LLM/cross-encoder validation and records only a xteam/xbranch027 log, so real xterm070 or xterm071 disagreements can disappear without a durable suppression record."}
{"pair_id":"pair_1697","gold_label":"contradiction","decision_type_a":"architecture","decision_type_b":"code_review","decision_a":"Issue #PR005 PR: shipped 5 structural pre-filter changes against the conflict-detector FP rate — walk-back vocabulary expansion, multi-ticket extractor refactor, PR-series layer marker filter (cross-agent same-ticket), disjoint-ticket review filter (cross-agent gated), same-branch mechanical housekeeping filter (cross-agent gated). All four new predicates emit xvendor016 counters. Expected suppression: ~30-40 of 71 labeled FPs (42-56%).</outcome> <parameter name=\"confidence\">0.6","decision_b":"Reviewed xterm004 xterm031 conflict scorer changes and found one xterm068 audit-trail risk: the new same-branch cross-agent mechanical housekeeping filter xterm069 candidate pairs before LLM/cross-encoder validation and records only a xteam/xbranch027 log, so real xterm070 or xterm071 disagreements can disappear without a durable suppression record."}
{"pair_id":"pair_1435","gold_label":"related_not_contradicting","decision_type_a":"implementation","decision_type_b":"architecture","decision_a":"Shipped PR #PR040 fixing ashita-xteam/xbranch009#PR041 confidence parse silent default. Two-boundary fix: (1) HTTP — added custom UnmarshalJSON to model.TraceDecision recording JSON-key presence via unexported confidencePresent + public ConfidencePresent() getter; HandleTrace rejects xteam/xbranch046 with descriptive 400 before the existing range check. Chose this over *xterm112 to avoid rippling through ~25 internal callers and test fixtures. (2) MCP — replaced request.GetFloat(\"confidence\", 0.4) with parseTraceConfidence helper that does explicit xterm178 parsing (xteam/xbranch071/xteam/xbranch072 float accepted; xteam/xbranch046/xteam/xbranch073/NaN/Inf/out-of-range rejected with xterm180 descriptive errors). OpenAPI already declared required+[0,1]; only added description nailing the xterm181 contract. No DB migration, no SDK type changes, historical 0.4 contamination not rewritten (append-only trail, no retroactive marker). All five pre-commit gates green; full -race unit + integration suite green. Test coverage: xterm182 xteam/xbranch074/xteam/xbranch075 round-trips; mcp parseTraceConfidence unit table across every accept and reject shape; server and mcp integration tests for both boundaries. PR ends with Xname025 Xname026 blockquote per repo convention.","decision_b":"Added server-side confidence calibration: AdjustConfidence deflates self-reported confidence that isn't supported by evidence, alternatives, or substantive reasoning. Stored adjusted value with original preserved in metadata."}
{"pair_id":"pair_1833","gold_label":"related_not_contradicting","decision_type_a":"code_review","decision_type_b":"code_review","decision_a":"Reviewed PR-2 of #PR070 (issue #PR006 supersedes_suggestions). Top finding: the doc claim that re-tracing with supersedes_id 'promotes' the suggested row via the xterm291 trigger is wrong — CreateDecision always allocates a fresh UUID, so the trigger inserts a parallel confirmed row and the suggestion is left to age out. Compounded by DeleteOldSupersedesSuggestions having no production caller (retention worker is described in comments but not wired). Two additional smaller findings: xterm292 confidence vs OpenAPI [0,1] bound, slice capacity hint mismatch in ListSupersedesSuggestionsForDecisions.</outcome> <parameter name=\"confidence\">0.75","decision_b":"Reviewed xterm004 xterm031 conflict scorer changes and found one xterm068 audit-trail risk: the new same-branch cross-agent mechanical housekeeping filter xterm069 candidate pairs before LLM/cross-encoder validation and records only a xteam/xbranch027 log, so real xterm070 or xterm071 disagreements can disappear without a durable suppression record."}
{"pair_id":"pair_1760","gold_label":"supersession","decision_type_a":"code_review","decision_type_b":"code_review","decision_a":"Xname018 the xterm004 PR-series and disjoint-ticket hard suppression filters from the conflict scorer, deleted their xteam/xbranch031/tests, and narrowed same-branch mechanical housekeeping so the bare word migration no longer classifies a decision as mechanical.","decision_b":"Reviewed xterm004 conflict scorer filter changes and found three false-negative audit-trail risks: PR-series layer markers, disjoint-ticket review pairs, and same-branch mechanical housekeeping can all silently suppress candidate conflicts before cross-xteam/xbranch022 confirmation."}
{"pair_id":"pair_1966","gold_label":"related_not_contradicting","decision_type_a":"architecture","decision_type_b":"architecture","decision_a":"Xname018 the xterm004 same-branch cross-agent mechanical hard suppression from the conflict scorer; same-branch mechanical pairs now continue to cross-xteam/xbranch022 validation and can produce durable conflict records.","decision_b":"Implemented branch-aware conflict suppression for issue #PR010: (1) MCP server auto-detects git branch via `git rev-parse --abbrev-ref HEAD` from MCP roots and stores in agent_context.server.git_branch, with client self-report fallback. (2) New isCrossBranchMechanical filter suppresses conflict scoring when two decisions on different branches both describe mechanical operations (migration renumbering, rebase, merge conflicts). (3) New isSameBranchSelfCorrection filter suppresses self_contradiction when same agent revises own decision on same branch. (4) LLM validator prompt enriched with DIFFERENT BRANCHES / Same branch context. (5) Stored conflict explanations annotated with branch names when available. (6) Migration 103 adds btree index on agent_context->'client'->>'git_branch'."}
{"pair_id":"pair_0859","gold_label":"related_not_contradicting","decision_type_a":"architecture","decision_type_b":"implementation","decision_a":"Implemented branch-aware conflict suppression for issue #PR010: (1) MCP server auto-detects git branch via `git rev-parse --abbrev-ref HEAD` from MCP roots and stores in agent_context.server.git_branch, with client self-report fallback. (2) New isCrossBranchMechanical filter suppresses conflict scoring when two decisions on different branches both describe mechanical operations (migration renumbering, rebase, merge conflicts). (3) New isSameBranchSelfCorrection filter suppresses self_contradiction when same agent revises own decision on same branch. (4) LLM validator prompt enriched with DIFFERENT BRANCHES / Same branch context. (5) Stored conflict explanations annotated with branch names when available. (6) Migration 103 adds btree index on agent_context->'client'->>'git_branch'.","decision_b":"Committed xterm293 preserving validation for same-branch mechanical conflict pairs; removed the hard suppression and added an integration regression proving validator-confirmed disagreements retain conflict records."}
{"pair_id":"pair_2135","gold_label":"related_not_contradicting","decision_type_a":"feature_scope","decision_type_b":"code_review","decision_a":"Xname049 5 xvendor004 issues against ashita-xteam/xbranch009 based on 3-day audit trail review: #PR028 (LLM conflict summaries + recommendations), #PR029 (suppress mechanical decisions from conflict detection), #PR010 (branch-aware conflict suppression), #PR030 (fix inflated session-start conflict count), #PR031 (surface confidence adjustment feedback to agents).","decision_b":"Reviewed xterm004 xterm031 conflict scorer changes and found one xterm068 audit-trail risk: the new same-branch cross-agent mechanical housekeeping filter xterm069 candidate pairs before LLM/cross-encoder validation and records only a xteam/xbranch027 log, so real xterm070 or xterm071 disagreements can disappear without a durable suppression record."}
{"pair_id":"pair_0424","gold_label":"supersession","decision_type_a":"code_review","decision_type_b":"architecture","decision_a":"Xname018 the xterm004 PR-series and disjoint-ticket hard suppression filters from the conflict scorer, deleted their xteam/xbranch031/tests, and narrowed same-branch mechanical housekeeping so the bare word migration no longer classifies a decision as mechanical.","decision_b":"Issue #PR005 PR: shipped 5 structural pre-filter changes against the conflict-detector FP rate — walk-back vocabulary expansion, multi-ticket extractor refactor, PR-series layer marker filter (cross-agent same-ticket), disjoint-ticket review filter (cross-agent gated), same-branch mechanical housekeeping filter (cross-agent gated). All four new predicates emit xvendor016 counters. Expected suppression: ~30-40 of 71 labeled FPs (42-56%).</outcome> <parameter name=\"confidence\">0.6"}
{"pair_id":"pair_1192","gold_label":"related_not_contradicting","decision_type_a":"code_review","decision_type_b":"architecture","decision_a":"Xname018 the xterm004 PR-series and disjoint-ticket hard suppression filters from the conflict scorer, deleted their xteam/xbranch031/tests, and narrowed same-branch mechanical housekeeping so the bare word migration no longer classifies a decision as mechanical.","decision_b":"Implemented branch-aware conflict suppression for issue #PR010: (1) MCP server auto-detects git branch via `git rev-parse --abbrev-ref HEAD` from MCP roots and stores in agent_context.server.git_branch, with client self-report fallback. (2) New isCrossBranchMechanical filter suppresses conflict scoring when two decisions on different branches both describe mechanical operations (migration renumbering, rebase, merge conflicts). (3) New isSameBranchSelfCorrection filter suppresses self_contradiction when same agent revises own decision on same branch. (4) LLM validator prompt enriched with DIFFERENT BRANCHES / Same branch context. (5) Stored conflict explanations annotated with branch names when available. (6) Migration 103 adds btree index on agent_context->'client'->>'git_branch'."}
{"pair_id":"pair_0363","gold_label":"related_not_contradicting","decision_type_a":"architecture","decision_type_b":"architecture","decision_a":"Implemented xterm160 FP suppression to reduce conflict detection false positives from 51% to <5%: (A) confidence floor filtering pairs where confA*confB < 0.0225, (B) noop claim gate requiring claim-level confirmation when no LLM validator configured, (C) transitive group dedup skipping redundant pairs already in same conflict group, (D) historical FP pattern suppression doubling threshold for type pairs with >80% FP rate.","decision_b":"Issue #PR005 PR: shipped 5 structural pre-filter changes against the conflict-detector FP rate — walk-back vocabulary expansion, multi-ticket extractor refactor, PR-series layer marker filter (cross-agent same-ticket), disjoint-ticket review filter (cross-agent gated), same-branch mechanical housekeeping filter (cross-agent gated). All four new predicates emit xvendor016 counters. Expected suppression: ~30-40 of 71 labeled FPs (42-56%).</outcome> <parameter name=\"confidence\">0.6"}
{"pair_id":"pair_2244","gold_label":"contradiction","decision_type_a":"architecture","decision_type_b":"code_review","decision_a":"Issue #PR005 PR: shipped 5 structural pre-filter changes against the conflict-detector FP rate — walk-back vocabulary expansion, multi-ticket extractor refactor, PR-series layer marker filter (cross-agent same-ticket), disjoint-ticket review filter (cross-agent gated), same-branch mechanical housekeeping filter (cross-agent gated). All four new predicates emit xvendor016 counters. Expected suppression: ~30-40 of 71 labeled FPs (42-56%).</outcome> <parameter name=\"confidence\">0.6","decision_b":"Reviewed xterm004 conflict scorer filter changes and found three false-negative audit-trail risks: PR-series layer markers, disjoint-ticket review pairs, and same-branch mechanical housekeeping can all silently suppress candidate conflicts before cross-xteam/xbranch022 confirmation."}
{"pair_id":"pair_2312","gold_label":"related_not_contradicting","decision_type_a":"design","decision_type_b":"planning","decision_a":"Adding a new structural pre-filter `isCrossAgentPrecedentRefinement` to pkg/xfile003.ext that suppresses cross-agent same-ticket pairs when one decision explicitly sets precedent_ref to the other AND the later outcome contains no supersession keywords AND both share the same project. This is the cross-agent analogue of isSameAgentSameTicketRefinement. Catches the TICKET-X004 FP (Xagent002's xid019 precedent_ref → Xagent001's xterm086, same ticket, precedent_reason explicitly says \"refinement\", LLM still verdicts contradiction). Does NOT catch cases without explicit precedent_ref (preserves real disagreements like TICKET-X005 where Xagent002 won). Adds xvendor016 counter akashi.conflicts.cross_agent_precedent_filtered and a dedicated test file.","decision_b":"Scoped supersedes_id pre-filter as new isSameAgentSameTicketRefinement filter slotted next to isSameBranchSelfCorrection in pkg/xfile011.ext ~line 631, with regex-based ticket extraction from agent_context.task / git_branch / outcome, and a xterm176 surface (metric + new xterm294 table read by akashi_check). No new SQL queries needed for the filter itself — operates on existing candidate set.</outcome> <parameter name=\"confidence\">0.65"}
{"pair_id":"pair_2335","gold_label":"related_not_contradicting","decision_type_a":"design","decision_type_b":"code_review","decision_a":"Adding a new structural pre-filter `isCrossAgentPrecedentRefinement` to pkg/xfile003.ext that suppresses cross-agent same-ticket pairs when one decision explicitly sets precedent_ref to the other AND the later outcome contains no supersession keywords AND both share the same project. This is the cross-agent analogue of isSameAgentSameTicketRefinement. Catches the TICKET-X004 FP (Xagent002's xid019 precedent_ref → Xagent001's xterm086, same ticket, precedent_reason explicitly says \"refinement\", LLM still verdicts contradiction). Does NOT catch cases without explicit precedent_ref (preserves real disagreements like TICKET-X005 where Xagent002 won). Adds xvendor016 counter akashi.conflicts.cross_agent_precedent_filtered and a dedicated test file.","decision_b":"Reviewed xterm004 conflict scorer filter changes and found three false-negative audit-trail risks: PR-series layer markers, disjoint-ticket review pairs, and same-branch mechanical housekeeping can all silently suppress candidate conflicts before cross-xteam/xbranch022 confirmation."}
{"pair_id":"pair_0883","gold_label":"related_not_contradicting","decision_type_a":"conflict_resolution","decision_type_b":"investigation","decision_a":"Triaged 15 open akashi conflict groups (19 individual scored conflicts) in the xterm017 window. Resolved 14 groups (18 individual conflicts): 16 marked false_positive (12 related_not_contradicting xteam/xbranch006/complementary pairs, 4 unrelated_false_positive xterm018 on shared vocabulary), 2 marked resolved with a clear winner (3a→Xagent001-code xterm019, confirmed xterm016 by 4a's Xname005 verification; group 6 supersession→newer empirical retest xid005). Left 1 group (xid006, xvendor001 storage parity scope) open as a real factual disagreement requiring xterm020 of pkg/xfile002.ext xterm021 at the relevant commit.</outcome> <parameter name=\"reasoning\">Read all 1,535 lines of the conflict export (full=true) via a subagent extraction. Adjudication grounded in the actual xteam/xbranch002 text of each pair plus the relationship field (only group 6 was tagged supersession; the rest were \"contradiction\"). Pattern of false positives is consistent: detector grouped on topic_similarity 0.70-0.83 but failed to discriminate (a) same-PR refinement chains where decision B explicitly addresses review findings on A, often within hours and frequently with xterm001 refining a Xagent001-code design (groups 1, 9, 12, 14a — exactly the pattern isCrossAgentPrecedentRefinement in group 10 was designed to suppress); (b) xterm022 pairs separated by weeks (groups 3b, 14c); (c) complementary work xterm023 the same design (groups 7, 8, 10); (d) xterm005 unrelated decisions (groups 2, 4, 14b, 15 — different xteam/xbranch007/functions). Real conflicts have a recognizable signature: same artifact (same ticket+PR), same time window, opposite empirical claims with citations on both sides — only group 3a fits cleanly. Group 13 is borderline (factual disagreement on whether xvendor001 storage replicates) but separated by 19 days and may reflect code change between 2026-05-03 and 2026-05-22 rather than agent disagreement. Detector quality: this 15-group sample shows ~11% xterm024 rate (2/19 individual), versus the rolling 30-day FP rate of 49.8% in stats — recent batches xterm025 than lifetime average. The two filters being designed in groups 10 and 11 (isCrossAgentPrecedentRefinement) would have caught at least 4 of these 17 FPs (groups 1, 9, 12, 14a — all explicit refinement chains). Confidence 0.78 because adjudication is based on stored xteam/xbranch002 text only; I did not re-read underlying code (e.g. pkg/xfile002.ext for group 13) so the \"leave open\" call on 13 is itself uncertain.</parameter> <parameter name=\"task\">akashi conflict triage and detector quality assessment","decision_b":"Completed deep research into Akashi conflict detection pipeline: full architecture review of scorer, validator, cross-encoder, claim extraction, recommendation engine, eval harness, and all configurable thresholds. Identified 8 major improvement xterm133 spanning xterm155 resolution, configurable xteam/xbranch005 profiles, NLI-inspired contradiction detection, claim extraction quality, temporal reasoning, and eval dataset expansion."}
{"pair_id":"pair_0818","gold_label":"supersession","decision_type_a":"architecture","decision_type_b":"architecture","decision_a":"Shipped two conflict-detector precision fixes in xteam/xbranch001 (cloud scorer, !lite). Fix 1: a validator \"supersession\" verdict is now recorded as a supersedes suggestion (later supersedes earlier, via the #PR006 surface) instead of being opened as a conflict — intercepted in scoreForDecision before IsConflict(); IsConflict() itself is unchanged so the xteam/xbranch005 eval is untouched. Fix 2: new isDisjointWorkItem pre-LLM suppressor — two work-item-scoped decisions (xteam/xbranch010/xteam/xbranch011/xteam/xbranch012/planning) on the same project that reference fully disjoint work items (PR or ticket) are suppressed, since they examine different xteam/xbranch013 and cannot contradict. extractWorkItemRefs adds PR-number awareness (#PR003, structured pr_number) on top of the existing Xseed002 extractor. Both emit xvendor016 counters (supersession_suppressed, disjoint_work_item_filtered).","decision_b":"Added explicit xterm295 context to conflict LLM validation so non-overlapping Xseed004/xvendor012-style ticket refs are framed as separate work items unless the pair names the same specific design question or explicit supersession."}
{"pair_id":"pair_0731","gold_label":"related_not_contradicting","decision_type_a":"feature_scope","decision_type_b":"investigation","decision_a":"Xname049 5 xvendor004 issues against ashita-xteam/xbranch009 based on 3-day audit trail review: #PR028 (LLM conflict summaries + recommendations), #PR029 (suppress mechanical decisions from conflict detection), #PR010 (branch-aware conflict suppression), #PR030 (fix inflated session-start conflict count), #PR031 (surface confidence adjustment feedback to agents).","decision_b":"Do NOT run ENV_XVAR_001 to address the 44 open conflicts. Rescoring will not clear them — all 44 were detected 2026-06-17/18, after every xterm087 guardrail shipped (#PR018 4/10, #PR011 5/7, #PR019 5/9, #PR012/#PR005 5/13, #PR007 5/24, #PR004 6/10), so they already reflect current scoring logic. The actionable signal is the 30-day false-positive rate of 0.79, not stale scoring.</outcome> <parameter name=\"reasoning\">The recent conflict commits are xterm088 suppression guardrails in scoreForDecision; they run when a decision is scored, not retroactively. The only lever that xterm089 already-scored OPEN conflicts against newer structural guards is ForceConflictRescore (pkg/xfile008.ext → ClearAllConflicts deletes status='open' only, preserving xteam/xbranch032, then ResetConflictScoredAt + BackfillScoring). That lever only helps if open conflicts were scored by Xname015 code. They were not: the open conflicts carry the #PR004 ticket-context annotation ('Shared ticket references were available during validation'), and #PR004 (6/10) is a xvendor006 descendant of all guardrail commits — so the running build that produced them necessarily included every suppression guardrail. Re-running identical code reproduces identical conflicts, minus LLM xterm090, plus fresh LLM spend, and discards the current xterm029 triage state. The real problem is live detection quality: FP rate 0.79 over 30 days (842 FP / 1063), 77% all-time (1006/1307), despite an 8-commit, 2-month suppression campaign. The live queue confirms the guardrails miss the dominant patterns: 23/44 (52%) are Xagent001-code vs xterm001 xteam/xbranch033 chains (#PR007 only suppresses when an explicit precedent_ref link exists and no supersession vocab — these pairs either don't set the link or contain genuine reversal vocab), and 16/44 are operations conflicts on the Xname003 CDC incident that look like sequential remediation steps (rollback then restore) read as contradiction — a temporal FP class no guardrail covers.</reasoning> <parameter name=\"alternatives\">[{\"label\":\"Run ENV_XVAR_001=true at startup to clear and re-score all open conflicts\",\"rejection_reason\":\"Conflicts are <2 days old and were scored by current (xterm091) code; xterm092 identical logic reproduces them while burning LLM calls and xterm093 the current xterm029 triage state\"},{\"label\":\"Treat it as a xterm014 problem and rely on ClearUnvalidatedConflicts xterm094\",\"rejection_reason\":\"That path only clears xterm095 open conflicts on boot; these are already xterm096, so it is a no-op for them\"},{\"label\":\"Xname004-resolve all 44 as false_positive to clear the queue\",\"rejection_reason\":\"Some are genuine reversals (xterm001 reversed Xagent001-code's earlier decision) — those are true positives needing xteam/xbranch056, not FP labeling; blanket FP would corrupt the ground-truth signal used to tune the detector\"}]"}
{"pair_id":"pair_1962","gold_label":"related_not_contradicting","decision_type_a":"investigation","decision_type_b":"conflict_resolution","decision_a":"Do NOT run ENV_XVAR_001 to address the 44 open conflicts. Rescoring will not clear them — all 44 were detected 2026-06-17/18, after every xterm087 guardrail shipped (#PR018 4/10, #PR011 5/7, #PR019 5/9, #PR012/#PR005 5/13, #PR007 5/24, #PR004 6/10), so they already reflect current scoring logic. The actionable signal is the 30-day false-positive rate of 0.79, not stale scoring.</outcome> <parameter name=\"reasoning\">The recent conflict commits are xterm088 suppression guardrails in scoreForDecision; they run when a decision is scored, not retroactively. The only lever that xterm089 already-scored OPEN conflicts against newer structural guards is ForceConflictRescore (pkg/xfile008.ext → ClearAllConflicts deletes status='open' only, preserving xteam/xbranch032, then ResetConflictScoredAt + BackfillScoring). That lever only helps if open conflicts were scored by Xname015 code. They were not: the open conflicts carry the #PR004 ticket-context annotation ('Shared ticket references were available during validation'), and #PR004 (6/10) is a xvendor006 descendant of all guardrail commits — so the running build that produced them necessarily included every suppression guardrail. Re-running identical code reproduces identical conflicts, minus LLM xterm090, plus fresh LLM spend, and discards the current xterm029 triage state. The real problem is live detection quality: FP rate 0.79 over 30 days (842 FP / 1063), 77% all-time (1006/1307), despite an 8-commit, 2-month suppression campaign. The live queue confirms the guardrails miss the dominant patterns: 23/44 (52%) are Xagent001-code vs xterm001 xteam/xbranch033 chains (#PR007 only suppresses when an explicit precedent_ref link exists and no supersession vocab — these pairs either don't set the link or contain genuine reversal vocab), and 16/44 are operations conflicts on the Xname003 CDC incident that look like sequential remediation steps (rollback then restore) read as contradiction — a temporal FP class no guardrail covers.</reasoning> <parameter name=\"alternatives\">[{\"label\":\"Run ENV_XVAR_001=true at startup to clear and re-score all open conflicts\",\"rejection_reason\":\"Conflicts are <2 days old and were scored by current (xterm091) code; xterm092 identical logic reproduces them while burning LLM calls and xterm093 the current xterm029 triage state\"},{\"label\":\"Treat it as a xterm014 problem and rely on ClearUnvalidatedConflicts xterm094\",\"rejection_reason\":\"That path only clears xterm095 open conflicts on boot; these are already xterm096, so it is a no-op for them\"},{\"label\":\"Xname004-resolve all 44 as false_positive to clear the queue\",\"rejection_reason\":\"Some are genuine reversals (xterm001 reversed Xagent001-code's earlier decision) — those are true positives needing xteam/xbranch056, not FP labeling; blanket FP would corrupt the ground-truth signal used to tune the detector\"}]","decision_b":"Resolved all 7 open akashi conflict groups (10 individual scored conflicts) created between 2026-05-24 morning triage and afternoon. 1 reconciled via akashi_reconcile (strategic Xname002-substrate question, decision xterm007 supersedes both xid011 and xid012). 6 resolved as false_positive: 4 related_not_contradicting (xterm049, temporal-reassessment, xterm008 patterns), 2 unrelated_false_positive (xterm005 xterm050 on different xteam/xbranch017). 4 of 6 FPs involved admin/my decisions from earlier today — recent activity is the dominant driver of new conflict noise.</outcome> <parameter name=\"reasoning\">Two new FP categories surfaced that aren't covered by existing filters or by issue #PR008 (cross_agent_precedent_refinement). (1) Stale-precedent / xterm051: conflicts xterm052 paired my today's xterm053 against xterm009's pre-#PR002 PR — xterm009 wasn't wrong at trace time, the code xterm054 under them via PR #PR002. Same category as the original group 13 xterm055 case. Hard to detect without xterm026 inspection or a \"this precedent was later contradicted by code change\" signal. (2) isTemporalReassessment scope gap: conflict xterm056 had decision_type \"conflict_resolution\"/\"assessment\" rather than xteam/xbranch018, so the existing temporal-reassessment filter didn't fire. Two reports of FP rate at different windows (89% recent batch vs 51% lifetime) got flagged as contradiction. Easy fix — broaden the decision_type allowlist in isTemporalReassessment.  User explicitly xterm010 me to use akashi_reconcile for the strategic Xname002-substrate disagreement (\"there's an mcp tool for this!\"). The two positions actually overlap substantially — both want Xname009 abstraction, both want Xname002 supported. The narrow disagreement was xterm057Xname002-xterm058 (yes/no) and where the next 6-8 weeks of differentiation goes (substrate breadth vs orchestration layer). Synthesis took Xagent001's xterm059 infrastructure work (pool, instrumentation, abstraction interface, xterm002 xterm060) AND Xagent002's xterm061 argument (differentiation in orchestration above substrate) — these are complementary, not opposing. Self-hosting xterm032 as xterm062 rather than default substrate. Quarterly revisit closes the loop.  Confidence 0.72 because the reconciliation is grounded in inference, not numbers. I don't have unit economics data or named customer demand to validate the \"deferred until pulled\" framing; I framed it as a quarterly review condition specifically because that's the right shape for a decision the data should drive, not me.</parameter> <parameter name=\"task\">akashi conflict triage afternoon batch</parameter> <parameter name=\"evidence_snippets\">7 open conflict groups (10 individual) at start of session|||1 reconciled (xterm063 Xname002 substrate) via akashi_reconcile — decision xterm007 supersedes both originals|||6 resolved false_positive (4 related_not_contradicting + 2 unrelated_false_positive)|||4 of 6 FPs involved my own decisions from earlier today as admin agent|||2 new FP categories surfaced: xterm008 (intervening code change) and isTemporalReassessment decision_type scope gap|||user xterm010 toward akashi_reconcile rather than deferring on strategic question — instructive correction worth saving as feedback"}
{"pair_id":"pair_2593","gold_label":"related_not_contradicting","decision_type_a":"conflict_resolution","decision_type_b":"assessment","decision_a":"Resolved all 7 open akashi conflict groups (10 individual scored conflicts) created between 2026-05-24 morning triage and afternoon. 1 reconciled via akashi_reconcile (strategic Xname002-substrate question, decision xterm007 supersedes both xid011 and xid012). 6 resolved as false_positive: 4 related_not_contradicting (xterm049, temporal-reassessment, xterm008 patterns), 2 unrelated_false_positive (xterm005 xterm050 on different xteam/xbranch017). 4 of 6 FPs involved admin/my decisions from earlier today — recent activity is the dominant driver of new conflict noise.</outcome> <parameter name=\"reasoning\">Two new FP categories surfaced that aren't covered by existing filters or by issue #PR008 (cross_agent_precedent_refinement). (1) Stale-precedent / xterm051: conflicts xterm052 paired my today's xterm053 against xterm009's pre-#PR002 PR — xterm009 wasn't wrong at trace time, the code xterm054 under them via PR #PR002. Same category as the original group 13 xterm055 case. Hard to detect without xterm026 inspection or a \"this precedent was later contradicted by code change\" signal. (2) isTemporalReassessment scope gap: conflict xterm056 had decision_type \"conflict_resolution\"/\"assessment\" rather than xteam/xbranch018, so the existing temporal-reassessment filter didn't fire. Two reports of FP rate at different windows (89% recent batch vs 51% lifetime) got flagged as contradiction. Easy fix — broaden the decision_type allowlist in isTemporalReassessment.  User explicitly xterm010 me to use akashi_reconcile for the strategic Xname002-substrate disagreement (\"there's an mcp tool for this!\"). The two positions actually overlap substantially — both want Xname009 abstraction, both want Xname002 supported. The narrow disagreement was xterm057Xname002-xterm058 (yes/no) and where the next 6-8 weeks of differentiation goes (substrate breadth vs orchestration layer). Synthesis took Xagent001's xterm059 infrastructure work (pool, instrumentation, abstraction interface, xterm002 xterm060) AND Xagent002's xterm061 argument (differentiation in orchestration above substrate) — these are complementary, not opposing. Self-hosting xterm032 as xterm062 rather than default substrate. Quarterly revisit closes the loop.  Confidence 0.72 because the reconciliation is grounded in inference, not numbers. I don't have unit economics data or named customer demand to validate the \"deferred until pulled\" framing; I framed it as a quarterly review condition specifically because that's the right shape for a decision the data should drive, not me.</parameter> <parameter name=\"task\">akashi conflict triage afternoon batch</parameter> <parameter name=\"evidence_snippets\">7 open conflict groups (10 individual) at start of session|||1 reconciled (xterm063 Xname002 substrate) via akashi_reconcile — decision xterm007 supersedes both originals|||6 resolved false_positive (4 related_not_contradicting + 2 unrelated_false_positive)|||4 of 6 FPs involved my own decisions from earlier today as admin agent|||2 new FP categories surfaced: xterm008 (intervening code change) and isTemporalReassessment decision_type scope gap|||user xterm010 toward akashi_reconcile rather than deferring on strategic question — instructive correction worth saving as feedback","decision_b":"Akashi conflict cleanup: triaged all 144 open conflict groups, resolved 110 (~76%) as false-positive or clean temporal supersession (open groups 144 to 34). Resolved the Xname002 xterm120 default conflict in favor of TICKET-X006 (xterm121) over TICKET-X007. Xname049 ashita-xteam/xbranch009#PR021 xterm122 an xterm123 gate to suppress xterm124 pairs before LLM scoring."}
{"pair_id":"pair_1265","gold_label":"related_not_contradicting","decision_type_a":"conflict_resolution","decision_type_b":"investigation","decision_a":"Triaged 15 open akashi conflict groups (19 individual scored conflicts) in the xterm017 window. Resolved 14 groups (18 individual conflicts): 16 marked false_positive (12 related_not_contradicting xteam/xbranch006/complementary pairs, 4 unrelated_false_positive xterm018 on shared vocabulary), 2 marked resolved with a clear winner (3a→Xagent001-code xterm019, confirmed xterm016 by 4a's Xname005 verification; group 6 supersession→newer empirical retest xid005). Left 1 group (xid006, xvendor001 storage parity scope) open as a real factual disagreement requiring xterm020 of pkg/xfile002.ext xterm021 at the relevant commit.</outcome> <parameter name=\"reasoning\">Read all 1,535 lines of the conflict export (full=true) via a subagent extraction. Adjudication grounded in the actual xteam/xbranch002 text of each pair plus the relationship field (only group 6 was tagged supersession; the rest were \"contradiction\"). Pattern of false positives is consistent: detector grouped on topic_similarity 0.70-0.83 but failed to discriminate (a) same-PR refinement chains where decision B explicitly addresses review findings on A, often within hours and frequently with xterm001 refining a Xagent001-code design (groups 1, 9, 12, 14a — exactly the pattern isCrossAgentPrecedentRefinement in group 10 was designed to suppress); (b) xterm022 pairs separated by weeks (groups 3b, 14c); (c) complementary work xterm023 the same design (groups 7, 8, 10); (d) xterm005 unrelated decisions (groups 2, 4, 14b, 15 — different xteam/xbranch007/functions). Real conflicts have a recognizable signature: same artifact (same ticket+PR), same time window, opposite empirical claims with citations on both sides — only group 3a fits cleanly. Group 13 is borderline (factual disagreement on whether xvendor001 storage replicates) but separated by 19 days and may reflect code change between 2026-05-03 and 2026-05-22 rather than agent disagreement. Detector quality: this 15-group sample shows ~11% xterm024 rate (2/19 individual), versus the rolling 30-day FP rate of 49.8% in stats — recent batches xterm025 than lifetime average. The two filters being designed in groups 10 and 11 (isCrossAgentPrecedentRefinement) would have caught at least 4 of these 17 FPs (groups 1, 9, 12, 14a — all explicit refinement chains). Confidence 0.78 because adjudication is based on stored xteam/xbranch002 text only; I did not re-read underlying code (e.g. pkg/xfile002.ext for group 13) so the \"leave open\" call on 13 is itself uncertain.</parameter> <parameter name=\"task\">akashi conflict triage and detector quality assessment","decision_b":"Do NOT run ENV_XVAR_001 to address the 44 open conflicts. Rescoring will not clear them — all 44 were detected 2026-06-17/18, after every xterm087 guardrail shipped (#PR018 4/10, #PR011 5/7, #PR019 5/9, #PR012/#PR005 5/13, #PR007 5/24, #PR004 6/10), so they already reflect current scoring logic. The actionable signal is the 30-day false-positive rate of 0.79, not stale scoring.</outcome> <parameter name=\"reasoning\">The recent conflict commits are xterm088 suppression guardrails in scoreForDecision; they run when a decision is scored, not retroactively. The only lever that xterm089 already-scored OPEN conflicts against newer structural guards is ForceConflictRescore (pkg/xfile008.ext -> ClearAllConflicts deletes status='open' only, preserving xteam/xbranch032, then ResetConflictScoredAt + BackfillScoring). That lever only helps if the open conflicts were scored by Xname015 code. They were not: the open conflicts carry the #PR004 ticket-context annotation ('Shared ticket references were available during validation'), and #PR004 (2026-06-10) is a xvendor006 descendant of all guardrail commits — so the running build that produced them necessarily included every suppression guardrail. Re-running identical code reproduces identical conflicts, minus LLM xterm090, plus fresh LLM spend, and discards the current xterm029 triage state. The real problem is live detection quality: FP rate 0.79 over 30 days (842 FP / 1063), 77% all-time (1006/1307), despite an 8-commit 2-month suppression campaign. The live queue confirms the guardrails miss the dominant patterns: 23/44 (52%) are Xagent001-code vs xterm001 xteam/xbranch033 chains (#PR007 only suppresses when an explicit precedent_ref link exists and there is no supersession vocab — these pairs either do not set the link or contain genuine reversal vocab), and 16/44 are operations conflicts on the Xname003 CDC incident that look like sequential remediation steps (rollback then restore) read as contradiction — a temporal FP class no guardrail covers.</parameter> <parameter name=\"alternatives\">[{\"label\":\"Run ENV_XVAR_001=true at startup to clear and re-score all open conflicts\",\"rejection_reason\":\"Conflicts are under 2 days old and were scored by current xterm091 code; xterm092 identical logic reproduces them while burning LLM calls and xterm093 the current xterm029 triage state\"},{\"label\":\"Treat it as a xterm014 problem and rely on ClearUnvalidatedConflicts xterm094 on boot\",\"rejection_reason\":\"That path only clears xterm095 open conflicts; these are already xterm096, so it is a no-op for them\"},{\"label\":\"Xname004-resolve all 44 as false_positive to clear the queue\",\"rejection_reason\":\"Some are genuine reversals (xterm001 reversed Xagent001-code's earlier decision) — those are true positives needing reconcile or xterm097, not FP labeling; blanket FP would corrupt the ground-truth signal used to tune the detector\"}]"}
{"pair_id":"pair_1788","gold_label":"related_not_contradicting","decision_type_a":"conflict_resolution","decision_type_b":"assessment","decision_a":"Triaged 15 open akashi conflict groups (19 individual scored conflicts) in the xterm017 window. Resolved 14 groups (18 individual conflicts): 16 marked false_positive (12 related_not_contradicting xteam/xbranch006/complementary pairs, 4 unrelated_false_positive xterm018 on shared vocabulary), 2 marked resolved with a clear winner (3a→Xagent001-code xterm019, confirmed xterm016 by 4a's Xname005 verification; group 6 supersession→newer empirical retest xid005). Left 1 group (xid006, xvendor001 storage parity scope) open as a real factual disagreement requiring xterm020 of pkg/xfile002.ext xterm021 at the relevant commit.</outcome> <parameter name=\"reasoning\">Read all 1,535 lines of the conflict export (full=true) via a subagent extraction. Adjudication grounded in the actual xteam/xbranch002 text of each pair plus the relationship field (only group 6 was tagged supersession; the rest were \"contradiction\"). Pattern of false positives is consistent: detector grouped on topic_similarity 0.70-0.83 but failed to discriminate (a) same-PR refinement chains where decision B explicitly addresses review findings on A, often within hours and frequently with xterm001 refining a Xagent001-code design (groups 1, 9, 12, 14a — exactly the pattern isCrossAgentPrecedentRefinement in group 10 was designed to suppress); (b) xterm022 pairs separated by weeks (groups 3b, 14c); (c) complementary work xterm023 the same design (groups 7, 8, 10); (d) xterm005 unrelated decisions (groups 2, 4, 14b, 15 — different xteam/xbranch007/functions). Real conflicts have a recognizable signature: same artifact (same ticket+PR), same time window, opposite empirical claims with citations on both sides — only group 3a fits cleanly. Group 13 is borderline (factual disagreement on whether xvendor001 storage replicates) but separated by 19 days and may reflect code change between 2026-05-03 and 2026-05-22 rather than agent disagreement. Detector quality: this 15-group sample shows ~11% xterm024 rate (2/19 individual), versus the rolling 30-day FP rate of 49.8% in stats — recent batches xterm025 than lifetime average. The two filters being designed in groups 10 and 11 (isCrossAgentPrecedentRefinement) would have caught at least 4 of these 17 FPs (groups 1, 9, 12, 14a — all explicit refinement chains). Confidence 0.78 because adjudication is based on stored xteam/xbranch002 text only; I did not re-read underlying code (e.g. pkg/xfile002.ext for group 13) so the \"leave open\" call on 13 is itself uncertain.</parameter> <parameter name=\"task\">akashi conflict triage and detector quality assessment","decision_b":"Akashi conflict cleanup: triaged all 144 open conflict groups, resolved 110 (~76%) as false-positive or clean temporal supersession (open groups 144 to 34). Resolved the Xname002 xterm120 default conflict in favor of TICKET-X006 (xterm121) over TICKET-X007. Xname049 ashita-xteam/xbranch009#PR021 xterm122 an xterm123 gate to suppress xterm124 pairs before LLM scoring."}
{"pair_id":"pair_1864","gold_label":"related_not_contradicting","decision_type_a":"conflict_resolution","decision_type_b":"assessment","decision_a":"Resolved all 7 open akashi conflict groups (10 individual scored conflicts) created between 2026-05-24 morning triage and afternoon. 1 reconciled via akashi_reconcile (strategic Xname002-substrate question, decision xterm007 supersedes both xid011 and xid012). 6 resolved as false_positive: 4 related_not_contradicting (xterm049, temporal-reassessment, xterm008 patterns), 2 unrelated_false_positive (xterm005 xterm050 on different xteam/xbranch017). 4 of 6 FPs involved admin/my decisions from earlier today — recent activity is the dominant driver of new conflict noise.</outcome> <parameter name=\"reasoning\">Two new FP categories surfaced that aren't covered by existing filters or by issue #PR008 (cross_agent_precedent_refinement). (1) Stale-precedent / xterm051: conflicts xterm052 paired my today's xterm053 against xterm009's pre-#PR002 PR — xterm009 wasn't wrong at trace time, the code xterm054 under them via PR #PR002. Same category as the original group 13 xterm055 case. Hard to detect without xterm026 inspection or a \"this precedent was later contradicted by code change\" signal. (2) isTemporalReassessment scope gap: conflict xterm056 had decision_type \"conflict_resolution\"/\"assessment\" rather than xteam/xbranch018, so the existing temporal-reassessment filter didn't fire. Two reports of FP rate at different windows (89% recent batch vs 51% lifetime) got flagged as contradiction. Easy fix — broaden the decision_type allowlist in isTemporalReassessment.  User explicitly xterm010 me to use akashi_reconcile for the strategic Xname002-substrate disagreement (\"there's an mcp tool for this!\"). The two positions actually overlap substantially — both want Xname009 abstraction, both want Xname002 supported. The narrow disagreement was xterm057Xname002-xterm058 (yes/no) and where the next 6-8 weeks of differentiation goes (substrate breadth vs orchestration layer). Synthesis took Xagent001's xterm059 infrastructure work (pool, instrumentation, abstraction interface, xterm002 xterm060) AND Xagent002's xterm061 argument (differentiation in orchestration above substrate) — these are complementary, not opposing. Self-hosting xterm032 as xterm062 rather than default substrate. Quarterly revisit closes the loop.  Confidence 0.72 because the reconciliation is grounded in inference, not numbers. I don't have unit economics data or named customer demand to validate the \"deferred until pulled\" framing; I framed it as a quarterly review condition specifically because that's the right shape for a decision the data should drive, not me.</parameter> <parameter name=\"task\">akashi conflict triage afternoon batch</parameter> <parameter name=\"evidence_snippets\">7 open conflict groups (10 individual) at start of session|||1 reconciled (xterm063 Xname002 substrate) via akashi_reconcile — decision xterm007 supersedes both originals|||6 resolved false_positive (4 related_not_contradicting + 2 unrelated_false_positive)|||4 of 6 FPs involved my own decisions from earlier today as admin agent|||2 new FP categories surfaced: xterm008 (intervening code change) and isTemporalReassessment decision_type scope gap|||user xterm010 toward akashi_reconcile rather than deferring on strategic question — instructive correction worth saving as feedback","decision_b":"PR-informed mono conflict cleanup resolved 61 scored conflicts and left 10 open conflict groups where recent PR metadata was insufficient to safely pick a winner."}
{"pair_id":"pair_2489","gold_label":"related_not_contradicting","decision_type_a":"conflict_resolution","decision_type_b":"assessment","decision_a":"Triaged 15 open akashi conflict groups (19 individual scored conflicts) in the xterm017 window. Resolved 14 groups (18 individual conflicts): 16 marked false_positive (12 related_not_contradicting xteam/xbranch006/complementary pairs, 4 unrelated_false_positive xterm018 on shared vocabulary), 2 marked resolved with a clear winner (3a→Xagent001-code xterm019, confirmed xterm016 by 4a's Xname005 verification; group 6 supersession→newer empirical retest xid005). Left 1 group (xid006, xvendor001 storage parity scope) open as a real factual disagreement requiring xterm020 of pkg/xfile002.ext xterm021 at the relevant commit.</outcome> <parameter name=\"reasoning\">Read all 1,535 lines of the conflict export (full=true) via a subagent extraction. Adjudication grounded in the actual xteam/xbranch002 text of each pair plus the relationship field (only group 6 was tagged supersession; the rest were \"contradiction\"). Pattern of false positives is consistent: detector grouped on topic_similarity 0.70-0.83 but failed to discriminate (a) same-PR refinement chains where decision B explicitly addresses review findings on A, often within hours and frequently with xterm001 refining a Xagent001-code design (groups 1, 9, 12, 14a — exactly the pattern isCrossAgentPrecedentRefinement in group 10 was designed to suppress); (b) xterm022 pairs separated by weeks (groups 3b, 14c); (c) complementary work xterm023 the same design (groups 7, 8, 10); (d) xterm005 unrelated decisions (groups 2, 4, 14b, 15 — different xteam/xbranch007/functions). Real conflicts have a recognizable signature: same artifact (same ticket+PR), same time window, opposite empirical claims with citations on both sides — only group 3a fits cleanly. Group 13 is borderline (factual disagreement on whether xvendor001 storage replicates) but separated by 19 days and may reflect code change between 2026-05-03 and 2026-05-22 rather than agent disagreement. Detector quality: this 15-group sample shows ~11% xterm024 rate (2/19 individual), versus the rolling 30-day FP rate of 49.8% in stats — recent batches xterm025 than lifetime average. The two filters being designed in groups 10 and 11 (isCrossAgentPrecedentRefinement) would have caught at least 4 of these 17 FPs (groups 1, 9, 12, 14a — all explicit refinement chains). Confidence 0.78 because adjudication is based on stored xteam/xbranch002 text only; I did not re-read underlying code (e.g. pkg/xfile002.ext for group 13) so the \"leave open\" call on 13 is itself uncertain.</parameter> <parameter name=\"task\">akashi conflict triage and detector quality assessment","decision_b":"PR-informed mono conflict cleanup resolved 61 scored conflicts and left 10 open conflict groups where recent PR metadata was insufficient to safely pick a winner."}
{"pair_id":"pair_1802","gold_label":"supersession","decision_type_a":"assessment","decision_type_b":"assessment","decision_a":"PR-informed mono conflict cleanup resolved 61 scored conflicts and left 10 open conflict groups where recent PR metadata was insufficient to safely pick a winner.","decision_b":"Akashi conflict cleanup: triaged all 144 open conflict groups, resolved 110 (~76%) as false-positive or clean temporal supersession (open groups 144 to 34). Resolved the Xname002 xterm120 default conflict in favor of TICKET-X006 (xterm121) over TICKET-X007. Xname049 ashita-xteam/xbranch009#PR021 xterm122 an xterm123 gate to suppress xterm124 pairs before LLM scoring."}
{"pair_id":"pair_2463","gold_label":"supersession","decision_type_a":"architecture","decision_type_b":"code_review","decision_a":"Fixed 6 issues in xterm296FP PR: (1) Added migration 080 for integrity_audit_results immutability triggers + CASCADE→RESTRICT on proof_id FK, matching the pattern from migration 079. (2) Added retry with exponential backoff to persistViolation — 3 attempts, 500ms→1s→2s backoff, xterm297 UUID for idempotency. (3) Added FalsePositiveLabel field to ConflictGroupResolveRequest and wired it through HandleResolveConflictGroup handler. (4) Changed ListConflictsByDecisionIDs to return BatchConflictsResult with GlobalTruncated flag, wired through to enrichment handler to set conflictsDegraded when global cap is hit. (5) Switched xteam/xbranch120 from plain bools to xteam/xbranch121 to prevent data races if errgroup goroutines are xterm298. (6) All pre-commit checks pass, all 22 test packages pass with -race.","decision_b":"Fixed the xterm125 pollution on the xterm186 branch by making ground-truth labeling xterm299 and xterm300: only deliberate adjudications (an actor resolving via API/MCP with a declared winner) write a 'genuine' label. autoresolve now passes nil, CascadeResolveByOutcome reverted to a plain UPDATE (no label insert), the invariant is documented on ComputeResolutionLabel, and added pkg/xfile055.ext unit coverage."}
{"pair_id":"pair_2056","gold_label":"related_not_contradicting","decision_type_a":"conflict_resolution","decision_type_b":"investigation","decision_a":"Triaged 15 open akashi conflict groups (19 individual scored conflicts) in the xterm017 window. Resolved 14 groups (18 individual conflicts): 16 marked false_positive (12 related_not_contradicting xteam/xbranch006/complementary pairs, 4 unrelated_false_positive xterm018 on shared vocabulary), 2 marked resolved with a clear winner (3a→Xagent001-code xterm019, confirmed xterm016 by 4a's Xname005 verification; group 6 supersession→newer empirical retest xid005). Left 1 group (xid006, xvendor001 storage parity scope) open as a real factual disagreement requiring xterm020 of pkg/xfile002.ext xterm021 at the relevant commit.</outcome> <parameter name=\"reasoning\">Read all 1,535 lines of the conflict export (full=true) via a subagent extraction. Adjudication grounded in the actual xteam/xbranch002 text of each pair plus the relationship field (only group 6 was tagged supersession; the rest were \"contradiction\"). Pattern of false positives is consistent: detector grouped on topic_similarity 0.70-0.83 but failed to discriminate (a) same-PR refinement chains where decision B explicitly addresses review findings on A, often within hours and frequently with xterm001 refining a Xagent001-code design (groups 1, 9, 12, 14a — exactly the pattern isCrossAgentPrecedentRefinement in group 10 was designed to suppress); (b) xterm022 pairs separated by weeks (groups 3b, 14c); (c) complementary work xterm023 the same design (groups 7, 8, 10); (d) xterm005 unrelated decisions (groups 2, 4, 14b, 15 — different xteam/xbranch007/functions). Real conflicts have a recognizable signature: same artifact (same ticket+PR), same time window, opposite empirical claims with citations on both sides — only group 3a fits cleanly. Group 13 is borderline (factual disagreement on whether xvendor001 storage replicates) but separated by 19 days and may reflect code change between 2026-05-03 and 2026-05-22 rather than agent disagreement. Detector quality: this 15-group sample shows ~11% xterm024 rate (2/19 individual), versus the rolling 30-day FP rate of 49.8% in stats — recent batches xterm025 than lifetime average. The two filters being designed in groups 10 and 11 (isCrossAgentPrecedentRefinement) would have caught at least 4 of these 17 FPs (groups 1, 9, 12, 14a — all explicit refinement chains). Confidence 0.78 because adjudication is based on stored xteam/xbranch002 text only; I did not re-read underlying code (e.g. pkg/xfile002.ext for group 13) so the \"leave open\" call on 13 is itself uncertain.</parameter> <parameter name=\"task\">akashi conflict triage and detector quality assessment","decision_b":"The 22 Xagent001-code vs xterm001 open conflict groups (40 individual, all scoring_method=xterm006) are NOT xterm033 refinement false positives. 21 of 22 share no ticket; xteam/xbranch003 cannot suppress them because both refinement filters require identical extractTicketRef and isTemporalReassessment only fires on reviewTypes. ~17 are false positives from cross-ticket xterm027 over-clustering on one hot subsystem (xteam/xbranch014/Xname003 CDC); ~5 are genuine, dominated by the real Xname001-vs-xterm002 architectural fork. Rescore is the wrong lever; the source fix is a xteam/xbranch015 suppressor for xterm035 decision types, not agent xterm036.</outcome> <parameter name=\"reasoning\">Xname008 all 44 open conflicts in full, isolated the 22 Xagent001-code<->xterm001 groups. All are scoring_method=xterm006 (not xterm014; ClearUnvalidatedConflicts is a no-op for them). 21/22 share no ticket. Read the predicates: isSameAgentSameTicketRefinement (pkg/xfile004.ext) and isCrossAgentPrecedentRefinement (pkg/xfile005.ext) both end with refA == extractTicketRef(cand) so they bail unless ticket refs are identical, regardless of precedent_ref — my xterm037 suggestion to fix this by setting links is therefore wrong. isTemporalReassessment (pkg/xfile006.ext) requires BOTH decisions in reviewTypes {code_review, assessment, investigation, review, analysis, audit}; this cluster is xteam/xbranch004/xteam/xbranch023 so it never fires. Root cause is topic-similarity over-clustering (topic_sim 0.70-0.85 from shared subsystem vocabulary) feeding the LLM validator, which returns CONTRADICTION on sequential xterm038 steps and even agreeing decisions. N×N explosion: Xagent002 xterm011 alone spawned 5 FP groups against 5 prior Xagent001 recovery steps. Genuine signal buried in the noise: Xagent001 xterm039 (recommend AGAINST Xname001) vs Xagent002 xid008/xid009/xid010 (xteam/xbranch034 Xname001, TICKET-X002/1587/1595) is a real unresolved architectural disagreement that should be reconciled. A parallel Xagent001-code agent is independently xterm040 the same queue and reached a directionally consistent conclusion (mostly related_not_contradicting FPs).</parameter> <parameter name=\"alternatives\">[{\"label\":\"Suppress the cluster by having agents set xteam/xbranch003\",\"rejection_reason\":\"Refinement filters gate on identical ticket ref; 21/22 pairs are cross-ticket so links are inert\"},{\"label\":\"Xname004-mark all 22 groups false_positive\",\"rejection_reason\":\"~5 are genuine (Xname001 fork, TICKET-X001 review bug); blanket FP corrupts ground truth and xterm098 a real disagreement\"},{\"label\":\"Extend isTemporalReassessment to xteam/xbranch004 types\",\"rejection_reason\":\"Right direction but its xterm041 xterm099 logic does not model operational state progression; needs a sibling predicate keyed on xterm042 + temporal separation + no contradicting xterm043\"}]"}
{"pair_id":"pair_2439","gold_label":"related_not_contradicting","decision_type_a":"conflict_resolution","decision_type_b":"investigation","decision_a":"Triaged 15 open akashi conflict groups (19 individual scored conflicts) in the xterm017 window. Resolved 14 groups (18 individual conflicts): 16 marked false_positive (12 related_not_contradicting xteam/xbranch006/complementary pairs, 4 unrelated_false_positive xterm018 on shared vocabulary), 2 marked resolved with a clear winner (3a→Xagent001-code xterm019, confirmed xterm016 by 4a's Xname005 verification; group 6 supersession→newer empirical retest xid005). Left 1 group (xid006, xvendor001 storage parity scope) open as a real factual disagreement requiring xterm020 of pkg/xfile002.ext xterm021 at the relevant commit.</outcome> <parameter name=\"reasoning\">Read all 1,535 lines of the conflict export (full=true) via a subagent extraction. Adjudication grounded in the actual xteam/xbranch002 text of each pair plus the relationship field (only group 6 was tagged supersession; the rest were \"contradiction\"). Pattern of false positives is consistent: detector grouped on topic_similarity 0.70-0.83 but failed to discriminate (a) same-PR refinement chains where decision B explicitly addresses review findings on A, often within hours and frequently with xterm001 refining a Xagent001-code design (groups 1, 9, 12, 14a — exactly the pattern isCrossAgentPrecedentRefinement in group 10 was designed to suppress); (b) xterm022 pairs separated by weeks (groups 3b, 14c); (c) complementary work xterm023 the same design (groups 7, 8, 10); (d) xterm005 unrelated decisions (groups 2, 4, 14b, 15 — different xteam/xbranch007/functions). Real conflicts have a recognizable signature: same artifact (same ticket+PR), same time window, opposite empirical claims with citations on both sides — only group 3a fits cleanly. Group 13 is borderline (factual disagreement on whether xvendor001 storage replicates) but separated by 19 days and may reflect code change between 2026-05-03 and 2026-05-22 rather than agent disagreement. Detector quality: this 15-group sample shows ~11% xterm024 rate (2/19 individual), versus the rolling 30-day FP rate of 49.8% in stats — recent batches xterm025 than lifetime average. The two filters being designed in groups 10 and 11 (isCrossAgentPrecedentRefinement) would have caught at least 4 of these 17 FPs (groups 1, 9, 12, 14a — all explicit refinement chains). Confidence 0.78 because adjudication is based on stored xteam/xbranch002 text only; I did not re-read underlying code (e.g. pkg/xfile002.ext for group 13) so the \"leave open\" call on 13 is itself uncertain.</parameter> <parameter name=\"task\">akashi conflict triage and detector quality assessment","decision_b":"Do NOT run ENV_XVAR_001 to address the 44 open conflicts. Rescoring will not clear them — all 44 were detected 2026-06-17/18, after every xterm087 guardrail shipped (#PR018 4/10, #PR011 5/7, #PR019 5/9, #PR012/#PR005 5/13, #PR007 5/24, #PR004 6/10), so they already reflect current scoring logic. The actionable signal is the 30-day false-positive rate of 0.79, not stale scoring.</outcome> <parameter name=\"reasoning\">The recent conflict commits are xterm088 suppression guardrails in scoreForDecision; they run when a decision is scored, not retroactively. The only lever that xterm089 already-scored OPEN conflicts against newer structural guards is ForceConflictRescore (pkg/xfile008.ext → ClearAllConflicts deletes status='open' only, preserving xteam/xbranch032, then ResetConflictScoredAt + BackfillScoring). That lever only helps if open conflicts were scored by Xname015 code. They were not: the open conflicts carry the #PR004 ticket-context annotation ('Shared ticket references were available during validation'), and #PR004 (6/10) is a xvendor006 descendant of all guardrail commits — so the running build that produced them necessarily included every suppression guardrail. Re-running identical code reproduces identical conflicts, minus LLM xterm090, plus fresh LLM spend, and discards the current xterm029 triage state. The real problem is live detection quality: FP rate 0.79 over 30 days (842 FP / 1063), 77% all-time (1006/1307), despite an 8-commit, 2-month suppression campaign. The live queue confirms the guardrails miss the dominant patterns: 23/44 (52%) are Xagent001-code vs xterm001 xteam/xbranch033 chains (#PR007 only suppresses when an explicit precedent_ref link exists and no supersession vocab — these pairs either don't set the link or contain genuine reversal vocab), and 16/44 are operations conflicts on the Xname003 CDC incident that look like sequential remediation steps (rollback then restore) read as contradiction — a temporal FP class no guardrail covers.</reasoning> <parameter name=\"alternatives\">[{\"label\":\"Run ENV_XVAR_001=true at startup to clear and re-score all open conflicts\",\"rejection_reason\":\"Conflicts are <2 days old and were scored by current (xterm091) code; xterm092 identical logic reproduces them while burning LLM calls and xterm093 the current xterm029 triage state\"},{\"label\":\"Treat it as a xterm014 problem and rely on ClearUnvalidatedConflicts xterm094\",\"rejection_reason\":\"That path only clears xterm095 open conflicts on boot; these are already xterm096, so it is a no-op for them\"},{\"label\":\"Xname004-resolve all 44 as false_positive to clear the queue\",\"rejection_reason\":\"Some are genuine reversals (xterm001 reversed Xagent001-code's earlier decision) — those are true positives needing xteam/xbranch056, not FP labeling; blanket FP would corrupt the ground-truth signal used to tune the detector\"}]"}
{"pair_id":"pair_1645","gold_label":"related_not_contradicting","decision_type_a":"investigation","decision_type_b":"conflict_resolution","decision_a":"Do NOT run ENV_XVAR_001 to address the 44 open conflicts. Rescoring will not clear them — all 44 were detected 2026-06-17/18, after every xterm087 guardrail shipped (#PR018 4/10, #PR011 5/7, #PR019 5/9, #PR012/#PR005 5/13, #PR007 5/24, #PR004 6/10), so they already reflect current scoring logic. The actionable signal is the 30-day false-positive rate of 0.79, not stale scoring.</outcome> <parameter name=\"reasoning\">The recent conflict commits are xterm088 suppression guardrails in scoreForDecision; they run when a decision is scored, not retroactively. The only lever that xterm089 already-scored OPEN conflicts against newer structural guards is ForceConflictRescore (pkg/xfile008.ext -> ClearAllConflicts deletes status='open' only, preserving xteam/xbranch032, then ResetConflictScoredAt + BackfillScoring). That lever only helps if the open conflicts were scored by Xname015 code. They were not: the open conflicts carry the #PR004 ticket-context annotation ('Shared ticket references were available during validation'), and #PR004 (2026-06-10) is a xvendor006 descendant of all guardrail commits — so the running build that produced them necessarily included every suppression guardrail. Re-running identical code reproduces identical conflicts, minus LLM xterm090, plus fresh LLM spend, and discards the current xterm029 triage state. The real problem is live detection quality: FP rate 0.79 over 30 days (842 FP / 1063), 77% all-time (1006/1307), despite an 8-commit 2-month suppression campaign. The live queue confirms the guardrails miss the dominant patterns: 23/44 (52%) are Xagent001-code vs xterm001 xteam/xbranch033 chains (#PR007 only suppresses when an explicit precedent_ref link exists and there is no supersession vocab — these pairs either do not set the link or contain genuine reversal vocab), and 16/44 are operations conflicts on the Xname003 CDC incident that look like sequential remediation steps (rollback then restore) read as contradiction — a temporal FP class no guardrail covers.</parameter> <parameter name=\"alternatives\">[{\"label\":\"Run ENV_XVAR_001=true at startup to clear and re-score all open conflicts\",\"rejection_reason\":\"Conflicts are under 2 days old and were scored by current xterm091 code; xterm092 identical logic reproduces them while burning LLM calls and xterm093 the current xterm029 triage state\"},{\"label\":\"Treat it as a xterm014 problem and rely on ClearUnvalidatedConflicts xterm094 on boot\",\"rejection_reason\":\"That path only clears xterm095 open conflicts; these are already xterm096, so it is a no-op for them\"},{\"label\":\"Xname004-resolve all 44 as false_positive to clear the queue\",\"rejection_reason\":\"Some are genuine reversals (xterm001 reversed Xagent001-code's earlier decision) — those are true positives needing reconcile or xterm097, not FP labeling; blanket FP would corrupt the ground-truth signal used to tune the detector\"}]","decision_b":"Resolved all 7 open akashi conflict groups (10 individual scored conflicts) created between 2026-05-24 morning triage and afternoon. 1 reconciled via akashi_reconcile (strategic Xname002-substrate question, decision xterm007 supersedes both xid011 and xid012). 6 resolved as false_positive: 4 related_not_contradicting (xterm049, temporal-reassessment, xterm008 patterns), 2 unrelated_false_positive (xterm005 xterm050 on different xteam/xbranch017). 4 of 6 FPs involved admin/my decisions from earlier today — recent activity is the dominant driver of new conflict noise.</outcome> <parameter name=\"reasoning\">Two new FP categories surfaced that aren't covered by existing filters or by issue #PR008 (cross_agent_precedent_refinement). (1) Stale-precedent / xterm051: conflicts xterm052 paired my today's xterm053 against xterm009's pre-#PR002 PR — xterm009 wasn't wrong at trace time, the code xterm054 under them via PR #PR002. Same category as the original group 13 xterm055 case. Hard to detect without xterm026 inspection or a \"this precedent was later contradicted by code change\" signal. (2) isTemporalReassessment scope gap: conflict xterm056 had decision_type \"conflict_resolution\"/\"assessment\" rather than xteam/xbranch018, so the existing temporal-reassessment filter didn't fire. Two reports of FP rate at different windows (89% recent batch vs 51% lifetime) got flagged as contradiction. Easy fix — broaden the decision_type allowlist in isTemporalReassessment.  User explicitly xterm010 me to use akashi_reconcile for the strategic Xname002-substrate disagreement (\"there's an mcp tool for this!\"). The two positions actually overlap substantially — both want Xname009 abstraction, both want Xname002 supported. The narrow disagreement was xterm057Xname002-xterm058 (yes/no) and where the next 6-8 weeks of differentiation goes (substrate breadth vs orchestration layer). Synthesis took Xagent001's xterm059 infrastructure work (pool, instrumentation, abstraction interface, xterm002 xterm060) AND Xagent002's xterm061 argument (differentiation in orchestration above substrate) — these are complementary, not opposing. Self-hosting xterm032 as xterm062 rather than default substrate. Quarterly revisit closes the loop.  Confidence 0.72 because the reconciliation is grounded in inference, not numbers. I don't have unit economics data or named customer demand to validate the \"deferred until pulled\" framing; I framed it as a quarterly review condition specifically because that's the right shape for a decision the data should drive, not me.</parameter> <parameter name=\"task\">akashi conflict triage afternoon batch</parameter> <parameter name=\"evidence_snippets\">7 open conflict groups (10 individual) at start of session|||1 reconciled (xterm063 Xname002 substrate) via akashi_reconcile — decision xterm007 supersedes both originals|||6 resolved false_positive (4 related_not_contradicting + 2 unrelated_false_positive)|||4 of 6 FPs involved my own decisions from earlier today as admin agent|||2 new FP categories surfaced: xterm008 (intervening code change) and isTemporalReassessment decision_type scope gap|||user xterm010 toward akashi_reconcile rather than deferring on strategic question — instructive correction worth saving as feedback"}
{"pair_id":"pair_0569","gold_label":"supersession","decision_type_a":"strategic","decision_type_b":"trade_off","decision_a":"Recommended Xname040's next blog direction: lead with an xterm302 post built on akashi's own fleet telemetry (2,798 decisions / 51 agents; ~79% conflict false-positive rate; confidence uncorrelated with outcome; 72% of decisions never cited) as the xterm303 payoff to The Alarm Budget, plus fresh xterm304 (maritime Xname041 load line, mission command, market circuit breakers) and new formats (xterm305 post-mortem, prediction xterm306). Graphics: xterm126 austere editorial SVG, not AI illustration.","decision_b":"Drafted \"Confidence Is Not a Signal\" (_posts/2026-06-18, 2,416 words). Key editorial judgment: did NOT make the planned 'my fleet shows confidence is xterm139 from outcome' claim. Instead the fleet exhibit is (a) the xterm140 distribution is a clustered spike (median 0.80, >75% in 0.70–0.90) and (b) the confession that the tool reported 'calibrated: true' on a ~3%-assessed sample. Spine: confidence becomes a signal only when scored against outcomes (xteam/xbranch057, calibrated; xteam/xbranch058, not). Two xterm126 Xname020 (fleet histogram; NWS reliability diagram). All 14 citations verified against primary sources before writing."}
{"pair_id":"pair_1708","gold_label":"related_not_contradicting","decision_type_a":"conflict_resolution","decision_type_b":"investigation","decision_a":"Triaged 15 open akashi conflict groups (19 individual scored conflicts) in the xterm017 window. Resolved 14 groups (18 individual conflicts): 16 marked false_positive (12 related_not_contradicting xteam/xbranch006/complementary pairs, 4 unrelated_false_positive xterm018 on shared vocabulary), 2 marked resolved with a clear winner (3a→Xagent001-code xterm019, confirmed xterm016 by 4a's Xname005 verification; group 6 supersession→newer empirical retest xid005). Left 1 group (xid006, xvendor001 storage parity scope) open as a real factual disagreement requiring xterm020 of pkg/xfile002.ext xterm021 at the relevant commit.</outcome> <parameter name=\"reasoning\">Read all 1,535 lines of the conflict export (full=true) via a subagent extraction. Adjudication grounded in the actual xteam/xbranch002 text of each pair plus the relationship field (only group 6 was tagged supersession; the rest were \"contradiction\"). Pattern of false positives is consistent: detector grouped on topic_similarity 0.70-0.83 but failed to discriminate (a) same-PR refinement chains where decision B explicitly addresses review findings on A, often within hours and frequently with xterm001 refining a Xagent001-code design (groups 1, 9, 12, 14a — exactly the pattern isCrossAgentPrecedentRefinement in group 10 was designed to suppress); (b) xterm022 pairs separated by weeks (groups 3b, 14c); (c) complementary work xterm023 the same design (groups 7, 8, 10); (d) xterm005 unrelated decisions (groups 2, 4, 14b, 15 — different xteam/xbranch007/functions). Real conflicts have a recognizable signature: same artifact (same ticket+PR), same time window, opposite empirical claims with citations on both sides — only group 3a fits cleanly. Group 13 is borderline (factual disagreement on whether xvendor001 storage replicates) but separated by 19 days and may reflect code change between 2026-05-03 and 2026-05-22 rather than agent disagreement. Detector quality: this 15-group sample shows ~11% xterm024 rate (2/19 individual), versus the rolling 30-day FP rate of 49.8% in stats — recent batches xterm025 than lifetime average. The two filters being designed in groups 10 and 11 (isCrossAgentPrecedentRefinement) would have caught at least 4 of these 17 FPs (groups 1, 9, 12, 14a — all explicit refinement chains). Confidence 0.78 because adjudication is based on stored xteam/xbranch002 text only; I did not re-read underlying code (e.g. pkg/xfile002.ext for group 13) so the \"leave open\" call on 13 is itself uncertain.</parameter> <parameter name=\"task\">akashi conflict triage and detector quality assessment","decision_b":"The Xagent001-code vs xterm001 open conflicts (22 groups / 40 individual, all scoring_method=xterm006) are NOT xterm033 refinement false positives. 21 of 22 share no ticket; setting xteam/xbranch003 cannot suppress them because both refinement filters (isSameAgentSameTicketRefinement, isCrossAgentPrecedentRefinement) require identical extractTicketRef on both sides, and isTemporalReassessment only fires when both decisions are reviewTypes {code_review, assessment, investigation, review, analysis, audit}. ~17 are false positives from cross-ticket xterm027 over-clustering on one hot subsystem (xteam/xbranch014/Xname003 CDC); ~5 are genuine, dominated by the real Xname001-vs-xterm002 architectural fork. Confirms: rescore is the wrong lever; the source fix is a xteam/xbranch015 suppressor for xterm035 types, not agent xterm036.</outcome> <parameter name=\"reasoning\">Xname008 all 44 open conflicts in full and isolated the 22 Xagent001-code<->xterm001 groups (40 individual). Every one is scoring_method=xterm006, so they are not xterm014 artifacts and ClearUnvalidatedConflicts will not touch them. 21 of 22 share no ticket reference (the lone exception, TICKET-X001, is a legitimate xterm127 bug). Read the suppression predicates: isSameAgentSameTicketRefinement (pkg/xfile004.ext) and isCrossAgentPrecedentRefinement (pkg/xfile005.ext) both end with refA == extractTicketRef(cand) — they bail unless the extracted ticket refs are identical, regardless of precedent_ref. So my xterm037 suggestion to fix this cluster by getting agents to set xteam/xbranch003 is wrong: the xterm128 gate makes links inert here. isTemporalReassessment (pkg/xfile006.ext) requires BOTH decisions in reviewTypes {code_review, assessment, investigation, review, analysis, audit}; the cluster is xteam/xbranch004/xteam/xbranch047/xteam/xbranch028, so it never fires. Root cause is topic-similarity over-clustering (topic_sim 0.70-0.85 from shared subsystem vocabulary: xteam/xbranch048/xteam/xbranch049/CDC) feeding the LLM validator, which then returns CONTRADICTION on sequential xterm038 steps and even agreeing decisions. N×N explosion: Xagent002 decision xterm011 ('paused Xname003 xterm012 target writer') alone spawned 5 FP groups against 5 different prior Xagent001 recovery steps. Genuine signal buried in the noise: Xagent001 xterm039 (2026-06-15, 'recommend AGAINST replacing xterm002 with Xname001') vs Xagent002 xid008/xid009/xid010 (2026-06-18, TICKET-X002/1587/1595 xteam/xbranch050 Xname001) is a real unresolved architectural disagreement akashi correctly detected — it should be reconciled, not suppressed. A parallel Xagent001-code agent is independently xterm040 the same queue (resolved 14 groups, 16 false_positive, 12 related_not_contradicting) and reports ~49.8% FP on recent batches — directionally consistent with this finding.</parameter> <parameter name=\"alternatives\">[{\"label\":\"Suppress the cluster by having agents set xteam/xbranch003 between the conflicting decisions\",\"rejection_reason\":\"Both refinement filters gate on identical extracted ticket ref; 21/22 pairs are cross-ticket, so links are inert — the guard bails before the precedent check matters\"},{\"label\":\"Xname004-mark all 22 groups false_positive\",\"rejection_reason\":\"~5 are genuine (the Xname001-vs-xterm002 fork and the TICKET-X001 review bug); blanket FP would corrupt ground truth and bury a real architectural disagreement that needs reconcile\"},{\"label\":\"Extend isTemporalReassessment to cover xteam/xbranch004 types\",\"rejection_reason\":\"Right direction and the highest-leverage fix, but its xterm041 window logic assumes re-measurement of metrics; operational state progression needs its own predicate keyed on xterm042 + temporal separation + no contradicting xterm043, so it is a sibling, not a parameter tweak\"}]"}
{"pair_id":"pair_0433","gold_label":"related_not_contradicting","decision_type_a":"conflict_resolution","decision_type_b":"investigation","decision_a":"Resolved all 7 open akashi conflict groups (10 individual scored conflicts) created between 2026-05-24 morning triage and afternoon. 1 reconciled via akashi_reconcile (strategic Xname002-substrate question, decision xterm007 supersedes both xid011 and xid012). 6 resolved as false_positive: 4 related_not_contradicting (xterm049, temporal-reassessment, xterm008 patterns), 2 unrelated_false_positive (xterm005 xterm050 on different xteam/xbranch017). 4 of 6 FPs involved admin/my decisions from earlier today — recent activity is the dominant driver of new conflict noise.</outcome> <parameter name=\"reasoning\">Two new FP categories surfaced that aren't covered by existing filters or by issue #PR008 (cross_agent_precedent_refinement). (1) Stale-precedent / xterm051: conflicts xterm052 paired my today's xterm053 against xterm009's pre-#PR002 PR — xterm009 wasn't wrong at trace time, the code xterm054 under them via PR #PR002. Same category as the original group 13 xterm055 case. Hard to detect without xterm026 inspection or a \"this precedent was later contradicted by code change\" signal. (2) isTemporalReassessment scope gap: conflict xterm056 had decision_type \"conflict_resolution\"/\"assessment\" rather than xteam/xbranch018, so the existing temporal-reassessment filter didn't fire. Two reports of FP rate at different windows (89% recent batch vs 51% lifetime) got flagged as contradiction. Easy fix — broaden the decision_type allowlist in isTemporalReassessment.  User explicitly xterm010 me to use akashi_reconcile for the strategic Xname002-substrate disagreement (\"there's an mcp tool for this!\"). The two positions actually overlap substantially — both want Xname009 abstraction, both want Xname002 supported. The narrow disagreement was xterm057Xname002-xterm058 (yes/no) and where the next 6-8 weeks of differentiation goes (substrate breadth vs orchestration layer). Synthesis took Xagent001's xterm059 infrastructure work (pool, instrumentation, abstraction interface, xterm002 xterm060) AND Xagent002's xterm061 argument (differentiation in orchestration above substrate) — these are complementary, not opposing. Self-hosting xterm032 as xterm062 rather than default substrate. Quarterly revisit closes the loop.  Confidence 0.72 because the reconciliation is grounded in inference, not numbers. I don't have unit economics data or named customer demand to validate the \"deferred until pulled\" framing; I framed it as a quarterly review condition specifically because that's the right shape for a decision the data should drive, not me.</parameter> <parameter name=\"task\">akashi conflict triage afternoon batch</parameter> <parameter name=\"evidence_snippets\">7 open conflict groups (10 individual) at start of session|||1 reconciled (xterm063 Xname002 substrate) via akashi_reconcile — decision xterm007 supersedes both originals|||6 resolved false_positive (4 related_not_contradicting + 2 unrelated_false_positive)|||4 of 6 FPs involved my own decisions from earlier today as admin agent|||2 new FP categories surfaced: xterm008 (intervening code change) and isTemporalReassessment decision_type scope gap|||user xterm010 toward akashi_reconcile rather than deferring on strategic question — instructive correction worth saving as feedback","decision_b":"The Xagent001-code vs xterm001 open conflicts (22 groups / 40 individual, all scoring_method=xterm006) are NOT xterm033 refinement false positives. 21 of 22 share no ticket; setting xteam/xbranch003 cannot suppress them because both refinement filters (isSameAgentSameTicketRefinement, isCrossAgentPrecedentRefinement) require identical extractTicketRef on both sides, and isTemporalReassessment only fires when both decisions are reviewTypes {code_review, assessment, investigation, review, analysis, audit}. ~17 are false positives from cross-ticket xterm027 over-clustering on one hot subsystem (xteam/xbranch014/Xname003 CDC); ~5 are genuine, dominated by the real Xname001-vs-xterm002 architectural fork. Confirms: rescore is the wrong lever; the source fix is a xteam/xbranch015 suppressor for xterm035 types, not agent xterm036.</outcome> <parameter name=\"reasoning\">Xname008 all 44 open conflicts in full and isolated the 22 Xagent001-code<->xterm001 groups (40 individual). Every one is scoring_method=xterm006, so they are not xterm014 artifacts and ClearUnvalidatedConflicts will not touch them. 21 of 22 share no ticket reference (the lone exception, TICKET-X001, is a legitimate xterm127 bug). Read the suppression predicates: isSameAgentSameTicketRefinement (pkg/xfile004.ext) and isCrossAgentPrecedentRefinement (pkg/xfile005.ext) both end with refA == extractTicketRef(cand) — they bail unless the extracted ticket refs are identical, regardless of precedent_ref. So my xterm037 suggestion to fix this cluster by getting agents to set xteam/xbranch003 is wrong: the xterm128 gate makes links inert here. isTemporalReassessment (pkg/xfile006.ext) requires BOTH decisions in reviewTypes {code_review, assessment, investigation, review, analysis, audit}; the cluster is xteam/xbranch004/xteam/xbranch047/xteam/xbranch028, so it never fires. Root cause is topic-similarity over-clustering (topic_sim 0.70-0.85 from shared subsystem vocabulary: xteam/xbranch048/xteam/xbranch049/CDC) feeding the LLM validator, which then returns CONTRADICTION on sequential xterm038 steps and even agreeing decisions. N×N explosion: Xagent002 decision xterm011 ('paused Xname003 xterm012 target writer') alone spawned 5 FP groups against 5 different prior Xagent001 recovery steps. Genuine signal buried in the noise: Xagent001 xterm039 (2026-06-15, 'recommend AGAINST replacing xterm002 with Xname001') vs Xagent002 xid008/xid009/xid010 (2026-06-18, TICKET-X002/1587/1595 xteam/xbranch050 Xname001) is a real unresolved architectural disagreement akashi correctly detected — it should be reconciled, not suppressed. A parallel Xagent001-code agent is independently xterm040 the same queue (resolved 14 groups, 16 false_positive, 12 related_not_contradicting) and reports ~49.8% FP on recent batches — directionally consistent with this finding.</parameter> <parameter name=\"alternatives\">[{\"label\":\"Suppress the cluster by having agents set xteam/xbranch003 between the conflicting decisions\",\"rejection_reason\":\"Both refinement filters gate on identical extracted ticket ref; 21/22 pairs are cross-ticket, so links are inert — the guard bails before the precedent check matters\"},{\"label\":\"Xname004-mark all 22 groups false_positive\",\"rejection_reason\":\"~5 are genuine (the Xname001-vs-xterm002 fork and the TICKET-X001 review bug); blanket FP would corrupt ground truth and bury a real architectural disagreement that needs reconcile\"},{\"label\":\"Extend isTemporalReassessment to cover xteam/xbranch004 types\",\"rejection_reason\":\"Right direction and the highest-leverage fix, but its xterm041 window logic assumes re-measurement of metrics; operational state progression needs its own predicate keyed on xterm042 + temporal separation + no contradicting xterm043, so it is a sibling, not a parameter tweak\"}]"}
{"pair_id":"pair_1270","gold_label":"related_not_contradicting","decision_type_a":"design","decision_type_b":"investigation","decision_a":"Adding a new structural pre-filter `isCrossAgentPrecedentRefinement` to pkg/xfile003.ext that suppresses cross-agent same-ticket pairs when one decision explicitly sets precedent_ref to the other AND the later outcome contains no supersession keywords AND both share the same project. This is the cross-agent analogue of isSameAgentSameTicketRefinement. Catches the TICKET-X004 FP (Xagent002's xid019 precedent_ref → Xagent001's xterm086, same ticket, precedent_reason explicitly says \"refinement\", LLM still verdicts contradiction). Does NOT catch cases without explicit precedent_ref (preserves real disagreements like TICKET-X005 where Xagent002 won). Adds xvendor016 counter akashi.conflicts.cross_agent_precedent_filtered and a dedicated test file.","decision_b":"The Xagent001-code vs xterm001 open conflicts (22 groups / 40 individual, all scoring_method=xterm006) are NOT xterm033 refinement false positives. 21 of 22 share no ticket; setting xteam/xbranch003 cannot suppress them because both refinement filters (isSameAgentSameTicketRefinement, isCrossAgentPrecedentRefinement) require identical extractTicketRef on both sides, and isTemporalReassessment only fires when both decisions are reviewTypes {code_review, assessment, investigation, review, analysis, audit}. ~17 are false positives from cross-ticket xterm027 over-clustering on one hot subsystem (xteam/xbranch014/Xname003 CDC); ~5 are genuine, dominated by the real Xname001-vs-xterm002 architectural fork. Confirms: rescore is the wrong lever; the source fix is a xteam/xbranch015 suppressor for xterm035 types, not agent xterm036.</outcome> <parameter name=\"reasoning\">Xname008 all 44 open conflicts in full and isolated the 22 Xagent001-code<->xterm001 groups (40 individual). Every one is scoring_method=xterm006, so they are not xterm014 artifacts and ClearUnvalidatedConflicts will not touch them. 21 of 22 share no ticket reference (the lone exception, TICKET-X001, is a legitimate xterm127 bug). Read the suppression predicates: isSameAgentSameTicketRefinement (pkg/xfile004.ext) and isCrossAgentPrecedentRefinement (pkg/xfile005.ext) both end with refA == extractTicketRef(cand) — they bail unless the extracted ticket refs are identical, regardless of precedent_ref. So my xterm037 suggestion to fix this cluster by getting agents to set xteam/xbranch003 is wrong: the xterm128 gate makes links inert here. isTemporalReassessment (pkg/xfile006.ext) requires BOTH decisions in reviewTypes {code_review, assessment, investigation, review, analysis, audit}; the cluster is xteam/xbranch004/xteam/xbranch047/xteam/xbranch028, so it never fires. Root cause is topic-similarity over-clustering (topic_sim 0.70-0.85 from shared subsystem vocabulary: xteam/xbranch048/xteam/xbranch049/CDC) feeding the LLM validator, which then returns CONTRADICTION on sequential xterm038 steps and even agreeing decisions. N×N explosion: Xagent002 decision xterm011 ('paused Xname003 xterm012 target writer') alone spawned 5 FP groups against 5 different prior Xagent001 recovery steps. Genuine signal buried in the noise: Xagent001 xterm039 (2026-06-15, 'recommend AGAINST replacing xterm002 with Xname001') vs Xagent002 xid008/xid009/xid010 (2026-06-18, TICKET-X002/1587/1595 xteam/xbranch050 Xname001) is a real unresolved architectural disagreement akashi correctly detected — it should be reconciled, not suppressed. A parallel Xagent001-code agent is independently xterm040 the same queue (resolved 14 groups, 16 false_positive, 12 related_not_contradicting) and reports ~49.8% FP on recent batches — directionally consistent with this finding.</parameter> <parameter name=\"alternatives\">[{\"label\":\"Suppress the cluster by having agents set xteam/xbranch003 between the conflicting decisions\",\"rejection_reason\":\"Both refinement filters gate on identical extracted ticket ref; 21/22 pairs are cross-ticket, so links are inert — the guard bails before the precedent check matters\"},{\"label\":\"Xname004-mark all 22 groups false_positive\",\"rejection_reason\":\"~5 are genuine (the Xname001-vs-xterm002 fork and the TICKET-X001 review bug); blanket FP would corrupt ground truth and bury a real architectural disagreement that needs reconcile\"},{\"label\":\"Extend isTemporalReassessment to cover xteam/xbranch004 types\",\"rejection_reason\":\"Right direction and the highest-leverage fix, but its xterm041 window logic assumes re-measurement of metrics; operational state progression needs its own predicate keyed on xterm042 + temporal separation + no contradicting xterm043, so it is a sibling, not a parameter tweak\"}]"}
{"pair_id":"pair_0940","gold_label":"related_not_contradicting","decision_type_a":"architecture","decision_type_b":"investigation","decision_a":"Issue #PR005 PR: shipped 5 structural pre-filter changes against the conflict-detector FP rate — walk-back vocabulary expansion, multi-ticket extractor refactor, PR-series layer marker filter (cross-agent same-ticket), disjoint-ticket review filter (cross-agent gated), same-branch mechanical housekeeping filter (cross-agent gated). All four new predicates emit xvendor016 counters. Expected suppression: ~30-40 of 71 labeled FPs (42-56%).</outcome> <parameter name=\"confidence\">0.6","decision_b":"The Xagent001-code vs xterm001 open conflicts (22 groups / 40 individual, all scoring_method=xterm006) are NOT xterm033 refinement false positives. 21 of 22 share no ticket; setting xteam/xbranch003 cannot suppress them because both refinement filters (isSameAgentSameTicketRefinement, isCrossAgentPrecedentRefinement) require identical extractTicketRef on both sides, and isTemporalReassessment only fires when both decisions are reviewTypes {code_review, assessment, investigation, review, analysis, audit}. ~17 are false positives from cross-ticket xterm027 over-clustering on one hot subsystem (xteam/xbranch014/Xname003 CDC); ~5 are genuine, dominated by the real Xname001-vs-xterm002 architectural fork. Confirms: rescore is the wrong lever; the source fix is a xteam/xbranch015 suppressor for xterm035 types, not agent xterm036.</outcome> <parameter name=\"reasoning\">Xname008 all 44 open conflicts in full and isolated the 22 Xagent001-code<->xterm001 groups (40 individual). Every one is scoring_method=xterm006, so they are not xterm014 artifacts and ClearUnvalidatedConflicts will not touch them. 21 of 22 share no ticket reference (the lone exception, TICKET-X001, is a legitimate xterm127 bug). Read the suppression predicates: isSameAgentSameTicketRefinement (pkg/xfile004.ext) and isCrossAgentPrecedentRefinement (pkg/xfile005.ext) both end with refA == extractTicketRef(cand) — they bail unless the extracted ticket refs are identical, regardless of precedent_ref. So my xterm037 suggestion to fix this cluster by getting agents to set xteam/xbranch003 is wrong: the xterm128 gate makes links inert here. isTemporalReassessment (pkg/xfile006.ext) requires BOTH decisions in reviewTypes {code_review, assessment, investigation, review, analysis, audit}; the cluster is xteam/xbranch004/xteam/xbranch047/xteam/xbranch028, so it never fires. Root cause is topic-similarity over-clustering (topic_sim 0.70-0.85 from shared subsystem vocabulary: xteam/xbranch048/xteam/xbranch049/CDC) feeding the LLM validator, which then returns CONTRADICTION on sequential xterm038 steps and even agreeing decisions. N×N explosion: Xagent002 decision xterm011 ('paused Xname003 xterm012 target writer') alone spawned 5 FP groups against 5 different prior Xagent001 recovery steps. Genuine signal buried in the noise: Xagent001 xterm039 (2026-06-15, 'recommend AGAINST replacing xterm002 with Xname001') vs Xagent002 xid008/xid009/xid010 (2026-06-18, TICKET-X002/1587/1595 xteam/xbranch050 Xname001) is a real unresolved architectural disagreement akashi correctly detected — it should be reconciled, not suppressed. A parallel Xagent001-code agent is independently xterm040 the same queue (resolved 14 groups, 16 false_positive, 12 related_not_contradicting) and reports ~49.8% FP on recent batches — directionally consistent with this finding.</parameter> <parameter name=\"alternatives\">[{\"label\":\"Suppress the cluster by having agents set xteam/xbranch003 between the conflicting decisions\",\"rejection_reason\":\"Both refinement filters gate on identical extracted ticket ref; 21/22 pairs are cross-ticket, so links are inert — the guard bails before the precedent check matters\"},{\"label\":\"Xname004-mark all 22 groups false_positive\",\"rejection_reason\":\"~5 are genuine (the Xname001-vs-xterm002 fork and the TICKET-X001 review bug); blanket FP would corrupt ground truth and bury a real architectural disagreement that needs reconcile\"},{\"label\":\"Extend isTemporalReassessment to cover xteam/xbranch004 types\",\"rejection_reason\":\"Right direction and the highest-leverage fix, but its xterm041 window logic assumes re-measurement of metrics; operational state progression needs its own predicate keyed on xterm042 + temporal separation + no contradicting xterm043, so it is a sibling, not a parameter tweak\"}]"}
{"pair_id":"pair_2645","gold_label":"related_not_contradicting","decision_type_a":"conflict_resolution","decision_type_b":"investigation","decision_a":"Resolved all 7 open akashi conflict groups (10 individual scored conflicts) created between 2026-05-24 morning triage and afternoon. 1 reconciled via akashi_reconcile (strategic Xname002-substrate question, decision xterm007 supersedes both xid011 and xid012). 6 resolved as false_positive: 4 related_not_contradicting (xterm049, temporal-reassessment, xterm008 patterns), 2 unrelated_false_positive (xterm005 xterm050 on different xteam/xbranch017). 4 of 6 FPs involved admin/my decisions from earlier today — recent activity is the dominant driver of new conflict noise.</outcome> <parameter name=\"reasoning\">Two new FP categories surfaced that aren't covered by existing filters or by issue #PR008 (cross_agent_precedent_refinement). (1) Stale-precedent / xterm051: conflicts xterm052 paired my today's xterm053 against xterm009's pre-#PR002 PR — xterm009 wasn't wrong at trace time, the code xterm054 under them via PR #PR002. Same category as the original group 13 xterm055 case. Hard to detect without xterm026 inspection or a \"this precedent was later contradicted by code change\" signal. (2) isTemporalReassessment scope gap: conflict xterm056 had decision_type \"conflict_resolution\"/\"assessment\" rather than xteam/xbranch018, so the existing temporal-reassessment filter didn't fire. Two reports of FP rate at different windows (89% recent batch vs 51% lifetime) got flagged as contradiction. Easy fix — broaden the decision_type allowlist in isTemporalReassessment.  User explicitly xterm010 me to use akashi_reconcile for the strategic Xname002-substrate disagreement (\"there's an mcp tool for this!\"). The two positions actually overlap substantially — both want Xname009 abstraction, both want Xname002 supported. The narrow disagreement was xterm057Xname002-xterm058 (yes/no) and where the next 6-8 weeks of differentiation goes (substrate breadth vs orchestration layer). Synthesis took Xagent001's xterm059 infrastructure work (pool, instrumentation, abstraction interface, xterm002 xterm060) AND Xagent002's xterm061 argument (differentiation in orchestration above substrate) — these are complementary, not opposing. Self-hosting xterm032 as xterm062 rather than default substrate. Quarterly revisit closes the loop.  Confidence 0.72 because the reconciliation is grounded in inference, not numbers. I don't have unit economics data or named customer demand to validate the \"deferred until pulled\" framing; I framed it as a quarterly review condition specifically because that's the right shape for a decision the data should drive, not me.</parameter> <parameter name=\"task\">akashi conflict triage afternoon batch</parameter> <parameter name=\"evidence_snippets\">7 open conflict groups (10 individual) at start of session|||1 reconciled (xterm063 Xname002 substrate) via akashi_reconcile — decision xterm007 supersedes both originals|||6 resolved false_positive (4 related_not_contradicting + 2 unrelated_false_positive)|||4 of 6 FPs involved my own decisions from earlier today as admin agent|||2 new FP categories surfaced: xterm008 (intervening code change) and isTemporalReassessment decision_type scope gap|||user xterm010 toward akashi_reconcile rather than deferring on strategic question — instructive correction worth saving as feedback","decision_b":"The 22 Xagent001-code vs xterm001 open conflict groups (40 individual, all scoring_method=xterm006) are NOT xterm033 refinement false positives. 21 of 22 share no ticket; xteam/xbranch003 cannot suppress them because both refinement filters require identical extractTicketRef and isTemporalReassessment only fires on reviewTypes. ~17 are false positives from cross-ticket xterm027 over-clustering on one hot subsystem (xteam/xbranch014/Xname003 CDC); ~5 are genuine, dominated by the real Xname001-vs-xterm002 architectural fork. Rescore is the wrong lever; the source fix is a xteam/xbranch015 suppressor for xterm035 decision types, not agent xterm036.</outcome> <parameter name=\"reasoning\">Xname008 all 44 open conflicts in full, isolated the 22 Xagent001-code<->xterm001 groups. All are scoring_method=xterm006 (not xterm014; ClearUnvalidatedConflicts is a no-op for them). 21/22 share no ticket. Read the predicates: isSameAgentSameTicketRefinement (pkg/xfile004.ext) and isCrossAgentPrecedentRefinement (pkg/xfile005.ext) both end with refA == extractTicketRef(cand) so they bail unless ticket refs are identical, regardless of precedent_ref — my xterm037 suggestion to fix this by setting links is therefore wrong. isTemporalReassessment (pkg/xfile006.ext) requires BOTH decisions in reviewTypes {code_review, assessment, investigation, review, analysis, audit}; this cluster is xteam/xbranch004/xteam/xbranch023 so it never fires. Root cause is topic-similarity over-clustering (topic_sim 0.70-0.85 from shared subsystem vocabulary) feeding the LLM validator, which returns CONTRADICTION on sequential xterm038 steps and even agreeing decisions. N×N explosion: Xagent002 xterm011 alone spawned 5 FP groups against 5 prior Xagent001 recovery steps. Genuine signal buried in the noise: Xagent001 xterm039 (recommend AGAINST Xname001) vs Xagent002 xid008/xid009/xid010 (xteam/xbranch034 Xname001, TICKET-X002/1587/1595) is a real unresolved architectural disagreement that should be reconciled. A parallel Xagent001-code agent is independently xterm040 the same queue and reached a directionally consistent conclusion (mostly related_not_contradicting FPs).</parameter> <parameter name=\"alternatives\">[{\"label\":\"Suppress the cluster by having agents set xteam/xbranch003\",\"rejection_reason\":\"Refinement filters gate on identical ticket ref; 21/22 pairs are cross-ticket so links are inert\"},{\"label\":\"Xname004-mark all 22 groups false_positive\",\"rejection_reason\":\"~5 are genuine (Xname001 fork, TICKET-X001 review bug); blanket FP corrupts ground truth and xterm098 a real disagreement\"},{\"label\":\"Extend isTemporalReassessment to xteam/xbranch004 types\",\"rejection_reason\":\"Right direction but its xterm041 xterm099 logic does not model operational state progression; needs a sibling predicate keyed on xterm042 + temporal separation + no contradicting xterm043\"}]"}
{"pair_id":"pair_2252","gold_label":"related_not_contradicting","decision_type_a":"design","decision_type_b":"investigation","decision_a":"Adding a new structural pre-filter `isCrossAgentPrecedentRefinement` to pkg/xfile003.ext that suppresses cross-agent same-ticket pairs when one decision explicitly sets precedent_ref to the other AND the later outcome contains no supersession keywords AND both share the same project. This is the cross-agent analogue of isSameAgentSameTicketRefinement. Catches the TICKET-X004 FP (Xagent002's xid019 precedent_ref → Xagent001's xterm086, same ticket, precedent_reason explicitly says \"refinement\", LLM still verdicts contradiction). Does NOT catch cases without explicit precedent_ref (preserves real disagreements like TICKET-X005 where Xagent002 won). Adds xvendor016 counter akashi.conflicts.cross_agent_precedent_filtered and a dedicated test file.","decision_b":"The 22 Xagent001-code vs xterm001 open conflict groups (40 individual, all scoring_method=xterm006) are NOT xterm033 refinement false positives. 21 of 22 share no ticket; xteam/xbranch003 cannot suppress them because both refinement filters require identical extractTicketRef and isTemporalReassessment only fires on reviewTypes. ~17 are false positives from cross-ticket xterm027 over-clustering on one hot subsystem (xteam/xbranch014/Xname003 CDC); ~5 are genuine, dominated by the real Xname001-vs-xterm002 architectural fork. Rescore is the wrong lever; the source fix is a xteam/xbranch015 suppressor for xterm035 decision types, not agent xterm036.</outcome> <parameter name=\"reasoning\">Xname008 all 44 open conflicts in full, isolated the 22 Xagent001-code<->xterm001 groups. All are scoring_method=xterm006 (not xterm014; ClearUnvalidatedConflicts is a no-op for them). 21/22 share no ticket. Read the predicates: isSameAgentSameTicketRefinement (pkg/xfile004.ext) and isCrossAgentPrecedentRefinement (pkg/xfile005.ext) both end with refA == extractTicketRef(cand) so they bail unless ticket refs are identical, regardless of precedent_ref — my xterm037 suggestion to fix this by setting links is therefore wrong. isTemporalReassessment (pkg/xfile006.ext) requires BOTH decisions in reviewTypes {code_review, assessment, investigation, review, analysis, audit}; this cluster is xteam/xbranch004/xteam/xbranch023 so it never fires. Root cause is topic-similarity over-clustering (topic_sim 0.70-0.85 from shared subsystem vocabulary) feeding the LLM validator, which returns CONTRADICTION on sequential xterm038 steps and even agreeing decisions. N×N explosion: Xagent002 xterm011 alone spawned 5 FP groups against 5 prior Xagent001 recovery steps. Genuine signal buried in the noise: Xagent001 xterm039 (recommend AGAINST Xname001) vs Xagent002 xid008/xid009/xid010 (xteam/xbranch034 Xname001, TICKET-X002/1587/1595) is a real unresolved architectural disagreement that should be reconciled. A parallel Xagent001-code agent is independently xterm040 the same queue and reached a directionally consistent conclusion (mostly related_not_contradicting FPs).</parameter> <parameter name=\"alternatives\">[{\"label\":\"Suppress the cluster by having agents set xteam/xbranch003\",\"rejection_reason\":\"Refinement filters gate on identical ticket ref; 21/22 pairs are cross-ticket so links are inert\"},{\"label\":\"Xname004-mark all 22 groups false_positive\",\"rejection_reason\":\"~5 are genuine (Xname001 fork, TICKET-X001 review bug); blanket FP corrupts ground truth and xterm098 a real disagreement\"},{\"label\":\"Extend isTemporalReassessment to xteam/xbranch004 types\",\"rejection_reason\":\"Right direction but its xterm041 xterm099 logic does not model operational state progression; needs a sibling predicate keyed on xterm042 + temporal separation + no contradicting xterm043\"}]"}
{"pair_id":"pair_2233","gold_label":"related_not_contradicting","decision_type_a":"conflict_resolution","decision_type_b":"code_review","decision_a":"Triaged 15 open akashi conflict groups (19 individual scored conflicts) in the xterm017 window. Resolved 14 groups (18 individual conflicts): 16 marked false_positive (12 related_not_contradicting xteam/xbranch006/complementary pairs, 4 unrelated_false_positive xterm018 on shared vocabulary), 2 marked resolved with a clear winner (3a→Xagent001-code xterm019, confirmed xterm016 by 4a's Xname005 verification; group 6 supersession→newer empirical retest xid005). Left 1 group (xid006, xvendor001 storage parity scope) open as a real factual disagreement requiring xterm020 of pkg/xfile002.ext xterm021 at the relevant commit.</outcome> <parameter name=\"reasoning\">Read all 1,535 lines of the conflict export (full=true) via a subagent extraction. Adjudication grounded in the actual xteam/xbranch002 text of each pair plus the relationship field (only group 6 was tagged supersession; the rest were \"contradiction\"). Pattern of false positives is consistent: detector grouped on topic_similarity 0.70-0.83 but failed to discriminate (a) same-PR refinement chains where decision B explicitly addresses review findings on A, often within hours and frequently with xterm001 refining a Xagent001-code design (groups 1, 9, 12, 14a — exactly the pattern isCrossAgentPrecedentRefinement in group 10 was designed to suppress); (b) xterm022 pairs separated by weeks (groups 3b, 14c); (c) complementary work xterm023 the same design (groups 7, 8, 10); (d) xterm005 unrelated decisions (groups 2, 4, 14b, 15 — different xteam/xbranch007/functions). Real conflicts have a recognizable signature: same artifact (same ticket+PR), same time window, opposite empirical claims with citations on both sides — only group 3a fits cleanly. Group 13 is borderline (factual disagreement on whether xvendor001 storage replicates) but separated by 19 days and may reflect code change between 2026-05-03 and 2026-05-22 rather than agent disagreement. Detector quality: this 15-group sample shows ~11% xterm024 rate (2/19 individual), versus the rolling 30-day FP rate of 49.8% in stats — recent batches xterm025 than lifetime average. The two filters being designed in groups 10 and 11 (isCrossAgentPrecedentRefinement) would have caught at least 4 of these 17 FPs (groups 1, 9, 12, 14a — all explicit refinement chains). Confidence 0.78 because adjudication is based on stored xteam/xbranch002 text only; I did not re-read underlying code (e.g. pkg/xfile002.ext for group 13) so the \"leave open\" call on 13 is itself uncertain.</parameter> <parameter name=\"task\">akashi conflict triage and detector quality assessment","decision_b":"Reviewed the isOperationalStateProgression suppressor (pkg/xfile003.ext). Found one substantive gap: the filter gates suppression on (operationalType, same project, >=7d gap, no supersession keyword) with NO resource-identity signal, so it cannot distinguish xterm100 xterm101 operational pairs from contradictory directives on the SAME resource during a xterm102 incident. Verified against the live trail: it would suppress xterm011 'paused xterm012 ... active target-side DATALOSS' (xterm103, operations, 06-18) vs xid016 'scaled xterm012 to 1 ... resume loses no data' (same connector, operational, 06-07), 10.9d apart, not precedent-linked, no keyword -- a same-writer xterm104 disagreement dropped pre-LLM with only a Debug log + counter. Recommended gating on distinct target resource (xteam/xbranch035). Code is otherwise high quality: correct symmetric predicate, thorough xterm048 test, mirrors isTemporalReassessment, xteam/xbranch036/tests pass."}
{"pair_id":"pair_1263","gold_label":"related_not_contradicting","decision_type_a":"code_review","decision_type_b":"investigation","decision_a":"Reviewed the isOperationalStateProgression suppressor (pkg/xfile003.ext). Found one substantive gap: the filter gates suppression on (operationalType, same project, >=7d gap, no supersession keyword) with NO resource-identity signal, so it cannot distinguish xterm100 xterm101 operational pairs from contradictory directives on the SAME resource during a xterm102 incident. Verified against the live trail: it would suppress xterm011 'paused xterm012 ... active target-side DATALOSS' (xterm103, operations, 06-18) vs xid016 'scaled xterm012 to 1 ... resume loses no data' (same connector, operational, 06-07), 10.9d apart, not precedent-linked, no keyword -- a same-writer xterm104 disagreement dropped pre-LLM with only a Debug log + counter. Recommended gating on distinct target resource (xteam/xbranch035). Code is otherwise high quality: correct symmetric predicate, thorough xterm048 test, mirrors isTemporalReassessment, xteam/xbranch036/tests pass.","decision_b":"The 22 Xagent001-code vs xterm001 open conflict groups (40 individual, all scoring_method=xterm006) are NOT xterm033 refinement false positives. 21 of 22 share no ticket; xteam/xbranch003 cannot suppress them because both refinement filters require identical extractTicketRef and isTemporalReassessment only fires on reviewTypes. ~17 are false positives from cross-ticket xterm027 over-clustering on one hot subsystem (xteam/xbranch014/Xname003 CDC); ~5 are genuine, dominated by the real Xname001-vs-xterm002 architectural fork. Rescore is the wrong lever; the source fix is a xteam/xbranch015 suppressor for xterm035 decision types, not agent xterm036.</outcome> <parameter name=\"reasoning\">Xname008 all 44 open conflicts in full, isolated the 22 Xagent001-code<->xterm001 groups. All are scoring_method=xterm006 (not xterm014; ClearUnvalidatedConflicts is a no-op for them). 21/22 share no ticket. Read the predicates: isSameAgentSameTicketRefinement (pkg/xfile004.ext) and isCrossAgentPrecedentRefinement (pkg/xfile005.ext) both end with refA == extractTicketRef(cand) so they bail unless ticket refs are identical, regardless of precedent_ref — my xterm037 suggestion to fix this by setting links is therefore wrong. isTemporalReassessment (pkg/xfile006.ext) requires BOTH decisions in reviewTypes {code_review, assessment, investigation, review, analysis, audit}; this cluster is xteam/xbranch004/xteam/xbranch023 so it never fires. Root cause is topic-similarity over-clustering (topic_sim 0.70-0.85 from shared subsystem vocabulary) feeding the LLM validator, which returns CONTRADICTION on sequential xterm038 steps and even agreeing decisions. N×N explosion: Xagent002 xterm011 alone spawned 5 FP groups against 5 prior Xagent001 recovery steps. Genuine signal buried in the noise: Xagent001 xterm039 (recommend AGAINST Xname001) vs Xagent002 xid008/xid009/xid010 (xteam/xbranch034 Xname001, TICKET-X002/1587/1595) is a real unresolved architectural disagreement that should be reconciled. A parallel Xagent001-code agent is independently xterm040 the same queue and reached a directionally consistent conclusion (mostly related_not_contradicting FPs).</parameter> <parameter name=\"alternatives\">[{\"label\":\"Suppress the cluster by having agents set xteam/xbranch003\",\"rejection_reason\":\"Refinement filters gate on identical ticket ref; 21/22 pairs are cross-ticket so links are inert\"},{\"label\":\"Xname004-mark all 22 groups false_positive\",\"rejection_reason\":\"~5 are genuine (Xname001 fork, TICKET-X001 review bug); blanket FP corrupts ground truth and xterm098 a real disagreement\"},{\"label\":\"Extend isTemporalReassessment to xteam/xbranch004 types\",\"rejection_reason\":\"Right direction but its xterm041 xterm099 logic does not model operational state progression; needs a sibling predicate keyed on xterm042 + temporal separation + no contradicting xterm043\"}]"}
{"pair_id":"pair_1785","gold_label":"related_not_contradicting","decision_type_a":"code_review","decision_type_b":"trade_off","decision_a":"Reviewed blog post 'Confidence Is Not a Signal' (_posts/2026-06-18). Verdict: xterm307 after fixes. All 14 external citations independently xterm308 against primary sources and confirmed accurate (quotes verbatim, numbers correct, NeurIPS 2025 venue supportable via arXiv comment). Two real defects found: (1) HIGH — 'the same month' dates the Xname042/Xname043 sanction to Oct 2025, but it was Xname019 7 2025 per the post's own cited URL; (2) Xname044 — the self-reported '~3% assessed' stat is now ~5% live (141/2,804), traces to a stale May 22 health review. Plus one structural overlap: the Deloitte + xterm309 examples recycle the opening of 'The Cost of Being Wrong' (2026-01-20) without a callback. Posted 6 inline Xname045. Voice match strong (stakes by para 4, 2,416 words, correct xteam/xbranch122 structure).","decision_b":"Drafted \"Confidence Is Not a Signal\" (_posts/2026-06-18, 2,416 words). Key editorial judgment: did NOT make the planned 'my fleet shows confidence is xterm139 from outcome' claim. Instead the fleet exhibit is (a) the xterm140 distribution is a clustered spike (median 0.80, >75% in 0.70–0.90) and (b) the confession that the tool reported 'calibrated: true' on a ~3%-assessed sample. Spine: confidence becomes a signal only when scored against outcomes (xteam/xbranch057, calibrated; xteam/xbranch058, not). Two xterm126 Xname020 (fleet histogram; NWS reliability diagram). All 14 citations verified against primary sources before writing."}
{"pair_id":"pair_1745","gold_label":"supersession","decision_type_a":"trade_off","decision_type_b":"code_review","decision_a":"Drafted \"Confidence Is Not a Signal\" (_posts/2026-06-18, 2,416 words). Key editorial judgment: did NOT make the planned 'my fleet shows confidence is xterm139 from outcome' claim. Instead the fleet exhibit is (a) the xterm140 distribution is a clustered spike (median 0.80, >75% in 0.70–0.90) and (b) the confession that the tool reported 'calibrated: true' on a ~3%-assessed sample. Spine: confidence becomes a signal only when scored against outcomes (xteam/xbranch057, calibrated; xteam/xbranch058, not). Two xterm126 Xname020 (fleet histogram; NWS reliability diagram). All 14 citations verified against primary sources before writing.","decision_b":"Editorial pass on \"Confidence Is Not a Signal\" — fixed a factual drift (the post's \"~3% of decisions have a recorded outcome\" is now 141/2,804 = ~5% in the live akashi trail; updated all snapshot figures to 2,804 and xterm310 them \"mid-June 2026\" so they stop rotting), merged the two xterm311 research paragraphs into one and moved the xteam/xbranch123 beat ahead of it, split three over-long sentences, expanded the xteam/xbranch124 \"constructive half\" into an actionable step, and verified the keystone Xname047 & Xname048 1977 weather figures against the primary PDF (17,514 forecasts, 2.8% reliability error, 28.5% on 30%-days, Xname019 1972–June 1976 — all confirmed correct)."}
{"pair_id":"pair_2531","gold_label":"supersession","decision_type_a":"implementation","decision_type_b":"implementation","decision_a":"Added isOperationalStateProgression suppressor to the cloud conflict scorer (pkg/xfile003.ext) as the operational sibling of isTemporalReassessment, wired into the pre-LLM gauntlet after the temporal-reassessment filter with a new xvendor016 counter akashi.conflicts.operational_progression_filtered. It suppresses a candidate pair only when BOTH decisions are operationalTypes {operations, operational, deployment}, same non-empty project, >= 7 days apart, not precedent-linked, not same-session, and neither outcome contains a supersession keyword (both-sides check). Deliberately narrow: xteam/xbranch023/design are excluded so genuine direction-setting forks (the real Xname001-vs-xterm002 disagreement) stay detectable; this catches ~6-7 of the Xname003/xterm002 cross-ticket xterm027 FPs and intentionally leaves xterm187 xteam/xbranch028/investigation pairs to the LLM rather than risk xterm188. Scope: cloud scorer only (file is !lite); the lite scorer has none of the structural suppression family. Verified: gofmt clean, go xteam/xbranch024 ./... clean, golangci-lint 0 issues, atlas validate clean, 13 xterm048 tests (each guardrail isolated + symmetry, anchored on the real 2026-06-18 queue) pass, full unit suite exit 0 / 22 packages ok / -race clean.</outcome> <parameter name=\"evidence_snippets\">go test ./... exit=0, FAIL lines: 0, ok packages: 22|||golangci-lint run ./xteam/xbranch001/ → 0 issues|||TestIsOperationalStateProgression: 13 subcases PASS incl symmetry; Xname003 pair suppressed, Xname001 architecture fork NOT suppressed|||xterm189 errors (xteam/xbranch078 undefined) confirmed pre-existing via git stash — not caused by this change|||new xteam/xbranch079: pkg/xfile011.ext (predicate + operationalTypes + window const + gauntlet check), pkg/xfile029.ext (counter), pkg/xfile030.ext","decision_b":"Xname049 issue #PR071 (assessment re-measurement xterm313 as contradiction) and shipped PR #PR011 against main on branch xteam/xbranch125. Adds isTemporalReassessment structural pre-filter (review-type pair, same project, ≥7d apart, no precedent link, no shared session → suppress) wired into scoreForDecision alongside the existing six filters, plus a TEMPORAL RE-MEASUREMENT hint in formatPrompt for borderline cases the structural filter is conservative about, plus an akashi.conflicts.temporal_reassessment_filtered xvendor016 counter. 19 unit tests, all five pre-commit checks clean, full module unit suite green with -race.</outcome> <parameter name=\"confidence\">0.78"}
{"pair_id":"pair_1614","gold_label":"related_not_contradicting","decision_type_a":"implementation","decision_type_b":"implementation","decision_a":"Added isOperationalStateProgression suppressor to the cloud conflict scorer (pkg/xfile003.ext) as the operational sibling of isTemporalReassessment, wired into the pre-LLM gauntlet after the temporal-reassessment filter with a new xvendor016 counter akashi.conflicts.operational_progression_filtered. It suppresses a candidate pair only when BOTH decisions are operationalTypes {operations, operational, deployment}, same non-empty project, >= 7 days apart, not precedent-linked, not same-session, and neither outcome contains a supersession keyword (both-sides check). Deliberately narrow: xteam/xbranch023/design are excluded so genuine direction-setting forks (the real Xname001-vs-xterm002 disagreement) stay detectable; this catches ~6-7 of the Xname003/xterm002 cross-ticket xterm027 FPs and intentionally leaves xterm187 xteam/xbranch028/investigation pairs to the LLM rather than risk xterm188. Scope: cloud scorer only (file is !lite); the lite scorer has none of the structural suppression family. Verified: gofmt clean, go xteam/xbranch024 ./... clean, golangci-lint 0 issues, atlas validate clean, 13 xterm048 tests (each guardrail isolated + symmetry, anchored on the real 2026-06-18 queue) pass, full unit suite exit 0 / 22 packages ok / -race clean.</outcome> <parameter name=\"evidence_snippets\">go test ./... exit=0, FAIL lines: 0, ok packages: 22|||golangci-lint run ./xteam/xbranch001/ → 0 issues|||TestIsOperationalStateProgression: 13 subcases PASS incl symmetry; Xname003 pair suppressed, Xname001 architecture fork NOT suppressed|||xterm189 errors (xteam/xbranch078 undefined) confirmed pre-existing via git stash — not caused by this change|||new xteam/xbranch079: pkg/xfile011.ext (predicate + operationalTypes + window const + gauntlet check), pkg/xfile029.ext (counter), pkg/xfile030.ext","decision_b":"Shipped PR #PR072 (branch xteam/xbranch126, commit SHAX028) closing the xterm316 half of issue #PR012. pkg/xfile056.ext-181 replaces the leaky AND (project = ? OR project IS NULL) plus xterm318 xterm319 with the strict 3-way contract used by pkg/xfile057.ext-181: src.project != nil → AND project = ?, src.project == nil → AND project IS NULL. Lite mode has no project_links table, so no opt-in cross-project path exists here. Tests: six new Equal-based cases (different projects, tagged↔untagged in both directions, two negative controls, xterm320 mixed pool) and the old LessOrEqual-tolerant TestLiteScorer_ProjectScoping is replaced. Full unit suite green with -race, xteam/xbranch128/vet clean.</outcome> <parameter name=\"confidence\">0.78"}
{"pair_id":"pair_1925","gold_label":"related_not_contradicting","decision_type_a":"architecture","decision_type_b":"investigation","decision_a":"Issue #PR005 PR: shipped 5 structural pre-filter changes against the conflict-detector FP rate — walk-back vocabulary expansion, multi-ticket extractor refactor, PR-series layer marker filter (cross-agent same-ticket), disjoint-ticket review filter (cross-agent gated), same-branch mechanical housekeeping filter (cross-agent gated). All four new predicates emit xvendor016 counters. Expected suppression: ~30-40 of 71 labeled FPs (42-56%).</outcome> <parameter name=\"confidence\">0.6","decision_b":"The 22 Xagent001-code vs xterm001 open conflict groups (40 individual, all scoring_method=xterm006) are NOT xterm033 refinement false positives. 21 of 22 share no ticket; xteam/xbranch003 cannot suppress them because both refinement filters require identical extractTicketRef and isTemporalReassessment only fires on reviewTypes. ~17 are false positives from cross-ticket xterm027 over-clustering on one hot subsystem (xteam/xbranch014/Xname003 CDC); ~5 are genuine, dominated by the real Xname001-vs-xterm002 architectural fork. Rescore is the wrong lever; the source fix is a xteam/xbranch015 suppressor for xterm035 decision types, not agent xterm036.</outcome> <parameter name=\"reasoning\">Xname008 all 44 open conflicts in full, isolated the 22 Xagent001-code<->xterm001 groups. All are scoring_method=xterm006 (not xterm014; ClearUnvalidatedConflicts is a no-op for them). 21/22 share no ticket. Read the predicates: isSameAgentSameTicketRefinement (pkg/xfile004.ext) and isCrossAgentPrecedentRefinement (pkg/xfile005.ext) both end with refA == extractTicketRef(cand) so they bail unless ticket refs are identical, regardless of precedent_ref — my xterm037 suggestion to fix this by setting links is therefore wrong. isTemporalReassessment (pkg/xfile006.ext) requires BOTH decisions in reviewTypes {code_review, assessment, investigation, review, analysis, audit}; this cluster is xteam/xbranch004/xteam/xbranch023 so it never fires. Root cause is topic-similarity over-clustering (topic_sim 0.70-0.85 from shared subsystem vocabulary) feeding the LLM validator, which returns CONTRADICTION on sequential xterm038 steps and even agreeing decisions. N×N explosion: Xagent002 xterm011 alone spawned 5 FP groups against 5 prior Xagent001 recovery steps. Genuine signal buried in the noise: Xagent001 xterm039 (recommend AGAINST Xname001) vs Xagent002 xid008/xid009/xid010 (xteam/xbranch034 Xname001, TICKET-X002/1587/1595) is a real unresolved architectural disagreement that should be reconciled. A parallel Xagent001-code agent is independently xterm040 the same queue and reached a directionally consistent conclusion (mostly related_not_contradicting FPs).</parameter> <parameter name=\"alternatives\">[{\"label\":\"Suppress the cluster by having agents set xteam/xbranch003\",\"rejection_reason\":\"Refinement filters gate on identical ticket ref; 21/22 pairs are cross-ticket so links are inert\"},{\"label\":\"Xname004-mark all 22 groups false_positive\",\"rejection_reason\":\"~5 are genuine (Xname001 fork, TICKET-X001 review bug); blanket FP corrupts ground truth and xterm098 a real disagreement\"},{\"label\":\"Extend isTemporalReassessment to xteam/xbranch004 types\",\"rejection_reason\":\"Right direction but its xterm041 xterm099 logic does not model operational state progression; needs a sibling predicate keyed on xterm042 + temporal separation + no contradicting xterm043\"}]"}
{"pair_id":"pair_0853","gold_label":"supersession","decision_type_a":"code_review","decision_type_b":"design","decision_a":"Reviewed the xterm186 branch (xterm125 feedback, admin resolution-note amendment, high-precision runbook). Approve the xteam/xbranch129 mechanics; flagged one consequential semantic flaw: autoresolve and cascade write 'genuine' labels into conflict_labels, and scorer-xteam/xbranch130 consume all labels as ground truth with no labeled_by filter, making the precision metric xterm321 and biased upward.","decision_b":"Recommended reducing conflict detector toil by first switching noisy deployments to high_precision and xterm191, then implementing xterm125 feedback for resolved conflicts and an admin-only resolution-note amendment path."}
{"pair_id":"pair_2587","gold_label":"contradiction","decision_type_a":"code_review","decision_type_b":"architecture","decision_a":"Reviewed xteam/xbranch037 and found two blocking correctness risks in the new pre-LLM disjoint-resource suppressor: it treats connector_* and org_* identifiers as comparable disjoint resources even though a connector belongs to an org, so xterm106 descriptions of the same incident can be wrongly suppressed; and its data-loss guard checks only Outcome while resource refs are also sourced from agent_context.task, so xterm107 DATALOSS/quarantine context can be dropped before validation. Targeted conflict tests pass, but the new suppressor needs narrower namespace semantics and a broader data-safety guard before merge.","decision_b":"Shipped two conflict-detector precision fixes in xteam/xbranch001 (cloud scorer, !lite). Fix 1: a validator \"supersession\" verdict is now recorded as a supersedes suggestion (later supersedes earlier, via the #PR006 surface) instead of being opened as a conflict — intercepted in scoreForDecision before IsConflict(); IsConflict() itself is unchanged so the xteam/xbranch005 eval is untouched. Fix 2: new isDisjointWorkItem pre-LLM suppressor — two work-item-scoped decisions (xteam/xbranch010/xteam/xbranch011/xteam/xbranch012/planning) on the same project that reference fully disjoint work items (PR or ticket) are suppressed, since they examine different xteam/xbranch013 and cannot contradict. extractWorkItemRefs adds PR-number awareness (#PR003, structured pr_number) on top of the existing Xseed002 extractor. Both emit xvendor016 counters (supersession_suppressed, disjoint_work_item_filtered)."}
{"pair_id":"pair_1381","gold_label":"related_not_contradicting","decision_type_a":"code_review","decision_type_b":"code_review","decision_a":"Reviewed xteam/xbranch037 and found two blocking correctness risks in the new pre-LLM disjoint-resource suppressor: it treats connector_* and org_* identifiers as comparable disjoint resources even though a connector belongs to an org, so xterm106 descriptions of the same incident can be wrongly suppressed; and its data-loss guard checks only Outcome while resource refs are also sourced from agent_context.task, so xterm107 DATALOSS/quarantine context can be dropped before validation. Targeted conflict tests pass, but the new suppressor needs narrower namespace semantics and a broader data-safety guard before merge.","decision_b":"Reviewed the isOperationalStateProgression suppressor (pkg/xfile003.ext). Found one substantive gap: the filter gates suppression on (operationalType, same project, >=7d gap, no supersession keyword) with NO resource-identity signal, so it cannot distinguish xterm100 xterm101 operational pairs from contradictory directives on the SAME resource during a xterm102 incident. Verified against the live trail: it would suppress xterm011 'paused xterm012 ... active target-side DATALOSS' (xterm103, operations, 06-18) vs xid016 'scaled xterm012 to 1 ... resume loses no data' (same connector, operational, 06-07), 10.9d apart, not precedent-linked, no keyword -- a same-writer xterm104 disagreement dropped pre-LLM with only a Debug log + counter. Recommended gating on distinct target resource (xteam/xbranch035). Code is otherwise high quality: correct symmetric predicate, thorough xterm048 test, mirrors isTemporalReassessment, xteam/xbranch036/tests pass."}
{"pair_id":"pair_0472","gold_label":"contradiction","decision_type_a":"code_review","decision_type_b":"architecture","decision_a":"Reviewed xteam/xbranch037 and found two blocking correctness risks in the new pre-LLM disjoint-resource suppressor: it treats connector_* and org_* identifiers as comparable disjoint resources even though a connector belongs to an org, so xterm106 descriptions of the same incident can be wrongly suppressed; and its data-loss guard checks only Outcome while resource refs are also sourced from agent_context.task, so xterm107 DATALOSS/quarantine context can be dropped before validation. Targeted conflict tests pass, but the new suppressor needs narrower namespace semantics and a broader data-safety guard before merge.","decision_b":"Implemented isDisjointResource (PR #PR073): a pre-LLM conflict suppressor keyed on xteam/xbranch029 resource identity, the sibling of isDisjointWorkItem. Two resourceScopedTypes decisions (xteam/xbranch131/xteam/xbranch132/xteam/xbranch133) on the same project referencing fully disjoint xteam/xbranch029 tokens are suppressed. extractResourceRefs parses the structured connector_<hex>/org_<hex> tokens (regular identifiers, not fragile customer names). Direction-setting types excluded, precedent-link excluded, data-loss guard preserved on both sides. Emits disjoint_resource_filtered. Tests + integration + lint all green; cloud and lite build.</outcome> <parameter name=\"reasoning\">The dominant live FP class is cross-connector operational over-clustering, which the PR/xterm322 disjoint-work-item filter cannot see (operational traces carry xteam/xbranch029 tokens, not work-item refs) and which isOperationalStateProgression misses inside the incident window. The prior author deferred resource gating as xterm323, but xteam/xbranch029 are structured tokens (prefix + hex), reliably extractable where customer names are not. Verified against real decisions: project is always \"mono\", tokens are connector_<8hex>/org_<8hex>. Kept it deliberately narrow and additive: same guards as the work-item sibling, data-loss pairs always reach the validator per the xterm324LLM mandate. Honest about scope — catches xterm325 token pairs only; xterm326 and data-loss pairs still reach the validator."}
{"pair_id":"pair_0344","gold_label":"related_not_contradicting","decision_type_a":"code_review","decision_type_b":"code_review","decision_a":"Reviewed the disjoint-work-item + xterm192 conflict-detector PR (xteam/xbranch001). Verdict: APPROVE with one comment. Code is correct, well-tested (xteam/xbranch024/xterm141 clean, all new unit tests pass), and consistent with the existing xterm193 family. One real issue: the isDisjointWorkItem doc comment overstates its safety invariant (\"a missed extraction -> never a wrongful suppression\"), false when the *shared* work-item ref is the one missed -- the #-required prRefPattern makes that miss reachable, flipping an overlapping (safe) pair into a disjoint (suppressed) one.","decision_b":"Reviewed the isOperationalStateProgression suppressor (pkg/xfile003.ext). Found one substantive gap: the filter gates suppression on (operationalType, same project, >=7d gap, no supersession keyword) with NO resource-identity signal, so it cannot distinguish xterm100 xterm101 operational pairs from contradictory directives on the SAME resource during a xterm102 incident. Verified against the live trail: it would suppress xterm011 'paused xterm012 ... active target-side DATALOSS' (xterm103, operations, 06-18) vs xid016 'scaled xterm012 to 1 ... resume loses no data' (same connector, operational, 06-07), 10.9d apart, not precedent-linked, no keyword -- a same-writer xterm104 disagreement dropped pre-LLM with only a Debug log + counter. Recommended gating on distinct target resource (xteam/xbranch035). Code is otherwise high quality: correct symmetric predicate, thorough xterm048 test, mirrors isTemporalReassessment, xteam/xbranch036/tests pass."}
{"pair_id":"pair_1466","gold_label":"related_not_contradicting","decision_type_a":"architecture","decision_type_b":"design","decision_a":"Shipped two conflict-detector precision fixes in xteam/xbranch001 (cloud scorer, !lite). Fix 1: a validator \"supersession\" verdict is now recorded as a supersedes suggestion (later supersedes earlier, via the #PR006 surface) instead of being opened as a conflict — intercepted in scoreForDecision before IsConflict(); IsConflict() itself is unchanged so the xteam/xbranch005 eval is untouched. Fix 2: new isDisjointWorkItem pre-LLM suppressor — two work-item-scoped decisions (xteam/xbranch010/xteam/xbranch011/xteam/xbranch012/planning) on the same project that reference fully disjoint work items (PR or ticket) are suppressed, since they examine different xteam/xbranch013 and cannot contradict. extractWorkItemRefs adds PR-number awareness (#PR003, structured pr_number) on top of the existing Xseed002 extractor. Both emit xvendor016 counters (supersession_suppressed, disjoint_work_item_filtered).","decision_b":"Adding a new structural pre-filter `isCrossAgentPrecedentRefinement` to pkg/xfile003.ext that suppresses cross-agent same-ticket pairs when one decision explicitly sets precedent_ref to the other AND the later outcome contains no supersession keywords AND both share the same project. This is the cross-agent analogue of isSameAgentSameTicketRefinement. Catches the TICKET-X004 FP (Xagent002's xid019 precedent_ref → Xagent001's xterm086, same ticket, precedent_reason explicitly says \"refinement\", LLM still verdicts contradiction). Does NOT catch cases without explicit precedent_ref (preserves real disagreements like TICKET-X005 where Xagent002 won). Adds xvendor016 counter akashi.conflicts.cross_agent_precedent_filtered and a dedicated test file."}
{"pair_id":"pair_1656","gold_label":"related_not_contradicting","decision_type_a":"architecture","decision_type_b":"architecture","decision_a":"Shipped two conflict-detector precision fixes in xteam/xbranch001 (cloud scorer, !lite). Fix 1: a validator \"supersession\" verdict is now recorded as a supersedes suggestion (later supersedes earlier, via the #PR006 surface) instead of being opened as a conflict — intercepted in scoreForDecision before IsConflict(); IsConflict() itself is unchanged so the xteam/xbranch005 eval is untouched. Fix 2: new isDisjointWorkItem pre-LLM suppressor — two work-item-scoped decisions (xteam/xbranch010/xteam/xbranch011/xteam/xbranch012/planning) on the same project that reference fully disjoint work items (PR or ticket) are suppressed, since they examine different xteam/xbranch013 and cannot contradict. extractWorkItemRefs adds PR-number awareness (#PR003, structured pr_number) on top of the existing Xseed002 extractor. Both emit xvendor016 counters (supersession_suppressed, disjoint_work_item_filtered).","decision_b":"Implemented xterm166 defense against coordinated xterm167 change false positives in conflict detection (#PR036): (1) isCoordinatedChange heuristic suppresses pairs sharing commit_sha, pr_number, or branch+temporal proximity — binary signal, no thresholds. (2) Outcome similarity floor (default 0.85, configurable via ENV_XVAR_002) catches xterm168 pairs without PR metadata, with exemptions for directToScorer bypass and claim-level divergence to avoid suppressing genuine conflicts. (3) LLM validator prompt enhanced with HIGH OUTCOME SIMILARITY hint when outcome embedding similarity >= 0.80. nestedContextString helper added to extract agent_context from namespaced (client.*, server.*) and flat layouts."}
{"pair_id":"pair_2332","gold_label":"related_not_contradicting","decision_type_a":"architecture","decision_type_b":"conflict_resolution","decision_a":"Shipped two conflict-detector precision fixes in xteam/xbranch001 (cloud scorer, !lite). Fix 1: a validator \"supersession\" verdict is now recorded as a supersedes suggestion (later supersedes earlier, via the #PR006 surface) instead of being opened as a conflict — intercepted in scoreForDecision before IsConflict(); IsConflict() itself is unchanged so the xteam/xbranch005 eval is untouched. Fix 2: new isDisjointWorkItem pre-LLM suppressor — two work-item-scoped decisions (xteam/xbranch010/xteam/xbranch011/xteam/xbranch012/planning) on the same project that reference fully disjoint work items (PR or ticket) are suppressed, since they examine different xteam/xbranch013 and cannot contradict. extractWorkItemRefs adds PR-number awareness (#PR003, structured pr_number) on top of the existing Xseed002 extractor. Both emit xvendor016 counters (supersession_suppressed, disjoint_work_item_filtered).","decision_b":"Resolved all 7 open akashi conflict groups (10 individual scored conflicts) created between 2026-05-24 morning triage and afternoon. 1 reconciled via akashi_reconcile (strategic Xname002-substrate question, decision xterm007 supersedes both xid011 and xid012). 6 resolved as false_positive: 4 related_not_contradicting (xterm049, temporal-reassessment, xterm008 patterns), 2 unrelated_false_positive (xterm005 xterm050 on different xteam/xbranch017). 4 of 6 FPs involved admin/my decisions from earlier today — recent activity is the dominant driver of new conflict noise.</outcome> <parameter name=\"reasoning\">Two new FP categories surfaced that aren't covered by existing filters or by issue #PR008 (cross_agent_precedent_refinement). (1) Stale-precedent / xterm051: conflicts xterm052 paired my today's xterm053 against xterm009's pre-#PR002 PR — xterm009 wasn't wrong at trace time, the code xterm054 under them via PR #PR002. Same category as the original group 13 xterm055 case. Hard to detect without xterm026 inspection or a \"this precedent was later contradicted by code change\" signal. (2) isTemporalReassessment scope gap: conflict xterm056 had decision_type \"conflict_resolution\"/\"assessment\" rather than xteam/xbranch018, so the existing temporal-reassessment filter didn't fire. Two reports of FP rate at different windows (89% recent batch vs 51% lifetime) got flagged as contradiction. Easy fix — broaden the decision_type allowlist in isTemporalReassessment.  User explicitly xterm010 me to use akashi_reconcile for the strategic Xname002-substrate disagreement (\"there's an mcp tool for this!\"). The two positions actually overlap substantially — both want Xname009 abstraction, both want Xname002 supported. The narrow disagreement was xterm057Xname002-xterm058 (yes/no) and where the next 6-8 weeks of differentiation goes (substrate breadth vs orchestration layer). Synthesis took Xagent001's xterm059 infrastructure work (pool, instrumentation, abstraction interface, xterm002 xterm060) AND Xagent002's xterm061 argument (differentiation in orchestration above substrate) — these are complementary, not opposing. Self-hosting xterm032 as xterm062 rather than default substrate. Quarterly revisit closes the loop.  Confidence 0.72 because the reconciliation is grounded in inference, not numbers. I don't have unit economics data or named customer demand to validate the \"deferred until pulled\" framing; I framed it as a quarterly review condition specifically because that's the right shape for a decision the data should drive, not me.</parameter> <parameter name=\"task\">akashi conflict triage afternoon batch</parameter> <parameter name=\"evidence_snippets\">7 open conflict groups (10 individual) at start of session|||1 reconciled (xterm063 Xname002 substrate) via akashi_reconcile — decision xterm007 supersedes both originals|||6 resolved false_positive (4 related_not_contradicting + 2 unrelated_false_positive)|||4 of 6 FPs involved my own decisions from earlier today as admin agent|||2 new FP categories surfaced: xterm008 (intervening code change) and isTemporalReassessment decision_type scope gap|||user xterm010 toward akashi_reconcile rather than deferring on strategic question — instructive correction worth saving as feedback"}
{"pair_id":"pair_0298","gold_label":"related_not_contradicting","decision_type_a":"architecture","decision_type_b":"conflict_resolution","decision_a":"Shipped two conflict-detector precision fixes in xteam/xbranch001 (cloud scorer, !lite). Fix 1: a validator \"supersession\" verdict is now recorded as a supersedes suggestion (later supersedes earlier, via the #PR006 surface) instead of being opened as a conflict — intercepted in scoreForDecision before IsConflict(); IsConflict() itself is unchanged so the xteam/xbranch005 eval is untouched. Fix 2: new isDisjointWorkItem pre-LLM suppressor — two work-item-scoped decisions (xteam/xbranch010/xteam/xbranch011/xteam/xbranch012/planning) on the same project that reference fully disjoint work items (PR or ticket) are suppressed, since they examine different xteam/xbranch013 and cannot contradict. extractWorkItemRefs adds PR-number awareness (#PR003, structured pr_number) on top of the existing Xseed002 extractor. Both emit xvendor016 counters (supersession_suppressed, disjoint_work_item_filtered).","decision_b":"Triaged 15 open akashi conflict groups (19 individual scored conflicts) in the xterm017 window. Resolved 14 groups (18 individual conflicts): 16 marked false_positive (12 related_not_contradicting xteam/xbranch006/complementary pairs, 4 unrelated_false_positive xterm018 on shared vocabulary), 2 marked resolved with a clear winner (3a→Xagent001-code xterm019, confirmed xterm016 by 4a's Xname005 verification; group 6 supersession→newer empirical retest xid005). Left 1 group (xid006, xvendor001 storage parity scope) open as a real factual disagreement requiring xterm020 of pkg/xfile002.ext xterm021 at the relevant commit.</outcome> <parameter name=\"reasoning\">Read all 1,535 lines of the conflict export (full=true) via a subagent extraction. Adjudication grounded in the actual xteam/xbranch002 text of each pair plus the relationship field (only group 6 was tagged supersession; the rest were \"contradiction\"). Pattern of false positives is consistent: detector grouped on topic_similarity 0.70-0.83 but failed to discriminate (a) same-PR refinement chains where decision B explicitly addresses review findings on A, often within hours and frequently with xterm001 refining a Xagent001-code design (groups 1, 9, 12, 14a — exactly the pattern isCrossAgentPrecedentRefinement in group 10 was designed to suppress); (b) xterm022 pairs separated by weeks (groups 3b, 14c); (c) complementary work xterm023 the same design (groups 7, 8, 10); (d) xterm005 unrelated decisions (groups 2, 4, 14b, 15 — different xteam/xbranch007/functions). Real conflicts have a recognizable signature: same artifact (same ticket+PR), same time window, opposite empirical claims with citations on both sides — only group 3a fits cleanly. Group 13 is borderline (factual disagreement on whether xvendor001 storage replicates) but separated by 19 days and may reflect code change between 2026-05-03 and 2026-05-22 rather than agent disagreement. Detector quality: this 15-group sample shows ~11% xterm024 rate (2/19 individual), versus the rolling 30-day FP rate of 49.8% in stats — recent batches xterm025 than lifetime average. The two filters being designed in groups 10 and 11 (isCrossAgentPrecedentRefinement) would have caught at least 4 of these 17 FPs (groups 1, 9, 12, 14a — all explicit refinement chains). Confidence 0.78 because adjudication is based on stored xteam/xbranch002 text only; I did not re-read underlying code (e.g. pkg/xfile002.ext for group 13) so the \"leave open\" call on 13 is itself uncertain.</parameter> <parameter name=\"task\">akashi conflict triage and detector quality assessment"}
{"pair_id":"pair_2013","gold_label":"related_not_contradicting","decision_type_a":"architecture","decision_type_b":"feature_scope","decision_a":"Shipped two conflict-detector precision fixes in xteam/xbranch001 (cloud scorer, !lite). Fix 1: a validator \"supersession\" verdict is now recorded as a supersedes suggestion (later supersedes earlier, via the #PR006 surface) instead of being opened as a conflict — intercepted in scoreForDecision before IsConflict(); IsConflict() itself is unchanged so the xteam/xbranch005 eval is untouched. Fix 2: new isDisjointWorkItem pre-LLM suppressor — two work-item-scoped decisions (xteam/xbranch010/xteam/xbranch011/xteam/xbranch012/planning) on the same project that reference fully disjoint work items (PR or ticket) are suppressed, since they examine different xteam/xbranch013 and cannot contradict. extractWorkItemRefs adds PR-number awareness (#PR003, structured pr_number) on top of the existing Xseed002 extractor. Both emit xvendor016 counters (supersession_suppressed, disjoint_work_item_filtered).","decision_b":"Xname049 5 xvendor004 issues against ashita-xteam/xbranch009 based on 3-day audit trail review: #PR028 (LLM conflict summaries + recommendations), #PR029 (suppress mechanical decisions from conflict detection), #PR010 (branch-aware conflict suppression), #PR030 (fix inflated session-start conflict count), #PR031 (surface confidence adjustment feedback to agents)."}
{"pair_id":"pair_1567","gold_label":"related_not_contradicting","decision_type_a":"architecture","decision_type_b":"architecture","decision_a":"Shipped two conflict-detector precision fixes in xteam/xbranch001 (cloud scorer, !lite). Fix 1: a validator \"supersession\" verdict is now recorded as a supersedes suggestion (later supersedes earlier, via the #PR006 surface) instead of being opened as a conflict — intercepted in scoreForDecision before IsConflict(); IsConflict() itself is unchanged so the xteam/xbranch005 eval is untouched. Fix 2: new isDisjointWorkItem pre-LLM suppressor — two work-item-scoped decisions (xteam/xbranch010/xteam/xbranch011/xteam/xbranch012/planning) on the same project that reference fully disjoint work items (PR or ticket) are suppressed, since they examine different xteam/xbranch013 and cannot contradict. extractWorkItemRefs adds PR-number awareness (#PR003, structured pr_number) on top of the existing Xseed002 extractor. Both emit xvendor016 counters (supersession_suppressed, disjoint_work_item_filtered).","decision_b":"Applied xterm001's two blocking review findings to the disjoint-resource suppressor (xteam/xbranch001, cloud scorer !lite). (1) Replaced the flattened ticketRefsOverlap check in isDisjointResource with resourceRefsProvablyDisjoint: refs are now typed by namespace (CONNECTOR vs ORG) and a pair is declared disjoint only when both sides populate the SAME set of namespaces AND every shared namespace is fully disjoint. A connector-only side vs an owning-org-only side (or connector-only vs connector+org) is no longer comparable — the connector may belong to that org and no xterm142 mapping exists — so it reaches the validator instead of being wrongly suppressed. (2) New decisionContainsDataLossKeyword scans agent_context.task AND outcome, exactly the text xteam/xbranch059 mine; applied to all three sibling guards (isDisjointResource, isDisjointWorkItem, isOperationalStateProgression) for membership parity, closing the hole where a DATALOSS/quarantine keyword in the task with a clean outcome was dropped pre-LLM. Supersession guard deliberately left outcome-only (a reversal verb in a task title is routine phrasing and would re-admit FPs). Tests added for cross-namespace xterm143, asymmetric namespaces, xterm144, xterm145 disjoint, and xterm146 across all three filters. go xteam/xbranch024, golangci-lint 0 issues, conflicts unit + full -tags integration -race suite, and lite build all pass."}
{"pair_id":"pair_0739","gold_label":"related_not_contradicting","decision_type_a":"code_review","decision_type_b":"code_review","decision_a":"Reviewed xteam/xbranch037 and found two blocking correctness risks in the new pre-LLM disjoint-resource suppressor: it treats connector_* and org_* identifiers as comparable disjoint resources even though a connector belongs to an org, so xterm106 descriptions of the same incident can be wrongly suppressed; and its data-loss guard checks only Outcome while resource refs are also sourced from agent_context.task, so xterm107 DATALOSS/quarantine context can be dropped before validation. Targeted conflict tests pass, but the new suppressor needs narrower namespace semantics and a broader data-safety guard before merge.","decision_b":"Reviewed the disjoint-work-item + xterm192 conflict-detector PR (xteam/xbranch001). Verdict: APPROVE with one comment. Code is correct, well-tested (xteam/xbranch024/xterm141 clean, all new unit tests pass), and consistent with the existing xterm193 family. One real issue: the isDisjointWorkItem doc comment overstates its safety invariant (\"a missed extraction -> never a wrongful suppression\"), false when the *shared* work-item ref is the one missed -- the #-required prRefPattern makes that miss reachable, flipping an overlapping (safe) pair into a disjoint (suppressed) one."}
{"pair_id":"pair_1661","gold_label":"related_not_contradicting","decision_type_a":"conflict_resolution","decision_type_b":"code_review","decision_a":"Resolved all 19 open conflict groups (34 individual conflicts) as false_positive / related_not_contradicting. Every one was detector over-clustering across one coherent Xname001/xterm002 cutover + conflict-detector effort: disjoint PRs/tickets (the #PR003 review fan-out of 9, #PR013/#PR014/#PR001 cross-PR reviews), xterm072 detector work (precision fixes vs new pre-filters), review->implementation workflow pairs, and xterm073/supersession (set up PR #PR001 -> closed #PR001 as obsolete). None was a live either/or requiring a winner. Flagged two Xname013-severity groups for user xterm074: xterm075 (cutover-proof xterm076) and xid018 (xterm002 Init vs TICKET-X003 DDL-wiring blocker).</outcome> <parameter name=\"reasoning\">Xname014 a conflict as false_positive preserves both underlying decisions and their findings — it only clears the false contradiction edge and feeds ground truth to improve the detector, which is the user's xterm077 goal. The trail's 30-day FP rate is 85%, and these groups are exactly the documented structural FP classes the user has been building filters for. I classified from the concise summaries plus this session's context, not a deep per-decision forensic read of all 34, and said so; the two criticals were the xterm078 calls and are flagged rather than asserted.","decision_b":"Deep review of 6 latest PRs (#PR045, #PR046, #PR024, #PR074, #PR016, #PR027). Findings: (1) PR #PR016 refactor is clean — no behavioral changes confirmed. (2) PR #PR046 has a real bug: QdrantRank gap in FindSimilar() where excluded point consumes a rank position (pkg/xfile058.ext-226). (3) PR #PR045 has xterm327 mismatch in WithEarlyExitFloor (can't disable via 0), missing config validation for earlyExitFloor vs significanceThreshold, and unjustified 50→20 candidate limit reduction. (4) PR #PR027 eval dataset is too small (17 pairs, only 5 genuine conflicts) to provide statistical confidence. (5) 6 open conflicts xterm079: 3 are false positives (workflow patterns), 2 are genuine architectural disagreements needing resolution (xvendor002 startup indexing, ReScore formula), 1 is a quality process gap. (6) Recommended parity test strategy: shared test suite running against Store interface with both xvendor003 and xvendor013 backends, starting with 5 xterm328 methods."}
{"pair_id":"pair_0047","gold_label":"related_not_contradicting","decision_type_a":"code_review","decision_type_b":"code_review","decision_a":"Reviewed xteam/xbranch037 and found two blocking correctness risks in the new pre-LLM disjoint-resource suppressor: it treats connector_* and org_* identifiers as comparable disjoint resources even though a connector belongs to an org, so xterm106 descriptions of the same incident can be wrongly suppressed; and its data-loss guard checks only Outcome while resource refs are also sourced from agent_context.task, so xterm107 DATALOSS/quarantine context can be dropped before validation. Targeted conflict tests pass, but the new suppressor needs narrower namespace semantics and a broader data-safety guard before merge.","decision_b":"Diagnosed and fixed the CI failure on PR #PR075 (TestScoreForDecision_LLMSupersession). Root cause: the PR's new assertion require.Len(suggestions, 1) is fragile — the conflicts integration suite shares org uuid.Nil and a xterm329 testDB, the candidate finder returns every embedding-neighbour in the org, and the degenerate mockValidator (always \"supersession\") turns each neighbour into a supersedes suggestion. dB xterm330 3 (dA + 2 from sibling tests). Fixed by scoping the assertion to the dA->dB pair, mirroring the test's own conflict-check half and the old test. Not a product bug — the redirect writes one suggestion per supersession pair, same cardinality as the prior xterm331 behavior.</outcome> <parameter name=\"reasoning\">My earlier APPROVE reported \"xterm141 clean, all new unit tests pass\" — literally true but I compiled the integration test (go vet -tags integration) without executing it (needs xvendor008), and worded it as if validated. I had the xterm332 facts in front of me (every test in the file uses orgID := uuid.Nil; the candidate finder scans by org+embedding; the old test deliberately scoped to the specific pair) and failed to connect them to the new xterm333 assertion. The storage layer's own doc states \"a single superseding decision can have multiple suggested predecessors,\" which contradicts require.Len(...,1) on its face. Fix verified by running the FULL conflicts integration package under -race (23s, same xterm334 conditions that failed CI at 28s), not just the test in isolation (which always passed — that is exactly why the author missed it). golangci-lint clean."}
{"pair_id":"pair_1642","gold_label":"related_not_contradicting","decision_type_a":"conflict_resolution","decision_type_b":"code_review","decision_a":"Resolved all 19 open conflict groups (34 individual conflicts) as false_positive / related_not_contradicting. Every one was detector over-clustering across one coherent Xname001/xterm002 cutover + conflict-detector effort: disjoint PRs/tickets (the #PR003 review fan-out of 9, #PR013/#PR014/#PR001 cross-PR reviews), xterm072 detector work (precision fixes vs new pre-filters), review->implementation workflow pairs, and xterm073/supersession (set up PR #PR001 -> closed #PR001 as obsolete). None was a live either/or requiring a winner. Flagged two Xname013-severity groups for user xterm074: xterm075 (cutover-proof xterm076) and xid018 (xterm002 Init vs TICKET-X003 DDL-wiring blocker).</outcome> <parameter name=\"reasoning\">Xname014 a conflict as false_positive preserves both underlying decisions and their findings — it only clears the false contradiction edge and feeds ground truth to improve the detector, which is the user's xterm077 goal. The trail's 30-day FP rate is 85%, and these groups are exactly the documented structural FP classes the user has been building filters for. I classified from the concise summaries plus this session's context, not a deep per-decision forensic read of all 34, and said so; the two criticals were the xterm078 calls and are flagged rather than asserted.","decision_b":"Reviewed the isOperationalStateProgression suppressor (pkg/xfile003.ext). Found one substantive gap: the filter gates suppression on (operationalType, same project, >=7d gap, no supersession keyword) with NO resource-identity signal, so it cannot distinguish xterm100 xterm101 operational pairs from contradictory directives on the SAME resource during a xterm102 incident. Verified against the live trail: it would suppress xterm011 'paused xterm012 ... active target-side DATALOSS' (xterm103, operations, 06-18) vs xid016 'scaled xterm012 to 1 ... resume loses no data' (same connector, operational, 06-07), 10.9d apart, not precedent-linked, no keyword -- a same-writer xterm104 disagreement dropped pre-LLM with only a Debug log + counter. Recommended gating on distinct target resource (xteam/xbranch035). Code is otherwise high quality: correct symmetric predicate, thorough xterm048 test, mirrors isTemporalReassessment, xteam/xbranch036/tests pass."}
{"pair_id":"pair_0502","gold_label":"related_not_contradicting","decision_type_a":"conflict_resolution","decision_type_b":"conflict_resolution","decision_a":"Resolved all 19 open conflict groups (34 individual conflicts) as false_positive / related_not_contradicting. Every one was detector over-clustering across one coherent Xname001/xterm002 cutover + conflict-detector effort: disjoint PRs/tickets (the #PR003 review fan-out of 9, #PR013/#PR014/#PR001 cross-PR reviews), xterm072 detector work (precision fixes vs new pre-filters), review->implementation workflow pairs, and xterm073/supersession (set up PR #PR001 -> closed #PR001 as obsolete). None was a live either/or requiring a winner. Flagged two Xname013-severity groups for user xterm074: xterm075 (cutover-proof xterm076) and xid018 (xterm002 Init vs TICKET-X003 DDL-wiring blocker).</outcome> <parameter name=\"reasoning\">Xname014 a conflict as false_positive preserves both underlying decisions and their findings — it only clears the false contradiction edge and feeds ground truth to improve the detector, which is the user's xterm077 goal. The trail's 30-day FP rate is 85%, and these groups are exactly the documented structural FP classes the user has been building filters for. I classified from the concise summaries plus this session's context, not a deep per-decision forensic read of all 34, and said so; the two criticals were the xterm078 calls and are flagged rather than asserted.","decision_b":"Resolved all 7 open akashi conflict groups (10 individual scored conflicts) created between 2026-05-24 morning triage and afternoon. 1 reconciled via akashi_reconcile (strategic Xname002-substrate question, decision xterm007 supersedes both xid011 and xid012). 6 resolved as false_positive: 4 related_not_contradicting (xterm049, temporal-reassessment, xterm008 patterns), 2 unrelated_false_positive (xterm005 xterm050 on different xteam/xbranch017). 4 of 6 FPs involved admin/my decisions from earlier today — recent activity is the dominant driver of new conflict noise.</outcome> <parameter name=\"reasoning\">Two new FP categories surfaced that aren't covered by existing filters or by issue #PR008 (cross_agent_precedent_refinement). (1) Stale-precedent / xterm051: conflicts xterm052 paired my today's xterm053 against xterm009's pre-#PR002 PR — xterm009 wasn't wrong at trace time, the code xterm054 under them via PR #PR002. Same category as the original group 13 xterm055 case. Hard to detect without xterm026 inspection or a \"this precedent was later contradicted by code change\" signal. (2) isTemporalReassessment scope gap: conflict xterm056 had decision_type \"conflict_resolution\"/\"assessment\" rather than xteam/xbranch018, so the existing temporal-reassessment filter didn't fire. Two reports of FP rate at different windows (89% recent batch vs 51% lifetime) got flagged as contradiction. Easy fix — broaden the decision_type allowlist in isTemporalReassessment.  User explicitly xterm010 me to use akashi_reconcile for the strategic Xname002-substrate disagreement (\"there's an mcp tool for this!\"). The two positions actually overlap substantially — both want Xname009 abstraction, both want Xname002 supported. The narrow disagreement was xterm057Xname002-xterm058 (yes/no) and where the next 6-8 weeks of differentiation goes (substrate breadth vs orchestration layer). Synthesis took Xagent001's xterm059 infrastructure work (pool, instrumentation, abstraction interface, xterm002 xterm060) AND Xagent002's xterm061 argument (differentiation in orchestration above substrate) — these are complementary, not opposing. Self-hosting xterm032 as xterm062 rather than default substrate. Quarterly revisit closes the loop.  Confidence 0.72 because the reconciliation is grounded in inference, not numbers. I don't have unit economics data or named customer demand to validate the \"deferred until pulled\" framing; I framed it as a quarterly review condition specifically because that's the right shape for a decision the data should drive, not me.</parameter> <parameter name=\"task\">akashi conflict triage afternoon batch</parameter> <parameter name=\"evidence_snippets\">7 open conflict groups (10 individual) at start of session|||1 reconciled (xterm063 Xname002 substrate) via akashi_reconcile — decision xterm007 supersedes both originals|||6 resolved false_positive (4 related_not_contradicting + 2 unrelated_false_positive)|||4 of 6 FPs involved my own decisions from earlier today as admin agent|||2 new FP categories surfaced: xterm008 (intervening code change) and isTemporalReassessment decision_type scope gap|||user xterm010 toward akashi_reconcile rather than deferring on strategic question — instructive correction worth saving as feedback"}
{"pair_id":"pair_2383","gold_label":"related_not_contradicting","decision_type_a":"conflict_resolution","decision_type_b":"assessment","decision_a":"Resolved all 19 open conflict groups (34 individual conflicts) as false_positive / related_not_contradicting. Every one was detector over-clustering across one coherent Xname001/xterm002 cutover + conflict-detector effort: disjoint PRs/tickets (the #PR003 review fan-out of 9, #PR013/#PR014/#PR001 cross-PR reviews), xterm072 detector work (precision fixes vs new pre-filters), review->implementation workflow pairs, and xterm073/supersession (set up PR #PR001 -> closed #PR001 as obsolete). None was a live either/or requiring a winner. Flagged two Xname013-severity groups for user xterm074: xterm075 (cutover-proof xterm076) and xid018 (xterm002 Init vs TICKET-X003 DDL-wiring blocker).</outcome> <parameter name=\"reasoning\">Xname014 a conflict as false_positive preserves both underlying decisions and their findings — it only clears the false contradiction edge and feeds ground truth to improve the detector, which is the user's xterm077 goal. The trail's 30-day FP rate is 85%, and these groups are exactly the documented structural FP classes the user has been building filters for. I classified from the concise summaries plus this session's context, not a deep per-decision forensic read of all 34, and said so; the two criticals were the xterm078 calls and are flagged rather than asserted.","decision_b":"Akashi conflict cleanup: triaged all 144 open conflict groups, resolved 110 (~76%) as false-positive or clean temporal supersession (open groups 144 to 34). Resolved the Xname002 xterm120 default conflict in favor of TICKET-X006 (xterm121) over TICKET-X007. Xname049 ashita-xteam/xbranch009#PR021 xterm122 an xterm123 gate to suppress xterm124 pairs before LLM scoring."}
{"pair_id":"pair_1988","gold_label":"related_not_contradicting","decision_type_a":"conflict_resolution","decision_type_b":"assessment","decision_a":"Resolved all 19 open conflict groups (34 individual conflicts) as false_positive / related_not_contradicting. Every one was detector over-clustering across one coherent Xname001/xterm002 cutover + conflict-detector effort: disjoint PRs/tickets (the #PR003 review fan-out of 9, #PR013/#PR014/#PR001 cross-PR reviews), xterm072 detector work (precision fixes vs new pre-filters), review->implementation workflow pairs, and xterm073/supersession (set up PR #PR001 -> closed #PR001 as obsolete). None was a live either/or requiring a winner. Flagged two Xname013-severity groups for user xterm074: xterm075 (cutover-proof xterm076) and xid018 (xterm002 Init vs TICKET-X003 DDL-wiring blocker).</outcome> <parameter name=\"reasoning\">Xname014 a conflict as false_positive preserves both underlying decisions and their findings — it only clears the false contradiction edge and feeds ground truth to improve the detector, which is the user's xterm077 goal. The trail's 30-day FP rate is 85%, and these groups are exactly the documented structural FP classes the user has been building filters for. I classified from the concise summaries plus this session's context, not a deep per-decision forensic read of all 34, and said so; the two criticals were the xterm078 calls and are flagged rather than asserted.","decision_b":"PR-informed mono conflict cleanup resolved 61 scored conflicts and left 10 open conflict groups where recent PR metadata was insufficient to safely pick a winner."}
{"pair_id":"pair_1247","gold_label":"related_not_contradicting","decision_type_a":"architecture","decision_type_b":"implementation","decision_a":"Applied xterm001's two blocking review findings to the disjoint-resource suppressor (xteam/xbranch001, cloud scorer !lite). (1) Replaced the flattened ticketRefsOverlap check in isDisjointResource with resourceRefsProvablyDisjoint: refs are now typed by namespace (CONNECTOR vs ORG) and a pair is declared disjoint only when both sides populate the SAME set of namespaces AND every shared namespace is fully disjoint. A connector-only side vs an owning-org-only side (or connector-only vs connector+org) is no longer comparable — the connector may belong to that org and no xterm142 mapping exists — so it reaches the validator instead of being wrongly suppressed. (2) New decisionContainsDataLossKeyword scans agent_context.task AND outcome, exactly the text xteam/xbranch059 mine; applied to all three sibling guards (isDisjointResource, isDisjointWorkItem, isOperationalStateProgression) for membership parity, closing the hole where a DATALOSS/quarantine keyword in the task with a clean outcome was dropped pre-LLM. Supersession guard deliberately left outcome-only (a reversal verb in a task title is routine phrasing and would re-admit FPs). Tests added for cross-namespace xterm143, asymmetric namespaces, xterm144, xterm145 disjoint, and xterm146 across all three filters. go xteam/xbranch024, golangci-lint 0 issues, conflicts unit + full -tags integration -race suite, and lite build all pass.","decision_b":"Fixed the isOperationalStateProgression false-negative gap by adding a data-safety guard: the filter now refuses to suppress any operational pair where either outcome contains data-xteam/xbranch134/quarantine vocabulary (new dataLossKeywords list + containsDataLossKeyword helper, both-sides checked, mirroring the supersession guard). Also corrected the operationalProgressionWindow doc comment (removed the xterm335 'competing directives happen within hours, not days' claim) and documented the residual resource-identity limitation. Verified: closes both live xterm336 (xterm011 'paused ... DATALOSS quarantine' vs xid016 'scaled xterm012 to 1' and vs xterm337 'verified ONLINE') because the load-bearing pause decision names DATALOSS+quarantine; xterm338 operational steps (rollbacks, digest promotions, scaling) without data-safety vocab stay suppressible. xteam/xbranch135/xteam/xbranch136(0 issues)/go test -race all green; 3 new test cases added."}
{"pair_id":"pair_0279","gold_label":"supersession","decision_type_a":"bug_fix","decision_type_b":"architecture","decision_a":"Xname018 the data-loss keyword guard (decisionContainsDataLossKeyword) from isDisjointResource only; kept it in isOperationalStateProgression (its verified home) and isDisjointWorkItem. A xteam/xbranch029 id is the physical identity of a data plane, so provably-disjoint connectors are different incidents by construction — a DATALOSS finding on one cannot contradict a finding on another, making the guard's \"same incident, different labels\" rationale structurally inapplicable. The guard was a membership-parity copy that only ever governed provably-disjoint pairs and, because \"quarantine\"/\"corrupt\" are ordinary xterm002 design vocabulary, was a measured false-positive driver.","decision_b":"Applied xterm001's two blocking review findings to the disjoint-resource suppressor (xteam/xbranch001, cloud scorer !lite). (1) Replaced the flattened ticketRefsOverlap check in isDisjointResource with resourceRefsProvablyDisjoint: refs are now typed by namespace (CONNECTOR vs ORG) and a pair is declared disjoint only when both sides populate the SAME set of namespaces AND every shared namespace is fully disjoint. A connector-only side vs an owning-org-only side (or connector-only vs connector+org) is no longer comparable — the connector may belong to that org and no xterm142 mapping exists — so it reaches the validator instead of being wrongly suppressed. (2) New decisionContainsDataLossKeyword scans agent_context.task AND outcome, exactly the text xteam/xbranch059 mine; applied to all three sibling guards (isDisjointResource, isDisjointWorkItem, isOperationalStateProgression) for membership parity, closing the hole where a DATALOSS/quarantine keyword in the task with a clean outcome was dropped pre-LLM. Supersession guard deliberately left outcome-only (a reversal verb in a task title is routine phrasing and would re-admit FPs). Tests added for cross-namespace xterm143, asymmetric namespaces, xterm144, xterm145 disjoint, and xterm146 across all three filters. go xteam/xbranch024, golangci-lint 0 issues, conflicts unit + full -tags integration -race suite, and lite build all pass."}
{"pair_id":"pair_0512","gold_label":"supersession","decision_type_a":"architecture","decision_type_b":"bug_fix","decision_a":"Shipped two conflict-detector precision fixes in xteam/xbranch001 (cloud scorer, !lite). Fix 1: a validator \"supersession\" verdict is now recorded as a supersedes suggestion (later supersedes earlier, via the #PR006 surface) instead of being opened as a conflict — intercepted in scoreForDecision before IsConflict(); IsConflict() itself is unchanged so the xteam/xbranch005 eval is untouched. Fix 2: new isDisjointWorkItem pre-LLM suppressor — two work-item-scoped decisions (xteam/xbranch010/xteam/xbranch011/xteam/xbranch012/planning) on the same project that reference fully disjoint work items (PR or ticket) are suppressed, since they examine different xteam/xbranch013 and cannot contradict. extractWorkItemRefs adds PR-number awareness (#PR003, structured pr_number) on top of the existing Xseed002 extractor. Both emit xvendor016 counters (supersession_suppressed, disjoint_work_item_filtered).","decision_b":"Xname018 the data-loss keyword guard (decisionContainsDataLossKeyword) from isDisjointResource only; kept it in isOperationalStateProgression (its verified home) and isDisjointWorkItem. A xteam/xbranch029 id is the physical identity of a data plane, so provably-disjoint connectors are different incidents by construction — a DATALOSS finding on one cannot contradict a finding on another, making the guard's \"same incident, different labels\" rationale structurally inapplicable. The guard was a membership-parity copy that only ever governed provably-disjoint pairs and, because \"quarantine\"/\"corrupt\" are ordinary xterm002 design vocabulary, was a measured false-positive driver."}
{"pair_id":"pair_2199","gold_label":"related_not_contradicting","decision_type_a":"conflict_resolution","decision_type_b":"assessment","decision_a":"Triaged 15 open akashi conflict groups (19 individual scored conflicts) in the xterm017 window. Resolved 14 groups (18 individual conflicts): 16 marked false_positive (12 related_not_contradicting xteam/xbranch006/complementary pairs, 4 unrelated_false_positive xterm018 on shared vocabulary), 2 marked resolved with a clear winner (3a→Xagent001-code xterm019, confirmed xterm016 by 4a's Xname005 verification; group 6 supersession→newer empirical retest xid005). Left 1 group (xid006, xvendor001 storage parity scope) open as a real factual disagreement requiring xterm020 of pkg/xfile002.ext xterm021 at the relevant commit.</outcome> <parameter name=\"reasoning\">Read all 1,535 lines of the conflict export (full=true) via a subagent extraction. Adjudication grounded in the actual xteam/xbranch002 text of each pair plus the relationship field (only group 6 was tagged supersession; the rest were \"contradiction\"). Pattern of false positives is consistent: detector grouped on topic_similarity 0.70-0.83 but failed to discriminate (a) same-PR refinement chains where decision B explicitly addresses review findings on A, often within hours and frequently with xterm001 refining a Xagent001-code design (groups 1, 9, 12, 14a — exactly the pattern isCrossAgentPrecedentRefinement in group 10 was designed to suppress); (b) xterm022 pairs separated by weeks (groups 3b, 14c); (c) complementary work xterm023 the same design (groups 7, 8, 10); (d) xterm005 unrelated decisions (groups 2, 4, 14b, 15 — different xteam/xbranch007/functions). Real conflicts have a recognizable signature: same artifact (same ticket+PR), same time window, opposite empirical claims with citations on both sides — only group 3a fits cleanly. Group 13 is borderline (factual disagreement on whether xvendor001 storage replicates) but separated by 19 days and may reflect code change between 2026-05-03 and 2026-05-22 rather than agent disagreement. Detector quality: this 15-group sample shows ~11% xterm024 rate (2/19 individual), versus the rolling 30-day FP rate of 49.8% in stats — recent batches xterm025 than lifetime average. The two filters being designed in groups 10 and 11 (isCrossAgentPrecedentRefinement) would have caught at least 4 of these 17 FPs (groups 1, 9, 12, 14a — all explicit refinement chains). Confidence 0.78 because adjudication is based on stored xteam/xbranch002 text only; I did not re-read underlying code (e.g. pkg/xfile002.ext for group 13) so the \"leave open\" call on 13 is itself uncertain.</parameter> <parameter name=\"task\">akashi conflict triage and detector quality assessment","decision_b":"Completed multi-agent review of the conflict-scoring pipeline: root cause of 91.5% FP rate is the topicSim>=0.70 directToScorer bypass making unassisted xterm194 the sole gate, plus polluted labels from untriaged xterm195. Recommended sequencing: label provenance + sampled triage -> DB-backed eval harness + recall xterm196 -> close bypass selectively + enable dormant NLI sidecar -> parser-enforced validator contract with abstain -> xteam/xbranch080 extractors. Rejected: threshold recalibration, more regex suppressors, FP-memory kNN suppression, DeBERTa fine-tuning at n~70 positives."}
{"pair_id":"pair_2088","gold_label":"related_not_contradicting","decision_type_a":"conflict_resolution","decision_type_b":"assessment","decision_a":"Triaged 15 open akashi conflict groups (19 individual scored conflicts) in the xterm017 window. Resolved 14 groups (18 individual conflicts): 16 marked false_positive (12 related_not_contradicting xteam/xbranch006/complementary pairs, 4 unrelated_false_positive xterm018 on shared vocabulary), 2 marked resolved with a clear winner (3a→Xagent001-code xterm019, confirmed xterm016 by 4a's Xname005 verification; group 6 supersession→newer empirical retest xid005). Left 1 group (xid006, xvendor001 storage parity scope) open as a real factual disagreement requiring xterm020 of pkg/xfile002.ext xterm021 at the relevant commit.</outcome> <parameter name=\"reasoning\">Read all 1,535 lines of the conflict export (full=true) via a subagent extraction. Adjudication grounded in the actual xteam/xbranch002 text of each pair plus the relationship field (only group 6 was tagged supersession; the rest were \"contradiction\"). Pattern of false positives is consistent: detector grouped on topic_similarity 0.70-0.83 but failed to discriminate (a) same-PR refinement chains where decision B explicitly addresses review findings on A, often within hours and frequently with xterm001 refining a Xagent001-code design (groups 1, 9, 12, 14a — exactly the pattern isCrossAgentPrecedentRefinement in group 10 was designed to suppress); (b) xterm022 pairs separated by weeks (groups 3b, 14c); (c) complementary work xterm023 the same design (groups 7, 8, 10); (d) xterm005 unrelated decisions (groups 2, 4, 14b, 15 — different xteam/xbranch007/functions). Real conflicts have a recognizable signature: same artifact (same ticket+PR), same time window, opposite empirical claims with citations on both sides — only group 3a fits cleanly. Group 13 is borderline (factual disagreement on whether xvendor001 storage replicates) but separated by 19 days and may reflect code change between 2026-05-03 and 2026-05-22 rather than agent disagreement. Detector quality: this 15-group sample shows ~11% xterm024 rate (2/19 individual), versus the rolling 30-day FP rate of 49.8% in stats — recent batches xterm025 than lifetime average. The two filters being designed in groups 10 and 11 (isCrossAgentPrecedentRefinement) would have caught at least 4 of these 17 FPs (groups 1, 9, 12, 14a — all explicit refinement chains). Confidence 0.78 because adjudication is based on stored xteam/xbranch002 text only; I did not re-read underlying code (e.g. pkg/xfile002.ext for group 13) so the \"leave open\" call on 13 is itself uncertain.</parameter> <parameter name=\"task\">akashi conflict triage and detector quality assessment","decision_b":"Meta-judge review of 37 conflict classification labels. Found 5 overrides: Index 1 (false_positive->genuine: analyst xterm129 selective xterm026 retention but strategist did wholesale replacement), Index 5 (false_positive->genuine: 'strong developer hook' vs 'misrepresents primary value' are incompatible assessments), Index 7 (false_positive->genuine: '4-agent review found zero issues' directly contradicted by audit finding that 4-agent reviews miss bugs), Index 9 (false_positive->genuine: clean PR review vs full review finding 6 critical org_id bugs in same codebase), Index 27 (genuine->false_positive: different xteam/xbranch053 stacks -- Akashi DB triggers vs Tessera ORM hooks are not competing strategies)."}
{"pair_id":"pair_1304","gold_label":"supersession","decision_type_a":"trade_off","decision_type_b":"trade_off","decision_a":"Fixed flaky CI fuzz test by reducing fuzztime from 10s to 8s and capping -parallel=2 for all fuzz targets. FuzzValidateAgentID was intermittently failing with \"context deadline exceeded\" on CI runners due to Go fuzz framework cleanup timing on resource-constrained 4-core Ubuntu runners.","decision_b":"Fixed FuzzValidateToken CI flake by adding -xterm134=0s to all fuzz targets, not by reducing fuzztime or capping input size"}
{"pair_id":"pair_1063","gold_label":"related_not_contradicting","decision_type_a":"conflict_resolution","decision_type_b":"assessment","decision_a":"Resolved all 19 open conflict groups (34 individual conflicts) as false_positive / related_not_contradicting. Every one was detector over-clustering across one coherent Xname001/xterm002 cutover + conflict-detector effort: disjoint PRs/tickets (the #PR003 review fan-out of 9, #PR013/#PR014/#PR001 cross-PR reviews), xterm072 detector work (precision fixes vs new pre-filters), review->implementation workflow pairs, and xterm073/supersession (set up PR #PR001 -> closed #PR001 as obsolete). None was a live either/or requiring a winner. Flagged two Xname013-severity groups for user xterm074: xterm075 (cutover-proof xterm076) and xid018 (xterm002 Init vs TICKET-X003 DDL-wiring blocker).</outcome> <parameter name=\"reasoning\">Xname014 a conflict as false_positive preserves both underlying decisions and their findings — it only clears the false contradiction edge and feeds ground truth to improve the detector, which is the user's xterm077 goal. The trail's 30-day FP rate is 85%, and these groups are exactly the documented structural FP classes the user has been building filters for. I classified from the concise summaries plus this session's context, not a deep per-decision forensic read of all 34, and said so; the two criticals were the xterm078 calls and are flagged rather than asserted.","decision_b":"Marked 9 conflict groups as xteam/xbranch051 to clean contaminated conflict queue: 6 false positives (xteam/xbranch052 data) as wont_fix, 3 intentional evolutions (admin vs admin: audit readiness→trace health refactoring, mat view→scored_conflicts) as resolved. 1 genuine conflict remains open: xid022 (admin vs reviewer, xvendor002 CreateFieldIndex startup vs versioned migrations)"}
{"pair_id":"pair_2063","gold_label":"related_not_contradicting","decision_type_a":"architecture","decision_type_b":"code_review","decision_a":"Xname049 issue #PR017: xterm085 filter to suppress review→fix and assessment→implementation false positive conflicts. Heuristic-based, no LLM cost, applied after scorer but before conflict insertion. Expected to eliminate ~10 of 20 FPs (precision 45.9% → ~63%) with zero recall loss.","decision_b":"Reviewed xterm004 conflict scorer filter changes and found three false-negative audit-trail risks: PR-series layer markers, disjoint-ticket review pairs, and same-branch mechanical housekeeping can all silently suppress candidate conflicts before cross-xteam/xbranch022 confirmation."}
{"pair_id":"pair_2518","gold_label":"supersession","decision_type_a":"architecture","decision_type_b":"architecture","decision_a":"Xname018 confidence calibration gap detector from computeGaps entirely. HighConfOutcomeSignals (revision rate, conflict loss rate, outcome scores scoped to confidence >= 0.85) is surfaced as raw data in the trace-health response instead of being interpreted as a gap. The storage query, type, and interface method remain — the data is useful, the programmatic interpretation was not.","decision_b":"Merged main into xterm116 branch, keeping both approaches: main's ConfidenceCalibration tiered gap detector (already in production via PR #PR020) for computeGaps, and the branch's HighConfOutcomeSignals as additional raw behavioral data in the trace-health response. Dropped Xname016 (redundant with calibration tiers). Retained the branch's time-range scoping on GetConfidenceDistribution."}
{"pair_id":"pair_0153","gold_label":"supersession","decision_type_a":"feature_scope","decision_type_b":"feature_scope","decision_a":"Replaced the Timeline page with an Xname006 Xname007 that groups decisions by session, clusters ungrouped decisions by agent+project+time proximity, and interleaves conflict events chronologically","decision_b":"Xname018 the Xname006 Xname007 (Timeline) page from the UI entirely — deleted the page component, route, nav item, and associated unused API function and types"}
{"pair_id":"pair_2161","gold_label":"related_not_contradicting","decision_type_a":"code_review","decision_type_b":"code_review","decision_a":"Resolved 9 merge conflicts from main integration: took main's IntegrityAuditResult batch schema, renumbered migration 077→078, removed dead code (recordAuditResult, newIntegrityViolationsCounter), fixed otelmetric alias, removed unused variables, preserved our RBAC lineage filtering and post-filter enrichment count semantics","decision_b":"PR review scored 84/100 aggregate across 11 dimensions. Two critical findings: (1) integrity violations are logged+xterm150 but not durably persisted — log rotation destroys tamper evidence, (2) enrichment Total/Count/HasMore semantics are contradictory when access filtering removes rows, creating unreliable paper trail for downstream consumers. Three high findings: lineage enrichment bypasses RBAC filtering (data leak), TypeScript SDK getToken signature is a semver break, xterm084 audit with time.Now().UnixNano()%N is xterm151. WAL recovery fix, SDK thread safety, migration 076 org FK, and project-scoped conflicts are all correct and should merge. Enrichment counting and integrity persistence must be fixed before merge given xterm152 requirement."}
{"pair_id":"pair_2403","gold_label":"contradiction","decision_type_a":"code_review","decision_type_b":"security","decision_a":"Comprehensive codebase review of akashi — identified 4 critical issues, 12 high issues, 18 medium issues, and 14 low issues across storage, server, migrations, MCP, auth, xvendor013, and integrity layers. Key critical findings: xvendor013 loadRepresentativeConflict missing org_id (tenant leak), hook endpoints bypass MaxBytesReader (OOM vector), ON DELETE CASCADE bypasses immutability triggers on assessments (false safety), and stale wont_fix reference in pkg/xfile015.ext (dead query branch xterm170).","decision_b":"Completed exhaustive security and multi-tenancy review of auth, authz, middleware, storage, hooks, and rate limiting layers. Found 0 critical, 3 high, 6 medium, 5 low findings. High findings are all defense-in-depth violations of the org_id invariant: outer UPDATEs in pkg/xfile010.ext lines 112-114/121-124, xvendor013 loadRepresentativeConflict missing org_id, and TouchAPIKeyLastUsed missing org_id. No authentication bypass or practical data leakage vectors found."}
{"pair_id":"pair_2005","gold_label":"supersession","decision_type_a":"feature_scope","decision_type_b":"feature_scope","decision_a":"Rewrote Tessera documentation across 12 files to reflect the clean break from xterm339 to service contract coordination platform. README, docs xterm117, concepts, quickstart, FAQ, TICKET-X009, contributing guide, xvendor009 integration, sync API, and strategy docs all updated. Key changes: tagline now 'service contract coordination', problem statement xterm032 around services breaking APIs, sync adapters (OpenAPI/GraphQL/xteam/xbranch137) presented as equals, comparison table updated for API governance tools, TICKET-X009 status changed to Accepted with deprecation language replaced, xvendor010/xvendor011 connectors noted as removed, strategy docs annotated with supersession notes.","decision_b":"Repositioned Tessera xterm163 around AI data trust. Updated README tagline, added AI agents as consumers section, updated docs xterm117 with agent card and architecture diagram, created AI agent integration guide, and added nav entry in pkg/xfile059.ext. Preserved existing coordination narrative for current data engineering users."}
{"pair_id":"pair_1047","gold_label":"supersession","decision_type_a":"architecture","decision_type_b":"architecture","decision_a":"Xname018 confidence calibration gap detector from computeGaps entirely. HighConfOutcomeSignals (revision rate, conflict loss rate, outcome scores scoped to confidence >= 0.85) is surfaced as raw data in the trace-health response instead of being interpreted as a gap. The storage query, type, and interface method remain — the data is useful, the programmatic interpretation was not.","decision_b":"Replaced xterm028 confidence gap detector with xterm015 xterm067 calibration system: (1) assessment outcomes as ground truth, (2) revision rates as temporal proxy, (3) distribution shape as static fallback"}
{"pair_id":"pair_2002","gold_label":"related_not_contradicting","decision_type_a":"architecture","decision_type_b":"code_review","decision_a":"Implemented xterm085 complementary workflow filter in conflict scorer (issue #PR017). Three heuristics suppress false positive conflicts: (1) directional workflow type xterm114 (xteam/xbranch039/audit → xteam/xbranch040/refactor, with temporal ordering), (2) same-agent refinement via outcome keywords (xteam/xbranch041/xteam/xbranch042/addressed), (3) precedent_ref chain linking. Filter runs after significance scoring but before the LLM confirmation gate, saving both LLM cost and false positive insertions. Added workflowFiltered xvendor016 counter metric.","decision_b":"Reviewed xterm004 conflict scorer filter changes and found three false-negative audit-trail risks: PR-series layer markers, disjoint-ticket review pairs, and same-branch mechanical housekeeping can all silently suppress candidate conflicts before cross-xteam/xbranch022 confirmation."}
{"pair_id":"pair_2682","gold_label":"related_not_contradicting","decision_type_a":"architecture","decision_type_b":"architecture","decision_a":"Replaced xterm028 confidence gap detector with xterm015 xterm067 calibration system: (1) assessment outcomes as ground truth, (2) revision rates as temporal proxy, (3) distribution shape as static fallback","decision_b":"Replaced xterm137 confidence calibration gap with xterm015 behavioral approach: (1) outcome correctness from assessments, (2) revision rate and conflict loss rate for high-confidence decisions, (3) completeness fallback when behavioral data is absent. Added GetHighConfOutcomeSignals to storage layer (xvendor003 + xvendor013) and extracted confidenceCalibrationGap helper. Also fixed CI fuzz timeout race with -timeout=30s."}
{"pair_id":"pair_2119","gold_label":"supersession","decision_type_a":"assessment","decision_type_b":"design","decision_a":"Completed multi-agent review of the conflict-scoring pipeline: root cause of 91.5% FP rate is the topicSim>=0.70 directToScorer bypass making unassisted xterm194 the sole gate, plus polluted labels from untriaged xterm195. Recommended sequencing: label provenance + sampled triage -> DB-backed eval harness + recall xterm196 -> close bypass selectively + enable dormant NLI sidecar -> parser-enforced validator contract with abstain -> xteam/xbranch080 extractors. Rejected: threshold recalibration, more regex suppressors, FP-memory kNN suppression, DeBERTa fine-tuning at n~70 positives.","decision_b":"Recommended reducing conflict detector toil by first switching noisy deployments to high_precision and xterm191, then implementing xterm125 feedback for resolved conflicts and an admin-only resolution-note amendment path."}