Version: 2.2 · Effective: July 19, 2026
This document applies to the IVD framework (ivdframework.dev), the hosted MCP server at
mcp.ivdframework.dev, the open-source repository at github.com/leocelis/ivd, and any self-hosted deployment of the same codebase.This document is not legal advice. It describes how IVD is designed, what it does and does not do, and what responsibilities remain with the user. If you are deploying IVD in a regulated context, consult qualified legal counsel before proceeding.
Related documents (all incorporated into these notices by reference):
- TERMS_OF_SERVICE.md — binding terms of use; governs API key acceptance and hosted server access
- PRIVACY_POLICY.md — GDPR Art. 13 compliant privacy notice; what data is collected, why, and your rights
- DATA_PROCESSING_AGREEMENT.md — GDPR Art. 28 DPA template for EU enterprise users processing personal data through the hosted server
Acceptance: By requesting an API key, activating an API key, or connecting to the hosted server, you are accepting the Terms of Service. Free and open-source use of the codebase is governed by the MIT License; hosted server use additionally requires ToS acceptance.
IVD (Intent-Verified Development) is a developer framework and MCP server that helps software teams write structured intent artifacts and run AI-assisted verification workflows against those artifacts. It is:
IVD is not:
Classification note (EU AI Act): IVD does not provide LLM inference — it orchestrates calls to third-party LLMs. It is not listed in Annex III of Regulation (EU) 2024/1689. Under guidance current at the effective date of this document, IVD appears likely to be classified as a non-high-risk general-purpose software tool; however, this classification is not legally certified, may be subject to regulatory reinterpretation, and does not bind any competent authority. If you use IVD to build a system covered by Annex III (employment screening, credit scoring, medical diagnosis, critical infrastructure management, etc.), your system — not IVD — bears the obligations under Articles 6, 9, 13, and 14 of the AI Act. You are the deployer responsible for compliance regardless of which tools you used to build the system.
Official text: https://eur-lex.europa.eu/legal-content/EN/TXT/?uri=OJ:L_202401689
Copyright © 2024–2026 Leo Celis. All rights reserved except as licensed below.
The IVD framework, including but not limited to the framework specification, the four-phase methodology (Intent · Implementation · Verification · Judgment), the Canon layer specification, all recipes, all intent artifact schemas, all MCP tool implementations, and all associated documentation, is the intellectual property of Leo Celis.
License: The source code is licensed under the MIT License (see LICENSE). The MIT
License grants you permission to use, copy, modify, merge, publish, distribute,
sublicense, and sell copies of the software. It does not transfer ownership of the
underlying IP, trademarks, or methodology; nor does it grant the right to represent
third-party implementations or derivatives as the official IVD framework.
Outputs generated by the tools: Intent artifacts, Judgment ledger entries, and other files produced by IVD tools when operating on your content belong to you. IVD makes no claim to user-generated content.
AI-generated content in artifacts: When an AI agent uses ivd_scaffold or other
generative IVD tools to draft an intent artifact, the resulting content is AI-generated.
Copyright status of AI-generated content varies by jurisdiction; consult legal counsel
if you are relying on copyright protection for AI-generated artifacts.
Names and branding: “IVD,” “Intent-Verified Development,” “ivdframework.dev,” and associated logos are common law marks under continuous use. Unauthorized use of these names in competing products, services, or marketing materials is not permitted.
No USPTO or EUIPO trademark registration currently exists for “IVD” or “Intent-Verified Development.” Until registered marks are in place, protection is limited to the geographic areas of actual commercial use. Common law rights do exist but are harder to enforce internationally than a registered mark. Do not use these names in any way that could imply affiliation with or endorsement by IVD.
Unauthorized forks and impersonators: the MIT License (see LICENSE) grants broad
rights to the source code — it does not grant the right to use the “IVD” or
“Intent-Verified Development” names, or to represent a fork, clone, or derivative
service as the official project. IVD (Leo Celis) is not responsible for the content,
conduct, security practices, or representations of any unauthorized fork, clone, or
service that uses the IVD name or implies affiliation without the written authorization
described above — including any harm, loss, or liability arising from a user’s
reliance on such an unauthorized service believing it to be official IVD. If you
encounter a product or service falsely claiming to be, or be affiliated with, IVD,
report it to leo@leocelis.com.
IVD mitigates known LLM failure modes but cannot eliminate them. The following are architectural properties of current large language models, not defects specific to IVD. Each of these limitations is your risk to manage in your use case.
An AI agent can recite all constraints from an intent artifact and confirm understanding — then violate those same constraints in the implementation. This occurs because LLM attention degrades over long contexts. IVD’s segmented implementation workflow reduces this risk but cannot mechanically guarantee compliance.
Research basis: anthropics/claude-code GitHub issues #26848, #6120, #32290, and #742; MOSAIC 2025; IFScale 2025.
Constraints listed earlier in an intent artifact receive weaker LLM attention than those
listed later. When conflicting constraints are present, the model tends to satisfy those
encountered last. ivd_scaffold and ivd_validate do not reorder constraints or warn
on constraint order — this is a fully manual discipline.
Research basis: NIST AI 600-1 GV-6.1; IFScale 2025.
Two constraints that cannot both be satisfied simultaneously will cause the LLM to silently satisfy whichever it encounters last, violating the other. No automated satisfiability checker exists in IVD. Satisfiability review (IVD Rule 4, Probe 4) is entirely a manual step that agents and users can skip without any tool-enforced gate.
In long coding sessions or with large intent trees (system + workflow + module + task intents plus Judgment injection), token pressure can cause early intent content to be deprioritized (the lost-in-the-middle effect). There is no tooling in IVD that enforces selective intent loading or provides token-budget warnings. Users who load the full intent tree may receive degraded constraint adherence without any error signal.
Child intents reference parent_intent: paths that must be loaded by the agent before
implementation. This loading is convention-only — no IVD tool enforces it. One-shot
prompts that skip parent-intent loading operate without project-wide conventions, and
any hallucinations about project architecture that the parent intent was designed to
prevent will recur.
When an AI agent scaffolds an intent artifact, the generated constraints may be plausible but factually incorrect, overly broad, or structurally valid while misrepresenting the actual user goal. Skipping the mandatory human review step (IVD Step 3) removes the only gate that catches this failure. If a user approves an artifact that subtly misrepresents their intent, the resulting implementation will be internally consistent with the wrong goal. This is an inherent risk of any intent-mediated workflow.
NIST AI 600-1 identifies confabulation as one of 13 primary generative AI risks and recommends human-in-the-loop processes for consequential outputs.
Source: https://nvlpubs.nist.gov/nistpubs/ai/NIST.AI.100-1.pdf
At high constraint density (above approximately 10–15 constraints per artifact), LLMs
begin silently violating earlier constraints to satisfy later ones. IFScale 2025 reports
~68% constraint compliance accuracy at high density. ivd_validate warns when an
artifact exceeds the 7-constraint budget and advises splitting into sub-module intents,
but the warning is advisory — it does not block, and the underlying statistical failure
mode remains a property of the model, not of the artifact. Users who proceed past the
warning accept that risk.
When the hosted IVD server restarts (including after a new deployment), all active MCP sessions become invalid. Subsequent tool calls return “No valid session ID provided.” Users must manually reconnect the MCP server in their IDE. There is no automatic session recovery mechanism.
The hosted server supports two transports: SSE (/sse, for Cursor) and Streamable-HTTP
(/mcp, for VS Code + GitHub Copilot). Using the wrong URL or wrong transport type
causes silent connection failure — MCP tools simply do not appear. The server returns
opaque HTTP errors (e.g., 406) that do not guide users to the correct configuration.
ivd_search uses embeddings generated at server build time. For self-hosted deployments,
any recipe files, framework docs, or intent templates added after the last embedding
generation will not be found by search. The tool succeeds and returns zero results —
which looks like “no relevant documentation exists” rather than “index is stale.”
The tool does not report index freshness or document count. Hosted-server embeddings are
regenerated on every deploy; self-hosted users must run embed.sh manually.
ivd_attest checks whether an agent followed the IVD method — segmentation at 3+
constraints, re-reading the intent from disk, per-constraint coverage, joint
satisfaction. It cannot observe the agent’s execution. Every input except one is
the agent’s own report, so a determined or malfunctioning agent can submit a fully
compliant attestation describing work it did not do.
The tool’s value is that it converts a silent omission into an explicit, auditable claim. It raises the floor; it does not close the gap.
The single exception is the provenance cross-check: whether a constraint’s only
evidence is an AI-written test is derived from the artifact, not the attestation, so a
claimed PASS on an ai_generated-only constraint is downgraded to
NEEDS_EXTERNAL_ORACLE regardless of what the agent asserts. That check is not
self-graded; the rest are. Do not represent an ivd_attest COMPLIANT verdict to a
third party as independent verification that the work was performed.
IVD’s marketing references “eliminating hallucinations” and “turning complex implementations into single-turn completions.” These claims apply under specific conditions and must not be generalized:
write well, be appropriate)
passes ivd_validate while providing no actual constraint signal. The user bears
full responsibility for artifact quality.The FTC has stated that unsubstantiated efficacy claims about AI capabilities are actionable as deceptive practices under 15 U.S.C. § 45. IVD does not guarantee marketing outcomes for use cases, models, or constraint qualities outside the conditions described above.
Source: https://www.ftc.gov/business-guidance/blog/2023/02/keep-your-ai-claims-check
Source: https://www.ftc.gov/news-events/news/press-releases/2024/09/ftc-announces-crackdown-deceptive-ai-claims-schemes
When you use the hosted IVD MCP server at mcp.ivdframework.dev:
Every tool call transmits the arguments you provide — including yaml_content,
project_root, artifact_path, correction text, and all other parameters — to the
hosted server over HTTPS. This content is processed to execute the tool.
Retention: Content transmitted through tool arguments is not retained in IVD’s own application storage beyond the active processing session. However, provider-level infrastructure logs, operational traces, and crash/error reports generated by the underlying hosting platform (DigitalOcean) and API providers (OpenAI) may capture transmitted content as a side effect of normal operations, subject to those providers’ own data handling policies.
The hosted server runs on DigitalOcean App Platform (US East region). Search queries
via ivd_search are processed using the OpenAI Embeddings API (text-embedding-3-small
model). Both providers are US-based.
If you are in the European Union: Transmitting personal data through tool arguments constitutes an international data transfer from the EU to the United States under GDPR Chapter V (Articles 44–46, Regulation (EU) 2016/679). No Standard Contractual Clauses (SCCs) or Data Processing Agreement (DPA) between IVD and its users currently exists. EU controllers must not transmit personal data through hosted-server tool arguments until SCCs or equivalent safeguards are in place. Use a self-hosted deployment instead.
Source: https://www.edpb.europa.eu/sme-data-protection-guide/international-data-transfers_en
Source: https://commission.europa.eu/law/law-topic/data-protection/international-dimension-data-protection/standard-contractual-clauses-scc_en
For the purposes of GDPR Article 28: IVD operates the hosted server as a processor of any personal data you transmit through tool arguments. You remain the controller for that data. This allocation of roles does not absolve IVD of processor-level obligations, nor does it reduce your controller-level accountability for transmitting personal data to a third-country server.
| Sub-processor | Role | DPA |
|---|---|---|
| DigitalOcean, Inc. | Infrastructure hosting | https://www.digitalocean.com/legal/data-processing-agreement |
| OpenAI, L.L.C. | Embedding generation (ivd_search) |
https://openai.com/policies/data-processing-addendum/ |
No signed DPA between IVD and its users currently covers these sub-processors. This is a known compliance gap (see internal compliance review FDR-024). Until a formal DPA is published, enterprise and EU-based users should use self-hosted deployments for any work involving personal data.
Do not transmit the following through hosted-server tool arguments:
IVD API keys are bearer tokens. A compromised key grants access to all 32 IVD tools under your identity. There is no per-key scope, IP restriction, rate limiting, or automatic expiry. If you believe your key has been exposed: (1) revoke it immediately via the IVD dashboard, (2) audit any recent tool call logs, (3) if personal data was accessible through the key, assess your obligations under GDPR Article 33 (72-hour breach notification) and applicable US breach notification laws.
If data isolation is required, deploy locally. In a self-hosted deployment, all
processing remains on your infrastructure. The OPENAI_API_KEY you configure is used
only by your own server instance and is not accessible to IVD as a project.
Self-hosting instructions: deploy/ directory and
CONTRIBUTING.md.
IVD’s hosted server depends on third-party infrastructure and AI services: DigitalOcean App Platform (hosting, Redis session management), OpenAI (search embeddings), and Redis (MCP session storage). IVD has no control over the availability, terms of service, pricing, API behavior, regulatory status, or data handling practices of these providers.
IVD is not liable for any interruption, degradation, data loss, API behavior change, or legal development attributable to DigitalOcean, OpenAI, Redis, or any other third-party provider on which IVD depends. Changes in these providers’ terms, pricing, or capabilities — including the deprecation of the OpenAI text-embedding-3-small model — may affect IVD tool functionality without advance notice.
OpenAI DPA: https://openai.com/policies/data-processing-addendum/
DigitalOcean DPA: https://www.digitalocean.com/legal/data-processing-agreement
IVD provides the hosted server on a best-effort basis. There is no SLA, no uptime guarantee, no status page, and no planned maintenance window commitment. The following events may cause full or partial unavailability without advance notice and without triggering any liability on IVD’s part:
ivd_search only; other 32 tools
continue to function)The self-hosted path, which runs on your own infrastructure, is the recommended option for any workflow that requires guaranteed availability.
The Judgment phase tools (ivd_judgment_capture, ivd_judgment_codify_correction,
ivd_judgment_distill_pattern, ivd_judgment_inject_context, and related tools) create
a persistent, accumulating record of AI corrections in the .judgment/ directory.
Before using Judgment tools, understand all of the following:
Correction descriptions are captured verbatim and written to YAML files on disk. If a correction references a specific person’s name, email address, code comment, ticket number, or other identifying information, that PII is persisted to the ledger file and to any git commit that includes it — permanently. Do not include PII, specific credentials, or production data in correction text.
Judgment ledger entries include source fields that link corrections to individual contributors. If ledger data is used by a manager or HR function to assess an individual’s performance, it may constitute profiling producing legally significant effects under GDPR Article 22. The individual has the right to object (GDPR Article 21), to receive an explanation of the automated logic (GDPR Article 22(3)), and to request human review. Judgment is designed as a team learning tool, not as an individual performance or audit mechanism. Using it for the latter may expose your organization to employment law and data protection liability.
Judgment patterns derive confidence from ledger entries. A single contributor with incorrect domain assumptions can generate multiple entries that promote an authoritative pattern injected into all future agents. Domain depth scores are self-assigned in the baseline configuration. There is no peer-review gate or override mechanism for single-source systematic bias.
ivd_judgment_inject_context returns all live patterns regardless of whether they are
relevant to the current task. Irrelevant patterns consume context budget and may cause
the agent to apply domain-specific rules from one context (e.g., React testing) to a
different task (e.g., SQL migration). This is a known design gap — task-aware filtering
does not currently exist.
.judgment/ grows indefinitely. There is no automatic expiry, pruning, or archive job.
At sufficient volume, the injection output can saturate context windows. Apply your
organization’s data retention policy to this directory. GDPR Article 5(1)(e) requires
that personal data not be kept longer than necessary; if ledger entries contain personal
data, this obligation applies.
Source: https://ico.org.uk/for-organisations/uk-gdpr-guidance-and-resources/artificial-intelligence/guidance-on-ai-and-data-protection/how-do-we-ensure-fairness-in-ai/
Source: https://edpb.europa.eu/sites/default/files/files/file1/edpb_guidelines_201904_dataprotection_by_design_and_by_default_v2.0_en.pdf
The Canon layer (Phase 0a rules + Phase 0b MCP tools) provides structured AI output guidelines and verification tools. The following limitations apply:
Canon rules installed in one instruction file (e.g., .cursor/rules/myproject.mdc)
have no effect if the AI agent reads from a different file (e.g., .cursorrules).
Zero R-invariants are enforced when the rules are present on disk but not in the
agent’s loaded instruction context. canon_check_rules_installed reports installation
status — but only when run. There is no automated check on agent startup.
Canon R5 fires a ACTION / REVERSIBLE / APPROVE? beat before irreversible actions. If
users habitually confirm without reading — a known click-through pattern common to
software consent dialogs — the safety gate becomes non-functional. The R13 (stakes-adaptive
format) rule attempts to reduce over-triggering, but IVD has no telemetry to detect
normalization. The user bears full responsibility for reading and evaluating each
verification beat.
Canon rules installed in an instruction file are static text. The hosted MCP Canon
engine may ship new R-invariants (e.g., R13 in v0.2.0) that the installed rules block
does not include. canon_check may report failures for rules the agent was never told
to enforce. Use canon_check_rules_installed to detect and refresh stale Canon rules.
If a project’s existing agent instructions conflict with Canon rules, the agent will
resolve the conflict unpredictably or produce inconsistent behavior between sessions.
canon_check_rules_installed does not scan for pre-existing conflicting instructions.
Conflict detection is the user’s responsibility.
Intent artifacts (particularly system_intent.yaml and workflow-level intents) typically contain architecture decisions, permission models, compliance requirements, and business rules. IVD’s default convention places intent artifacts at the repository root or in module directories, directly alongside code. If your repository is public, this information is public.
For sensitive projects: keep system-level and workflow-level intents in a separate private repository or another gitignored location outside this public repo. Do not store maintainer-only material in the OSS tree.
Self-hosted deployments require a .env file containing OPENAI_API_KEY, REDIS_URL,
and IVD_API_KEYS. If this file is committed to a repository — even temporarily — the
credentials are exposed. The IVD repo’s .gitignore excludes .env; this protection
does not automatically transfer when you fork, copy, or reuse the configuration in a new
project. Verify that .env is explicitly excluded in every repository that contains
an IVD deployment.
If credentials are exposed in a public repository, treat it as a security incident: rotate all keys immediately and audit access logs for the affected services.
If a team’s adoption goal becomes “all modules have intent artifacts” rather than
“we ship fewer constraint violations,” the optimization shifts to producing
structurally valid artifacts that satisfy ivd_validate without providing useful
contextual signal. This is Goodhart’s Law applied to IVD. Such artifacts satisfy the
format check while providing no actual constraint to the AI — reproducing exactly the
failure mode IVD was built to prevent.
IVD’s value comes from substantive constraint quality. An organization that treats artifact creation as a checkbox metric will not realize the methodology’s benefits and should not represent its systems as “IVD-verified” to downstream parties.
IVD recipes are designed for specific technology contexts described in their use_cases
field. Applying a recipe (e.g., infra-background-job.yaml, which targets Celery/Redis)
to a different infrastructure (e.g., AWS SQS) without reviewing the use-case section
will cause the agent to implement faithfully against the wrong constraints. ivd_load_recipe
returns the full recipe content but does not gate on use-case confirmation. Verify that
the recipe’s constraints match your actual stack before proceeding.
New team members who onboard by reading intent artifacts assume those artifacts reflect
the current system. If intent has drifted from code (R-004), this creates a wrong mental
model at scale. Artifacts carry status: metadata (canonical, experimental,
deprecated) and a verification: section, but stale artifacts are rarely proactively
marked deprecated. There is no tooling that flags artifacts not updated in a given period.
IVD adds structured intent overhead before implementation. This overhead is not warranted for trivial changes (fixing a typo, renaming a variable, adding a comment). Applying the full IVD workflow to every task will produce fatigue and adoption failure. IVD is designed for tasks where the AI’s interpretation of intent matters — not as a universal requirement for all code changes.
When you use IVD to build AI-powered systems, you are the deployer of those systems. The obligations that apply to your systems are yours. IVD’s involvement as the toolchain used in development does not transfer, share, or reduce those obligations.
Under Article 25, deployers of high-risk AI systems bear obligations regardless of the development tool used. If you are building an Annex III system using IVD:
Timeline note (updated 2026-07-19): the Annex III high-risk system compliance deadline, originally August 2026, has been postponed by the Digital Omnibus on AI to December 2, 2027 (high-risk systems embedded in regulated products: August 2, 2028). GPAI model provider obligations (Article 53+) remain in application since August 2, 2025 and are unaffected by this delay. Verify the current date against the official timeline before relying on any specific deadline — the EU has amended this schedule once already and may do so again.
Source: https://artificialintelligenceact.eu/article/14/
Source: https://artificialintelligenceact.eu/article/25/
Source: https://ai-act-service-desk.ec.europa.eu/en/ai-act/timeline/timeline-implementation-eu-ai-act
Updated 2026-07-19: Colorado’s original AI Act (SB 24-205, cited in earlier versions of this document) was repealed and replaced by SB 26-189, signed May 14, 2026, following a federal magistrate’s stay of SB 24-205 enforcement and a constitutional challenge joined by the DOJ. The replacement is narrower: it drops the SB 24-205 duty of care and mandatory algorithmic impact assessments, and substitutes disclosure and record-keeping obligations with a 60-day pre-enforcement cure period (sunsets January 1, 2030). The bill is generally effective August 12, 2026; the developer technical- documentation and consumer-notice obligations described below phase in January 1, 2027.
If you deploy an IVD-assisted automated-decision-making system affecting Colorado residents in employment, housing, financial services, insurance, healthcare, or government benefits, you must:
Source: https://leg.colorado.gov/bills/sb26-189
If your AI system processes personal data of EU residents, you are a data controller.
IVD intent artifacts may support GDPR Article 25 (data protection by design) and
Article 13 (transparency) compliance — but only if those artifacts are accurate, current,
and substantive. Structural compliance (artifacts exist and pass ivd_validate) without
substantive compliance (artifacts accurately constrain the deployed system) does not
satisfy the regulation. You bear the controller obligations; IVD bears processor
obligations only with respect to personal data you transmit through the hosted server.
Source: https://eur-lex.europa.eu/eli/reg/2016/679/oj
If your business meets CCPA applicability thresholds (annual gross revenue > $25M, or data of ≥ 100,000 California consumers, or ≥ 50% revenue from selling personal information), CCPA/CPRA applies to your processing of California residents’ data. IVD provides no CCPA compliance functionality, tooling, or documentation.
SB 53, the Transparency in Frontier Artificial Intelligence Act, signed September 29, 2025, effective January 1, 2026, requires “large frontier developers” (a threshold based on compute and revenue) to publish safety frameworks, report critical safety incidents, and provide whistleblower protections. It targets frontier model developers, not downstream deployers — it applies to you only if you are training or fine-tuning a frontier-scale model, not if you are using IVD to build applications on top of one.
AB 2013, the GAI Training Data Transparency Act, effective January 1, 2026, requires developers of generative AI systems to publicly document the provenance of training data. If you build a generative AI product using IVD and make training-data representations to your users, those representations are yours to substantiate — IVD provides no training-data provenance tooling.
Source: https://leginfo.legislature.ca.gov/faces/billTextClient.xhtml?bill_id=202520260SB53
Source: https://www.gov.ca.gov/2025/09/29/governor-newsom-signs-sb-53-advancing-californias-world-leading-artificial-intelligence-industry/
Signed June 22, 2025, effective January 1, 2026. TRAIGA prohibits specific AI practices (intentional discrimination against a protected class, manipulation causing self-harm/violence, generating unlawful CSAM or deepfakes) and applies to developers and deployers doing business in Texas or serving Texas residents. Enforcement is exclusively by the Texas Attorney General — there is no private right of action — with penalties of $10,000–$200,000 per violation depending on severity and curability.
If you deploy an IVD-assisted AI system serving Texas residents, TRAIGA’s prohibited- practice list applies to your system regardless of the tools used to build it.
Source: https://capitol.texas.gov/BillLookup/History.aspx?LegSess=89R&Bill=HB149
Effective January 1, 2026, this amendment to the Illinois Human Rights Act makes it a civil rights violation for an employer to use AI that has a discriminatory effect on a protected class in employment decisions (recruitment, hiring, promotion, discharge, discipline, or terms of employment), or to use zip code as a proxy for a protected class. Employers must provide notice when AI is used in covered employment decisions.
If you use IVD to help build an AI system used in employment decisions affecting Illinois employees or applicants, this obligation is yours regardless of the development toolchain.
Source: https://www.ilga.gov/ftp/legislation/103/BillStatus/HTML/10300HB3773.html
The hosted MCP server at mcp.ivdframework.dev cannot access your local filesystem.
Path-based tools (ivd_find_artifacts, ivd_assess_coverage, ivd_check_placement,
ivd_list_features, ivd_init) accept project_root paths but operate against the
server’s own sandboxed filesystem — not your machine. Any path such as
/Users/yourname/myproject will return “Project root not found.”
This is a consequence of the remote service architecture, not a bug. If you need these tools to operate against your local project files, use a self-hosted deployment.
This limitation is a material fact for any organization evaluating IVD for compliance documentation under EU AI Act Article 13(3)(b) (known limitations) or for any disclosure obligation under FTC Act Section 5 (material omissions).
Use of IVD — whether hosted or self-hosted, free or paid, under any licensing arrangement — does not create a professional services relationship of any kind between you and Leo Celis or the IVD project. In particular:
If you require professional advice — legal, compliance, engineering, or otherwise — engage a qualified professional independently.
To the maximum extent permitted by applicable law, you agree to defend, indemnify, and hold harmless Leo Celis, the IVD project, its contributors, and its maintainers from and against any and all claims, damages, obligations, losses, liabilities, costs, or expenses (including reasonable legal fees) arising from:
This indemnification obligation survives termination or discontinuation of your use of IVD.
THE IVD FRAMEWORK, HOSTED SERVER, MCP TOOLS, RECIPES, INTENT ARTIFACT SCHEMAS, CANON LAYER, JUDGMENT PHASE, AND ALL ASSOCIATED MATERIALS ARE PROVIDED “AS IS,” WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO:
USE OF IVD DOES NOT GUARANTEE THAT YOUR AI SYSTEM WILL COMPLY WITH ANY LAW, REGULATION, OR STANDARD, INCLUDING BUT NOT LIMITED TO THE EU AI ACT, GDPR, CCPA/CPRA, NIS2, THE CYBER RESILIENCE ACT, NIST AI RMF, THE COLORADO AI ACT, OR ANY SECTOR-SPECIFIC REGULATION.
ALL USES OF IVD — INCLUDING USES, WORKFLOWS, AND RISKS NOT INDIVIDUALLY ENUMERATED IN THIS DOCUMENT — ARE AT YOUR OWN RISK. This document identifies known and foreseeable risks; it is not an exhaustive enumeration of all risks you may encounter.
TO THE MAXIMUM EXTENT PERMITTED BY APPLICABLE LAW:
16.1 IN NO EVENT SHALL LEO CELIS, THE IVD PROJECT, ITS CONTRIBUTORS, OR ITS MAINTAINERS BE LIABLE FOR ANY INDIRECT, INCIDENTAL, SPECIAL, CONSEQUENTIAL, OR PUNITIVE DAMAGES — INCLUDING BUT NOT LIMITED TO LOSS OF DATA, LOSS OF PROFITS, LOSS OF BUSINESS OPPORTUNITY, REGULATORY FINES OR PENALTIES, BUSINESS INTERRUPTION, OR REPUTATIONAL HARM — ARISING OUT OF OR IN CONNECTION WITH YOUR USE OF IVD, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
16.2 AGGREGATE LIABILITY CAP: IVD’S TOTAL AGGREGATE LIABILITY TO YOU FOR ALL CLAIMS ARISING OUT OF OR RELATED TO YOUR USE OF IVD — INCLUDING DIRECT DAMAGES — SHALL NOT EXCEED THE GREATER OF (a) THE TOTAL FEES ACTUALLY PAID BY YOU TO IVD IN THE TWELVE MONTHS IMMEDIATELY PRECEDING THE CLAIM, OR (b) USD $50. FOR USERS WHO HAVE PAID NOTHING (INCLUDING ALL FREE-TIER AND OPEN-SOURCE USERS), THIS CAP IS USD $0.
16.3 NOTHING IN THIS SECTION LIMITS LIABILITY FOR FRAUD OR INTENTIONAL MISCONDUCT ON THE PART OF LEO CELIS.
16.4 SOME JURISDICTIONS DO NOT ALLOW THE EXCLUSION OF CERTAIN WARRANTIES OR THE LIMITATION OF CERTAIN TYPES OF DAMAGES. WHERE SUCH RESTRICTIONS APPLY, THE EXCLUSIONS AND LIMITATIONS ABOVE APPLY TO THE FULLEST EXTENT PERMITTED BY APPLICABLE LAW.
This document and all disputes arising from your use of IVD are governed by the laws of the State of Florida, United States, without regard to its conflict-of-law provisions.
Any legal action or proceeding arising from this document or your use of IVD must be brought exclusively in the state or federal courts located in Broward County, Florida, United States. You irrevocably consent to the personal jurisdiction and venue of those courts and waive any objection based on inconvenient forum.
EU users note: Nothing in this section limits mandatory consumer or data-subject rights available under EU law, including rights under GDPR, the EU AI Act, or applicable EU consumer protection law. EU-resident users retain those rights regardless of this choice-of-law clause.
To report a security vulnerability in IVD (including the hosted server), follow the
responsible disclosure process in SECURITY.md. Do not open a public
GitHub issue for security vulnerabilities.
For potential personal data breaches involving the hosted server (e.g., suspected unauthorized access to data transmitted through tool arguments), contact leo@leocelis.com immediately. If you are an EU controller and the breach triggers GDPR Article 33 obligations for your organization, do not wait for IVD’s response — begin your 72-hour supervisory authority notification process immediately using the information available to you.
Full legal document set:
| Document | Purpose |
|---|---|
| TERMS_OF_SERVICE.md | Binding terms of use and acceptance |
| PRIVACY_POLICY.md | GDPR Art. 13 privacy notice |
| DATA_PROCESSING_AGREEMENT.md | GDPR Art. 28 DPA (request for EU enterprise) |
| SECURITY.md | Vulnerability disclosure process |
| LICENSE | MIT License (open-source code) |
Material changes to this document will be noted in DECISIONS.md with an FDR entry.
The version number and effective date at the top of this file reflect the last revision.
Notice to hosted-server users: Because this document is maintained in a public git repository, changes do not trigger automatic email notification. If you rely on this document for compliance purposes, monitor the repository for changes or periodically review the effective date. For enterprise or regulated deployments, maintaining a local copy of the version effective at your deployment date is recommended.
All legal sources cited in this document, with official URLs and verification dates:
Version 2.2 — corrected §11.2 (Colorado’s SB 24-205 was repealed and replaced by SB 26-189 in May 2026), updated §11.1’s EU AI Act high-risk deadline (postponed to December 2027), and added §11.5–11.7 covering California SB 53/AB 2013, Texas TRAIGA, and Illinois Public Act 103-0804 — all enacted or taking effect since this document’s prior revision (FDR-026, regulatory-currency review of 2026-07-19). Version 2.1 added the unauthorized-fork/impersonation disclaimer (§2) addressing a gap identified in the bad-actor-user threat review of 2026-07-19 (FDR-025). Version 2.0 expanded from v1.0 with full risk coverage, owner-protective clauses, and addressing all gaps identified in the cross-check revision of 2026-05-10.
This document is not legal advice. Consult qualified legal counsel before making compliance or legal decisions based on this text.