arckit-cli 6.1.1__py3-none-any.whl

arckit_cli-6.1.1.data/data/share/arckit/docs/guides/custom-commands.md

@@ -0,0 +1,236 @@
+# Custom Commands Authoring Guide
+
+> **Guide Origin**: Official | **ArcKit Version**: [VERSION]
+
+This guide explains how to add a new `/arckit.<n>` command. A command is a single Markdown file that ArcKit fans out to six AI-assistant formats automatically. Read this before opening a PR that adds a command.
+
+For template customisation (changing the output of an existing command), see [`customize.md`](customize.md). For background on why ArcKit uses commands rather than skills, see the README section "Why Commands, Not Skills".
+
+---
+
+## How Commands Work
+
+You write **one** source file in `plugins/arckit-claude/commands/<n>.md`. The converter at `scripts/converter.py` reads it and produces six target-specific outputs:
+
+| Target | Output path | Format |
+|-------|-------------|--------|
+| Claude Code (source — edit this) | `plugins/arckit-claude/commands/<n>.md` | Markdown with YAML frontmatter |
+| Codex CLI (command) | `extensions/arckit-codex/prompts/arckit.<n>.md` | Markdown |
+| Codex CLI (skill) | `extensions/arckit-codex/skills/arckit-<n>/SKILL.md` | Skill format |
+| OpenCode CLI | `extensions/arckit-opencode/commands/arckit.<n>.md` | Markdown |
+| Gemini CLI | `extensions/arckit-gemini/commands/arckit/<n>.toml` | TOML |
+| GitHub Copilot | `extensions/arckit-copilot/prompts/arckit-<n>.prompt.md` | Prompt frontmatter |
+| Paperclip | `extensions/arckit-paperclip/src/data/commands.json` (entry) | JSON |
+
+The first row is the file you edit by hand; the converter generates all others. You do not edit the generated files directly. The converter handles argument-placeholder rewriting, path rewriting for the Gemini sandbox, frontmatter stripping for Claude-only fields, and extension-file copying.
+
+---
+
+## The Source File
+
+Create `plugins/arckit-claude/commands/<n>.md` with YAML frontmatter and a prompt body.
+
+````markdown
+---
+description: One-line description in imperative mood
+argument-hint: "<hint shown in autocomplete>"
+effort: medium
+handoffs:
+  - command: next-command
+    description: Why a user might run this next
+---
+
+You are helping an enterprise architect do X.
+
+## User Input
+
+```text
+$ARGUMENTS
+```
+
+## Instructions
+
+1. Read the template (with user override support): ...
+2. Read related artifacts from the project context: ...
+3. Generate the output: ...
+4. Write to `projects/<project-id>/ARC-<id>-<CODE>-v<version>.md`
+````
+
+### Frontmatter Reference
+
+| Field | Required | Notes |
+|-------|----------|-------|
+| `description` | Yes | Imperative, one line. Used as the slash-command description in every target. |
+| `argument-hint` | Recommended | Shown in Claude Code autocomplete. Short hint showing the expected shape of input. |
+| `effort` | No | `low` / `medium` / `high`. Claude Code only — stripped from other targets by the converter. |
+| `handoffs` | No | List of `{command, description}` entries suggesting follow-on commands. Rendered into a handoffs section in generated outputs. |
+| `paths` | No | Claude-only. Stripped from other targets. |
+| `keep-coding-instructions` | No | Claude-only. Stripped from other targets. |
+
+### The `$ARGUMENTS` Contract
+
+Always include a `## User Input` section with a fenced `text` block containing `$ARGUMENTS`. The converter rewrites the placeholder per target:
+
+| Target | Placeholder used |
+|-------|------------------|
+| Claude Code | `$ARGUMENTS` (unchanged) |
+| Codex, OpenCode | `$ARGUMENTS` (unchanged) |
+| Gemini | `{{args}}` |
+| Copilot | `${input:topic:Enter project name or topic}` |
+| Paperclip | `{topic}` |
+
+Do not hand-write target-specific placeholders — use `$ARGUMENTS` and let the converter do the work.
+
+> **Need a literal `$` before a digit?** Claude Code treats `$1`, `$2`, … as positional argument placeholders in command/skill bodies. To write a literal dollar-then-digit (e.g. a price like `$5`, or a regex like `$1`), escape it as `\$` (Claude Code v2.1.163+) — `\$5`, `\$1`. ArcKit commands rarely need this since they use `$ARGUMENTS`, but it matters if you write a worked example containing currency or shell positional vars.
+
+> The Copilot placeholder currently hard-codes the `topic:` label regardless of what the command expects as input. If you need a command-specific label, it requires changes to `scripts/converter.py` — the converter is the right place to thread that customisation through.
+
+### Reading Templates with User Overrides
+
+Commands should prefer a user-customised template over the bundled default. Use this pattern in the prompt body:
+
+```markdown
+1. **Read the template** (with user override support):
+   - **First**, check if `.arckit/templates/<your-template>.md` exists in the project root
+   - **If found**: Read the user's customised template (user override takes precedence)
+   - **If not found**: Read `${CLAUDE_PLUGIN_ROOT}/templates/<your-template>.md` (default)
+```
+
+The converter rewrites `${CLAUDE_PLUGIN_ROOT}` paths to the correct location for each target (for example, shell commands against `~/.gemini/extensions/arckit/` for Gemini because that directory sits outside Gemini's workspace sandbox).
+
+Put the template file alongside the command: `plugins/arckit-claude/templates/<your-template>-template.md`. The filename convention is `<command-name>-template.md`.
+
+How the template reaches each target:
+
+- **Paperclip** embeds the template content directly into its generated `commands.json` via `read_template_for_command()` in the converter.
+- **All other targets** receive the whole `templates/` tree copied verbatim into each extension directory by `copy_extension_files()`, and the command reads the file at runtime via the target's path prefix (`${CLAUDE_PLUGIN_ROOT}`, `~/.gemini/extensions/arckit/`, etc.).
+
+---
+
+## Worked Example: `/arckit:sla`
+
+Say you want a command that generates a Service Level Agreement skeleton from existing non-functional requirements.
+
+**1. Create `plugins/arckit-claude/commands/sla.md`:**
+
+````markdown
+---
+description: Generate an SLA skeleton from non-functional requirements
+argument-hint: "<project ID, e.g. '001'>"
+effort: medium
+handoffs:
+  - command: servicenow
+    description: Feed SLAs into ServiceNow service design
+  - command: dld-review
+    description: Validate SLA coverage in detailed design review
+---
+
+You are helping an enterprise architect draft a Service Level Agreement (SLA) that inherits its targets from previously documented non-functional requirements.
+
+## User Input
+
+```text
+$ARGUMENTS
+```
+
+## Instructions
+
+1. **Read the template** (with user override support):
+   - **First**, check if `.arckit/templates/sla-template.md` exists in the project root
+   - **If found**: Read the user's customised template
+   - **If not found**: Read `${CLAUDE_PLUGIN_ROOT}/templates/sla-template.md` (default)
+
+2. **Read the project requirements**:
+   - Locate `projects/<project-id>/ARC-<id>-REQ-v*.md`
+   - Extract all NFR-* entries (availability, latency, throughput, RTO/RPO)
+   - If no requirements file exists, ask the user to run `/arckit:requirements` first
+
+3. **Generate the SLA** using the extracted NFRs:
+   - One row per NFR, mapped to an SLA target
+   - Include measurement method, reporting cadence, and breach consequences
+   - Maintain traceability: every SLA row cites its source NFR ID
+
+4. **Detect version** and write to `projects/<project-id>/ARC-<id>-SLA-v<version>.md`.
+````
+
+**2. Create `plugins/arckit-claude/templates/sla-template.md`** with the document skeleton (document-control header, SLA table, review cadence, and signature block).
+
+**3. Run the converter:**
+
+```bash
+python scripts/converter.py
+```
+
+This writes out the six target files with correct placeholders and paths.
+
+**4. Add the user-facing guide** at `plugins/arckit-claude/docs/guides/sla.md` following the house style (see `plugins/arckit-claude/docs/guides/principles.md` or `plugins/arckit-claude/docs/guides/adr.md` for examples). This is the source location; the `sync-guides` hook and converter mirror it to `docs/guides/` and into every extension's `docs/guides/` tree.
+
+**5. Update `CHANGELOG.md`** under `## [Unreleased]`.
+
+---
+
+## Commands, Skills, Agents, and Hooks — When to Use Which
+
+| You want to... | Use | Location |
+|-------|-----|----------|
+| Generate a specific artifact on explicit invocation | **Command** | `plugins/arckit-claude/commands/` |
+| Share procedural knowledge across multiple commands | **Skill** | `plugins/arckit-claude/skills/<skill-name>/` |
+| Run heavy research in an isolated context window | **Agent** | `plugins/arckit-claude/agents/arckit-<n>.md` |
+| React to lifecycle events (session start, file write, prompt submit) | **Hook** | `plugins/arckit-claude/hooks/` |
+| Override a command's behaviour on non-Claude targets only | **Standalone command** | `plugins/arckit-claude/commands-standalone/` |
+
+A command and an agent with matching names are linked automatically: the converter uses the agent's prompt as the command body for non-Claude targets (which lack Claude Code's agent architecture). See `plugins/arckit-claude/agents/arckit-research.md` paired with `plugins/arckit-claude/commands/research.md` for the canonical example.
+
+---
+
+## Conventions
+
+Taken from [`CONTRIBUTING.md`](../../CONTRIBUTING.md). Repeated here because they matter most for commands:
+
+- **Naming**: lowercase with hyphens (`data-model`, not `dataModel`). Verbs for actions (`analyse`, `review`). Nouns for artifacts (`requirements`, `runbook`). Group related commands with shared prefixes (`hld-review`, `dld-review`).
+- **UK English** throughout (`organisation`, `analyse`, `colour`).
+- **MUST / SHOULD / MAY** for normative language — aligns with the wider ArcKit tone and with GDS content design.
+- **Technology-agnostic** — describe qualities and patterns, not specific vendors or products.
+- **Traceability** — every generated artifact should cite its inputs (requirement IDs, risk IDs, principle IDs).
+- **Commit message**: `feat(commands): add /arckit.<n> command`.
+
+---
+
+## Testing a New Command
+
+Before opening the PR, verify the command works across at least Claude Code and one other target:
+
+```bash
+# 1. Regenerate all target files
+python scripts/converter.py
+
+# 2. Test in Claude Code (requires the plugin installed from marketplace)
+/arckit.<n> Test scenario description
+
+# 3. Test in Gemini CLI
+gemini extensions install .
+/arckit:<n> Test scenario description
+
+# 4. Inspect the generated output
+cat projects/001-<test-project>/ARC-001-<CODE>-v1.0.md
+```
+
+Check:
+
+- [ ] The command reads the template (customised or default) correctly
+- [ ] The output contains every section the template specifies
+- [ ] Every reference to a source artifact uses a real ID that exists in the project
+- [ ] Re-running the command with an existing output file correctly bumps the version
+- [ ] `python scripts/converter.py` regenerates cleanly with no diff noise
+- [ ] Generated TOML and prompt files look sensible on a quick read
+
+---
+
+## Submitting the PR
+
+1. Branch: pick a short descriptive name — recent history uses both `feat/` and `docs/` prefixes, either is fine.
+2. Commit the source command, the template, the guide, the converter-regenerated files, and the CHANGELOG entry together.
+3. PR title follows conventional commits: `feat(commands): add /arckit.<n> command`.
+4. PR description should include: the use case, a link to any related issue, and at least one screenshot or pasted output showing the command running in Claude Code.
+
+See [`CONTRIBUTING.md`](../../CONTRIBUTING.md) for the broader contribution process.

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

@@ -0,0 +1,108 @@
+# Template Customization Guide
+
+> **Guide Origin**: Official | **ArcKit Version**: [VERSION]
+
+`/arckit:customize` copies templates to `.arckit/templates-custom/` for customization, preserving changes across updates.
+
+---
+
+## Command
+
+```bash
+# Copy a specific template
+/arckit:customize requirements
+
+# Copy all templates
+/arckit:customize all
+
+# List available templates
+/arckit:customize list
+
+# Show template info
+/arckit:customize info requirements
+```
+
+---
+
+## How It Works
+
+| Location | Purpose |
+|----------|---------|
+| `.arckit/templates/` | Default templates (refreshed by `arckit init`) |
+| `.arckit/templates-custom/` | Your customizations (preserved across updates) |
+
+Commands automatically check for custom templates first, falling back to defaults.
+
+---
+
+## Common Customizations
+
+| Customization | Example |
+|---------------|---------|
+| Document Control | Add organization-specific fields |
+| Compliance Sections | Include ISO 27001, PCI-DSS, SOC 2 requirements |
+| Approval Workflows | Add department-specific sign-off sections |
+| Classification Banners | Customize UK Government classification headers |
+| Branding | Add organization logo, footer, contact information |
+
+---
+
+## Workflow
+
+1. **Copy template**: `/arckit:customize requirements`
+2. **Edit**: Modify `.arckit/templates-custom/requirements-template.md`
+3. **Use**: Run `/arckit:requirements` — automatically uses your custom template
+4. **Update ArcKit**: Run `arckit init` — your customizations preserved
+
+---
+
+## Template Structure
+
+Templates use placeholders that commands replace:
+
+| Placeholder | Replaced With |
+|-------------|---------------|
+| `[PROJECT_ID]` | Project number (e.g., "001") |
+| `[PROJECT_NAME]` | Project name |
+| `[VERSION]` | Document version |
+| `[DATE]` | Current date |
+| `[STATUS]` | Document status (DRAFT, etc.) |
+
+---
+
+## Best Practices
+
+1. **Start minimal**: Copy only templates you need to customize
+2. **Document changes**: Add comments explaining customizations
+3. **Test first**: Verify custom template works before production use
+4. **Version control**: Commit `.arckit/templates-custom/` to git
+5. **Review updates**: Check ArcKit release notes for template changes
+
+---
+
+## Reverting to Defaults
+
+To revert a template to default:
+
+```bash
+# Delete the custom template
+rm .arckit/templates-custom/requirements-template.md
+
+# Command will now use default from .arckit/templates/
+```
+
+---
+
+## Available Templates
+
+| Template | Command |
+|----------|---------|
+| `requirements-template.md` | `/arckit:requirements` |
+| `stakeholder-drivers-template.md` | `/arckit:stakeholders` |
+| `risk-register-template.md` | `/arckit:risk` |
+| `sobc-template.md` | `/arckit:sobc` |
+| `architecture-principles-template.md` | `/arckit:principles` |
+| `data-model-template.md` | `/arckit:data-model` |
+| `sow-template.md` | `/arckit:sow` |
+| `pages-template.html` | `/arckit:pages` |
+| ... | (run `/arckit:customize list` for full list) |

arckit_cli-6.1.1.data/data/share/arckit/docs/guides/data-mesh-contract.md

@@ -0,0 +1,239 @@
+# Data Mesh Contract Quick Guide
+
+> **Guide Origin**: Official | **ArcKit Version**: [VERSION]
+
+`/arckit:data-mesh-contract` creates federated data product contracts for mesh architectures with SLAs, governance, and interoperability guarantees.
+
+---
+
+## Inputs Checklist
+
+| Artefact | Purpose |
+|----------|---------|
+| `ARC-<id>-DATA-v1.0.md` with entity definitions | Provides schema source of truth |
+| `ARC-<id>-REQ-v1.0.md` with DR-xxx entries | Defines data quality requirements and SLAs |
+| `ARC-<id>-STKE-v1.0.md` | Identifies domain owners and data consumers |
+| Architecture principles | Ensures mesh alignment with governance standards |
+
+---
+
+## Command
+
+```bash
+/arckit:data-mesh-contract Create contract for <domain name> data product
+```
+
+Output: `projects/<id>/ARC-<id>-DMC-001-v1.0.md` (uses multi-instance numbering)
+
+---
+
+## What is a Data Mesh Contract?
+
+A **data product contract** defines the formal agreement between a data product provider (domain team) and consumers in a federated mesh architecture.
+
+Unlike traditional data models, mesh contracts emphasize:
+
+- **Federated ownership** – Domain teams own their data products end-to-end
+- **Data as a product** – Treated like APIs with SLAs, versioning, and support
+- **Self-serve infrastructure** – Standardized access patterns and discovery
+- **Computational governance** – Automated policy enforcement
+
+---
+
+## Deliverable Snapshot
+
+| Section | Highlights | Next Action |
+|---------|------------|-------------|
+| Product metadata | Domain, owner, mesh plane alignment | Assign product owner and steward |
+| Schema & versioning | Contracted fields, breaking change policy | Sync with `ARC-<id>-DATA-v1.0.md` for consistency |
+| SLAs | Freshness, availability, quality KPIs | Define monitoring thresholds in observability platform |
+| Access methods | APIs, query endpoints, data feeds | Document authentication and rate limits |
+| Data quality | Validation rules, testing requirements | Implement automated quality checks |
+| Governance & policy | GDPR compliance, access controls, audit hooks | Review with DPO; integrate with governance platform |
+| Consumer obligations | Usage constraints, attribution, support SLA | Publish in data catalogue for discovery |
+| Change management | Versioning, deprecation, approval workflow | Establish governance board review cadence |
+
+---
+
+## UK Government Context
+
+### Technology Code of Practice Alignment
+
+| TCoP Point | Mesh Contract Application |
+|------------|---------------------------|
+| **8. Share, reuse and collaborate** | Federated data products replace siloed databases |
+| **6. Make things secure** | Access policies and encryption enforced at contract level |
+| **7. Make privacy integral** | PII classification, consent management, and data subject rights |
+| **11. Define your purchasing strategy** | Reuse existing mesh products before building new ones |
+
+### Data Quality Framework
+
+Mesh contracts support the **Government Data Quality Framework** five dimensions:
+
+1. **Accuracy** – Validation rules and quality KPIs in contract
+2. **Validity** – Schema constraints and allowed values
+3. **Completeness** – Mandatory field requirements and null handling
+4. **Consistency** – Cross-system reconciliation rules
+5. **Timeliness** – Freshness SLAs and update frequency
+
+### National Data Strategy (NDS)
+
+Contracts align with NDS pillars:
+
+- **Pillar 1 (Unlocking value)** – Discoverability and self-serve access
+- **Pillar 2 (Secure and resilient infrastructure)** – Security controls in contract
+- **Pillar 3 (Transforming capability)** – Federated domain expertise
+- **Pillar 4 (Ensuring responsible use)** – Governance and ethics policies
+
+---
+
+## Mesh Architecture Principles
+
+### Domain-Driven Design
+
+- Each contract represents **one domain's data product**
+- Domain teams own product lifecycle (schema, SLA, support)
+- Cross-domain data sharing via published contracts
+
+### Data Product Characteristics
+
+- **Discoverable** – Registered in data catalogue with metadata
+- **Addressable** – Unique endpoint or data lake path
+- **Understandable** – Schema, semantics, and lineage documented
+- **Trustworthy** – SLAs, quality metrics, and governance
+- **Secure** – Access policies and encryption standards
+- **Interoperable** – Standard formats and protocols
+
+### Federated Computational Governance
+
+- **Automated policy enforcement** – Not manual review
+- **Global standards** – Applied locally by domain teams
+- **Observable compliance** – Auditable governance hooks
+
+---
+
+## Integration with ArcKit Workflow
+
+### Prerequisites (Run These First)
+
+1. `/arckit:principles` – Establish architecture principles including mesh standards
+2. `/arckit:stakeholders` – Identify domain owners and consumers
+3. `/arckit:data-model` – Define entities that become data products
+4. `/arckit:requirements` – Capture DR-xxx data requirements including quality/SLAs
+
+### Mesh Contract Generation
+
+5. `/arckit:data-mesh-contract` – Create contract per domain data product
+
+### Follow-Up Commands
+
+6. `/arckit:traceability` – Link contracts to requirements and consumers
+7. `/arckit:analyze` – Score contract completeness and governance quality
+8. `/arckit:dpia` – If contract involves PII (auto-references contract)
+
+---
+
+## Compliance Focus
+
+### GDPR / UK GDPR
+
+- **PII inventory** – List all personal data fields in contract
+- **Legal basis** – Document lawful basis for processing
+- **Data subject rights** – Mechanism for access, rectification, erasure
+- **Cross-border transfers** – If data leaves UK, document adequacy decisions
+- **Retention** – Contract specifies deletion policy
+
+### Security Standards
+
+- **Encryption** – At-rest and in-transit standards
+- **Access control** – Role-based or attribute-based policies
+- **Audit logging** – Who accessed what data when
+- **Threat model** – Known risks and mitigations
+
+---
+
+## Contract Lifecycle
+
+### 1. Design Phase
+
+- Domain team drafts contract using template
+- References source `ARC-<id>-DATA-v1.0.md` for schema
+- Defines SLAs based on consumer requirements
+- Documents governance policies
+
+### 2. Review Phase
+
+- Architecture review against mesh principles
+- DPO review for privacy compliance
+- Security review for access controls
+- Governance board approval (if required)
+
+### 3. Publishing Phase
+
+- Register contract in data catalogue
+- Provision infrastructure (APIs, storage, monitoring)
+- Document consumer onboarding process
+
+### 4. Operations Phase
+
+- Monitor SLA adherence (freshness, availability, quality)
+- Track usage metrics and consumer feedback
+- Respond to support requests per contract SLA
+
+### 5. Change Management
+
+- Propose schema changes with impact analysis
+- Versioning strategy (semantic versioning recommended)
+- Deprecation notice period (e.g., 90 days)
+- Consumer migration support
+
+---
+
+## Review Tips
+
+- **One contract per domain data product** – Don't bundle unrelated datasets
+- **Start with high-value products** – Focus on data with multiple consumers
+- **Automate quality checks** – Contract is meaningless without observability
+- **Version early** – Use semantic versioning from day one (v1.0.0)
+- **Consumer feedback loop** – Review SLAs quarterly based on actual usage
+- **Federated ownership** – Domain team owns contract, not central data team
+
+---
+
+## Common Pitfalls
+
+❌ **Treating contracts as documentation** – They must be enforceable via automation
+✅ **Integrate with governance platform** – Use contracts to drive policy engines
+
+❌ **Overly rigid schemas** – Allow for evolution with backward compatibility
+✅ **Semantic versioning** – Breaking changes increment major version
+
+❌ **Vague SLAs** – "High quality" is not measurable
+✅ **Specific KPIs** – "99.5% availability, <5min freshness, >95% completeness"
+
+❌ **Centralized approval** – Defeats federated mesh model
+✅ **Guardrails + autonomy** – Global policies, local implementation
+
+❌ **No consumer onboarding** – Great product, no users
+✅ **Self-serve discovery** – Catalogue, examples, sandbox environment
+
+---
+
+## Related Commands
+
+- `/arckit:data-model` – Define entities before creating contracts
+- `/arckit:requirements` – Capture DR-xxx requirements that drive SLAs
+- `/arckit:traceability` – Link contracts to requirements and consumers
+- `/arckit:analyze` – Score contract completeness
+- `/arckit:dpia` – Privacy impact assessment for PII-containing products
+
+---
+
+## References
+
+- **PayPal Data Contract Template**: https://github.com/paypal/data-contract-template
+- **Open Data Contract Standard (ODCS)**: https://github.com/bitol-io/open-data-contract-standard
+- **Data Mesh book (Zhamak Dehghani)**: O'Reilly 2022
+- **UK Government Data Quality Framework**: https://www.gov.uk/government/publications/the-government-data-quality-framework
+- **National Data Strategy**: https://www.gov.uk/government/publications/uk-national-data-strategy
+- **GovS 005: Data Standards**: https://www.gov.uk/government/publications/open-standards-for-government

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

@@ -0,0 +1,69 @@
+# Data Model Quick Guide
+
+> **Guide Origin**: Official | **ArcKit Version**: [VERSION]
+
+`/arckit:data-model` transforms Data Requirements (DR-xxx) into an ERD, governance catalogue, and GDPR compliance pack.
+
+---
+
+## Inputs Checklist
+
+| Artefact | Purpose |
+|----------|---------|
+| `ARC-<id>-REQ-v1.0.md` with DR-xxx entries | Defines entities and attributes |
+| Up-to-date stakeholders & risk register | Drives governance roles and retention risk |
+| Latest architecture diagrams | Populate CRUD matrix and integrations |
+
+---
+
+## Command
+
+```bash
+/arckit:data-model Create data model for <project name>
+```
+
+Output: `projects/<id>/ARC-<id>-DATA-v1.0.md`
+
+---
+
+## Deliverable Snapshot
+
+| Section | Highlights | Next Action |
+|---------|------------|-------------|
+| Mermaid ERD | Normalised entity diagram ready for mermaid.live | Share with architects for validation |
+| Entity catalogue | Attributes, data types, keys, derived fields | Flag unknown data types for modelling session |
+| GDPR pack | PII inventory, legal basis, retention, data subject rights | Review with DPO; schedule DPIA if high risk |
+| Governance matrix | Owner, steward, custodian, classification | Update RACI and onboarding materials |
+| CRUD & integrations | Component ↔ entity access + upstream/downstream feeds | Align with API contracts and ETL plans |
+| Data quality | KPIs, controls, monitoring cadence | Feed into ServiceNow service design |
+
+---
+
+## Compliance Focus
+
+- **Identify PII** – mark direct/indirect PII in the catalogue.
+- **Retention** – confirm duration against organisation policy.
+- **Security** – ensure encryption/segmentation controls align with risk appetite.
+- **Subject rights** – validate mechanism for access/erasure/export.
+
+Use the output to enrich `/arckit:dpia` (automatic when run afterwards).
+
+---
+
+## Review Tips
+
+- Run the command whenever requirements change materially.
+- Ask data stewards to sign off catalogue rows before build.
+- Store diagrams alongside other architecture artefacts for audit trails.
+
+---
+
+## Related Commands
+
+- `/arckit:dpia` - Generate Data Protection Impact Assessment (auto-references data model)
+- `/arckit:data-mesh-contract` - Create federated data product contracts from entities (mesh architecture)
+- `/arckit:traceability` - Link entities to requirements and test cases
+
+## UK Government Data Policy
+
+For UK Government data projects, the data model provides evidence for the [National Data Strategy](https://www.gov.uk/government/publications/uk-national-data-strategy/national-data-strategy) — particularly the **Data Foundations** pillar (metadata standards, data quality) and **Availability** pillar (data access controls, sharing agreements). The Data Quality Framework section aligns with the [Government Data Quality Framework](https://www.gov.uk/government/publications/the-government-data-quality-framework/the-government-data-quality-framework) (6 dimensions, 5 principles). See `docs/guides/national-data-strategy.md` and `docs/guides/data-quality-framework.md` for full mappings.