DriftGuard

Problem & Solution Statement: Design docs, PRDs, ADRs, and API specs are accurate on day one and wrong within weeks. An endpoint gets removed but stays documented. A field gets renamed in code but not in the spec. A doc claims synchronous behavior that has since become async. Nobody notices until it costs something real: a new hire builds the wrong mental model from a stale doc, a reviewer approves a PR trusting outdated context, or a downstream team gets blindsided when an API contract silently changed. Today, catching this requires a human to manually reread the doc and the code side by side, something nobody actually does until after it breaks. There is no tooling that treats "does the doc still match the code" as a continuously checked, first-class signal. DriftGuard solves this as a multi-stage agentic pipeline built on IBM Bob 2.0, rather than a single script or a linear code assistant. A DocParser subagent uses document understanding to ingest PRDs, ADRs, OpenAPI specs, and Markdown or PDF docs, extracting atomic, checkable claims: behavioral ("service A calls B synchronously"), contractual ("endpoint returns field Z"), and architectural ("uses Postgres"). A CodeMapper subagent builds a ground-truth map of the actual codebase: entry points, public APIs, data models, and real inter-service calls. DriftAnalyzer subagents then run in parallel, one per module, each comparing only its relevant claims against its own slice of the codemap and returning MATCH, DRIFT, or UNVERIFIABLE with a confidence score and a cited code location. A FixGenerator subagent turns every confirmed drift into two reviewable diffs: a patch updating the doc to match the code, or a flag on the code noting the doc's original intent. Nothing is auto-applied. A Reporter subagent compiles everything into a single HTML dashboard showing per-module drift scores, side-by-side doc and code excerpts, and the generated fix diffs. A PR-bot mode extends this to individual pull requests, scoping subagents only to touched modules and posting a review comment such as "This PR appears to contradict ADR-003's claim that X," catching drift the moment it is introduced rather than months later. The target users are engineering teams, particularly reviewers, tech leads, and new hires, on codebases where documentation is treated as a source of truth but rarely re-verified. Users interact with DriftGuard by pointing it at a repo and its docs folder, or by triggering it on a pull request; it returns a ranked, explorable report rather than a wall of text, and every finding links to an actual reviewable diff they can merge or dismiss. What makes this creative and unique is that it treats documentation drift as a structured, agentic problem rather than a search or linting problem: document understanding produces structured claims instead of keyword matches, and parallel, module-scoped subagents replace what would otherwise be a slow, serial, manual audit, each operating with only the narrow context it needs. Each phase logs wall-clock timing, so the demo directly compares manual audit time per module, roughly 10 to 20 minutes by hand, against the agent's parallel runtime, under a minute across all modules. Run against a sample project with deliberately seeded drifts, DriftGuard surfaces real, previously invisible mismatches and ships working fix diffs, not just a report, but reviewable pull requests a team could merge the same day.