RepoTruth- Verified Software Knowledge for IBM Bob

RepoTruth - Evidence-Backed Repository Knowledge for IBM Bob The Problem: Enterprise software repositories don't tell one story — they tell many, and they disagree. The same business rule gets restated across executable COBOL, copybooks, JCL jobs, README files, inline comments, and test assertions. Over time these sources drift. A threshold changes in the code but not the docs. A dependency is renamed in one place but not another. A test is never written for a critical paragraph. This drift becomes actively dangerous the moment an AI coding agent enters the picture. IBM Bob reads the repository before making changes — but if it contains contradictions, Bob inherits them silently. If Bob trusts the README, it will "fix" working COBOL to the wrong number. More context doesn't help. A longer prompt still contains both the correct IF statement and the stale documentation, and the model can quote either one. The missing layer is not more data. It is a check that says which source wins, how confident that verdict is, and which line is the evidence. The Solution RepoTruth is that layer — a pre-flight, evidence-backed knowledge pipeline that runs before IBM Bob acts on any repository. One click — Analyze IBM Z sample — sends the repository through six specialist agents: Repository Analyst — inventories programs, paragraphs, copybooks, JCL jobs, and tests Code Semantics — extracts business rules, inputs, outputs, and purpose from COBOL Dependency Tracer — maps USES_COPYBOOK, CALLS, IMPLEMENTS_RULE, TESTED_BY Documentation Truth — classifies claims as ACCURATE, STALE, MISSING, CONTRADICTORY, or AMBIGUOUS Test / Behavior — determines TESTED, PARTIALLY_TESTED, UNTESTED, or CONFLICTING_TEST per entity Adjudicator — ranks conflicting evidence by authority, not by vote When sources disagree, the Adjudicator applies a strict hierarchy: Executable code → Tests → Configuration → Documentation → Comments This produces an unambiguous result for contradictions like Issue #04: the README states transactions above $50,000 require review; the executable COBOL and TEST-014 both use 100000; a comment also contains the stale 50000. RepoTruth prioritizes executable and test evidence, labels the record DOCUMENTATION_CONTRADICTION (HIGH severity), and recommends Update README — no human required. Every entity exits the pipeline with a structured knowledge record: entity_id, purpose, relationships, quality, evidence pointers, final_label, confidence, and review_state. Records above 0.85 confidence are verified automatically. Only genuinely undecided cases route to the human review queue — human time is reserved for ambiguity, not for contradictions the system can already resolve. The verified dataset exports as JSONL, JSON, or CSV. Target Users: Primary: IBM Bob and the developer invoking it before a maintenance or modernization task on an IBM Z repository. Secondary: the developer or team lead who reviews flagged ambiguous records before approving a change. What Makes It Creative and Unique: Most approaches add more retrieval — more files, larger context windows, better embeddings. RepoTruth takes the opposite position: the problem is not volume, it is trust. Repository artefacts are treated as competing witnesses, not a single knowledge source, and a ranked adjudicator rules instead of a majority vote. A vote between a README, a comment, and a COBOL IF can crown the documentation. A ranked adjudicator cannot. The system runs without a GPU, without watsonx in the loop, and without hardcoded thresholds — a deterministic COBOL and JCL parser pipeline with live-streamed results and a verifiable benchmark against 100 gold-labeled cases. How It Addresses the Challenge: RepoTruth eliminates the manual reconciliation step that precedes every AI-assisted change. Instead of asking Bob to resolve which conflicting repository statement is correct — a task it was not designed for — RepoTruth hands Bob a pre-resolved, evidence-ranked knowledge record.