Skill Hub — AI-Assisted Analysis

Validate AI-Generated Requirements

Check AI-generated requirements for hallucinations, missing context, fake certainty, and hidden assumptions before they enter a requirements document.

What this skill is for

AI can draft requirements quickly, but it invents fields, omits stakeholders, and states business rules with fake confidence. This skill provides a structured validation workflow to catch these failures before the requirements reach a stakeholder or a system. The output is a validated requirements brief where every item has a confidence label and a traceable source.

When to use this skill

After using AI to generate or expand a requirements draft.
Before sending AI-generated requirements to business stakeholders for review.
When AI output references SAP transactions, tables, or fields you do not recognize.
When integrating AI-generated content into an official requirements document or backlog.
When a stakeholder challenges a requirement and the only source is an AI session.

Real work situations

AI invents a field that does not exist

An AI drafts requirements for a new SAP SD pricing workflow and includes a requirement to "set the customer credit override flag in table KNA1." There is no such flag in KNA1. If this enters the requirements document, the development team will waste time searching for a nonexistent field, and the business will lose trust in the analysis.

AI omits a critical integration prerequisite

An AI generates requirements for a new EDI invoice interface and describes message mapping, error handling, and monitoring — but never mentions the EDI partner agreement or the need for SAP S/4 compatibility pack validation. The project proceeds without these checks and stalls during technical design.

AI assumes real-time data availability

An AI drafts requirements for a real-time operational dashboard and assumes the SAP data warehouse supports near-real-time latency. The actual warehouse is batch-updated nightly. The requirements are approved, the dashboard is built, and the first demonstration reveals a 24-hour data lag that makes the metrics unusable for the intended use case.

Inputs required

AI-generated requirements draft — the raw output from the AI tool.
System documentation — SAP module guides, existing configuration, transaction reference.
Stakeholder interview notes — to verify that the AI captured the right people and needs.
Business process maps — to confirm that the AI described the actual process, not an idealized one.
Existing requirements baseline — if any (optional).

Questions to ask

Which SAP transactions, tables, or fields does the AI reference, and do they exist in this version?
Which business rules are stated, and who in the organization confirmed them?
Which stakeholders are mentioned, and who is missing from the AI output?
What assumptions does the AI make about system behavior, data availability, or process timing?
What evidence does the AI provide for each claim, and is the evidence verifiable?
Does the AI confuse a need with a solution, or a symptom with a requirement?

Working method

Freeze the AI output. Save the raw AI-generated requirements as a separate document so you can compare before and after.
Flag every system-specific claim. Highlight every mention of a transaction code, table name, field name, configuration object, or API endpoint.
Cross-reference with system documentation. Verify each flagged claim against SAP Help, existing system documentation, or a sandbox system. Mark verified, unverified, or false.
Check for missing stakeholders. Compare the AI output against the stakeholder list from the project. Flag any missing owners, reviewers, or approvers.
Surface hidden assumptions. Read each requirement and ask: what must be true for this to work? List assumptions that the AI never stated.
Assess confidence versus evidence. For each requirement, rate the AI's confidence (high, medium, low, speculative) based on the evidence it provided.
Label each requirement. Apply one of: Verified, Assumption, Needs Review, Hallucination, Conflict.
Produce a validated brief. Rewrite the requirements with labels, sources, and a log of what was corrected or removed.
Share the hallucination log. Document what the AI got wrong so the team can improve prompts or avoid the same patterns.

Decision rules

If the AI claims a field or transaction exists, verify it in the system before accepting the requirement.
If the AI states a business rule, find the business owner who confirmed it; otherwise label it as an assumption.
If the AI omits a stakeholder who owns the affected data or process, add them and flag the gap.
If the AI is confident but provides no evidence, downgrade the requirement to "unverified assumption."
If the AI contradicts existing documentation, trust the documentation and flag the AI output for review.
If a requirement is a hallucination, remove it and log it; do not try to salvage it.
If two requirements depend on the same assumption, group them and elevate the assumption to a risk.

Deliverables

Validated Requirements Brief — requirements with confidence labels and sources.
Hallucination Log — a list of invented or false claims found in the AI output.
Assumption Register — unstated assumptions that must be verified before implementation.
Stakeholder Gap List — missing stakeholders who need to be consulted before the requirements are finalized.

Templates

Validated Requirements Brief

---
title: Validated Requirements Brief
source: AI-generated draft + human validation
project: [project name]
validated_by: [name]
date: [YYYY-MM-DD]
---

## Requirement V-001
- **Statement**: [exact requirement text]
- **Confidence**: [Verified / Assumption / Needs Review / Hallucination / Conflict]
- **Source**: [AI output, stakeholder interview, system doc, unknown]
- **System claim**: [transaction / table / field mentioned]
- **Verification result**: [confirmed / not found / contradicts doc]
- **Stakeholder**: [owner or reviewer]
- **Assumption**: [what must be true]
- **Risk if assumption is wrong**: [consequence]

## Hallucination Log
| # | AI Claim | Actual Status | Impact |
|---|----------|---------------|--------|
| 1 | [claim] | [false / unverified] | [what would have gone wrong] |

## Assumption Register
| # | Assumption | Affects Requirements | Owner to Verify |
|---|------------|----------------------|-----------------|
| 1 | [assumption] | [V-001, V-002] | [stakeholder name] |

Quality checklist

[ ] Every requirement has a confidence label.
[ ] Every system-specific claim is verified or flagged as unverified.
[ ] Every stakeholder mentioned in the source material is present, or the gap is documented.
[ ] The hallucination log contains at least one entry if the AI made a system-specific claim.
[ ] No requirement enters the final document with a "Hallucination" label.
[ ] The assumption register links assumptions to specific requirements.
[ ] The brief can be read by someone who did not see the AI output and still makes sense.

Common mistakes

Mistake: Trusting the AI's tone of confidence as evidence. Consequence: A hallucinated field or transaction enters the requirements document and wastes development time.
Mistake: Skipping cross-reference because the requirement "looks right." Consequence: A plausible-sounding but incorrect business rule is adopted, creating downstream compliance or process failure.
Mistake: Accepting AI output without traceability to source. Consequence: When stakeholders challenge a requirement, there is no evidence of who said it or why it was included.
Mistake: Treating hallucinations as minor errors that can be ignored. Consequence: The same AI tool will hallucinate again on the next project because the pattern was never logged or corrected.

Weak output vs Strong output

Weak output — bad AI usage

A consultant pastes AI-generated requirements into a Word document without review. The AI included a requirement to "update the Z-CUSTOM-FIELD in the sales order header via BAPI_SALESORDER_CREATE." The team spends three days searching for the field before discovering it does not exist. The requirement also assumed that all sales organizations use the same incompletion procedure, which is false in this landscape. The client receives a document with two critical errors and loses confidence in the analysis.

Strong output — good AI usage

The consultant uses AI to draft requirements, then applies the validation skill. The hallucination log catches a fake transaction code (BAPI_SALESORDER_MODIFY) and a nonexistent table (VBAK_EXT). The assumption register surfaces that the AI assumed real-time ATP availability for a make-to-order process. The validated brief rewrites requirement V-003 with a "Needs Review" label and assigns it to the SD lead. The stakeholder review session is productive because every question has a source and every risk has an owner.

Agent instructions

AI Prompt Pattern

Role: You are a requirements validation assistant.
Context: I have an AI-generated requirements draft for a [SAP module / business process] project. I need you to validate it.
Tasks:
1. Flag every mention of a transaction code, table, field, or configuration object.
2. Compare each claim against [system documentation / known SAP behavior].
3. Identify missing stakeholders from this list: [list].
4. Surface hidden assumptions.
5. Label each requirement as Verified, Assumption, Needs Review, Hallucination, or Conflict.
6. Output a validated brief in the template format provided.
Constraints: Do not invent system objects. Do not present assumptions as facts. If you cannot verify a claim, label it as unknown.

Agent dos

Ask for the system documentation or SAP version before validating system claims.
Produce the hallucination log and assumption register as separate artifacts.
Link each requirement to a source document or stakeholder quote.
Flag conflicts between AI output and existing documentation explicitly.

Agent don'ts

Do not trust the AI's confidence level as evidence.
Do not skip cross-referencing because a claim "sounds right."
Do not merge hallucinated requirements into the validated brief.
Do not present your own assumptions as verified facts.

Related skills

Requirements Elicitation — capturing original stakeholder needs before AI generation.
Gap Analysis — comparing validated requirements against current state.
Agent Usage Guide — general rules for how agents should use Skill Hub.

Related Atlas pages

SAP Process Audit — structured diagnostic frame for cross-process audits.
SAP Incompletion Procedure Diagnostics — example of how specific SAP diagnostics surface hidden requirements.

Verification status and limitations

This skill is a public working interpretation of AI-assisted requirements validation. It is not an official SAP, BABOK, or vendor guideline. The validation steps assume access to system documentation or a sandbox environment; if neither is available, the confidence labels will be less reliable. AI tools change frequently; the hallucination patterns described here are representative, not exhaustive. Use this skill as a structured starting point, not as a guarantee of accuracy.