AI component vs use case
AI component vs use case
Every project card on DecAIHub has two fields that look similar but answer different questions: AI component and Use case. The first describes the specific technology inside the project; the second describes what the project does for its users. Mixing them up makes it harder to assess whether the AI is real and whether the product solves a genuine problem.
In short: AI component is what the AI does inside the system. Use case is what the user gets from the product. A project can have a strong use case but no real AI component — or vice versa.
What "AI component" means
The AI component (ai_component) field in a project card answers the question: what specific AI technology operates inside this project? It points to the mechanism — inference, training, analytics, data labeling, agent orchestration, compute routing — not to the marketing description.
Examples from real DecAIHub cards:
AI agent platform (workflows/tools/KB)— an agent framework with tools and knowledge baseAI/ML crypto market analytics (app)— machine learning models analyzing market dataAI data labeling + model evaluation (human experts)— a labeling pipeline with human-in-the-loopcompute orchestration— scheduling and distributing AI compute jobsagentic framework (memory/actions/plugins)— an agent runtime with memory and tool integrations
The AI component tells you what kind of AI work actually happens — regardless of the product's brand or marketing claims.
How to use this field: look for nouns that name mechanisms — models, pipelines, orchestrators, evaluators. If the line reads like a slogan, cross-check the evidence section. Strong cards often pair a concrete component string with reproducible artifacts or public technical descriptions.
What "Use case" means
The Use case (use_case) field answers a different question: what does the user do with this product? It describes the job the project performs — trading analytics, compute marketplace, agent builder, data annotation marketplace — without regard to how the AI is implemented underneath.
Examples:
AI trading terminal + no-code agent buildercompute marketplace + orchestrationdata labeling marketplace + dataset tradingbuild + run autonomous AI agentscrypto intelligence for humans + AI agents
The use case tells you why someone would use this product, not how the AI works inside.
How to use this field: ask whether the described job could exist without modern AI (for example, as a static dashboard). If yes, the AI component line becomes the differentiator — it should name what is non-obvious technically.
Why they are different and why both matter
A project might offer a compute marketplace (use case) powered by compute orchestration (AI component). Another might claim to be an AI trading terminal (use case) while its AI component is positioning only (plans/roadmap) — meaning there is no confirmed working AI yet.
When you read a card, comparing these two fields reveals whether the product's promise matches its technical reality:
- Strong AI component + clear use case — technology and product are both visible.
- Weak or absent AI component + bold use case — a possible gap between marketing and reality.
- Strong AI component + vague use case — technology exists but the product story is unclear.
Both fields feed into the DecAI Fit score. A high score requires evidence of real AI (AI component) and meaningful on-chain integration — not just a compelling product narrative.
Cross-check with category: composite AI categories summarize direction and domain; AI component and use case zoom in. A label like AI/Agents | Infra does not replace a precise component string — it situates the project for browsing.
How to read special values
Some cards contain values that are not technologies or use cases but interpretation modes — they signal how much evidence was found as of the verification date.
| Value | What it means |
|---|---|
positioning only (...) |
AI is mentioned in marketing or plans, but no Tier-1 evidence of a working AI component has been found. The parenthetical gives context, e.g. (plans/roadmap) or (meme/narrative). |
none |
No AI component or use case has been detected. This is not a permanent verdict — it reflects the state as of the verification date. |
unknown |
The assessor could not determine the value from available sources. No Tier-1, Tier-2, or Tier-3 data was found. |
These are field interpretation modes, not standalone technologies. They tell you about the evidence status, not about the underlying technology. A value of positioning only is not an accusation against the project — it means the gap between a marketing claim and a Tier-1 artifact has not been closed yet. For more on this principle, see Why absence of evidence is not absence of technology.
Where it appears in DecAIHub project cards
Both fields are in the Project Passport table. Look for:
- AI component (ai_component) — the technical mechanism
- Use case (use_case) — the product-level description
These fields, along with the AI thesis fit section and the Evidence table, help you separate marketing from verifiable claims.
What these terms alone do not prove
- Listing a specific AI component does not prove it actually works. The component description reflects what the assessor found, but evidence depth varies.
- A clear use case does not prove the product delivers on it. Use case is what the project claims to offer, not a performance guarantee.
- The combination of AI component + use case does not prove the token is necessary. Token necessity is a separate axis of DecAI Fit.
Do not confuse with
- Category is not the same as AI component or use case. Category (e.g.
AI/Agents | DeFi) classifies the project at a high level; the AI component and use case describe it in detail. - AI component is not a product description. It is narrower: only the AI mechanism, not the full feature set.
- Use case is not a financial forecast. It describes what the product does, not whether it is worth using.
Frequently asked questions
Can the same phrase appear in both fields?
Sometimes, but the meaning should differ. A short label might echo across fields when the product is narrow (for example, a pure inference API). In those cases, other parts of the card — benchmarks, architecture notes, evidence — carry the detail.
Which field should I read first?
If you care what the software does for users, start with use case, then validate with AI component. If you care whether a model or agent exists, start with AI component, then see whether use case explains who benefits.
How does this relate to automation vs real AI?
Use case can be satisfied by rules and scripts; AI component should name learning-based or model-based mechanisms when that is what the project claims. Mismatch between “AI” marketing and a non-learning stack is a common verification theme.
External references
- NIST — Artificial Intelligence Resource Center — definitions and guidance that align everyday words (“model,” “inference,” “training”) with technical usage in standards-oriented contexts.
- Partnership on AI — resources — research and guidance on how organizations describe AI capabilities and impacts.
No comments to display
No comments to display