Spec Drift Detector: code vs spec
Load the approved requirements and the changes from Git or a pull request. The tool builds a requirement ↔ file ↔ test map and shows where the implementation probably drifts from the spec: changes without requirements, requirements without tests, deletions in linked code, different numbers in code. Every finding has a rule, evidence and a place for the reviewer's decision.
Free, no sign-up
Requirements baseline
A requirements-baseline file from the Requirements interviewer or another InterLAB tool. You can add more with the list below.
Lines like “REQ-001: Sign in with email [Must]”, “- [NFR-2] …”, headings “### REQ-3 …” or a Markdown table with an ID column. Lines under a requirement extend it: “Keywords: login, lockout”, “Priority: Must”, “Acceptance: …”.
Comma-separated. Prefixes of baseline IDs are added automatically.
How the check works
Requirements with IDs
A requirements-baseline file from the Requirements interviewer, or a pasted list: “REQ-001: …”, “- [NFR-2] …”, headings or a Markdown table. ID prefixes are configurable.
Changes
A unified diff (git diff, git format-patch, a PR .diff/.patch), and optionally the commit log, the PR title and description, the branch name.
Test evidence
Test files in the diff are detected by path (tests/…, __tests__/…, e2e/…; login.test.ts, cart.spec.js; auth_test.go; test_auth.py, auth_test.py; AuthServiceTest.java; AuthTests.cs; user_spec.rb; UserTest.php; LoginTests.swift; __snapshots__/x.snap). You can also paste a JUnit XML report or a list of tests with statuses.
Tracing and rules
Links come from explicit IDs (high confidence) and word matches (medium or low, with the words listed). Rules SD-01…SD-08 then produce findings with evidence.
Reviewer decision
Each finding gets a status — open, confirmed drift, false positive, accepted change (needs a change request) — a comment and a name. Decisions survive re-analysis when the “rule + requirement + file” key matches.
Rules and thresholds
The tables below are generated from the same code as the analysis — rules v1.0 (2026-10-13).
SD-01
- What
- Requirement touched without test evidence
- How it is detected
- The requirement is linked to changed code (by ID or a medium-confidence word match) or mentioned in a commit, PR or branch, but no changed test file and no passing test from the report is linked to it.
- Severity
- Must — high, Should — medium, Could/Won't — low
- Why it matters
- Behaviour changed with nothing showing it still matches the spec.
SD-02
- What
- Change not traced to any requirement
- How it is detected
- A changed code file (not a test and not a housekeeping file) is not linked to any requirement with high or medium confidence.
- Severity
- medium from 30 changed lines, otherwise low
- Why it matters
- Possibly an undocumented change or scope creep.
SD-03
- What
- Deletion in code linked to a requirement
- How it is detected
- The file is linked to a requirement (high or medium confidence) and is deleted, or has a hunk removing at least 3 lines and more than it adds; the removed lines contain the ID or the requirement's words.
- Severity
- Must — high, others — medium
- Why it matters
- Possible regression: an implemented requirement may no longer hold.
SD-04
- What
- ID mentioned that is not in the requirements
- How it is detected
- An ID matching the prefixes appears in a commit, PR, branch, code, path or test name, but no such requirement exists.
- Severity
- medium
- Why it matters
- A typo, a stale baseline, or work on a requirement that was never approved.
SD-05
- What
- Possible value mismatch
- How it is detected
- The requirement contains a number with a unit (attempts, time, size, count, characters, percent). Added lines of a linked file contain numbers next to words of the same unit and the requirement's words, but none equals the required value (with unit conversion: 30 minutes = 1800 s = 1,800,000 ms).
- Severity
- medium, confidence always low
- Why it matters
- The value in code may differ from the spec. Both are shown — compare them yourself.
SD-06
- What
- Security or performance change without tests
- How it is detected
- Same as SD-01, but the requirement is non-functional or its text is about security or performance (the category word list is published below).
- Severity
- high
- Why it matters
- These properties are invisible in a manual UI check — they need tests or measurements.
SD-07
- What
- Must requirement not in this change
- How it is detected
- A Must requirement is not linked to any code, test or commit in this change.
- Severity
- info (not drift)
- Why it matters
- Not a problem by itself: it shows what this change leaves out.
SD-08
- What
- Linked test fails
- How it is detected
- A test from the report (JUnit XML or list) is linked to the requirement by ID or words and has the failed/error status.
- Severity
- high
- Why it matters
- The requirement probably does not hold in the current version.
Explicit ID
- Condition
- The requirement ID in a commit, PR, branch, code line, file path or test name
- Confidence
- high
Words — medium
- Condition
- score ≥ 4 with at least 2 distinct concepts (1 per concept in changed lines, +1 if it is in the file path)
- Confidence
- medium
Words — weak
- Condition
- score ≥ 2; shown on the map but not counted as a trace
- Confidence
- low
Report test by words
- Condition
- ≥ 2 concepts match; a test with an ID in its name links by ID only
- Confidence
- medium
Too generic concepts
- Condition
- a concept found in more than 50% of requirements (with 4+ requirements) is ignored
- Confidence
- —
Words: camelCase, snake_case, kebab-case and paths are split into words; English words are stemmed (attempts → attempt), Russian ones are cut to the first 5 letters after dropping the ending. Russian stems also get English equivalents from a glossary, for example: вход… → login, signin, auth; авториз… → auth, login, authorize; аутен… → auth, authenticate; регис… → signup, register, registration; парол… → password, passwd, pwd; попыт… → attempt, tries, retry; блоки… → lock, lockout, block; забло… → lock, lockout, block.
Non-functional categories (for SD-06): security — secure, password, encrypt, auth, permission, rate limit, lockout, lock, failed attempts, csrf, xss, injection…; performance — latency, response time, p95, p99, throughput, load time, cache, concurrent, rps, ms.
Housekeeping files never count as a “change without a requirement”: documentation (.md, .txt, .rst); the docs/ directory; repository settings, licence, CHANGELOG; images, fonts, media, package-manager lock files, binary files.
Limitations
- Word links are a heuristic: false links and misses are both possible. The most reliable way is to put requirement IDs in commits, PRs and test names.
- The code is not executed; logic, semantics and files outside the diff are not analysed. “A test exists” does not mean “the test checks the requirement”.
- Value mismatches (SD-05) are only looked for next to words of the same unit and are always low confidence; numbers written as words are not recognised.
- Multi-user access with roles comes after demand is validated: right now the data lives only in your browser, and “decided by” is what the reviewer types, not an electronic signature.
Privacy
- Requirements, the diff, commits and reports are processed in your browser: the texts themselves are never sent to a server or put into the page address.
- The draft, reviewer decisions and versions are stored only in this browser (localStorage); “Clear all” deletes them.
- Before export the tool warns about lines that look like secrets; the report replaces such values with [REDACTED].
- Analytics receives only the fact of a check or an export and a category (requirements source, file format) — no content.
- The result reaches us only if you send a request yourself and keep the “Attach the result” box ticked — the form shows exactly what will be sent. The summary holds counts, coverage and rule · requirement ID · file, never code, the diff or requirement texts.
Related tools
All tools · 40
Code reviewer, incl. AI-written codePaste a pull request diff — get findings on security, migrations, tests and architecture with evidence from the code, sorted by severity. The code is never changed.
MVP health check16 questions about code, access, data, tests and releases. Shows what to check first — no “score out of 100”, no sign-up.
Context VaultProject docs, decisions and constraints in one place: source search, staleness control and task-specific context packs for an AI agent or a new developer.
Project handoffRepository snapshot, architecture, progress, blockers, risks, tests and next tasks → a verifiable handoff package for a developer or an AI agent.
Agent cost trackerImport API events (CSV/JSONL) → tokens and spend by project, model and task, retries, budgets and alerts. Prices come from your own price list.
Release readinessAn evidence-backed check matrix: CI, migrations, backups, a rollback plan, monitoring, risk exceptions and sign-off → a GO / NO-GO decision.Want code checked against the spec?
A code audit, including code written with AI agents: spec conformance, security, tests and a fix plan. The first short call is free; scope and cost come after a brief.
- The first short conversation is free — we choose the format
- NDA — yours or ours
- Pricing after a brief and an agreed scope