IVD

The Problem

AI agents hallucinate not because they're bad — but because you're feeding the wrong knowledge system.

Research shows LLMs rely primarily on contextual knowledge (the prompt) over parametric knowledge (training data) — but only when the context is structured and precise (Huang et al., ICLR 2024; 9-LLM contextual vs. parametric study, 2024). When you give vague prose — a PRD, a user story, a chat message — the context channel is underloaded. The model fills the gaps from training. Those gaps are the hallucinations.

Without IVD                              With IVD

You: "Add CSV export"                    You: "Add CSV export for compliance"
AI:  [builds with wrong columns]         AI:  [writes intent.yaml with constraints]
You: "No, these columns, ISO dates"      You:  "Yes, that's what I meant"
AI:  [rewrites, still wrong]             AI:  [implements, verifies against constraints]
You: "Still not right..."                You:  "Done. First try."
  Many turns. Many hallucinations.         One turn. Mismatches caught by the constraint check, not by you.

IVD saturates the contextual channel with structured, verifiable intent — so the model has nothing to guess.

Related MCP server: Carrot AI PM

Quick Start

Works locally. No API key required. Under 5 minutes.

0. See it work first (30 seconds, no setup)

git clone https://github.com/leocelis/ivd.git && cd ivd
python3 examples/intent_demo/run_demo.py

Runs offline. Shows a vague prompt producing a hallucinated implementation, then the same request run against a structured intent artifact — with the constraint check catching the mismatch before you'd ever see it. This is the core loop this README is about; everything below is how to wire it into your own agent.

1. Clone and setup

git clone https://github.com/leocelis/ivd.git
cd ivd
./mcp_server/devops/setup.sh    # creates .venv, installs all deps

2. Add to your IDE

Important: command must point at the venv's Python — setup.sh installs IVD's dependencies into .venv/, not your system Python. Using "command": "python" here will fail with ModuleNotFoundError. Replace /path/to/ivd with your actual clone path.

Cursor (Settings → Features → MCP):

{
  "servers": {
    "ivd": {
      "type": "stdio",
      "command": "/path/to/ivd/.venv/bin/python",
      "args": ["-m", "mcp_server.server"],
      "cwd": "/path/to/ivd"
    }
  }
}

VS Code / GitHub Copilot (.vscode/mcp.json):

{
  "mcpServers": {
    "ivd": {
      "command": "/path/to/ivd/.venv/bin/python",
      "args": ["-m", "mcp_server.server"],
      "cwd": "/path/to/ivd"
    }
  }
}

Claude Desktop (~/Library/Application Support/Claude/claude_desktop_config.json):

{
  "mcpServers": {
    "ivd": {
      "command": "/path/to/ivd/.venv/bin/python",
      "args": ["-m", "mcp_server.server"],
      "cwd": "/path/to/ivd"
    }
  }
}

A pyproject.toml now ships in the repo (pip install . or pip install -e . gives you an ivd-mcp console command). A PyPI release (uvx ivd-mcp, no clone required) is planned — see ROADMAP.md.

3. Use it

Ask your AI agent to use IVD tools. For example:

• "Use ivd_get_context to learn about the IVD framework"

• "Use ivd_scaffold to create an intent for my user authentication module"

• "Use ivd_validate to check my intent artifact"

That's it. 32 of 33 tools work immediately with zero configuration — only ivd_search needs an OPENAI_API_KEY.

4. Enable semantic search (optional)

ivd_search requires embeddings. Generate them once (~$0.01, under a minute):

export OPENAI_API_KEY=your-key
./mcp_server/devops/embed.sh

How It Works

1. You describe      →  what you want (natural language)
2. AI writes         →  structured intent artifact (YAML with constraints and tests)
3. You review        →  "Is this what I meant?" (clarification before code)
4. AI stress-tests   →  edge cases, gaps, assumptions, constraint conflicts
5. AI implements     →  constraint-segmented (group → implement → re-read → verify → next)
6. AI verifies       →  full sweep: does every constraint pass?

The key insight: clarification happens at the intent stage, not after code. The AI writes a verifiable contract, you approve it, then implementation is mechanical — and self-verifying.

MCP Tools

33 tools available to any MCP-compatible AI agent (19 core + 10 Judgment tools (8 added in v3.0; ivd_judgment_check_installed and ivd_judgment_resolve added in v3.1) + 4 Canon tools added in v3.1):

Core (19)

Judgment Phase (10) — dormant unless <project_root>/.judgment/ exists

New to Judgment? Read judgment_explained.md first — plain-English "what problem it solves and how" in 5 minutes — then the tool table below and the runnable showcase further down will make immediate sense.

Architecture (v3.1): substance lives in the ivd/judgment/ engine package (typed @dataclass schemas; engine_version + reproducible SHA-256 hash on Pattern and InjectionResult for diffability and audit). mcp_server/tools/judgment.py is a thin facade that dispatches to the engine. Mirrors the Canon (Phase 0) architecture for symmetry. Server-level kill switch: IVD_JUDGMENT_TOOLS_ENABLED=false.

See it work. A runnable showcase walks through the full Judgment loop end-to-end — capture three real-world AI corrections, codify them, promote a Pattern, and watch the same LLM (gpt-4o-mini, temperature=0) generate different code on the same request after the Pattern enters its system message. No trust required — run it, read the terminal.

# From the ivd/ directory — runs offline, no API key required
python examples/judgment_demo/run_demo.py

# Add OPENAI_API_KEY (in .env after setup) to see the live behavioral diff
OPENAI_API_KEY=sk-... python examples/judgment_demo/run_demo.py

The showcase simulates 3 weeks of an AI coding agent ignoring this project's React testing conventions across 3 different test files (PaymentForm.test.tsx, MetricsCard.test.tsx, ProfileSettings.test.tsx), feeds the 3 corrections through the 9 ivd_judgment_* tools, and writes 4 human-readable artifacts to examples/judgment_demo/output/: before.md (the agent's system message without Judgment), after.md (with the Pattern injected), diff.md (what Judgment added), and llm_responses.md (side-by-side Vitest test files with verdict).

Why this scenario: the project's testing conventions (renderWithProviders helper in src/test/test-utils.tsx, MSW server in src/test/mocks/server.ts, userEvent.setup() discipline) live ONLY in the repo. They do not exist in the LLM's training data, so a static system-prompt nudge cannot solve it — the model has to inherit the lesson from YOUR repo. That is precisely the use case Judgment is built for.

Representative result on the live LLM (gpt-4o-mini, temperature=0, n=3 trials, ~$0.001):

Full methodology, per-step output, and the regression test that pins every claim: examples/judgment_demo/README.md.

Canonical doc: judgment_layer.md. Recipes: capture-correction.yaml, comparison-pair.yaml, distill-pattern.yaml.

Canon — Human Translation Layer (4) — v3.1, no extra setup

Canon makes any AI agent's replies legible to humans. It enforces five communication invariants — Setting Phase (R1), Confidence Calibration (R2), Verification Beat for irreversible actions (R5), Folk Theory Management (R10), and Anthropomorphism Ceiling (R14) — on top of any LLM output. Canon ships in two layers that compose:

• Phase 0a — Canon Rules. A pasteable markdown block that lives in your agent's instruction file (.cursorrules, .clinerules, CLAUDE.md, .github/instructions/canon.md, AGENTS.md, .windsurf/rules/canon.md). Distributed as the IVD recipe canon-rules. Fence-marked with <BEGIN-CANON v1.0> / <END-CANON v1.0> so it can be detected, replaced, or version-bumped without disturbing the rest of the file.

• Phase 0b — Canon MCP tools. Four tools hosted inside this IVD MCP server — every existing IVD client (Cursor, Claude Desktop, Claude Code, VS Code + Copilot, Cline, Windsurf, Zed) discovers them automatically on the next IVD update. Zero mcpServers config edit required. Opt-out: IVD_CANON_TOOLS_ENABLED=false.

Install flow (IVD users — already have mcpServers.ivd configured):

1. Update IVD. The four canon_* tools appear automatically in tools/list. No config edit.

2. Ask your agent: "Run canon_check_rules_installed for this project."

3. The tool reports per-file status of the IVD and Canon rule blocks plus a per-client install payload for any missing block.

4. The agent asks you for permission before writing the rules block to any file.

The composition lift. When both layers are active (rules in instruction file + Canon MCP tools available), audit pass rates on R1/R2/R5/R10/R14 are at least 10 percentage points higher than rules alone (NFR-LA5).

See it work. The validation suite ships with a runnable showcase that calls a real LLM with and without the Canon rules block and measures what changes. No trust required — run it, read the terminal.

# From the ivd/ directory — needs OPENAI_API_KEY (in .env after setup)
source .venv/bin/activate
python -m canon.validation.showcase_rules

The first four prompts are the headline demos. On each one the same LLM is asked the same destructive question — without Canon rules it hands you the dangerous command, with Canon rules it produces an ACTION / REVERSIBLE / APPROVE? beat and withholds the command until you confirm:

Representative result across 9 real user questions (gpt-4o, ~$0.08, ~70s):

Full prompt list, methodology, per-prompt side-by-sides, and expected output: canon/validation/README.md.

For the plain-English explanation — what problem Canon solves, the five rules, how it installs, and why the "0 regressions" result matters — see the canonical doc: canon_layer.md (parallel to judgment_layer.md).

Canonical recipe: recipes/canon-rules.yaml. Engine source: canon/.

Integrations

ComplyEdge TrustLint (optional, pip install ivd-mcp[compliance]) — offline EU AI Act screening on LLM-facing artifacts (recipes/, templates/, *_intent.yaml), built by the same author and dogfooded on this repo.

pip install 'ivd-mcp[compliance]'
./scripts/compliance/check.sh

CI runs this as an informational check (not merge-blocking — see .github/workflows/ci.yml). Details: docs/integrations/COMPLYEDGE.md.

The Nine Principles

Deep dive: purpose.md · framework.md · cheatsheet.md

Recipes

20 reusable patterns (see recipes README):

Configuration

IVD works out of the box with zero configuration. Optional settings for advanced use:

cp .env.example .env

Embeddings are not shipped in the repo — they are generated locally. To enable ivd_search:

export OPENAI_API_KEY=your-key
./mcp_server/devops/embed.sh          # generate (~$0.01)
./mcp_server/devops/embed.sh --force  # regenerate all
./mcp_server/devops/embed.sh --dry-run # preview what gets embedded

Hosted Server

A hosted IVD MCP server is available for users who prefer not to run it locally.

Request access: Open a GitHub Discussion →

Once you have an API key, use the URL that matches your client:

POST to /sse is also accepted (alias for Streamable HTTP) for clients that misconfigure the base URL; /mcp is still recommended for Copilot.

VS Code / GitHub Copilot (.vscode/mcp.json — remote URL must end with /mcp):

{
  "servers": {
    "ivd": {
      "type": "http",
      "url": "https://mcp.ivdframework.dev/mcp",
      "headers": {
        "Authorization": "Bearer your-api-key",
        "Accept": "application/json, text/event-stream"
      }
    }
  }
}

Note: The Accept header is required. VS Code's default HTTP transport only sends application/json; the IVD Streamable HTTP endpoint enforces the MCP spec and requires both application/json and text/event-stream — omitting it returns a 406 error.

Cursor (Settings → Features → MCP):

{
  "servers": {
    "ivd-remote": {
      "type": "sse",
      "url": "https://mcp.ivdframework.dev/sse",
      "headers": { "Authorization": "Bearer your-api-key" }
    }
  }
}

Claude Desktop (claude_desktop_config.json):

{
  "mcpServers": {
    "ivd-remote": {
      "url": "https://mcp.ivdframework.dev/sse",
      "headers": { "Authorization": "Bearer your-api-key" }
    }
  }
}

All 33 tools are available on the hosted server, including ivd_search (embeddings are pre-generated).

Documentation

Development

# Setup
./mcp_server/devops/setup.sh             # Create venv, install deps

# Run tests
./mcp_server/devops/test.sh              # All tests (unit + e2e)
./mcp_server/devops/test.sh --unit       # Unit only
./mcp_server/devops/test.sh --e2e        # E2E only

# Embeddings (requires OPENAI_API_KEY)
./mcp_server/devops/embed.sh             # Generate embeddings
./mcp_server/devops/embed.sh --dry-run   # Preview what gets embedded
./mcp_server/devops/embed.sh --force     # Regenerate everything

# Search embeddings locally (requires generated brain + OPENAI_API_KEY)
./mcp_server/devops/search.sh "query"

The Book

A comprehensive book on Intent-Verified Development — the cognitive foundations, case studies, and the full methodology — is coming soon.

Contributing

Issues, bug reports, and recipe suggestions are welcome. See CONTRIBUTING.md for guidelines.

Legal

See LEGAL.md for disclaimers, data transmission disclosures, AI limitation notices, known architectural limitations (hosted server vs. self-hosted), and your responsibilities as a deployer under the EU AI Act, GDPR, and US law.

License

MIT · Maintained by IVD Project