mirrors / tractorjuice--arckit-gemini

项目文件夹

tractorjuice--arckit-gemini
文件
main
T
wehub-resource-sync 4050a9af7b chore: import upstream snapshot with attribution
2026-07-13 12:35:03 +08:00

8.9 KiB
原始文件 永久链接 Blame 文件历史

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

/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

  1. /arckit:data-mesh-contract – Create contract per domain data product

Follow-Up Commands

  1. /arckit:traceability – Link contracts to requirements and consumers
  2. /arckit:analyze – Score contract completeness and governance quality
  3. /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

在新工单中引用 查看 Git Blame 复制永久链接