arckit-cli 6.1.1__py3-none-any.whl

arckit_cli-6.1.1.data/data/share/arckit/docs/guides/fr-pssi.md

@@ -0,0 +1,87 @@
+# PSSI (Information System Security Policy) Playbook
+
+> **Guide Origin**: Community | **ArcKit Version**: [VERSION]
+
+`/arckit:fr-pssi` generates an Information System Security Policy (PSSI) for French public sector entities, following ANSSI PSSI guidance and RGS v2 requirements. The PSSI must be approved and signed by the Highest Authority (AA — Autorité d'Approbation).
+
+---
+
+## Inputs
+
+| Artefact | Purpose |
+|----------|---------|
+| Requirements (`ARC-<id>-REQ-v1.0.md`) | IS scope and security requirements |
+| EBIOS RM study | Risk analysis feeding policy objectives |
+| ANSSI assessment | 42 hygiene measures baseline |
+| IS Cartography | 4-level IS map for scope definition |
+
+---
+
+## Command
+
+```bash
+/arckit:fr-pssi Generate PSSI for <organisation and IS scope>
+```
+
+Output: `projects/<id>/ARC-<id>-PSSI-v1.0.md`
+
+---
+
+## Assessment Structure (9 Sections)
+
+| Section | Contents |
+|---------|----------|
+| 1. Purpose and Context | Organisational context, IS scope, regulatory basis |
+| 2. Security Objectives | Confidentiality, integrity, availability, traceability targets |
+| 3. Security Principles | 8+ core principles (defence in depth, least privilege, etc.) |
+| 4. Organisational Structure | AA, RSSI, DPO, DSI, FSSI roles and responsibilities |
+| 5. Applicable Standards | ANSSI referentials, RGS, NIS2, GDPR, sector standards |
+| 6. Security Domains | 7 domains (network, workstations, applications, IS management, physical, personnel, continuity) |
+| 7. User Obligations | Acceptable use, incident reporting, classification handling |
+| 8. Incident Management | Detection, response, escalation procedures |
+| 9. Lifecycle | 3-year review cycle, update triggers, approval process |
+
+---
+
+## Key Roles
+
+| Role | Responsibility |
+|------|---------------|
+| AA (Autorité d'Approbation) | Approves and signs the PSSI (highest authority in scope) |
+| RSSI | Responsible for IS security, PSSI maintenance |
+| DPO | Data protection obligations, GDPR intersection |
+| DSI | Technical implementation, IS operations |
+| FSSI | Functional IS security officer (operational level) |
+
+---
+
+## One-Page Workflow
+
+| Phase | Key Activities | ArcKit Commands |
+|-------|----------------|-----------------|
+| Foundation | Requirements, risk, cartography | `/arckit:fr-ebios`, `/arckit:fr-anssi-carto` |
+| Baseline | ANSSI 42 measures | `/arckit:fr-anssi` |
+| Policy | Generate PSSI | `/arckit:fr-pssi` |
+| DR | DR handling policy section | `/arckit:fr-dr` |
+
+---
+
+## Review Checklist
+
+- AA (Highest Authority) identified and prepared to sign.
+- IS scope matches cartography Level 1 missions.
+- 8+ security principles documented.
+- All 7 security domains covered with specific measures.
+- RSSI, DPO, DSI, FSSI roles defined with named individuals or positions.
+- EBIOS RM study referenced for risk analysis basis.
+- 3-year review cycle defined with explicit update triggers.
+- User obligations accessible and acknowledged (awareness programme planned).
+- Document classified OFFICIAL-SENSITIVE.
+
+---
+
+## Key Notes
+
+- **AA signature is mandatory**: the PSSI without AA approval has no legal standing in the French public sector context.
+- **Living document**: PSSI must be updated when IS changes significantly — not a set-and-forget document.
+- **Analogous to**: ISO 27001 ISMS policy, but specific to French public IS governance.

arckit_cli-6.1.1.data/data/share/arckit/docs/guides/fr-rgpd.md

@@ -0,0 +1,75 @@
+# French GDPR / CNIL Compliance Playbook
+
+> **Guide Origin**: Community | **ArcKit Version**: [VERSION]
+
+`/arckit:fr-rgpd` generates a French CNIL-specific GDPR layer assessment supplementing `/arckit:eu-rgpd`. It covers CNIL délibérations, health data (HDS), cookie rules, age 15 for minors, and CNIL enforcement patterns.
+
+---
+
+## Inputs
+
+| Artefact | Purpose |
+|----------|---------|
+| Requirements (`ARC-<id>-REQ-v1.0.md`) | Processing activities, data flows |
+| EU GDPR assessment (`ARC-<id>-RGPD-v*.md`) | Base GDPR compliance (run first) |
+| Data model (`ARC-<id>-DATA-v1.0.md`) | Personal data categories |
+
+---
+
+## Command
+
+```bash
+/arckit:fr-rgpd Assess CNIL compliance for <project or processing activity>
+```
+
+Output: `projects/<id>/ARC-<id>-CNIL-v1.0.md`
+
+> **Run after**: `/arckit:eu-rgpd` — this command adds the French layer on top.
+
+---
+
+## Assessment Structure
+
+| Section | Contents |
+|---------|----------|
+| CNIL Référentiels | Applicable sector référentiels (health, HR, CCTV, etc.) |
+| Cookie Compliance | Délibération 2020-091, opt-in consent, analytics exemptions |
+| Health Data (HDS) | HDS certification requirement for health data hosting |
+| Minors | Age 15 threshold, parental consent mechanisms |
+| Sensitive Data | Biometric processing (CNIL authorisation required) |
+| CNIL Prior Consultation | When to notify CNIL before processing |
+| DPO Registration | CNIL DPO registration obligations |
+| Enforcement Patterns | Recent CNIL sanctions and priority areas |
+| Gap Analysis | French-specific gaps beyond EU GDPR baseline |
+
+---
+
+## One-Page Workflow
+
+| Phase | Key Activities | ArcKit Commands |
+|-------|----------------|-----------------|
+| EU baseline | GDPR compliance | `/arckit:eu-rgpd` |
+| French layer | CNIL-specific assessment | `/arckit:fr-rgpd` |
+| High-risk | DPIA for high-risk processing | `/arckit:dpia` |
+
+---
+
+## Review Checklist
+
+- EU GDPR assessment (`ARC-<id>-RGPD-v*.md`) completed first.
+- CNIL référentiel applicable to the sector identified.
+- Cookie consent mechanism compliant with Délibération 2020-091.
+- Health data: HDS certification required for health data hosting in France.
+- Age verification mechanism for services targeting minors (age 15 threshold in France).
+- Biometric processing: CNIL authorisation or applicable exemption identified.
+- DPO registered with CNIL if obligatory.
+- CNIL prior consultation assessed for high-risk residual processing.
+
+---
+
+## Key Notes
+
+- **HDS (Hébergeur de Données de Santé)**: Any hosting of personal health data in France requires HDS certification — stricter than GDPR alone.
+- **Age 15**: France chose 15 as the digital consent age (GDPR allows 13–16) — platforms must verify age for minor users.
+- **Biometric data**: CNIL requires authorisation for most biometric processing (workplace access control is a common case).
+- **Scope**: Supplements `/arckit:eu-rgpd`. Do not run in isolation — EU GDPR baseline must be established first.

arckit_cli-6.1.1.data/data/share/arckit/docs/guides/fr-secnumcloud.md

@@ -0,0 +1,80 @@
+# SecNumCloud Qualification Assessment Playbook
+
+> **Guide Origin**: Community | **ArcKit Version**: [VERSION]
+
+`/arckit:fr-secnumcloud` assesses cloud provider and customer obligations under ANSSI's SecNumCloud 3.2 referential — the French sovereign cloud qualification scheme. Required for OIV SIIV hosting and sensitive public sector data.
+
+---
+
+## Inputs
+
+| Artefact | Purpose |
+|----------|---------|
+| Requirements (`ARC-<id>-REQ-v1.0.md`) | Cloud service type and data sensitivity |
+| EBIOS RM study | Risk level determination |
+| ANSSI assessment | Security baseline |
+
+---
+
+## Command
+
+```bash
+/arckit:fr-secnumcloud Assess SecNumCloud compliance for <cloud usage and data classification>
+```
+
+Output: `projects/<id>/ARC-<id>-SECNUM-v1.0.md`
+
+---
+
+## Assessment Structure
+
+| Section | Contents |
+|---------|----------|
+| Scope Determination | Is SecNumCloud required (OIV SIIV / ministerial decree / sensitive data)? |
+| Visa vs Qualification | Critical distinction — only full qualification satisfies legal obligations |
+| Provider Assessment | Qualified providers list, service scope, IS boundary |
+| Customer Obligations | Homologation prerequisites, data classification, access controls |
+| Architecture Requirements | SecNumCloud-compatible design (no non-qualified cloud dependencies) |
+| Procurement Clauses | Contractual minimum requirements for public-cloud contracts |
+| Gap Analysis | Gaps to achieve SecNumCloud-compliant architecture |
+
+---
+
+## Key Distinction: Visa vs Qualification
+
+| Status | Meaning | Satisfies OIV/Ministerial? |
+|--------|---------|---------------------------|
+| SecNumCloud Visa | In qualification process | No |
+| SecNumCloud Qualification | Full ANSSI qualification granted | Yes |
+| ISO 27001 / C5 / EUCS | European alternatives | No (for French OIV SIIV) |
+
+---
+
+## One-Page Workflow
+
+| Phase | Key Activities | ArcKit Commands |
+|-------|----------------|-----------------|
+| Risk | EBIOS RM study to determine risk level | `/arckit:fr-ebios` |
+| Security baseline | ANSSI 42 measures | `/arckit:fr-anssi` |
+| Cloud assessment | SecNumCloud compliance | `/arckit:fr-secnumcloud` |
+| Procurement | Cloud procurement clauses | `/arckit:fr-marche-public` |
+
+---
+
+## Review Checklist
+
+- SecNumCloud requirement confirmed (legal basis: OIV / ministerial decree / circular).
+- Visa vs Qualification distinction clearly stated.
+- Qualified provider and qualifying service scope confirmed on ANSSI published list.
+- IS homologation prerequisites documented.
+- Data classification confirmed (DR, Sensible but not classified, etc.).
+- Architecture reviewed for non-qualified cloud dependencies (which break qualification scope).
+- Procurement contractual clauses include SecNumCloud qualification as selection criterion.
+
+---
+
+## Key Notes
+
+- **Visa ≠ Qualification**: A provider with a visa is in the process — it does NOT satisfy the legal obligation for OIV SIIV hosting.
+- **More stringent than EUCS**: SecNumCloud 3.2 is stricter than the EU's EUCS high level — important for cross-border comparisons.
+- **DINUM doctrine cloud**: The Doctrine d'utilisation de l'informatique en nuage de l'État (2022) mandates SecNumCloud or equivalent for sensitive data — run `/arckit:fr-dinum` for the full doctrine assessment.

arckit_cli-6.1.1.data/data/share/arckit/docs/guides/framework.md

@@ -0,0 +1,234 @@
+# Framework Guide
+
+> **Guide Origin**: Official | **ArcKit Version**: [VERSION]
+
+`/arckit:framework` transforms existing project artifacts into a structured, phased framework with an overview document and executive guide, organising scattered architecture outputs into a coherent, actionable structure.
+
+---
+
+## Purpose
+
+As architecture projects progress, they accumulate a wealth of artifacts -- requirements, strategies, data models, stakeholder analyses, research reports, decision records. Individually, each artifact serves its purpose, but collectively they can become difficult to navigate, prioritise, and act upon. Without a unifying structure:
+
+- **Scattered recommendations** -- insights are spread across dozens of documents with no clear implementation sequence
+- **No phased roadmap** -- stakeholders cannot see what to do first, next, or later
+- **Executive inaccessibility** -- senior leaders lack a concise summary of what the project recommends and why
+- **Completeness gaps** -- it is hard to verify that all requirements and principles are addressed
+
+The `/arckit:framework` command **synthesises and organises** all existing artifacts into a phased framework that:
+
+- Organises scattered documents into a coherent, navigable structure
+- Creates an executive-friendly overview for senior stakeholder briefings
+- Enables phased adoption with clear implementation sequencing
+- Demonstrates completeness by mapping artifacts to framework phases
+- Provides a single entry point for understanding the entire project
+
+---
+
+## Inputs
+
+| Artifact | Requirement | What It Provides |
+|----------|-------------|------------------|
+| Architecture Principles (PRIN) | **MANDATORY** | Framework must reference and align with architecture principles |
+| Requirements Specification (REQ) | **MANDATORY** | Framework must address all business, functional, and non-functional requirements |
+| Stakeholder Analysis (STKE) | Recommended | Stakeholder context, roles, influence, and communication needs |
+| Architecture Strategy (STRAT) | Recommended | Strategic direction, capability gaps, target state vision |
+| Data Model (DATA) | Recommended | Data architecture, entity relationships, data governance needs |
+| Research Report (RSCH) | Recommended | Technology research findings, vendor evaluations, build vs buy analysis |
+| All other ARC-* artifacts | Optional | Any additional artifact (ADR, RISK, SOBC, DIAG, WARD, etc.) can be included and categorised into framework phases |
+
+> **Note**: At minimum, architecture principles and requirements must exist before running. The more artifacts available, the richer and more comprehensive the framework will be.
+
+---
+
+## Command
+
+```bash
+/arckit:framework Create framework for <project-name>
+```
+
+Outputs:
+
+- `projects/<id>/framework/` -- directory with phase subdirectories
+- `projects/<id>/ARC-<id>-FWRK-v1.0.md` -- Framework Overview
+- `projects/<id>/framework/<Project-Name>-Executive-Guide.md` -- Executive Guide
+
+---
+
+## What It Produces
+
+The framework command generates a structured output comprising:
+
+| Output | Description |
+|--------|-------------|
+| **Framework directory** (`framework/`) | Top-level directory containing phase subdirectories that organise recommendations by implementation stage |
+| **Phase subdirectories** | Numbered directories (e.g., `phase-1-foundation/`, `phase-2-core/`) grouping related recommendations |
+| **Framework Overview** (`ARC-{PID}-FWRK-v1.0.md`) | Comprehensive document mapping all artifacts, requirements, and recommendations into the phased structure with traceability |
+| **Executive Guide** (`{Project-Name}-Executive-Guide.md`) | Concise, non-technical summary designed for senior stakeholders and decision-makers |
+
+---
+
+## Framework Structure
+
+The framework organises recommendations into five default phases, though these adapt based on the project's domain and content:
+
+| Phase | Name | Purpose |
+|-------|------|---------|
+| 1 | **Foundation** | Governance, principles, standards, and baseline capabilities that must be established first |
+| 2 | **Core** | Essential platform components, data architecture, and integration patterns |
+| 3 | **Enhancement** | Extended capabilities, advanced features, and optimisation of core components |
+| 4 | **Integration** | Cross-system integration, external interfaces, and ecosystem connectivity |
+| 5 | **Optimisation** | Continuous improvement, maturity advancement, and operational excellence |
+
+Phases adapt to the project domain. For example, a data governance project might use phases like "Data Discovery", "Data Quality", "Data Cataloguing", "Data Stewardship", and "Data Monetisation". The command analyses the content of available artifacts to determine the most appropriate phase structure.
+
+---
+
+## Workflow Position
+
+The framework command sits LATE in the ArcKit workflow -- it requires many artifacts to already exist so it can synthesise them into a coherent structure:
+
+```text
+┌──────────┐  ┌──────────┐  ┌──────────┐  ┌──────────┐
+│   PRIN   │  │   REQ    │  │   STKE   │  │   STRAT  │
+└────┬─────┘  └────┬─────┘  └────┬─────┘  └────┬─────┘
+     │             │             │              │
+     │   ┌─────────┤   ┌────────┤   ┌──────────┘
+     │   │  ┌──────┘   │  ┌─────┘   │
+     │   │  │    ┌─────┘  │   ┌─────┘
+     ▼   ▼  ▼    ▼        ▼   ▼
+┌──────────────────────────────────────┐
+│         /arckit:framework            │
+└──────────────────┬───────────────────┘
+                   │
+          ┌────────┼────────┐
+          ▼                 ▼
+  ┌──────────────┐  ┌────────────────┐
+  │   Glossary   │  │ Maturity Model │
+  └──────────────┘  └────────────────┘
+```
+
+**Best Practice**: Run the framework command when you have at least 5 artifacts in place. The framework synthesises and organises -- it needs substantial source material to produce a meaningful structure.
+
+---
+
+## Key Differentiators
+
+| Aspect | `/arckit:framework` | `/arckit:strategy` | `/arckit:presentation` |
+|--------|---------------------|--------------------|-----------------------|
+| **Purpose** | Organises artifacts into a phased implementation structure | Creates an executive strategic narrative and roadmap | Generates a slide deck for a specific audience |
+| **Audience** | All stakeholders (technical, business, executive) | CTO, Strategy Board, senior leadership | Specific target audience (varies) |
+| **Output** | Framework directory, overview document, executive guide | Strategy document with vision, goals, roadmap | Presentation slides with speaker notes |
+| **Focus** | Implementation sequencing and completeness | Strategic direction and investment case | Communication and persuasion |
+| **When to use** | After many artifacts exist, to organise them | Early/mid-project, to set direction | Before a specific meeting or briefing |
+
+---
+
+## Example Usage
+
+### Minimal (5 artifacts)
+
+```bash
+# Create the mandatory artifacts
+/arckit:principles Create principles for Training Marketplace
+/arckit:requirements Create requirements for Training Marketplace
+
+# Add recommended context
+/arckit:stakeholders Analyze stakeholders for Training Marketplace
+/arckit:strategy Create strategy for Training Marketplace
+/arckit:data-model Create data model for Training Marketplace
+
+# Generate framework from available artifacts
+/arckit:framework Create framework for Training Marketplace
+```
+
+### Comprehensive (15+ artifacts)
+
+```bash
+# Build a rich set of artifacts first
+/arckit:principles Create principles for NHS Appointment Booking
+/arckit:requirements Create requirements for NHS Appointment Booking
+/arckit:stakeholders Analyze stakeholders for NHS Appointment Booking
+/arckit:strategy Create strategy for NHS Appointment Booking
+/arckit:data-model Create data model for NHS Appointment Booking
+/arckit:research Research technology options for NHS Appointment Booking
+/arckit:sobc Create business case for NHS Appointment Booking
+/arckit:risk Create risk register for NHS Appointment Booking
+/arckit:adr Record decision on API gateway for NHS Appointment Booking
+/arckit:adr Record decision on authentication approach for NHS Appointment Booking
+/arckit:diagram Create integration architecture diagram for NHS Appointment Booking
+/arckit:wardley Create wardley map for NHS Appointment Booking
+/arckit:codes-of-practice Assess codes of practice for NHS Appointment Booking
+/arckit:conformance Create conformance assessment for NHS Appointment Booking
+/arckit:devops Create DevOps strategy for NHS Appointment Booking
+
+# Generate comprehensive framework
+/arckit:framework Create framework for NHS Appointment Booking
+```
+
+---
+
+## Tips
+
+- **Run when you have 5+ artifacts**: The framework command synthesises existing work. With fewer than 5 artifacts, the framework will be thin and the phasing less meaningful. Wait until you have substantial material.
+
+- **Re-run to update as artifacts evolve**: As you create new artifacts or update existing ones, re-run the framework command to incorporate new content. A new version (v2.0) will be created, reflecting the latest project state.
+
+- **Adapt phases to your domain**: The default five phases (Foundation, Core, Enhancement, Integration, Optimisation) are starting points. The command analyses your artifacts and adapts phase names and boundaries to suit the project domain.
+
+- **Use the Executive Guide for stakeholder briefings**: The Executive Guide is specifically designed for senior stakeholders who need a concise overview without technical detail. Use it as a briefing document, board paper appendix, or steering committee handout.
+
+- **Pair with maturity model**: After creating the framework, use `/arckit:maturity-model` to define how to measure progress through framework phases and track adoption maturity.
+
+---
+
+## Follow-On Commands
+
+After creating the framework, typical next steps include:
+
+| Command | Purpose |
+|---------|---------|
+| `/arckit:glossary` | Generate glossary of framework terminology for consistent language |
+| `/arckit:maturity-model` | Create maturity model to measure progress through framework phases |
+
+---
+
+## Output Example
+
+```text
+## Framework Created
+
+**Framework Overview**: `projects/007-nhs-appointment/ARC-007-FWRK-v1.0.md`
+**Executive Guide**: `projects/007-nhs-appointment/framework/NHS-Appointment-Booking-Executive-Guide.md`
+**Document ID**: ARC-007-FWRK-v1.0
+
+### Framework Summary
+- **Phases Defined**: 5
+- **Source Artifacts Analysed**: 12
+- **Requirements Mapped**: 47
+- **Principles Referenced**: 8
+- **Recommendations Categorised**: 63
+
+### Phase Overview
+| Phase | Name | Recommendations | Key Artifacts |
+|-------|------|-----------------|---------------|
+| 1 | Foundation & Governance | 14 | PRIN, STKE, CoP |
+| 2 | Core Platform | 18 | REQ, DATA, ADR-001 |
+| 3 | Integration & APIs | 12 | REQ (INT), ADR-002, DIAG |
+| 4 | Security & Compliance | 10 | RISK, CONF, NFR-SEC |
+| 5 | Optimisation & Scale | 9 | WARD, DevOps, NFR-P |
+
+### Executive Guide Highlights
+- Strategic context and project rationale
+- Phased implementation roadmap (visual timeline)
+- Investment summary by phase
+- Key risks and mitigations
+- Success metrics and governance approach
+
+### Coverage
+- All 47 requirements mapped to framework phases
+- All 8 architecture principles referenced
+- 3 artifacts with no direct framework mapping (flagged for review)
+
+**Framework directory**: `projects/007-nhs-appointment/framework/`
+```

arckit_cli-6.1.1.data/data/share/arckit/docs/guides/gap-analysis.md

@@ -0,0 +1,70 @@
+# TOGAF Gap Analysis Playbook
+
+> **Guide Origin**: Community | **ArcKit Version**: [VERSION]
+
+`/arckit:gap-analysis` compares current and target architecture states, scores gaps, maps them to workstreams, and prepares the evidence base for TOGAF ADM Phase E and migration planning.
+
+---
+
+## Inputs
+
+| Artefact | Purpose |
+|----------|---------|
+| Business capability map (`ARC-<id>-BPCM-v1.0.md`) | Mandatory baseline for capability gaps |
+| Architecture principles (`ARC-000-PRIN-v1.0.md`) | Compliance and principle-alignment checks |
+| Architecture strategy (`ARC-<id>-STRAT-v1.0.md`) | Target state and investment priorities |
+| Application inventory (`ARC-<id>-APP-v1.0.md`) | Current application coverage |
+| Application rationalisation (`ARC-<id>-APPR-v1.0.md`) | Target portfolio decisions |
+| Existing assessments or migration plans | Evidence for baseline and target states |
+
+---
+
+## Command
+
+```bash
+/arckit:gap-analysis <project ID or gap-analysis scope>
+```
+
+Output: `projects/<id>/ARC-<id>-GAPA-v1.0.md`
+
+---
+
+## Deliverable Snapshot
+
+| Section | Contents |
+|---------|----------|
+| Capability Gap Matrix | Current state, target state, gap, severity |
+| Gap Heatmap | Priority view by impact and urgency |
+| Workstream Mapping | Gaps grouped into delivery workstreams |
+| Gap-to-Risk Mapping | Relationship between gaps and project or enterprise risks |
+| Assumptions and Constraints | Evidence gaps and known limits |
+| Traceability | Capability, principle, strategy, application, and risk links |
+
+---
+
+## Severity Guidance
+
+| Severity | Meaning |
+|----------|---------|
+| Critical | Blocks target outcomes or creates unacceptable risk |
+| High | Materially weakens a priority capability or compliance position |
+| Medium | Requires planned remediation but does not block delivery |
+| Low | Improvement opportunity or documentation gap |
+
+---
+
+## Review Checklist
+
+- Gaps are stated as differences between current and target states.
+- Severity ratings include rationale and evidence.
+- Every high or critical gap has an owner or proposed workstream.
+- Gap-to-risk mapping includes existing risk identifiers where available.
+- Assumptions are visible rather than hidden in the analysis.
+
+---
+
+## Related Commands
+
+- `/arckit:transition-architecture` - Turn gaps into migration waves.
+- `/arckit:architecture-board` - Present prioritised gaps for governance.
+- `/arckit:architecture-change` - Reassess gaps after approved changes.

arckit_cli-6.1.1.data/data/share/arckit/docs/guides/gcloud-clarify.md

@@ -0,0 +1,108 @@
+# G-Cloud Clarification Questions Playbook
+
+> **Guide Origin**: Official | **ArcKit Version**: [VERSION]
+
+`/arckit:gcloud-clarify` analyzes G-Cloud service gaps and generates supplier clarification questions for procurement.
+
+---
+
+## Inputs
+
+| Artefact | Purpose |
+|----------|---------|
+| Requirements (`ARC-<id>-REQ-v1.0.md`) | What the service must deliver |
+| G-Cloud search results | Services being evaluated |
+| Architecture principles | Governance standards to verify |
+| Security requirements | NCSC, Cyber Essentials requirements |
+
+---
+
+## Command
+
+```bash
+/arckit:gcloud-clarify Generate clarification questions for <service>
+```
+
+Output: `projects/<id>/ARC-<id>-GCLC-v1.0.md`
+
+---
+
+## Clarification Document Structure
+
+| Section | Contents |
+|---------|----------|
+| Service Summary | G-Cloud service being evaluated |
+| Requirements Mapping | How service maps to requirements |
+| Gap Analysis | Requirements not clearly addressed |
+| Clarification Questions | Specific questions for supplier |
+| Evaluation Impact | How answers affect scoring |
+
+---
+
+## Question Categories
+
+| Category | Purpose | Examples |
+|----------|---------|----------|
+| Functional | Feature capabilities | "Does the service support X?" |
+| Technical | Architecture and integration | "What APIs are available?" |
+| Security | Security controls and compliance | "What certifications held?" |
+| Commercial | Pricing and terms | "What's included in the price?" |
+| Support | Service levels and support | "What SLAs are offered?" |
+| Data | Data handling and location | "Where is data stored?" |
+
+---
+
+## Gap Types
+
+| Gap Type | Description | Question Focus |
+|----------|-------------|----------------|
+| Missing | Requirement not mentioned | Does service support it? |
+| Unclear | Vague description | Can supplier clarify? |
+| Partial | Some but not all features | What's included/excluded? |
+| Conflicting | Service description contradicts | Which is correct? |
+
+---
+
+## One-Page Workflow
+
+| Phase | Key Activities | ArcKit Commands |
+|-------|----------------|-----------------|
+| Requirements | Define what's needed | `/arckit:requirements` |
+| Search | Find candidate services | `/arckit:gcloud-search` |
+| Analysis | Generate clarification questions | `/arckit:gcloud-clarify` |
+| Clarification | Send questions to suppliers | Manual via Digital Marketplace |
+| Evaluation | Score services with answers | `/arckit:evaluate` |
+
+---
+
+## Review Checklist
+
+- Questions reference specific requirements (e.g., NFR-SEC-001).
+- Questions are specific and answerable (not vague).
+- Security questions cover required certifications.
+- Data residency questions asked if relevant.
+- Pricing questions clarify what's included.
+- SLA questions align with NFR requirements.
+- Integration questions cover required APIs.
+
+---
+
+## Digital Marketplace Process
+
+| Step | Description |
+|------|-------------|
+| 1 | Identify services via G-Cloud search |
+| 2 | Generate clarification questions |
+| 3 | Submit via Digital Marketplace messaging |
+| 4 | Supplier responds (usually 5 working days) |
+| 5 | Evaluate responses against requirements |
+
+---
+
+## Key Principles
+
+1. **Requirement Traceability**: Every question links to a requirement.
+2. **Specificity**: Avoid vague questions that get vague answers.
+3. **Fairness**: Ask same questions to all shortlisted suppliers.
+4. **Completeness**: Cover all unclear areas before evaluation.
+5. **Documentation**: Record questions and answers for audit trail.