How to tell if a project really has AI
How to tell if a project really has AI
You are looking at a crypto project that claims to use AI. The website says "AI-powered." The pitch deck mentions neural networks. The token name has "AI" in it. But how do you know whether a real, working AI component exists behind those claims, or whether "AI" is just a marketing label?
This is the central question that DecAIHub was built to answer. The difference between genuine AI and AI-washing is not visible from the surface. Marketing teams know that "AI" is one of the most powerful keywords in crypto, and many projects use it regardless of what the technology actually does. Real innovation sits side by side with empty claims, and without a structured method, telling them apart takes hours of independent research for every project. This guide gives you a practical toolkit that works whether you are a newcomer trying to avoid hype or an experienced participant who needs a fast screening framework.
In short: check the AI component field for specificity, look at ai_score for a quantified verdict, review the evidence tier, compare claims against verifiable artifacts, apply the five-question test, and watch for red flags that suggest AI-washing.
The five-question test
Before diving into a full card review, run a quick diagnostic. Each question targets a specific layer of AI verification.
| # | Question | Strong answer | Weak answer |
|---|---|---|---|
| 1 | What exactly does the AI do? | Names the model type, task, and mechanism | "We use AI to optimize everything" |
| 2 | Where can I see it working? | Live demo, public API, recorded outputs | "Coming soon" or private beta with no artifacts |
| 3 | Where is the code or model? | Public repo with training/inference code, model card | Empty repo, fork of a tutorial, nothing public |
| 4 | How do you measure quality? | Named benchmark, dataset, version, date | "Best accuracy in the industry" or no metrics |
| 5 | What happens if you remove the AI? | "The product cannot function without it" | "It still works, just less smart" |
Questions 1-2 test specificity and existence: can the project describe and demonstrate its AI? Questions 3-4 test verifiability and rigor: can an outsider inspect the evidence? Question 5 tests centrality: is AI architecturally essential or cosmetic?
A project with strong answers to all five is likely to have a high ai_score. Three or more weak answers warrant close scrutiny.
Step-by-step verification guide
Step 1: Check the AI component field
The AI component field in the Project Passport describes the specific AI technology inside the project. It is the single fastest indicator of substance.
Concrete values like inference engine for LLM routing or AI agent platform (workflows/tools/KB) tell you what the AI actually does. Special values signal gaps: positioning only means AI appears in marketing but no working component has been confirmed; none or unknown means no AI was detected from available sources. These are not permanent verdicts; they reflect the evidence available at review time. See Why absence of evidence is not absence of technology.
Step 2: Check the ai_score
The ai_score (0-3) quantifies how much verifiable evidence exists for a project's AI claims. It is part of the DecAI Fit metric, calculated as min(3, AI_0 + AI_1 + AI_2 + AI_3 + AI_4) — five binary flags capped at 3.
| ai_score | Meaning |
|---|---|
| 0 | No verified AI presence. DecAI Fit is forced to zero. |
| 1 | Tier-1 declaration of intent exists, but no working AI verified. |
| 2 | Partial evidence: the AI is described and some artifacts or demos exist. |
| 3 | Strong evidence: public code, benchmarks, architecture docs, working demos. |
If ai_score = 0, the AI claim is currently unsubstantiated. This is not an accusation against the project, but no Tier-1 source confirms the claim.
Step 3: Look for Tier-1 evidence
Tier-1 evidence consists of artifacts closest to the project's actual reality:
- Public code repositories with AI-related code: model definitions, training scripts, inference pipelines, not just a README.
- Technical documentation describing model architecture, data pipeline, or system design with versions and dates.
- Model artifacts such as published weights, model cards, or entries on Hugging Face.
- Benchmarks with methodology, comparison baselines, dataset specification, and version information.
- Working demos where the AI component produces observable, testable outputs.
Tier-2 (aggregator descriptions, interviews) provides useful context but should not be the sole basis for confirming AI. Tier-3 (influencer posts, PR articles, rumors) carries minimal weight.
Step 4: Cross-check claims against artifacts
Compare what the project says with what can be independently verified. A project claiming "proprietary neural network for real-time prediction" should have code, documentation, or at least a demo that demonstrates this capability. When the marketing language is ambitious but the verifiable artifacts are thin, the gap itself is a signal.
Common red flags
Certain patterns suggest AI claims may not be real. None of these is an accusation against the project on its own, but each warrants deeper investigation.
- Marketing-only AI. "AI" in the name and pitch deck, but no architecture, model name, or data pipeline described anywhere. This is the most common form of AI-washing.
- Empty or unrelated repository. A GitHub link exists but contains no AI-related code, no releases, or code unrelated to the claimed component.
- Metrics without methodology. Claims like "99% accuracy" without specifying benchmark, dataset, evaluation method, or version.
- Pure API wrapper. The entire "AI" is a call to a third-party API with no proprietary logic, fine-tuning, or domain-specific processing on top.
- Post-launch AI branding. "AI" was added to the project name after the token launched, with no corresponding technical changes.
- No versioning or timeline. AI-related claims lack dates, version numbers, or traceable development history.
- Circular evidence. The project cites its own marketing materials as proof, or references articles that only repeat the project's press release.
- Perpetual roadmap. AI features are always "coming soon" with no shipped milestones or public artifacts despite months of existence.
- Mismatched complexity. The project claims advanced capabilities (verifiable inference, federated learning) but the team and codebase do not match that complexity.
Common green flags
Genuine AI projects share recognizable characteristics. The more of these a project demonstrates, the more likely its AI claims are substantive.
- Specific, testable claims. The project names the model architecture, training approach, and data sources with enough detail for a technical reviewer to evaluate.
- Active, relevant code. A public repository with model training or inference code, meaningful commit history, tests, and recent activity.
- Reproducible metrics. Performance results include benchmark name, dataset, methodology, version, and date.
- Architecture documentation. Technical docs include system design, data flow, and versioned authorship that evolves over time.
- Working, testable demos. A live application or public API that produces AI outputs anyone can independently test.
- Team with verifiable AI/ML backgrounds. Published papers, open-source contributions, or verifiable professional history.
- Model cards or data sheets. The project follows established practices for documenting models: intended use, limitations, training data, evaluation results.
Real-world patterns
To build intuition, consider these contrasting archetypes. No specific projects are named; the goal is to recognize structural differences.
Pattern A: Genuine AI with strong evidence. Active repository with model training code, evaluation scripts, and documented inference pipeline. Benchmarks published with methodology. Live demo producing observable AI outputs. The ai_score is 3.
Pattern B: Early-stage AI with partial evidence. Official docs describe what the AI will do with a roadmap including AI milestones. A prototype exists but is not publicly accessible. No benchmarks yet. The ai_score is 1-2. This is not AI-washing; it is an early-stage project where evidence has not yet materialized.
Pattern C: AI-washing with no substance. "AI" prominent in branding. Pitch deck mentions "proprietary neural networks." No technical documentation beyond marketing. No repo, demos, benchmarks, or model artifacts. The ai_score is 0.
Pattern D: API wrapper presented as proprietary AI. The AI component consists entirely of calls to a third-party provider. No fine-tuning, no custom pipeline, no domain-specific processing. This is not an accusation against the project, but calling it "proprietary AI" misrepresents the technical reality. See Automation vs real AI component.
How DecAIHub solves this
DecAIHub exists because answering "is this AI real?" should not require hours of independent research for every project. The platform uses a structured framework to separate real AI from AI-washing.
DecAI Fit
DecAI Fit is a composite index (0-6) measuring how well a project aligns with the principles of Decentralized AI. It combines four dimensions: AI reality, Onchain necessity, Token necessity, and Evidence.
The critical rule: if ai_score = 0, then DecAI Fit = 0 regardless of the other dimensions. No verified AI means the project does not meet the threshold for Decentralized AI classification. This single rule eliminates the most common form of AI-washing from the scoring system.
AI reality flags (AI_0 through AI_4)
AI reality is built from five binary flags, each capturing a progressively deeper layer of verification:
| Flag | What it checks | Example of evidence |
|---|---|---|
| AI_0 | Tier-1 declaration of AI intent | Roadmap or official docs mentioning AI plans |
| AI_1 | Description of what the AI does | Technical docs explaining the model's function |
| AI_2 | Working demos or examples | Public demo, live API, recorded outputs |
| AI_3 | Metrics and benchmarks | Published F1 score on a named dataset with version |
| AI_4 | Architecture and model versions | Architecture diagrams, model cards, version history |
All five flags set to 1 means strong, multi-layered evidence of real AI. Only AI_0 = 1 means declared intent with nothing verifiable yet.
Tier-1, Tier-2, Tier-3 evidence system
Every claim in a project card is grounded in classified sources:
- Tier-1 (evidence): code, contracts, official documentation, audits, on-chain facts. Highest weight.
- Tier-2 (context): aggregator descriptions, ecosystem catalogs, analytics dashboards, interviews. Useful for cross-checking, insufficient as sole proof.
- Tier-3 (noise): influencer posts, PR articles, rumors, unsourced claims. If only Tier-3 sources exist, DecAI Fit is capped at 2.
This hierarchy ensures that marketing materials alone cannot elevate a project's assessment.
AI-washing detection
DecAIHub does not assign accusatory or vindicating labels to projects. Instead, it measures the gap between claims and evidence. When marketing claims significantly exceed verifiable artifacts, this gap becomes visible in the card: a bold AI use case paired with positioning only or ai_score = 0 is a measurable, objective signal. The reader draws their own conclusions.
Quick verification checklist
| Check | Where to look | What to expect |
|---|---|---|
| AI component specificity | AI component field | Concrete mechanism, not buzzwords |
| AI score | ai_score in DecAI Fit | Above 0 for any verified AI |
| Evidence tier | Evidence table | Tier-1 artifacts for strong claims |
| Code existence | Linked repositories | AI-related code with commit history |
| Metrics quality | Documentation, benchmarks | Methodology, dataset, version, date |
| Demo availability | Product links, public APIs | Observable AI outputs |
| Team AI expertise | Team section, published papers | Verifiable ML/AI background |
| Versioning | Documentation, changelog | Dates, version numbers, history |
What verification alone does not prove
Even thorough verification has limits:
- A high ai_score does not mean the AI is good. It means verifiable artifacts exist. Quality is a separate question.
- A high ai_score does not mean the project will succeed. Technological merit and viability are different dimensions.
- A low ai_score is not an accusation against the project. Some projects have real technology but poor documentation or a closed development model.
- Verification reflects a point in time. Assessments are dated (
Last verified) and updated when new evidence appears. - AI verification does not assess the business model, team quality, or market fit. These are relevant but outside the scope of AI reality assessment.
Frequently asked questions
How quickly can I verify if a crypto project has real AI?
A basic check takes under five minutes using the project card on DecAIHub. Look at the AI component field, the ai_score, and the evidence tier. If the AI component says positioning only and ai_score = 0, you already have a strong signal. A deeper check with the five-question test and repository review takes 15-30 minutes.
What if a project has AI code on GitHub but no working product?
Code is a positive signal, but it needs context. Is it actively maintained? Does it relate to the claimed product? A repository with training scripts that has not been updated in two years, or appears unrelated to the project's stated functionality, is weaker evidence than an active, well-documented codebase with CI/CD and recent commits.
Does having a demo prove the AI is real?
A demo is strong evidence (it sets the AI_2 flag), but not definitive. It could use a third-party API behind the scenes or showcase a narrow prototype. The strongest verification combines a demo with code, documentation, and metrics: multiple independent layers telling a consistent story.
Can a project score well on DecAI Fit without open-source code?
Yes. Open-source code is the strongest Tier-1 evidence, but not the only kind. A project can achieve a meaningful ai_score through detailed technical documentation, published benchmarks, working demos, and model artifacts. However, without any Tier-1 evidence, governance caps limit the maximum score.
What is the most common form of AI-washing in crypto?
The most common pattern is marketing-only AI: "AI" in the name and materials, but no technical description, code, demos, or metrics. The second most common is the API wrapper: calling a third-party AI provider and presenting this as proprietary technology without fine-tuning or domain-specific logic.
Is it possible for a project to have real AI but a low DecAI Fit?
Yes. DecAI Fit measures verifiable evidence, not the actual state of technology behind closed doors. A project with sophisticated AI that publishes nothing will receive a low score because there is nothing to verify. DecAI Fit rewards transparency by design. When such a project later publishes artifacts, the score is updated.
See also
- What is an AI component
- AI component vs use case
- What counts as evidence of AI
- What does not count as evidence of AI
- What is an API wrapper
- Automation vs real AI component
- AI-washing, onchain-washing and token-washing
- Why absence of evidence is not absence of technology
- What is DecAI Fit
- How to read a project card
- Tier-1, Tier-2 and Tier-3 evidence
- AI reality, Onchain necessity and Token necessity
External references
- Stanford HAI — Artificial Intelligence Index Report — annual data on the state of AI research and industry adoption.
- OECD AI Policy Observatory — international AI governance frameworks and definitions.
- MIT Technology Review — AI topic — accessible reporting on advances and trends in AI.
- Hugging Face — Model Cards — documentation standard for publishing model information and evaluation results.
- Papers With Code — benchmarks, datasets, and state-of-the-art results across AI tasks.
No comments to display
No comments to display