Skip to main content

G-Cloud Clarification Questions

Generate structured clarification questions for G-Cloud service suppliers based on requirement gaps.

Command

arckit gcloud-clarify "<service name>"

Description

Analyzes gaps between your requirements and G-Cloud service descriptions, then generates structured clarification questions to send to suppliers. Helps validate services before procurement decisions.

Arguments

  • Service name: Name of the service to analyze (e.g., ‘Salesforce CRM Lot 2’)

When to Use

  • After running arckit gcloud-search
  • Before making procurement decisions
  • When service descriptions are vague
  • To validate technical capabilities
  • For due diligence on shortlisted services

Required Context

  • Requirements (ARC--REQ-.md) - MANDATORY
  • G-Cloud Search Results (ARC--GCLD-.md) - MANDATORY
  • Architecture Principles (ARC-000-PRIN-*.md) - Recommended

Features

Gap Analysis

For each MUST requirement, identifies:
  • CONFIRMED: Explicitly mentioned with specifics
  • ⚠️ AMBIGUOUS: Mentioned vaguely, needs clarification
  • NOT MENTIONED: Not addressed in service description

Ambiguous Claims Detection

Flags vague marketing language:
  • “Industry-standard” → Which specific standards?
  • “High availability” → What specific SLA percentage?
  • “Scalable” → To what capacity? Limits?
  • “Secure” → Which security certifications?
  • “Fast” → What specific performance metrics?

Question Prioritization

🔴 CRITICAL (Blocking):
  • MUST requirement not confirmed
  • Compliance requirement without evidence
  • Blocker for procurement
🟠 HIGH (Affects Scoring):
  • MUST requirement ambiguous
  • Integration unclear
  • SLA not specified
🔵 MEDIUM (Due Diligence):
  • SHOULD requirement missing
  • Pricing details incomplete
  • Data residency not confirmed
🟢 LOW (Nice to Know):
  • Nice-to-have features
  • Future roadmap questions

Output

Creates: projects/{project}/procurement/ARC-{PROJECT_ID}-GCLC-v1.0.md Includes:
  • Gap summary for each service
  • Structured clarification questions by priority
  • Risk assessment matrix
  • Email templates for suppliers
  • Service comparison - risk summary

Example Output

Question Format

#### Q1: Prometheus Metric Export
**Requirement**: NFR-005 (MUST) - Export metrics in Prometheus format

**Gap**: Service mentions "industry-standard monitoring" but 
Prometheus not explicitly mentioned.

**Question**:
> Does the service support Prometheus metric export?
> - Which Prometheus versions are supported?
> - What is the export format and endpoint?
> - Are custom metrics supported?

**Evidence Needed**:
- API documentation showing /metrics endpoint
- Example Prometheus configuration

**Priority**: 🔴 CRITICAL

Risk Assessment

Each service gets a risk level:
  • 🔴 CRITICAL: 1+ MUST requirements not confirmed → DO NOT PROCEED
  • 🟠 HIGH: 2+ MUST requirements ambiguous → CLARIFY FIRST
  • 🔵 MEDIUM: 1 MUST ambiguous OR 3+ SHOULD missing
  • 🟢 LOW: All MUST confirmed, few SHOULD missing

Email Templates

Provides ready-to-send templates:
Subject: Technical Clarification Required - [Service Name]

Dear [Supplier] Team,

We are evaluating [Service Name] for procurement via the 
Digital Marketplace. Before proceeding, we need clarification 
on several technical requirements:

**Critical Requirements (Blocking)**:
[List Q-numbers for critical questions]

**High Priority Requirements**:
[List Q-numbers for high priority questions]

Could you please provide:
- Written responses to questions [Q1-QN]
- Supporting documentation
- Access to demo/trial environment

We aim to make a procurement decision by [DATE + 2 weeks].
  • arckit gcloud-search - Find services (run this first)
  • arckit evaluate - Score suppliers after receiving responses
  • arckit requirements - Define requirements for gap analysis

Next Steps

After generating clarification questions:
  1. Review questions with technical team
  2. Send emails to suppliers using provided templates
  3. Set response deadline (typically 1 week)
  4. Schedule follow-up to review responses
  5. Run arckit evaluate after receiving responses
  6. Schedule technical demos for top candidates
  7. Make procurement decision

Build docs developers (and LLMs) love