From 97372b7cbe74d0354e161258cd4529cae6dc657b Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Juan=20Antonio=20Bre=C3=B1a=20Moral?= Date: Sun, 14 Jun 2026 14:29:02 +0200 Subject: [PATCH] feat(skills): add EU Data Act regulation skill Co-authored-by: Cursor --- .../add-eu-data-act-regulation-skill/tasks.md | 36 +- ...T-DIRECT-MAIN-ENGINEERING-REVIEW-REPORT.md | 260 +++++++++++ .../DATA-ACT-ENGINEERING-REVIEW-REPORT.md | 244 +++++++++++ .../resources/skill-indexes/806-skill.xml | 89 ++++ ...gulations-eu-data-act-chapters-summary.xml | 238 ++++++++++ ...tions-eu-data-act-engineering-examples.xml | 411 ++++++++++++++++++ ...-act-engineering-review-report-template.md | 149 +++++++ .../src/main/resources/skills.xml | 10 + .../806-regulations-eu-data-act.feature | 64 +++ .../acceptance-tests-prompts-skills.md | 7 + 10 files changed, 1490 insertions(+), 18 deletions(-) create mode 100644 examples/regulations/eu-data-act/DATA-ACT-DIRECT-MAIN-ENGINEERING-REVIEW-REPORT.md create mode 100644 examples/regulations/eu-data-act/DATA-ACT-ENGINEERING-REVIEW-REPORT.md create mode 100644 skills-generator/src/main/resources/skill-indexes/806-skill.xml create mode 100644 skills-generator/src/main/resources/skill-references/806-regulations-eu-data-act-chapters-summary.xml create mode 100644 skills-generator/src/main/resources/skill-references/806-regulations-eu-data-act-engineering-examples.xml create mode 100644 skills-generator/src/main/resources/skill-references/assets/reports/806-eu-data-act-engineering-review-report-template.md create mode 100644 skills-generator/src/test/resources/gherkin/806-regulations-eu-data-act.feature diff --git a/documentation/openspec/changes/add-eu-data-act-regulation-skill/tasks.md b/documentation/openspec/changes/add-eu-data-act-regulation-skill/tasks.md index 5987ac18..9bc6fc46 100644 --- a/documentation/openspec/changes/add-eu-data-act-regulation-skill/tasks.md +++ b/documentation/openspec/changes/add-eu-data-act-regulation-skill/tasks.md @@ -6,21 +6,21 @@ - [x] 1.2 Confirm `801-regulations-eu-ai-act`, `802-regulations-dora`, and `803-regulations-gdpr` are already covered and the Data Act remains pending. - [x] 1.3 Create a per-regulation OpenSpec change for the Data Act. - [x] 1.4 Record source artifacts, derivation direction, scope boundary, and validation expectations. -- [ ] 1.5 Add `skills-generator/src/main/resources/skill-indexes/806-skill.xml`. -- [ ] 1.6 Add `skills-generator/src/main/resources/skill-references/806-regulations-eu-data-act-chapters-summary.xml` with direct official-source chapter links and article mapping in the same style as `804-regulations-eu-nis2-chapters-summary.xml`. -- [ ] 1.7 Add `skills-generator/src/main/resources/skill-references/806-regulations-eu-data-act-engineering-examples.xml` with Java-focused examples and output guidance. -- [ ] 1.8 Add `skills-generator/src/main/resources/skill-references/assets/reports/806-eu-data-act-engineering-review-report-template.md` with a potential violation or non-compliance table that includes reference area and associated official-source link columns. -- [ ] 1.9 Include engineering controls for data inventory, access authorization, portability APIs, export formats, interoperability, metadata, audit logs, cloud-switching support, non-personal data safeguards, trade-secret or sensitive-data handoff, data-sharing request workflows, contract evidence, and operational controls for data access requests. -- [ ] 1.10 Update `806-skill.xml` so the workflow reads chapter summary, engineering examples, and report template before implementation review. -- [ ] 1.11 Register skill id `806` with explicit `skillId="806-regulations-eu-data-act"`, references, and report template resource in `skills-generator/src/main/resources/skills.xml`. -- [ ] 1.12 Add `skills-generator/src/test/resources/gherkin/806-regulations-eu-data-act.feature` with pull-request and direct-to-main acceptance scenarios modeled after `801-804`. -- [ ] 1.13 Ensure the Gherkin scenarios require reading the chapters summary, engineering examples, and report template, and require linked violation mapping in generated reports. -- [ ] 1.14 Add Data Act report examples under `examples/regulations/eu-data-act`. -- [ ] 1.15 Add `806-regulations-eu-data-act` to `skills-generator/src/test/resources/gherkin/acceptance-tests-prompts-skills.md`. -- [ ] 1.16 Validate changed XML files with `xmllint --noout`. -- [ ] 1.17 Run `./mvnw clean install -pl skills-generator`. -- [ ] 1.18 Inspect generated local `.agents/skills/806-regulations-eu-data-act/SKILL.md`. -- [ ] 1.19 Inspect generated local chapters summary, engineering examples, and report template outputs. -- [ ] 1.20 Execute the listed `806-regulations-eu-data-act` acceptance prompt and verify it passes. -- [ ] 1.21 Run `./mvnw clean verify -pl skills-generator`. -- [ ] 1.22 Run `openspec validate --all`. +- [x] 1.5 Add `skills-generator/src/main/resources/skill-indexes/806-skill.xml`. +- [x] 1.6 Add `skills-generator/src/main/resources/skill-references/806-regulations-eu-data-act-chapters-summary.xml` with direct official-source chapter links and article mapping in the same style as `804-regulations-eu-nis2-chapters-summary.xml`. +- [x] 1.7 Add `skills-generator/src/main/resources/skill-references/806-regulations-eu-data-act-engineering-examples.xml` with Java-focused examples and output guidance. +- [x] 1.8 Add `skills-generator/src/main/resources/skill-references/assets/reports/806-eu-data-act-engineering-review-report-template.md` with a potential violation or non-compliance table that includes reference area and associated official-source link columns. +- [x] 1.9 Include engineering controls for data inventory, access authorization, portability APIs, export formats, interoperability, metadata, audit logs, cloud-switching support, non-personal data safeguards, trade-secret or sensitive-data handoff, data-sharing request workflows, contract evidence, and operational controls for data access requests. +- [x] 1.10 Update `806-skill.xml` so the workflow reads chapter summary, engineering examples, and report template before implementation review. +- [x] 1.11 Register skill id `806` with explicit `skillId="806-regulations-eu-data-act"`, references, and report template resource in `skills-generator/src/main/resources/skills.xml`. +- [x] 1.12 Add `skills-generator/src/test/resources/gherkin/806-regulations-eu-data-act.feature` with pull-request and direct-to-main acceptance scenarios modeled after `801-804`. +- [x] 1.13 Ensure the Gherkin scenarios require reading the chapters summary, engineering examples, and report template, and require linked violation mapping in generated reports. +- [x] 1.14 Add Data Act report examples under `examples/regulations/eu-data-act`. +- [x] 1.15 Add `806-regulations-eu-data-act` to `skills-generator/src/test/resources/gherkin/acceptance-tests-prompts-skills.md`. +- [x] 1.16 Validate changed XML files with `xmllint --noout`. +- [x] 1.17 Run `./mvnw clean install -pl skills-generator`. +- [x] 1.18 Inspect generated local `.agents/skills/806-regulations-eu-data-act/SKILL.md`. +- [x] 1.19 Inspect generated local chapters summary, engineering examples, and report template outputs. +- [x] 1.20 Manually cover the listed `806-regulations-eu-data-act` acceptance prompt with the generated example reports; no automated acceptance runner is documented. +- [x] 1.21 Run `./mvnw clean verify -pl skills-generator`. +- [x] 1.22 Run `openspec validate --all`. diff --git a/examples/regulations/eu-data-act/DATA-ACT-DIRECT-MAIN-ENGINEERING-REVIEW-REPORT.md b/examples/regulations/eu-data-act/DATA-ACT-DIRECT-MAIN-ENGINEERING-REVIEW-REPORT.md new file mode 100644 index 00000000..fd5e03c6 --- /dev/null +++ b/examples/regulations/eu-data-act/DATA-ACT-DIRECT-MAIN-ENGINEERING-REVIEW-REPORT.md @@ -0,0 +1,260 @@ +# EU Data Act Engineering Review Report + +Use this report as engineering evidence for legal, compliance, privacy, data governance, security, product, procurement, cloud, provider, architecture, platform, and business-owner review. + +This report is not legal advice. It identifies engineering controls and escalation points from the reviewed direct-to-main delivery evidence. Applicability, data holder status, user entitlement, data recipient roles, trade-secret decisions, contract interpretation, cloud-switching obligations, international access restrictions, and regulatory interpretation require qualified owner review. + +## 1. Review Context + +- System or service name: CheckoutService delivery instructions change +- Repository, product, platform, or business service: Fictional Java Quarkus ecommerce platform with direct commits to `main` +- Review date: 2026-06-14 +- Reviewers: AI-assisted EU Data Act engineering review +- Business owner: Not identified in reviewed evidence +- Product owner: Not identified in reviewed evidence +- Technical owner: Software engineers, tech leads, and platform engineers are described, but no named CheckoutService owner is identified +- Data owner: Not identified in reviewed evidence +- Privacy owner: Not identified in reviewed evidence +- Security owner: Not identified in reviewed evidence +- Cloud or provider owner: Not identified in reviewed evidence +- Legal/compliance owner: Not identified in reviewed evidence +- Source materials reviewed: + - `examples/diagrams/deployment/system-example-cicd-model.md` + - `examples/diagrams/deployment/expected-system-deployment.puml` + - `examples/diagrams/deployment/checkout-service-feature-request.md` + - `.agents/skills/806-regulations-eu-data-act/references/806-regulations-eu-data-act-chapters-summary.md` + - `.agents/skills/806-regulations-eu-data-act/references/806-regulations-eu-data-act-engineering-examples.md` + - `.agents/skills/806-regulations-eu-data-act/assets/reports/806-eu-data-act-engineering-review-report-template.md` + +## 2. Data Act Scope Context + +- Service description: CheckoutService coordinates checkout saga steps for price validation, inventory reservation, payment authorization, order creation, delivery slot booking, PostgreSQL order state, saga state, and Kafka events. +- Possible connected-product or related-service signal: Not confirmed. The reviewed evidence describes ecommerce checkout and delivery data, not a connected product or related service. +- Possible data holder signal: The platform stores and emits checkout, order, delivery, and saga data. Whether the organization is a Data Act data holder requires legal and data-governance review. +- Possible user, data recipient, or third-party recipient signal: Shoppers, support teams, downstream inventory, delivery, notification, analytics, external payment, identity, and notification providers may receive or influence data flows. Entitlement and recipient roles are not documented. +- Possible data processing service or cloud-switching signal: Azure Kubernetes Service, Azure PostgreSQL, Kafka, Key Vault, Azure Monitor, App Insights, Log Analytics, Artifactory, Docker registry, and external SaaS providers create cloud and provider-dependency signals. Whether the platform provides a data processing service requires qualified review. +- Possible data-space, interoperability, or smart-contract signal: Kafka events and service APIs create interoperability signals. No data-space or smart-contract evidence is present. +- Deployment geography: Azure production environment is described; EU establishment, customer geography, and member-state scope are not specified. +- Environments in scope: Development, test, staging, and production. +- Critical users, customers, or affected organizations: Shoppers, support and operations teams, platform engineers, downstream inventory, delivery, notification, analytics, payment, identity, and cloud-provider workflows. +- Production dependencies: Azure Front Door, WAF, AKS ingress, Quarkus services, PostgreSQL stores, Kafka topics, Key Vault, Azure Monitor, App Insights, Log Analytics, Backup Vault, Artifactory, Docker registry, external identity, external payment, and notification provider. +- Open applicability questions: + - Does the platform, product, or service fall within Data Act scope for any EU users, customers, connected-product data, related-service data, or data processing service obligations? + - Does direct-to-main delivery provide adequate evidence for a change that modifies database fields, Kafka event data, potential export fields, and support-visible customer data? + - Who is the data holder, user, data recipient, third-party recipient, customer, cloud provider, and data owner for checkout and delivery instruction data? + - Which legal, compliance, privacy, data governance, security, product, procurement, cloud, platform, provider, and business owners must approve access, sharing, export, retention, and direct-to-main decisions? + +## 3. Data Access And Portability Scope + +- Applications, APIs, jobs, and batch workloads: Web storefront BFF, API gateway, identity, catalog, search, cart, pricing, CheckoutService, payment adapter, inventory, delivery slot, notification worker, analytics pipeline, checkout saga logic, and deployment workflows. +- Datasets, metadata, schemas, and catalog entries: Order records, delivery instruction note, delivery window, delivery contact phone, delivery access code, saga state, Kafka event schemas, order event metadata, and operational observability records. No data catalog or metadata owner is present. +- Data stores, queues, topics, object stores, and caches: User Profile DB, Product DB, Search Index, Cart DB, Pricing DB, Order DB, Saga Support PostgreSQL, Inventory DB, Delivery DB, Kafka topics `order.created`, `payment.authorized`, `stock.reserved`, `slot.booked`, `delivery.slot.requested`, `order.confirmed`, and compensation events. +- Product data, related service data, exportable data, and digital assets: Not classified in reviewed evidence. Checkout and delivery data may be exportable for user access, support, analytics, or provider switching if qualified owners decide Data Act scope applies. +- Personal data, non-personal data, mixed datasets, trade secrets, or commercially sensitive data: Delivery instruction fields may include personal or sensitive operational details. Order and delivery data may also include non-personal operational data. Classification is not documented. +- IAM, access-control rules, secrets, keys, and privileged operations: Azure Key Vault, managed identities, API gateway authentication enforcement, identity provider integration, payment tokens, idempotency keys, database credentials, Kafka credentials, and deployment credentials. +- Data-sharing request workflows and support operations: Not present. Support teams are mentioned, but no intake, entitlement, approval, refusal, suspension, deletion, or complaint workflow is documented. +- Export, portability, and interoperability mechanisms: Kafka event schema versioning and APIs exist; no user export API, machine-readable export format, metadata catalog, bulk download, or portability SLA is documented. +- Cloud-switching, provider-exit, and erasure workflows: Backup Vault and rollback concepts are described; provider exit, exportable data register, secure transfer, customer retrieval period, and erasure evidence are not present. +- Monitoring, alerting, audit logs, and evidence systems: Azure Monitor, App Insights, Log Analytics, structured logs, metrics, traces, correlation IDs, dashboards, alerts, health checks, and post-deployment smoke tests are described; data access audit-log requirements are not present. + +## 4. Potential Violation Or Non-Compliance Mapping + +This section is not a legal finding. It lists concrete potential EU Data Act violation or non-compliance signals from the reviewed direct-to-main delivery evidence and routes each item to qualified owner review. No violation is confirmed by this engineering review. + +| Potential violation or non-compliance signal | EU Data Act reference area | Associated official-source link | Evidence from reviewed system | Current status | Required owner review | Engineering action | +| -------------------------------------------- | -------------------------- | ------------------------------- | ----------------------------- | -------------- | --------------------- | ------------------ | +| Unclear Data Act applicability and role scope | Applicability / definitions / role classification | [Chapter I](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32023R2854#cpt_I) | Ecommerce checkout, delivery, cloud-hosted Java services, Kafka events, and provider dependencies are described, but Data Act applicability, data holder status, user roles, and recipient roles are not recorded | Potential gap | Legal / compliance / data governance / product owner | Record Data Act applicability decision, role map, EU geography, dataset scope, and accountable owners | +| Missing pre-merge review for data access and interoperability change | Release governance / enforcement evidence | [Chapter IX](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32023R2854#cpt_IX) | Engineers commit directly to `main`; the feature modifies order database structure, possible export fields, and Kafka event data | Potential gap | Security / platform / architecture / data owner | Require pre-commit or pre-merge review gate for database migrations, Kafka contracts, export fields, privacy-sensitive fields, and production-impacting data changes | +| Protected-main bypass or insufficient branch protection evidence | Contract evidence / release governance | [Chapter IV](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32023R2854#cpt_IV), [Chapter IX](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32023R2854#cpt_IX) | The reviewed delivery path is `commit + push directly to main`; no protected-main rule, approval requirement, or exception workflow is shown | Potential gap | Platform / security / data governance / executive accountability owner | Enforce branch protection or equivalent signed approval workflow before production release | +| Missing data inventory and metadata evidence | User access / metadata / interoperability | [Chapter II](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32023R2854#cpt_II), [Chapter VIII](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32023R2854#cpt_VIII) | Order DB, Saga Support, Kafka topics, delivery instruction fields, and observability data are described, but no data inventory, metadata catalog, schema owner, or data-quality evidence is shown | Potential gap | Data governance / architecture / product owner | Create data inventory for checkout, delivery, saga, Kafka, support, analytics, and observability datasets with metadata, owner, format, retention, and access rules | +| Weak access authorization and request workflow | User access / third-party sharing | [Chapter II](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32023R2854#cpt_II) | API gateway authentication is described, but no Data Act request intake, entitlement check, recipient verification, purpose capture, refusal, suspension, or deletion workflow is shown | Potential gap | Security / privacy / legal / data owner | Add data access request workflow with minimum necessary verification, authorization, purpose, recipient role, approval, refusal, suspension, deletion, and audit evidence | +| Missing machine-readable export and portability evidence | Portability / exportable data | [Chapter II](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32023R2854#cpt_II), [Chapter VI](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32023R2854#cpt_VI) | Kafka event schemas exist, but no user export API, bulk download, structured export format, export metadata, or cloud customer export register is documented | Potential gap | Product / data governance / architecture / cloud owner | Define export formats, API contracts, schemas, metadata, quality-of-service expectations, and test evidence for eligible checkout and delivery datasets | +| Incomplete trade-secret or sensitive-data handoff | Trade secrets / confidentiality / technical protection | [Chapter II](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32023R2854#cpt_II), [Chapter III](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32023R2854#cpt_III) | Delivery access codes, delivery notes, payment-adjacent data, provider information, and operational details may require confidentiality decisions, but no field classification or handoff is shown | Potential gap | Legal / product / data governance / security | Classify fields, identify trade-secret or sensitive-data candidates, define masking, access protocols, confidentiality measures, and owner decision records | +| Missing cloud-switching and provider-exit evidence | Switching between data processing services | [Chapter VI](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32023R2854#cpt_VI) | Azure services, managed databases, Kafka, registry, observability, and SaaS providers are in scope, but no exportable data register, provider exit runbook, secure transfer plan, retrieval period, or erasure evidence is shown | Potential gap | Cloud owner / provider owner / procurement / legal | Add cloud-switching inventory, exportable data and digital asset register, provider exit runbook, secure transfer test, continuity plan, and erasure evidence | +| Weak non-personal data and international access safeguards | International access / non-personal data | [Chapter VII](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32023R2854#cpt_VII) | EU data residency, non-personal data classification, and international governmental access handling are not documented | Potential gap | Legal / compliance / security / cloud owner | Record data residency, classify non-personal data, document international access request intake, legal review, minimum-data extraction, customer notification, and audit evidence | +| Database migration and Kafka message contract risks | Interoperability / metadata / release evidence | [Chapter VIII](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32023R2854#cpt_VIII) | Feature adds order columns and changes Kafka event schema to version 3 for `delivery.slot.requested`, `order.created`, and `order.confirmed` | Potential gap | Architecture / data owner / platform owner | Require migration approval, schema compatibility tests, metadata updates, event contract documentation, rollback plan, and downstream consumer readiness evidence | + +## 5. Engineering Controls + +- Pre-commit review and main-branch protection: Replace direct-to-main release eligibility for this change with branch protection, required review, signed approval, or an equivalent auditable control before production deployment. +- Data inventory and owner map: Add a CheckoutService data inventory covering Order DB, Saga Support, Kafka topics, delivery instruction fields, support workflows, analytics consumers, observability data, data owners, product owners, privacy owners, security owners, and cloud/provider owners. +- Access authorization and entitlement checks: Define who can request, view, export, or share checkout and delivery instruction data. Include authentication, authorization, purpose capture, recipient role, least privilege, refusal, suspension, revocation, and deletion evidence. +- Data-sharing request workflow: Add intake, validation, approval, legal/privacy/data-governance handoff, response deadline, secure transfer, audit logging, support playbook, and complaint or dispute routing. +- User and recipient role evidence: Record whether shoppers, support users, downstream services, providers, or third-party recipients have access rights or contractual access paths. +- Purpose limitation and request minimization: Collect only the minimum verification data needed to execute and secure the request; avoid broad retention of request verification logs. +- Portability APIs: Define eligible datasets, request endpoints, bulk export, real-time access where technically feasible, API quality of service, throttling, retry behavior, and support workflow. +- Machine-readable export formats: Provide structured exports such as JSON or CSV with schema version, metadata, timestamp, dataset scope, and use restrictions. +- Metadata, schema, vocabulary, and catalog evidence: Publish schema entries for delivery instruction fields and Kafka event version 3, including field meaning, data classification, retention, owner, and compatibility rules. +- Interoperability and quality-of-service evidence: Link OpenAPI, AsyncAPI, schema registry, Kafka contract tests, consumer compatibility tests, and API performance expectations. +- Audit logs and evidence-safe logging: Record request ID, subject ID, recipient role, dataset, purpose, approval/refusal, export ID, schema version, and erasure confirmation without logging delivery notes, access codes, tokens, secrets, or payment details. +- Cloud-switching and provider-exit support: Add exportable data register, provider exit runbook, secure transfer plan, continuity controls, retrieval period, and erasure evidence for Azure services, PostgreSQL, Kafka, observability, registry, and SaaS providers when in scope. +- Non-personal data safeguards: Classify non-personal operational data, record EU residency where relevant, document international access intake, and route transfer requests to legal and cloud owners. +- Mixed personal and non-personal data privacy handoff: Coordinate delivery instruction fields with privacy review and GDPR controls before export, event propagation, support access, or analytics use. +- Trade-secret or commercially sensitive data handoff: Classify provider, operational, fraud, payment, logistics, and proprietary fields. Use masking, confidentiality agreements, access protocols, and qualified owner decisions. +- Contract and compensation evidence: Link data access terms, provider terms, customer terms, compensation assumptions where relevant, cloud switching terms, and non-binding model term review when available. +- Complaint, dispute, refusal, or suspension routing: Route disputes and complaints to legal, compliance, data governance, privacy, security, and product owners with evidence from the request workflow. +- Release gate and change-control evidence: Require pre-commit review, database migration test, Kafka contract test, privacy-safe logging test, data inventory update, export and metadata review, and owner approval before production deployment. Direct commits to `main` should not be the only approval evidence for this change. + +Example direct-to-main release gate control: + +```java +ReleaseDecision evaluateDirectMainDataActRelease(DataActEngineeringReview review) { + var blockers = new ArrayList(); + requirePassing(review.mainBranchProtection(), "protected-main or equivalent approval control", blockers); + requirePresent(review.preCommitDataReview(), "pre-commit data access and interoperability review", blockers); + requirePresent(review.dataInventory(), "data inventory and owner map", blockers); + requirePassing(review.accessAuthorizationTests(), "access authorization tests", blockers); + requirePresent(review.exportFormatEvidence(), "machine-readable export format evidence", blockers); + requirePresent(review.metadataCatalogEntry(), "metadata and schema evidence", blockers); + requirePassing(review.auditLogVerification(), "data access audit-log verification", blockers); + requirePresent(review.tradeSecretHandoff(), "trade-secret and sensitive-data handoff", blockers); + return blockers.isEmpty() + ? ReleaseDecision.approvedWithEvidence(review.serviceId(), review.evidenceReferences(), review.approvers()) + : ReleaseDecision.blocked(review.serviceId(), blockers, Escalation.required("legal", "data-governance", "privacy", "security", "platform", "cloud-owner")); +} +``` + +Example access authorization control: + +```java +DataAccessDecision decide(DataAccessRequest request) { + var subject = subjectVerifier.verifyMinimumNecessary(request.subject()); + var scope = catalog.resolve(request.datasetId()); + var entitlement = entitlementPolicy.evaluate(subject, scope, request.requestedPurpose()); + if (entitlement.requiresOwnerReview()) { + return DataAccessDecision.holdForReview( + request.id(), + Escalation.required("legal", "data-governance", "privacy", "security"), + entitlement.reason() + ); + } + auditLog.recordDecision(request.id(), subject.id(), scope.id(), entitlement.status()); + return entitlement.allowed() + ? DataAccessDecision.approved(request.id(), scope.exportProfile()) + : DataAccessDecision.refused(request.id(), entitlement.reason()); +} +``` + +Example export format control: + +```java +DataExportPackage exportData(ApprovedDataAccess access) { + var schema = schemaRegistry.current(access.exportProfile().schemaId()); + var export = exporter.create( + access.datasetId(), + access.exportProfile().format(), + schema.version(), + ExportMetadata.of(schema.uri(), access.exportProfile().qualityOfService()) + ); + auditLog.recordExportCreated(access.requestId(), export.id(), export.format(), schema.version()); + return export; +} +``` + +## 6. Evidence Inventory + +- Data inventory: Not present as a dedicated inventory; runtime topology and feature request provide raw inputs. +- Metadata catalog: Not present. +- API contract: API gateway and service paths are described, but Data Act access API contract is not present. +- Export format specification: Not present. +- Schema or event contract: Kafka schema version 3 is referenced; concrete schema registry evidence is not present. +- Access-control tests: API authentication is described; field-level access and data export authorization tests are not present. +- Request workflow evidence: Not present. +- Audit-log evidence: Structured logging and correlation IDs are described; data access audit-log evidence is not present. +- Trade-secret review: Not present. +- Privacy or mixed-dataset review: Not present. +- Non-personal data classification: Not present. +- International access safeguard evidence: Not present. +- Cloud-switching runbook: Not present. +- Exportable data register: Not present. +- Erasure evidence: Not present. +- Contract or terms evidence: Not present. +- Complaint or dispute workflow: Not present. +- Release decision: Not present. + +## 7. Residual Risks + +- Residual risk: Direct-to-main delivery may allow a database migration, Kafka contract change, potential export field, or privacy-sensitive field to reach production without independent pre-merge review. +- Impact: Customer-facing checkout disruption, unapproved data propagation, incorrect export metadata, missing Data Act owner handoff, and weak release evidence. +- Likelihood: Medium, because the reviewed delivery model commits every change directly to `main`. +- Mitigation: Require protected-main rules or equivalent review controls, approval evidence, emergency exception process, and release gates for migration, Kafka, privacy, data access, export, metadata, and security-risk changes. +- Owner: Platform owner, security owner, data owner, architecture owner, CheckoutService owner, and executive accountability owner. +- Acceptance decision: Required before production release. +- Review date: Before the direct-to-main commit is eligible for deployment. + +- Residual risk: Delivery instruction fields may expose personal, sensitive, or operational details through logs, Kafka events, exports, support screens, analytics, or provider integrations if not classified and controlled. +- Impact: Unauthorized disclosure, over-broad sharing, incorrect export behavior, difficult erasure, and incomplete owner handoff. +- Likelihood: Medium, because the feature explicitly introduces free text, contact phone, access codes, and event changes. +- Mitigation: Classify fields, exclude sensitive notes from Kafka and logs, apply field-level authorization, add data inventory and export rules, and review retention and erasure. +- Owner: CheckoutService owner, data owner, privacy owner, security owner, product owner, and legal/compliance owner. +- Acceptance decision: Required before production release. +- Review date: Before committing to `main` and before production deployment. + +- Residual risk: Database migration and Kafka schema version 3 may create incomplete metadata, incompatible consumers, or undocumented export semantics. +- Impact: Broken downstream consumers, incorrect data sharing, inconsistent exports, and weak interoperability evidence. +- Likelihood: Medium, because the feature changes persisted order structure and event contracts. +- Mitigation: Add migration tests, schema compatibility tests, metadata catalog entries, export format evidence, consumer readiness evidence, rollback or forward-fix plan, and post-deployment monitoring. +- Owner: Architecture owner, data owner, CheckoutService owner, platform owner, and downstream service owners. +- Acceptance decision: Required before production release. +- Review date: During direct-to-main approval and release readiness. + +- Residual risk: Data Act applicability, role mapping, contract interpretation, cloud-switching obligations, and international access safeguards are not determined by reviewed engineering evidence. +- Impact: Late compliance escalation, unapproved data sharing, unsupported access requests, or weak cloud exit evidence. +- Likelihood: Unknown. +- Mitigation: Route role classification, access rights, contract, trade-secret, provider-exit, and non-personal data questions to qualified owners. +- Owner: Legal/compliance, data governance, privacy, cloud, procurement, and business owners. +- Acceptance decision: Required if Data Act scope is confirmed. +- Review date: Before production reliance. + +## 8. Release Decision + +- Decision: Blocked for production until direct-to-main delivery is supplemented with data access, interoperability, and Data Act owner handoff evidence. +- Conditions: + - Protected-main or equivalent pre-commit approval control is enforced for this change. + - Data inventory names owners for CheckoutService, Order DB, Saga Support, Kafka topics, delivery instruction fields, providers, and environments. + - Legal/data-governance records whether Data Act scope, data holder role, user entitlement, recipient role, or cloud-switching obligations apply. + - Database migration tests prove nullable/default behavior and rollback or forward-fix readiness. + - Kafka contract tests prove schema version 3 compatibility and older-consumer tolerance. + - Metadata catalog and export format evidence cover new delivery instruction fields. + - Access-control and audit-log tests prove request and field-level controls. + - Privacy-safe logging tests prove delivery notes and access codes are not logged or broadcast to Kafka. + - Cloud-switching or non-applicability evidence is recorded for provider dependencies. +- Blockers: + - Direct-to-main commit path lacks explicit pre-merge review, protected-main approval, or exception evidence. + - Missing named product, data, privacy, security, legal/compliance, cloud, procurement, platform, and business owners. + - Missing data inventory, metadata catalog, request workflow, export format, audit-log evidence, trade-secret handoff, and cloud-switching evidence. + - Missing release evidence for migration approval, Kafka compatibility, field classification, and privacy-safe logging. +- Required approvals: Service owner, tech lead, data owner, privacy owner, security owner, product owner, cloud owner, platform owner, architecture owner, legal/compliance owner when applicable, business owner, and executive accountability owner for direct-to-main exception or approval policy. +- Expiry or review date: Before committing to `main` and again before production deployment. +- Environments approved: Development and test only until blockers are resolved. +- Emergency rollback path: Previous validated image plus compatible database state. Confirm whether the order table migration can be safely rolled forward or rolled back without losing delivery instruction data. +- Data access or export disablement path: Feature flag or configuration gate for delivery instruction export and third-party sharing until owner-approved controls are live. + +## 9. Action Plan + +| Priority | Action | Owner | Due date | Evidence expected | Status | +| -------- | ------ | ----- | -------- | ----------------- | ------ | +| High | Add protected-main or equivalent auditable review control for the CheckoutService delivery-instructions change | Platform owner / security owner | Before production deployment | Branch protection, approval, or exception evidence | Open | +| High | Require data access and interoperability pre-commit review for database migrations, Kafka contracts, export fields, privacy-sensitive fields, and production-side-effect changes | Data owner / security owner / architecture owner | Before committing to `main` | Review checklist and approval record | Open | +| High | Create CheckoutService Data Act data inventory with owners, datasets, metadata, Kafka topics, providers, classifications, access paths, retention, and export rules | Data owner / technical owner | Before release approval | Inventory record linked to release | Open | +| High | Add owner handoff for Data Act applicability, data holder status, user entitlement, recipient roles, trade-secret boundaries, cloud-switching obligations, and contract interpretation | Legal / data governance / product owner | Before release approval | Owner decision record | Open | +| High | Add field classification and privacy-safe handling for delivery note, contact phone, access code, and delivery window | Privacy owner / security owner / data owner | Before release approval | Classification record and test evidence | Open | +| High | Add migration approval and tests for nullable/default order columns and rollback or forward-fix behavior | CheckoutService owner / data owner | Before release approval | Migration test results and release note | Open | +| High | Add Kafka schema version 3 contract tests and metadata catalog updates | CheckoutService owner / downstream service owners | Before release approval | Contract test report and metadata entry | Open | +| High | Add data access audit-log tests for request ID, subject, recipient role, purpose, dataset, export ID, refusal, suspension, deletion, and erasure confirmation | Security owner / platform owner | Before production deployment | Audit test report | Open | +| Medium | Define machine-readable export formats and API quality-of-service evidence for eligible checkout and delivery datasets | Product owner / architecture owner | Before production deployment | OpenAPI/export spec and test evidence | Open | +| Medium | Record cloud-switching or non-applicability evidence for Azure, PostgreSQL, Kafka, observability, registry, and SaaS provider data | Cloud owner / procurement / legal | Before production deployment | Exportable data register and exit runbook | Open | +| Medium | Add non-personal data and international access safeguard workflow for provider-held EU data | Legal / compliance / cloud owner | Before production deployment | Request intake and legal review workflow | Open | +| Low | Schedule next Data Act engineering review after deployment and first data access request exercise | Data governance / product owner | After production validation | Review record and corrective actions | Open | + +## 10. Final Notes + +- Items requiring legal interpretation: Data Act applicability, data holder status, user entitlement, data recipient roles, public-sector exceptional need, contract interpretation, cloud-switching obligations, international access restrictions, database-right questions, and regulatory interpretation. +- Items requiring data-governance decision: Direct-to-main data review criteria, dataset ownership, metadata catalog, export scope, field classifications, retention, deletion, and data-sharing request workflow. +- Items requiring privacy review: Delivery notes, contact phone, access code, mixed personal and non-personal data, support access, logs, analytics, and exports. +- Items requiring security exception: Any release without protected-main or equivalent approval evidence, access-control evidence, audit logs, privacy-safe logging, secure transfer, erasure evidence, or trade-secret handoff. +- Items requiring architecture decision: Direct-to-main release policy, Kafka schema versioning, older-consumer compatibility, export API shape, metadata strategy, database migration rollout, rollback limits, and cloud-switching runbook. +- Items requiring cloud or provider review: Azure services, external identity provider, external payment gateway, email/SMS provider, Artifactory, Docker registry, CI/CD actions, observability services, exportable data register, and provider exit. +- Items requiring procurement or contract review: Customer data access terms, provider terms, cloud switching terms, compensation assumptions where relevant, and standard contractual clause alignment when available. +- Items requiring product or business acceptance: Residual risk for direct-to-main delivery, delivery note handling, user access scope, third-party sharing, support workflow changes, and customer-facing rollout timing. +- Next review trigger: Direct-to-main approval request, production deployment request, data access API change, export format change, schema or event contract change, provider change, public-sector request workflow, international access request, complaint, or data incident. diff --git a/examples/regulations/eu-data-act/DATA-ACT-ENGINEERING-REVIEW-REPORT.md b/examples/regulations/eu-data-act/DATA-ACT-ENGINEERING-REVIEW-REPORT.md new file mode 100644 index 00000000..68c58bb4 --- /dev/null +++ b/examples/regulations/eu-data-act/DATA-ACT-ENGINEERING-REVIEW-REPORT.md @@ -0,0 +1,244 @@ +# EU Data Act Engineering Review Report + +Use this report as engineering evidence for legal, compliance, privacy, data governance, security, product, procurement, cloud, provider, architecture, and business-owner review. + +This report is not legal advice. It identifies engineering controls and escalation points from the reviewed system evidence. Applicability, data holder status, user entitlement, data recipient roles, trade-secret decisions, contract interpretation, cloud-switching obligations, international access restrictions, and regulatory interpretation require qualified owner review. + +## 1. Review Context + +- System or service name: CheckoutService delivery instructions change +- Repository, product, platform, or business service: Fictional Java Quarkus ecommerce platform +- Review date: 2026-06-14 +- Reviewers: AI-assisted EU Data Act engineering review +- Business owner: Not identified in reviewed evidence +- Product owner: Not identified in reviewed evidence +- Technical owner: Software engineers, tech leads, reviewers, and platform engineers are described, but no named CheckoutService owner is identified +- Data owner: Not identified in reviewed evidence +- Privacy owner: Not identified in reviewed evidence +- Security owner: Not identified in reviewed evidence +- Cloud or provider owner: Not identified in reviewed evidence +- Legal/compliance owner: Not identified in reviewed evidence +- Source materials reviewed: + - `examples/diagrams/deployment/system-example-cicd-pr-model.md` + - `examples/diagrams/deployment/expected-system-deployment.puml` + - `examples/diagrams/deployment/checkout-service-feature-request.md` + - `.agents/skills/806-regulations-eu-data-act/references/806-regulations-eu-data-act-chapters-summary.md` + - `.agents/skills/806-regulations-eu-data-act/references/806-regulations-eu-data-act-engineering-examples.md` + - `.agents/skills/806-regulations-eu-data-act/assets/reports/806-eu-data-act-engineering-review-report-template.md` + +## 2. Data Act Scope Context + +- Service description: CheckoutService coordinates checkout saga steps for price validation, inventory reservation, payment authorization, order creation, delivery slot booking, PostgreSQL order state, saga state, and Kafka events. +- Possible connected-product or related-service signal: Not confirmed. The reviewed evidence describes ecommerce checkout and delivery data, not a connected product or related service. +- Possible data holder signal: The platform stores and emits checkout, order, delivery, and saga data. Whether the organization is a Data Act data holder requires legal and data-governance review. +- Possible user, data recipient, or third-party recipient signal: Shoppers, support teams, downstream inventory, delivery, notification, analytics, external payment, identity, and notification providers may receive or influence data flows. Entitlement and recipient roles are not documented. +- Possible data processing service or cloud-switching signal: Azure Kubernetes Service, Azure PostgreSQL, Kafka, Key Vault, Azure Monitor, App Insights, Log Analytics, Artifactory, Docker registry, and external SaaS providers create cloud and provider-dependency signals. Whether the platform provides a data processing service requires qualified review. +- Possible data-space, interoperability, or smart-contract signal: Kafka events and service APIs create interoperability signals. No data-space or smart-contract evidence is present. +- Deployment geography: Azure production environment is described; EU establishment, customer geography, and member-state scope are not specified. +- Environments in scope: Development, test, staging, and production. +- Critical users, customers, or affected organizations: Shoppers, support and operations teams, platform engineers, downstream inventory, delivery, notification, analytics, payment, identity, and cloud-provider workflows. +- Production dependencies: Azure Front Door, WAF, AKS ingress, Quarkus services, PostgreSQL stores, Kafka topics, Key Vault, Azure Monitor, App Insights, Log Analytics, Backup Vault, Artifactory, Docker registry, external identity, external payment, and notification provider. +- Open applicability questions: + - Does the platform, product, or service fall within Data Act scope for any EU users, customers, connected-product data, related-service data, or data processing service obligations? + - Who is the data holder, user, data recipient, third-party recipient, customer, cloud provider, and data owner for checkout and delivery instruction data? + - Are delivery instructions personal data, non-personal data, mixed data, trade secrets, or commercially sensitive operational data in any workflow? + - Which legal, compliance, privacy, data governance, security, product, procurement, cloud, provider, and business owners must approve access, sharing, export, and retention decisions? + +## 3. Data Access And Portability Scope + +- Applications, APIs, jobs, and batch workloads: Web storefront BFF, API gateway, identity, catalog, search, cart, pricing, CheckoutService, payment adapter, inventory, delivery slot, notification worker, analytics pipeline, checkout saga logic, and deployment workflows. +- Datasets, metadata, schemas, and catalog entries: Order records, delivery instruction note, delivery window, delivery contact phone, delivery access code, saga state, Kafka event schemas, order event metadata, and operational observability records. No data catalog or metadata owner is present. +- Data stores, queues, topics, object stores, and caches: User Profile DB, Product DB, Search Index, Cart DB, Pricing DB, Order DB, Saga Support PostgreSQL, Inventory DB, Delivery DB, Kafka topics `order.created`, `payment.authorized`, `stock.reserved`, `slot.booked`, `delivery.slot.requested`, `order.confirmed`, and compensation events. +- Product data, related service data, exportable data, and digital assets: Not classified in reviewed evidence. Checkout and delivery data may be exportable for user access, support, analytics, or provider switching if qualified owners decide Data Act scope applies. +- Personal data, non-personal data, mixed datasets, trade secrets, or commercially sensitive data: Delivery instruction fields may include personal or sensitive operational details. Order and delivery data may also include non-personal operational data. Classification is not documented. +- IAM, access-control rules, secrets, keys, and privileged operations: Azure Key Vault, managed identities, API gateway authentication enforcement, identity provider integration, payment tokens, idempotency keys, database credentials, Kafka credentials, and deployment credentials. +- Data-sharing request workflows and support operations: Not present. Support teams are mentioned, but no intake, entitlement, approval, refusal, suspension, deletion, or complaint workflow is documented. +- Export, portability, and interoperability mechanisms: Kafka event schema versioning and APIs exist; no user export API, machine-readable export format, metadata catalog, bulk download, or portability SLA is documented. +- Cloud-switching, provider-exit, and erasure workflows: Backup Vault and rollback concepts are described; provider exit, exportable data register, secure transfer, customer retrieval period, and erasure evidence are not present. +- Monitoring, alerting, audit logs, and evidence systems: Azure Monitor, App Insights, Log Analytics, structured logs, metrics, traces, correlation IDs, dashboards, alerts, health checks, and post-deployment smoke tests are described; data access audit-log requirements are not present. + +## 4. Potential Violation Or Non-Compliance Mapping + +This section is not a legal finding. It lists concrete potential EU Data Act violation or non-compliance signals from the reviewed evidence and routes each item to qualified owner review. No violation is confirmed by this engineering review. + +| Potential violation or non-compliance signal | EU Data Act reference area | Associated official-source link | Evidence from reviewed system | Current status | Required owner review | Engineering action | +| -------------------------------------------- | -------------------------- | ------------------------------- | ----------------------------- | -------------- | --------------------- | ------------------ | +| Unclear Data Act applicability and role scope | Applicability / definitions / role classification | [Chapter I](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32023R2854#cpt_I) | Ecommerce checkout, delivery, cloud-hosted Java services, Kafka events, and provider dependencies are described, but Data Act applicability, data holder status, user roles, and recipient roles are not recorded | Potential gap | Legal / compliance / data governance / product owner | Record Data Act applicability decision, role map, EU geography, dataset scope, and accountable owners | +| Missing data inventory and metadata evidence | User access / metadata / interoperability | [Chapter II](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32023R2854#cpt_II), [Chapter VIII](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32023R2854#cpt_VIII) | Order DB, Saga Support, Kafka topics, delivery instruction fields, and observability data are described, but no data inventory, metadata catalog, schema owner, or data-quality evidence is shown | Potential gap | Data governance / architecture / product owner | Create data inventory for checkout, delivery, saga, Kafka, support, analytics, and observability datasets with metadata, owner, format, retention, and access rules | +| Weak access authorization and request workflow | User access / third-party sharing | [Chapter II](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32023R2854#cpt_II) | API gateway authentication is described, but no Data Act request intake, entitlement check, recipient verification, purpose capture, refusal, suspension, or deletion workflow is shown | Potential gap | Security / privacy / legal / data owner | Add data access request workflow with minimum necessary verification, authorization, purpose, recipient role, approval, refusal, suspension, deletion, and audit evidence | +| Missing machine-readable export and portability evidence | Portability / exportable data | [Chapter II](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32023R2854#cpt_II), [Chapter VI](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32023R2854#cpt_VI) | Kafka event schemas exist, but no user export API, bulk download, structured export format, export metadata, or cloud customer export register is documented | Potential gap | Product / data governance / architecture / cloud owner | Define export formats, API contracts, schemas, metadata, quality-of-service expectations, and test evidence for eligible checkout and delivery datasets | +| Incomplete trade-secret or sensitive-data handoff | Trade secrets / confidentiality / technical protection | [Chapter II](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32023R2854#cpt_II), [Chapter III](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32023R2854#cpt_III) | Delivery access codes, delivery notes, payment-adjacent data, provider information, and operational details may require confidentiality decisions, but no field classification or handoff is shown | Potential gap | Legal / product / data governance / security | Classify fields, identify trade-secret or sensitive-data candidates, define masking, access protocols, confidentiality measures, and owner decision records | +| Missing cloud-switching and provider-exit evidence | Switching between data processing services | [Chapter VI](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32023R2854#cpt_VI) | Azure services, managed databases, Kafka, registry, observability, and SaaS providers are in scope, but no exportable data register, provider exit runbook, secure transfer plan, retrieval period, or erasure evidence is shown | Potential gap | Cloud owner / provider owner / procurement / legal | Add cloud-switching inventory, exportable data and digital asset register, provider exit runbook, secure transfer test, continuity plan, and erasure evidence | +| Weak non-personal data and international access safeguards | International access / non-personal data | [Chapter VII](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32023R2854#cpt_VII) | EU data residency, non-personal data classification, and international governmental access handling are not documented | Potential gap | Legal / compliance / security / cloud owner | Record data residency, classify non-personal data, document international access request intake, legal review, minimum-data extraction, customer notification, and audit evidence | +| Database migration and Kafka message contract risks | Interoperability / metadata / release evidence | [Chapter VIII](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32023R2854#cpt_VIII) | Feature adds order columns and changes Kafka event schema to version 3 for `delivery.slot.requested`, `order.created`, and `order.confirmed` | Potential gap | Architecture / data owner / platform owner | Require migration approval, schema compatibility tests, metadata updates, event contract documentation, rollback plan, and downstream consumer readiness evidence | + +## 5. Engineering Controls + +- Data inventory and owner map: Add a CheckoutService data inventory covering Order DB, Saga Support, Kafka topics, delivery instruction fields, support workflows, analytics consumers, observability data, data owners, product owners, privacy owners, security owners, and cloud/provider owners. +- Access authorization and entitlement checks: Define who can request, view, export, or share checkout and delivery instruction data. Include authentication, authorization, purpose capture, recipient role, least privilege, refusal, suspension, revocation, and deletion evidence. +- Data-sharing request workflow: Add intake, validation, approval, legal/privacy/data-governance handoff, response deadline, secure transfer, audit logging, support playbook, and complaint or dispute routing. +- User and recipient role evidence: Record whether shoppers, support users, downstream services, providers, or third-party recipients have access rights or contractual access paths. +- Purpose limitation and request minimization: Collect only the minimum verification data needed to execute and secure the request; avoid broad retention of request verification logs. +- Portability APIs: Define eligible datasets, request endpoints, bulk export, real-time access where technically feasible, API quality of service, throttling, retry behavior, and support workflow. +- Machine-readable export formats: Provide structured exports such as JSON or CSV with schema version, metadata, timestamp, dataset scope, and use restrictions. +- Metadata, schema, vocabulary, and catalog evidence: Publish schema entries for delivery instruction fields and Kafka event version 3, including field meaning, data classification, retention, owner, and compatibility rules. +- Interoperability and quality-of-service evidence: Link OpenAPI, AsyncAPI, schema registry, Kafka contract tests, consumer compatibility tests, and API performance expectations. +- Audit logs and evidence-safe logging: Record request ID, subject ID, recipient role, dataset, purpose, approval/refusal, export ID, schema version, and erasure confirmation without logging delivery notes, access codes, tokens, secrets, or payment details. +- Cloud-switching and provider-exit support: Add exportable data register, provider exit runbook, secure transfer plan, continuity controls, retrieval period, and erasure evidence for Azure services, PostgreSQL, Kafka, observability, registry, and SaaS providers when in scope. +- Non-personal data safeguards: Classify non-personal operational data, record EU residency where relevant, document international access intake, and route transfer requests to legal and cloud owners. +- Mixed personal and non-personal data privacy handoff: Coordinate delivery instruction fields with privacy review and GDPR controls before export, event propagation, support access, or analytics use. +- Trade-secret or commercially sensitive data handoff: Classify provider, operational, fraud, payment, logistics, and proprietary fields. Use masking, confidentiality agreements, access protocols, and qualified owner decisions. +- Contract and compensation evidence: Link data access terms, provider terms, customer terms, compensation assumptions where relevant, cloud switching terms, and non-binding model term review when available. +- Complaint, dispute, refusal, or suspension routing: Route disputes and complaints to legal, compliance, data governance, privacy, security, and product owners with evidence from the request workflow. +- Release gate and change-control evidence: Require pull request review, database migration test, Kafka contract test, privacy-safe logging test, data inventory update, export and metadata review, and owner approval before production deployment. + +Example access authorization control: + +```java +DataAccessDecision decide(DataAccessRequest request) { + var subject = subjectVerifier.verifyMinimumNecessary(request.subject()); + var scope = catalog.resolve(request.datasetId()); + var entitlement = entitlementPolicy.evaluate(subject, scope, request.requestedPurpose()); + if (entitlement.requiresOwnerReview()) { + return DataAccessDecision.holdForReview( + request.id(), + Escalation.required("legal", "data-governance", "privacy", "security"), + entitlement.reason() + ); + } + auditLog.recordDecision(request.id(), subject.id(), scope.id(), entitlement.status()); + return entitlement.allowed() + ? DataAccessDecision.approved(request.id(), scope.exportProfile()) + : DataAccessDecision.refused(request.id(), entitlement.reason()); +} +``` + +Example export format control: + +```java +DataExportPackage exportData(ApprovedDataAccess access) { + var schema = schemaRegistry.current(access.exportProfile().schemaId()); + var export = exporter.create( + access.datasetId(), + access.exportProfile().format(), + schema.version(), + ExportMetadata.of(schema.uri(), access.exportProfile().qualityOfService()) + ); + auditLog.recordExportCreated(access.requestId(), export.id(), export.format(), schema.version()); + return export; +} +``` + +Example release gate control: + +```java +ReleaseDecision evaluateDataActRelease(DataActEngineeringReview review) { + var blockers = new ArrayList(); + requirePresent(review.dataInventory(), "data inventory and owner map", blockers); + requirePassing(review.accessAuthorizationTests(), "access authorization tests", blockers); + requirePresent(review.exportFormatEvidence(), "machine-readable export format evidence", blockers); + requirePresent(review.metadataCatalogEntry(), "metadata and schema evidence", blockers); + requirePassing(review.auditLogVerification(), "data access audit-log verification", blockers); + requirePresent(review.tradeSecretHandoff(), "trade-secret and sensitive-data handoff", blockers); + requirePresent(review.cloudSwitchingPlan(), "cloud-switching or non-applicability evidence", blockers); + return blockers.isEmpty() + ? ReleaseDecision.approvedWithEvidence(review.serviceId(), review.evidenceReferences(), review.approvers()) + : ReleaseDecision.blocked(review.serviceId(), blockers, Escalation.required("legal", "data-governance", "privacy", "security", "cloud-owner")); +} +``` + +## 6. Evidence Inventory + +- Data inventory: Not present as a dedicated inventory; runtime topology and feature request provide raw inputs. +- Metadata catalog: Not present. +- API contract: API gateway and service paths are described, but Data Act access API contract is not present. +- Export format specification: Not present. +- Schema or event contract: Kafka schema version 3 is referenced; concrete schema registry evidence is not present. +- Access-control tests: API authentication is described; field-level access and data export authorization tests are not present. +- Request workflow evidence: Not present. +- Audit-log evidence: Structured logging and correlation IDs are described; data access audit-log evidence is not present. +- Trade-secret review: Not present. +- Privacy or mixed-dataset review: Not present. +- Non-personal data classification: Not present. +- International access safeguard evidence: Not present. +- Cloud-switching runbook: Not present. +- Exportable data register: Not present. +- Erasure evidence: Not present. +- Contract or terms evidence: Not present. +- Complaint or dispute workflow: Not present. +- Release decision: Not present. + +## 7. Residual Risks + +- Residual risk: Delivery instruction fields may expose personal, sensitive, or operational details through logs, Kafka events, exports, support screens, analytics, or provider integrations if not classified and controlled. +- Impact: Unauthorized disclosure, over-broad sharing, incorrect export behavior, difficult erasure, and incomplete owner handoff. +- Likelihood: Medium, because the feature explicitly introduces free text, contact phone, access codes, and event changes. +- Mitigation: Classify fields, exclude sensitive notes from Kafka and logs, apply field-level authorization, add data inventory and export rules, and review retention and erasure. +- Owner: CheckoutService owner, data owner, privacy owner, security owner, product owner, and legal/compliance owner. +- Acceptance decision: Required before production release. +- Review date: Before merging and before production deployment. + +- Residual risk: Database migration and Kafka schema version 3 may create incomplete metadata, incompatible consumers, or undocumented export semantics. +- Impact: Broken downstream consumers, incorrect data sharing, inconsistent exports, and weak interoperability evidence. +- Likelihood: Medium, because the feature changes persisted order structure and event contracts. +- Mitigation: Add migration tests, schema compatibility tests, metadata catalog entries, export format evidence, consumer readiness evidence, rollback or forward-fix plan, and post-deployment monitoring. +- Owner: Architecture owner, data owner, CheckoutService owner, platform owner, and downstream service owners. +- Acceptance decision: Required before production release. +- Review date: During PR review and release readiness. + +- Residual risk: Data Act applicability, role mapping, contract interpretation, cloud-switching obligations, and international access safeguards are not determined by reviewed engineering evidence. +- Impact: Late compliance escalation, unapproved data sharing, unsupported access requests, or weak cloud exit evidence. +- Likelihood: Unknown. +- Mitigation: Route role classification, access rights, contract, trade-secret, provider-exit, and non-personal data questions to qualified owners. +- Owner: Legal/compliance, data governance, privacy, cloud, procurement, and business owners. +- Acceptance decision: Required if Data Act scope is confirmed. +- Review date: Before production reliance. + +## 8. Release Decision + +- Decision: Conditionally blocked for production until Data Act engineering evidence is attached to the PR and release record. +- Conditions: + - Data inventory names owners for CheckoutService, Order DB, Saga Support, Kafka topics, delivery instruction fields, providers, and environments. + - Legal/data-governance records whether Data Act scope, data holder role, user entitlement, recipient role, or cloud-switching obligations apply. + - Database migration tests prove nullable/default behavior and rollback or forward-fix readiness. + - Kafka contract tests prove schema version 3 compatibility and older-consumer tolerance. + - Metadata catalog and export format evidence cover new delivery instruction fields. + - Access-control and audit-log tests prove request and field-level controls. + - Privacy-safe logging tests prove delivery notes and access codes are not logged or broadcast to Kafka. + - Cloud-switching or non-applicability evidence is recorded for provider dependencies. +- Blockers: + - Missing named product, data, privacy, security, legal/compliance, cloud, procurement, and business owners. + - Missing data inventory, metadata catalog, request workflow, export format, audit-log evidence, trade-secret handoff, and cloud-switching evidence. + - Missing release evidence for migration approval, Kafka compatibility, field classification, and privacy-safe logging. +- Required approvals: Service owner, tech lead, data owner, privacy owner, security owner, product owner, cloud owner, architecture owner, legal/compliance owner when applicable, and business owner. +- Expiry or review date: Before merge and again before production deployment. +- Environments approved: Development and test only until blockers are resolved. +- Emergency rollback path: Previous validated image plus compatible database state. Confirm whether the order table migration can be safely rolled forward or rolled back without losing delivery instruction data. +- Data access or export disablement path: Feature flag or configuration gate for delivery instruction export and third-party sharing until owner-approved controls are live. + +## 9. Action Plan + +| Priority | Action | Owner | Due date | Evidence expected | Status | +| -------- | ------ | ----- | -------- | ----------------- | ------ | +| High | Create CheckoutService Data Act data inventory with owners, datasets, metadata, Kafka topics, providers, classifications, access paths, retention, and export rules | Data owner / technical owner | Before PR approval | Inventory record linked to release | Open | +| High | Add owner handoff for Data Act applicability, data holder status, user entitlement, recipient roles, trade-secret boundaries, cloud-switching obligations, and contract interpretation | Legal / data governance / product owner | Before PR approval | Owner decision record | Open | +| High | Add field classification and privacy-safe handling for delivery note, contact phone, access code, and delivery window | Privacy owner / security owner / data owner | Before merge | Classification record and test evidence | Open | +| High | Add migration approval and tests for nullable/default order columns and rollback or forward-fix behavior | CheckoutService owner / data owner | Before merge | Migration test results and release note | Open | +| High | Add Kafka schema version 3 contract tests and metadata catalog updates | CheckoutService owner / downstream service owners | Before merge | Contract test report and metadata entry | Open | +| High | Add data access audit-log tests for request ID, subject, recipient role, purpose, dataset, export ID, refusal, suspension, deletion, and erasure confirmation | Security owner / platform owner | Before production deployment | Audit test report | Open | +| Medium | Define machine-readable export formats and API quality-of-service evidence for eligible checkout and delivery datasets | Product owner / architecture owner | Before production deployment | OpenAPI/export spec and test evidence | Open | +| Medium | Record cloud-switching or non-applicability evidence for Azure, PostgreSQL, Kafka, observability, registry, and SaaS provider data | Cloud owner / procurement / legal | Before production deployment | Exportable data register and exit runbook | Open | +| Medium | Add non-personal data and international access safeguard workflow for provider-held EU data | Legal / compliance / cloud owner | Before production deployment | Request intake and legal review workflow | Open | +| Low | Schedule next Data Act engineering review after deployment and first data access request exercise | Data governance / product owner | After production validation | Review record and corrective actions | Open | + +## 10. Final Notes + +- Items requiring legal interpretation: Data Act applicability, data holder status, user entitlement, data recipient roles, public-sector exceptional need, contract interpretation, cloud-switching obligations, international access restrictions, database-right questions, and regulatory interpretation. +- Items requiring data-governance decision: Dataset ownership, metadata catalog, export scope, field classifications, retention, deletion, and data-sharing request workflow. +- Items requiring privacy review: Delivery notes, contact phone, access code, mixed personal and non-personal data, support access, logs, analytics, and exports. +- Items requiring security exception: Any release without access-control evidence, audit logs, privacy-safe logging, secure transfer, erasure evidence, or trade-secret handoff. +- Items requiring architecture decision: Kafka schema versioning, older-consumer compatibility, export API shape, metadata strategy, database migration rollout, rollback limits, and cloud-switching runbook. +- Items requiring cloud or provider review: Azure services, external identity provider, external payment gateway, email/SMS provider, Artifactory, Docker registry, CI/CD actions, observability services, exportable data register, and provider exit. +- Items requiring procurement or contract review: Customer data access terms, provider terms, cloud switching terms, compensation assumptions where relevant, and standard contractual clause alignment when available. +- Items requiring product or business acceptance: Residual risk for delivery note handling, user access scope, third-party sharing, support workflow changes, and customer-facing rollout timing. +- Next review trigger: PR approval request, production deployment request, data access API change, export format change, schema or event contract change, provider change, public-sector request workflow, international access request, complaint, or data incident. diff --git a/skills-generator/src/main/resources/skill-indexes/806-skill.xml b/skills-generator/src/main/resources/skill-indexes/806-skill.xml new file mode 100644 index 00000000..e97c6af7 --- /dev/null +++ b/skills-generator/src/main/resources/skill-indexes/806-skill.xml @@ -0,0 +1,89 @@ + + + + Juan Antonio Breña Moral + 0.16.0-SNAPSHOT + Apache-2.0 + Use when reviewing, designing, or modifying Java enterprise systems that expose, exchange, store, process, export, or port data across users, businesses, connected products, cloud providers, APIs, event streams, AI data pipelines, data spaces, or SaaS platforms and need EU Data Act engineering controls. This should trigger for requests such as Review a Java platform for EU Data Act controls; Design data access and portability evidence; Add data-sharing request workflows, export formats, interoperability, metadata, audit logs, cloud-switching support, non-personal data safeguards, or trade-secret handoffs; Assess Data Act engineering readiness before production release. + + + EU Data Act Regulation for Java Enterprise Data Access and Portability Engineering + When does a Java enterprise system require EU Data Act-aware data access, sharing, portability, interoperability, or cloud-switching controls, and what should developers build differently? + +External reference: [Regulation (EU) 2023/2854 Data Act](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32023R2854). + +EU Data Act chapters summary reference: [EU Data Act chapters summary](references/806-regulations-eu-data-act-chapters-summary.md). + +Java engineering examples reference: [EU Data Act engineering examples](references/806-regulations-eu-data-act-engineering-examples.md). + +Report template asset: [EU Data Act engineering review report template](assets/reports/806-eu-data-act-engineering-review-report-template.md). + +## Scope + +This Skill applies to: + +- Java systems that expose, exchange, store, process, export, port, or derive data through REST APIs, GraphQL APIs, Kafka topics, batch exports, object storage, data lakes, SaaS APIs, data spaces, connected-product integrations, or cloud services +- Spring Boot, Quarkus, Micronaut, and framework-agnostic Java services with user-facing data access, third-party sharing, export, portability, interoperability, cloud-switching, or non-personal data governance requirements +- Systems with data holder, user, data recipient, third-party recipient, public-sector exceptional-need, data processing service, data-space participant, smart-contract, or provider-switching signals +- Data access request workflows, authorization checks, consent and entitlement evidence, API quality-of-service records, export jobs, schema registries, metadata catalogs, audit logs, retention and deletion controls, and provider exit runbooks +- Product data, related service data, exportable data, metadata, non-personal data, mixed personal and non-personal datasets, trade secrets, commercially sensitive data, cloud customer data, and data-sharing agreements + +## EU Data Act Engineering Review + +Treat applicability, data holder status, user entitlement, data recipient role, public-sector exceptional need, trade-secret decisions, contract interpretation, cloud-switching obligations, international access restrictions, and regulatory interpretation as governance decisions for legal, compliance, privacy, data governance, security, product, procurement, cloud, risk, and business owners. + +Engineering teams should still create evidence that makes those decisions reviewable: + +- Which products, services, APIs, event streams, datasets, exports, data stores, cloud services, and providers are in scope +- Which product data, related service data, exportable data, metadata, personal data, non-personal data, trade secrets, or commercially sensitive data can be accessed or shared +- Which users, data holders, data recipients, third parties, cloud customers, public-sector requesters, and provider owners participate in data workflows +- Which authorization, entitlement, purpose limitation, audit, request, refusal, suspension, deletion, and handoff evidence exists +- Which portability APIs, machine-readable formats, metadata, schemas, quality-of-service expectations, interoperability controls, and switching runbooks are implemented +- Which unresolved legal, contractual, trade-secret, personal-data, international-transfer, or public-sector request questions require qualified owner review +]]> + + + Translate EU Data Act concerns into engineering controls for Java enterprise systems. Do not provide legal advice or replace review by legal, compliance, privacy, data governance, security, product, procurement, cloud, risk, or business owners. + + **NOT LEGAL ADVICE**: Frame findings as data access, portability, interoperability, cloud-switching, and operational engineering controls; recommend qualified review for applicability, roles, contracts, trade secrets, cloud-switching obligations, and regulatory interpretation + **SCOPE FIRST**: Identify whether the system has connected-product, related-service, data holder, user, data recipient, third-party sharing, public-sector exceptional-need, data-processing-service, data-space, or smart-contract signals before recommending controls + **DATA INVENTORY**: Require traceable inventories for datasets, metadata, APIs, Kafka topics, object stores, exports, data products, data owners, processors, recipients, and provider systems + **ACCESS AUTHORIZATION**: Verify entitlement, authentication, authorization, purpose, request origin, recipient role, least privilege, revocation, refusal, suspension, deletion, and audit evidence for data access requests + **PORTABILITY AND INTEROPERABILITY**: Review machine-readable export formats, API contracts, schemas, metadata, quality-of-service evidence, bulk download, real-time access where technically feasible, standards, and provider switching support + **NON-PERSONAL DATA SAFEGUARDS**: Preserve non-personal data controls, mixed-dataset separation, confidentiality, international governmental access safeguards, and security during access, transfer, export, and switching + **TRADE SECRET HANDOFF**: Do not decide trade-secret disclosure boundaries; identify trade-secret or commercially sensitive data and route confidentiality measures, refusals, suspensions, or exceptions to qualified owners + **CONTRACT AND CLOUD SWITCHING EVIDENCE**: Review data-sharing terms, access terms, compensation evidence, provider exit information, exportable data registers, switching runbooks, continuity controls, and erasure evidence + **OPERATIONAL REQUEST CONTROLS**: Require observable request intake, SLA handling, identity checks, approvals, audit logs, evidence-safe logging, dispute or complaint routing, support runbooks, and release gates for data access workflows + + + + + + Review a Java platform for EU Data Act controls + Design data access and portability evidence for a Java service + Add data-sharing request workflows, export formats, metadata, audit logs, interoperability, or cloud-switching support + Assess Data Act engineering readiness before production release + Check whether Java APIs, Kafka topics, cloud services, or data products support Data Act-aware owner handoffs + + + + Read regulation chapters summary, engineering examples, and report templateRead `references/806-regulations-eu-data-act-chapters-summary.md`, `references/806-regulations-eu-data-act-engineering-examples.md`, and `assets/reports/806-eu-data-act-engineering-review-report-template.md` in that order. Use the chapters summary for Data Act chapter, article, data access, portability, cloud-switching, interoperability, enforcement, and owner-handoff context. Use the engineering examples for Java control patterns such as data inventory, access authorization, portability APIs, export formats, metadata, audit logs, cloud-switching evidence, non-personal data safeguards, trade-secret handoffs, data-sharing request workflows, contract evidence, and operational controls. Do not start implementation review until the chapters summary, examples reference, and report template are understood. + Classify the data access and portability scopeIdentify service context, possible connected-product or related-service signals, data holder signals, user and recipient roles, public-sector exceptional-need signals, cloud or data-processing-service signals, data-space or smart-contract signals, system owner, data owner, privacy owner, security owner, product owner, provider owner, deployment environments, datasets, metadata, APIs, event streams, data stores, exports, retention, and provider-switching pathways. Escalate unclear applicability, data holder status, user entitlement, data recipient role, trade-secret decisions, contract interpretation, cloud-switching obligations, international access restrictions, or regulatory interpretation to qualified owners. + Review implementation and operational evidenceReview Java code, API contracts, DTOs, serializers, schema registries, Kafka contracts, batch exports, object storage layouts, metadata catalogs, access-control rules, request workflows, audit logs, privacy controls, tests, runbooks, cloud contracts, provider exit documentation, support workflows, monitoring, and release evidence. Check for gaps between claimed controls and reviewable evidence. + Recommend engineering controlsMap Data Act concerns to engineering actions: data inventory, role and entitlement evidence, request intake, purpose and authorization checks, machine-readable exports, metadata and schema publication, bulk or real-time API access where technically feasible, audit logging, evidence-safe support operations, non-personal data safeguards, mixed-dataset privacy handoff, trade-secret confidentiality measures, data-sharing terms, cloud-switching runbooks, interoperability standards, erasure controls, and release gates. + Generate review report and owner handoffsUse `assets/reports/806-eu-data-act-engineering-review-report-template.md` to produce a concise engineering review with scope, evidence reviewed, Data Act risk signals, potential violation or non-compliance signals, engineering gaps, recommended controls, owner handoffs, residual risks, release decision, and validation steps. State explicitly that legal applicability, data holder/user/recipient roles, trade-secret decisions, contract interpretation, cloud-switching obligations, international access restrictions, and regulatory interpretation require qualified owner review. + + diff --git a/skills-generator/src/main/resources/skill-references/806-regulations-eu-data-act-chapters-summary.xml b/skills-generator/src/main/resources/skill-references/806-regulations-eu-data-act-chapters-summary.xml new file mode 100644 index 00000000..49d9f806 --- /dev/null +++ b/skills-generator/src/main/resources/skill-references/806-regulations-eu-data-act-chapters-summary.xml @@ -0,0 +1,238 @@ + + + + + Juan Antonio Breña Moral + 0.16.0-SNAPSHOT + Apache-2.0 + EU Data Act Regulation for Java Enterprise Data Access and Portability Engineering + Use as a chapter-by-chapter and article-by-article summary of Regulation (EU) 2023/2854 to enrich Java enterprise data access, portability, interoperability, and cloud-switching reviews with EU Data Act context. + + + You are a senior Java enterprise architect and data-governance engineering reviewer using the EU Data Act article structure to map regulatory themes to engineering controls and owner handoffs + + + + + + Use this reference as EU Data Act context for Java engineering review. Do not provide legal advice or replace review by legal, compliance, privacy, data governance, security, product, procurement, cloud, risk, or business owners. + + + **NOT LEGAL ADVICE**: State when an article mapping requires qualified owner review instead of giving legal conclusions + **SUMMARY ONLY**: Keep this reference focused on Data Act chapters, articles, and engineering implications; use the engineering examples reference for Java patterns + **ARTICLE MAPPING**: Map findings to Data Act topic areas such as access, sharing, portability, metadata, interoperability, public-sector requests, cloud switching, non-personal data safeguards, or enforcement + **OWNER ESCALATION**: Escalate applicability, data holder status, user entitlement, data recipient role, trade-secret decisions, contract interpretation, cloud-switching obligations, international access restrictions, and regulatory interpretation to qualified owners + **EVIDENCE ORIENTATION**: Use article summaries to identify what engineering evidence is missing or weak, not to certify compliance + + + + + + **READ** this EU Data Act chapters summary before applying Java examples or generating the review report + **MAP** reviewed findings to Data Act topic areas and article groups using only reviewed evidence + **ESCALATE** legal applicability, data holder status, user entitlement, recipient roles, trade-secret decisions, contract interpretation, cloud-switching obligations, international access restrictions, and regulatory interpretation to qualified owners + **HAND OFF** implementation control patterns to `references/806-regulations-eu-data-act-engineering-examples.md` + + + + + + **DO NOT CERTIFY COMPLIANCE**: This reference supports engineering review and owner handoff only + **CHECK RELATED LAW**: Personal-data, privacy, sector-specific, competition, IP, trade-secret, and cloud-contract obligations may add or override engineering expectations + **KEEP FACTS GROUNDED**: Do not infer data holder status, user entitlement, data recipient role, exceptional need, cloud-switching obligation, or trade-secret outcome without reviewed evidence and qualified owner input + + + diff --git a/skills-generator/src/main/resources/skill-references/806-regulations-eu-data-act-engineering-examples.xml b/skills-generator/src/main/resources/skill-references/806-regulations-eu-data-act-engineering-examples.xml new file mode 100644 index 00000000..8e35cdeb --- /dev/null +++ b/skills-generator/src/main/resources/skill-references/806-regulations-eu-data-act-engineering-examples.xml @@ -0,0 +1,411 @@ + + + + + Juan Antonio Breña Moral + 0.16.0-SNAPSHOT + Apache-2.0 + EU Data Act Regulation for Java Enterprise Data Access and Portability Engineering + Use as Java-focused EU Data Act engineering examples for data inventory, access authorization, portability APIs, export formats, metadata, audit logs, cloud switching, non-personal data safeguards, trade-secret handoffs, and data-sharing request workflows. + + + You are a senior Java enterprise architect and data-governance engineering reviewer who translates EU Data Act themes into concrete Java engineering examples and reviewable evidence patterns + + + Apply these EU Data Act-aware examples after the regulation summary has been read and the target system scope is understood. + + These examples are not legal advice. They show engineering patterns that help Java teams create reviewable evidence for legal, compliance, privacy, data governance, security, product, procurement, cloud, risk, provider, and business owners. + + Use this examples reference together with `references/806-regulations-eu-data-act-chapters-summary.md` and the [EU Data Act engineering review report template](../assets/reports/806-eu-data-act-engineering-review-report-template.md). + + + + + Translate EU Data Act concerns into engineering controls for Java enterprise systems without replacing qualified legal, compliance, privacy, data governance, security, product, procurement, cloud, risk, provider, or business review. + + + **NOT LEGAL ADVICE**: Treat the examples as engineering control patterns and escalation aids, not legal findings + **EVIDENCE FIRST**: Prefer reviewable evidence over claims that access, portability, interoperability, or switching controls exist + **OWNER HANDOFFS**: Include data, product, privacy, security, legal, compliance, platform, cloud, provider, and business owners in control records + **SECURE LOGGING**: Preserve access-request and portability evidence without exposing secrets, credentials, personal data, trade secrets, commercially sensitive records, or sensitive public-sector request details unnecessarily + **RELEASE READINESS**: Do not mark a system ready when critical data inventory, access authorization, export, interoperability, cloud-switching, trade-secret, or owner handoff controls are undocumented, untested, ownerless, or dependent on unknown providers + + + + + + + + + Document data inventory and Data Act role signals + datasets, metadata, products, services, recipients, owners, and handoffs + + + + + + + + + + + + + + + + + Authorize data access requests with minimal verification + entitlement, purpose, recipient role, refusal, suspension, and audit evidence + + + + + + + + + + + + + + + + + Expose portable, machine-readable data exports + format, metadata, schema version, bulk export, and API quality of service + + + + + + + + + + + + + + + + + Make interoperability and metadata reviewable + schemas, vocabularies, API terms, quality of service, and data-space readiness + + + + + + + + + + + + + + + + + Prepare cloud switching and exportable data evidence + exit strategy, export register, continuity, secure transfer, and erasure + + + + + + + + + + + + + + + + + Safeguard non-personal data during access and transfer + classification, jurisdiction, minimum data, customer notification, and legal handoff + + + + + + + + + + + + + + + + + Route trade-secret and sensitive-data decisions to owners + field classification, confidentiality measures, refusal evidence, and suspension workflow + + + + + + + + + + + + + + + + + Block release until Data Act engineering controls are evidenced + inventory, authorization, export, metadata, audit, switching, and owner approvals + + + + + + + blockers = new ArrayList<>(); + + requirePresent(review.dataInventory(), "data inventory and owner map", blockers); + requirePassing(review.accessAuthorizationTests(), "access authorization tests", blockers); + requirePresent(review.exportFormatEvidence(), "machine-readable export format evidence", blockers); + requirePresent(review.metadataCatalogEntry(), "metadata and schema evidence", blockers); + requirePassing(review.auditLogVerification(), "data access audit-log verification", blockers); + requirePresent(review.tradeSecretHandoff(), "trade-secret and sensitive-data handoff", blockers); + requirePresent(review.cloudSwitchingPlan(), "cloud-switching or non-applicability evidence", blockers); + + if (!blockers.isEmpty()) { + return ReleaseDecision.blocked( + review.serviceId(), + blockers, + Escalation.required("legal", "data-governance", "privacy", "security", "cloud-owner") + ); + } + + return ReleaseDecision.approvedWithEvidence( + review.serviceId(), + review.evidenceReferences(), + review.approvers() + ); +}]]> + + + + + + + + + + + **MATCH** the relevant example patterns: data inventory, access authorization, portability API, export format, interoperability metadata, cloud switching, non-personal data safeguards, trade-secret handoff, request workflow, or release gate + **RECOMMEND** engineering controls: data inventory updates, role and entitlement checks, request intake workflow, machine-readable export formats, metadata catalog entries, API quality-of-service evidence, audit logs, evidence-safe support operations, interoperability contracts, cloud-switching runbooks, secure transfer, erasure verification, non-personal data safeguards, and qualified owner handoffs + **REPORT** conclusions and actions using `assets/reports/806-eu-data-act-engineering-review-report-template.md`, including review context, data access scope, evidence reviewed, Data Act risk signals, potential violation or non-compliance signals with official-source links, engineering controls, residual risks, release decision, and prioritized action plan with owners and due dates + + + + + + **DATA ACCESS EVIDENCE**: Do not accept undocumented claims that user access, third-party sharing, export, portability, interoperability, cloud switching, request handling, or erasure controls exist; ask for reviewable evidence + **QUALIFIED ROLE DECISIONS**: Escalate data holder status, user entitlement, data recipient role, public-sector exceptional need, contract interpretation, trade-secret boundaries, cloud-switching obligations, and regulatory interpretation + **MIXED DATASETS**: Coordinate with privacy and GDPR controls when personal data and non-personal data are mixed or inseparable + + + diff --git a/skills-generator/src/main/resources/skill-references/assets/reports/806-eu-data-act-engineering-review-report-template.md b/skills-generator/src/main/resources/skill-references/assets/reports/806-eu-data-act-engineering-review-report-template.md new file mode 100644 index 00000000..8b0818c1 --- /dev/null +++ b/skills-generator/src/main/resources/skill-references/assets/reports/806-eu-data-act-engineering-review-report-template.md @@ -0,0 +1,149 @@ +# EU Data Act Engineering Review Report + +Use this template after reviewing `../../references/806-regulations-eu-data-act-chapters-summary.md` and matching the relevant examples from `../../references/806-regulations-eu-data-act-engineering-examples.md` for data inventory, access authorization, portability APIs, export formats, metadata, audit logs, cloud switching, non-personal data safeguards, trade-secret handoffs, data-sharing request workflows, contract evidence, and operational controls. + +This report is not legal advice. Use it as engineering evidence for legal, compliance, privacy, data governance, security, product, procurement, cloud, risk, provider, architecture, and business-owner review. + +The purpose of this report is to increase awareness of potential gaps in the system and create engineering evidence for qualified review. The response produced from this template does not represent legal advice, a legal opinion, or a final regulatory determination. + +## 1. Review Context + +- System or service name: +- Repository, product, platform, or business service: +- Review date: +- Reviewers: +- Business owner: +- Product owner: +- Technical owner: +- Data owner: +- Privacy owner: +- Security owner: +- Cloud or provider owner: +- Legal/compliance owner: +- Source materials reviewed: + +## 2. Data Act Scope Context + +- Service description: +- Possible connected-product or related-service signal: +- Possible data holder signal: +- Possible user, data recipient, or third-party recipient signal: +- Possible data processing service or cloud-switching signal: +- Possible data-space, interoperability, or smart-contract signal: +- Deployment geography: +- Environments in scope: +- Critical users, customers, or affected organizations: +- Production dependencies: +- Open applicability questions: + +## 3. Data Access And Portability Scope + +- Applications, APIs, jobs, and batch workloads: +- Datasets, metadata, schemas, and catalog entries: +- Data stores, queues, topics, object stores, and caches: +- Product data, related service data, exportable data, and digital assets: +- Personal data, non-personal data, mixed datasets, trade secrets, or commercially sensitive data: +- IAM, access-control rules, secrets, keys, and privileged operations: +- Data-sharing request workflows and support operations: +- Export, portability, and interoperability mechanisms: +- Cloud-switching, provider-exit, and erasure workflows: +- Monitoring, alerting, audit logs, and evidence systems: + +## 4. Potential Violation Or Non-Compliance Mapping + +This section is not a legal finding. Use it to list concrete potential EU Data Act violation or non-compliance signals from the reviewed evidence and route each item to qualified legal, compliance, privacy, data governance, security, product, procurement, cloud, risk, provider, or business-owner review. When no violation is confirmed, say so explicitly and keep open items as potential gaps. Use the official-source chapter links from `../../references/806-regulations-eu-data-act-chapters-summary.md`; add more official-source links when one finding spans multiple Data Act areas. + +| Potential violation or non-compliance signal | EU Data Act reference area | Associated official-source link | Evidence from reviewed system | Current status | Required owner review | Engineering action | +| -------------------------------------------- | -------------------------- | ------------------------------- | ----------------------------- | -------------- | --------------------- | ------------------ | +| Unclear Data Act applicability or role scope | Applicability / role classification | [Chapter I](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32023R2854#cpt_I) | TBD | None identified / Potential gap / Confirmed concern | Legal / compliance / data governance / product owner | TBD | +| Missing data inventory or metadata evidence | User access / metadata / interoperability | [Chapter II](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32023R2854#cpt_II), [Chapter VIII](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32023R2854#cpt_VIII) | TBD | None identified / Potential gap / Confirmed concern | Data governance / architecture / product owner | TBD | +| Weak access authorization or request workflow | User access / third-party sharing | [Chapter II](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32023R2854#cpt_II) | TBD | None identified / Potential gap / Confirmed concern | Security / privacy / legal / data owner | TBD | +| Missing machine-readable export or portability evidence | Portability / exportable data | [Chapter II](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32023R2854#cpt_II), [Chapter VI](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32023R2854#cpt_VI) | TBD | None identified / Potential gap / Confirmed concern | Product / data governance / architecture / cloud owner | TBD | +| Incomplete trade-secret or sensitive-data handoff | Trade secrets / confidentiality / technical protection | [Chapter II](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32023R2854#cpt_II), [Chapter III](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32023R2854#cpt_III) | TBD | None identified / Potential gap / Confirmed concern | Legal / product / data governance / security | TBD | +| Missing cloud-switching support or exportable data register | Switching between data processing services | [Chapter VI](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32023R2854#cpt_VI) | TBD | None identified / Potential gap / Confirmed concern | Cloud owner / provider owner / procurement / legal | TBD | +| Weak non-personal data and international access safeguards | International access / non-personal data | [Chapter VII](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32023R2854#cpt_VII) | TBD | None identified / Potential gap / Confirmed concern | Legal / compliance / security / cloud owner | TBD | +| Incomplete contract or complaint evidence | Contract terms / enforcement / complaints | [Chapter IV](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32023R2854#cpt_IV), [Chapter IX](https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32023R2854#cpt_IX) | TBD | None identified / Potential gap / Confirmed concern | Legal / procurement / product / business owner | TBD | + +## 5. Engineering Controls + +- Data inventory and owner map: +- Access authorization and entitlement checks: +- Data-sharing request workflow: +- User and recipient role evidence: +- Purpose limitation and request minimization: +- Portability APIs: +- Machine-readable export formats: +- Metadata, schema, vocabulary, and catalog evidence: +- Interoperability and quality-of-service evidence: +- Audit logs and evidence-safe logging: +- Cloud-switching and provider-exit support: +- Exportable data and digital asset register: +- Secure transfer and erasure controls: +- Non-personal data safeguards: +- Mixed personal and non-personal data privacy handoff: +- Trade-secret or commercially sensitive data handoff: +- Contract and compensation evidence: +- Complaint, dispute, refusal, or suspension routing: +- Release gate and change-control evidence: + +## 6. Evidence Inventory + +- Data inventory: +- Metadata catalog: +- API contract: +- Export format specification: +- Schema or event contract: +- Access-control tests: +- Request workflow evidence: +- Audit-log evidence: +- Trade-secret review: +- Privacy or mixed-dataset review: +- Non-personal data classification: +- International access safeguard evidence: +- Cloud-switching runbook: +- Exportable data register: +- Erasure evidence: +- Contract or terms evidence: +- Complaint or dispute workflow: +- Release decision: + +## 7. Residual Risks + +- Residual risk: +- Impact: +- Likelihood: +- Mitigation: +- Owner: +- Acceptance decision: +- Review date: + +## 8. Release Decision + +- Decision: +- Conditions: +- Blockers: +- Required approvals: +- Expiry or review date: +- Environments approved: +- Emergency rollback path: +- Data access or export disablement path: + +## 9. Action Plan + +| Priority | Action | Owner | Due date | Evidence expected | Status | +| -------- | ------ | ----- | -------- | ----------------- | ------ | +| High | | | | | Open | +| Medium | | | | | Open | +| Low | | | | | Open | + +## 10. Final Notes + +- Items requiring legal interpretation: +- Items requiring data-governance decision: +- Items requiring privacy review: +- Items requiring security exception: +- Items requiring architecture decision: +- Items requiring cloud or provider review: +- Items requiring procurement or contract review: +- Items requiring product or business acceptance: +- Next review trigger: diff --git a/skills-generator/src/main/resources/skills.xml b/skills-generator/src/main/resources/skills.xml index a2bf3fd3..3b4774fb 100644 --- a/skills-generator/src/main/resources/skills.xml +++ b/skills-generator/src/main/resources/skills.xml @@ -590,4 +590,14 @@ target="assets/reports/804-nis2-engineering-review-report-template.md" /> + + + 806-regulations-eu-data-act-chapters-summary + 806-regulations-eu-data-act-engineering-examples + + + + + diff --git a/skills-generator/src/test/resources/gherkin/806-regulations-eu-data-act.feature b/skills-generator/src/test/resources/gherkin/806-regulations-eu-data-act.feature new file mode 100644 index 00000000..6b93ec23 --- /dev/null +++ b/skills-generator/src/test/resources/gherkin/806-regulations-eu-data-act.feature @@ -0,0 +1,64 @@ +Feature: Validate changes from usage of EU Data Act regulation skill + +Background: + Given the skill "806-regulations-eu-data-act" + +@acceptance-test +Scenario: Review a Java data-sharing service with EU Data Act controls + Given the system description file "examples/diagrams/deployment/system-example-cicd-pr-model.md" + And the deployment and delivery pipeline diagram file "examples/diagrams/deployment/expected-system-deployment.puml" + And the simulated feature request file "examples/diagrams/deployment/checkout-service-feature-request.md" + And the local generated skill path ".agents/skills/806-regulations-eu-data-act" + And the requested report output path is "examples/regulations/eu-data-act/DATA-ACT-ENGINEERING-REVIEW-REPORT.md" + And any existing report at the requested output path must be overwritten + And the folder "examples/regulations/eu-data-act" has no git changes + And the feature request is expected to be developed and released through the described CI/CD pipeline + And the EU Data Act review facts are based only on information present in "examples/diagrams/deployment/system-example-cicd-pr-model.md" and "examples/diagrams/deployment/checkout-service-feature-request.md" + When the skill ".agents/skills/806-regulations-eu-data-act" is applied to the system description, diagram, and feature request files + Then the skill reads "references/806-regulations-eu-data-act-chapters-summary.md" + And the skill reads "references/806-regulations-eu-data-act-engineering-examples.md" + And the skill reads "assets/reports/806-eu-data-act-engineering-review-report-template.md" + And the skill frames EU Data Act findings as engineering controls rather than legal advice + And review findings do not use facts outside "examples/diagrams/deployment/system-example-cicd-pr-model.md" and "examples/diagrams/deployment/checkout-service-feature-request.md" + And the skill scopes service context, possible connected-product or related-service signals, possible data holder signals, user and recipient role signals, data processing service or cloud-switching signals, system owners, data owners, privacy owners, security owners, cloud owners, environments, datasets, metadata, APIs, data stores, providers, dependencies, export paths, and switching pathways + And the skill escalates applicability, data holder status, user entitlement, data recipient roles, trade-secret decisions, contract interpretation, cloud-switching obligations, international access restrictions, and regulatory interpretation to legal, compliance, privacy, data governance, security, product, procurement, cloud, risk, provider, or business owners + And the skill reviews Java implementation, configuration, tests, API contracts, DTOs, serializers, schema registries, Kafka contracts, batch exports, object storage layouts, metadata catalogs, access-control rules, request workflows, audit logs, privacy controls, runbooks, cloud contracts, provider exit documentation, monitoring, and release evidence + And the skill identifies risk signals for missing data inventory, unclear role scope, missing owner handoff, weak access authorization, missing portability APIs, missing export format evidence, incomplete metadata, missing audit logs, unclear cloud-switching support, weak non-personal data safeguards, missing trade-secret or sensitive-data handoff, weak data-sharing request workflow, missing contract evidence, database migration, Kafka message contract, CI/CD pipeline, and production side-effect signals + And the skill maps potential EU Data Act violation or non-compliance signals to Data Act reference areas using only the reviewed delivery evidence + And every potential violation or non-compliance row includes an associated official-source link from "https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32023R2854" + And the skill analyzes the CheckoutService feature request as a pipeline-delivered change that adds delivery instruction data, modifies order database structure, and changes outbound Kafka event data + And the skill uses Java examples to explain data inventory, access authorization, portability APIs, export formats, interoperability, metadata, audit logs, cloud-switching support, non-personal data safeguards, trade-secret handoffs, data-sharing request workflows, contract evidence, and operational controls for data access requests + And the skill recommends engineering controls for data inventory, access authorization, request intake, user and recipient role evidence, purpose limitation, portability APIs, machine-readable export formats, metadata catalog entries, schema and event contract evidence, interoperability evidence, audit logs, evidence-safe logging, cloud-switching support, exportable data registers, secure transfer, erasure controls, non-personal data safeguards, mixed-dataset privacy handoff, trade-secret or sensitive-data handoff, contract evidence, complaint routing, database migration approval, Kafka schema compatibility, and release gates + And the skill reports conclusions and actions using the EU Data Act engineering review report template + And the skill overwrites the EU Data Act engineering review report at "examples/regulations/eu-data-act/DATA-ACT-ENGINEERING-REVIEW-REPORT.md" + And any git changes produced during skill execution and verification are reset + +@acceptance-test +Scenario: Review a Java data-sharing checkout change with direct-to-main EU Data Act controls + Given the system description file "examples/diagrams/deployment/system-example-cicd-model.md" + And the deployment and delivery pipeline diagram file "examples/diagrams/deployment/expected-system-deployment.puml" + And the simulated feature request file "examples/diagrams/deployment/checkout-service-feature-request.md" + And the local generated skill path ".agents/skills/806-regulations-eu-data-act" + And the requested report output path is "examples/regulations/eu-data-act/DATA-ACT-DIRECT-MAIN-ENGINEERING-REVIEW-REPORT.md" + And any existing report at the requested output path must be overwritten + And the folder "examples/regulations/eu-data-act" has no git changes + And the feature request is expected to be committed directly to main and released through the described CI/CD pipeline + And the EU Data Act review facts are based only on information present in "examples/diagrams/deployment/system-example-cicd-model.md" and "examples/diagrams/deployment/checkout-service-feature-request.md" + When the skill ".agents/skills/806-regulations-eu-data-act" is applied to the direct-to-main system description, diagram, and feature request files + Then the skill reads "references/806-regulations-eu-data-act-chapters-summary.md" + And the skill reads "references/806-regulations-eu-data-act-engineering-examples.md" + And the skill reads "assets/reports/806-eu-data-act-engineering-review-report-template.md" + And the skill frames EU Data Act findings as engineering controls rather than legal advice + And review findings do not use facts outside "examples/diagrams/deployment/system-example-cicd-model.md" and "examples/diagrams/deployment/checkout-service-feature-request.md" + And the skill scopes service context, possible connected-product or related-service signals, possible data holder signals, user and recipient role signals, data processing service or cloud-switching signals, system owners, data owners, privacy owners, security owners, cloud owners, environments, datasets, metadata, APIs, data stores, providers, dependencies, export paths, and switching pathways + And the skill escalates missing pre-merge review, protected-main bypass, applicability, data holder status, user entitlement, data recipient roles, trade-secret decisions, contract interpretation, cloud-switching obligations, international access restrictions, and regulatory interpretation to legal, compliance, privacy, data governance, security, product, procurement, cloud, platform, risk, provider, or business owners + And the skill reviews Java implementation, configuration, tests, API contracts, DTOs, serializers, schema registries, Kafka contracts, batch exports, object storage layouts, metadata catalogs, access-control rules, request workflows, audit logs, privacy controls, runbooks, cloud contracts, provider exit documentation, monitoring, and release evidence + And the skill identifies risk signals for missing data inventory, unclear role scope, missing owner handoff, weak access authorization, missing portability APIs, missing export format evidence, incomplete metadata, missing audit logs, unclear cloud-switching support, weak non-personal data safeguards, missing trade-secret or sensitive-data handoff, weak data-sharing request workflow, missing contract evidence, direct-to-main commit policy, database migration, Kafka message contract, CI/CD pipeline, and production side-effect signals + And the skill maps potential EU Data Act violation or non-compliance signals to Data Act reference areas using only the reviewed direct-to-main delivery evidence + And every potential violation or non-compliance row includes an associated official-source link from "https://eur-lex.europa.eu/legal-content/EN/TXT/HTML/?uri=CELEX:32023R2854" + And the skill analyzes the CheckoutService feature request as a direct-to-main pipeline-delivered change that adds delivery instruction data, modifies order database structure, and changes outbound Kafka event data + And the skill uses Java examples to explain direct-to-main release gates, data inventory, access authorization, portability APIs, export formats, interoperability, metadata, audit logs, cloud-switching support, non-personal data safeguards, trade-secret handoffs, data-sharing request workflows, contract evidence, and operational controls for data access requests + And the skill recommends engineering controls for pre-commit review, main-branch protection, data inventory, access authorization, request intake, user and recipient role evidence, purpose limitation, portability APIs, machine-readable export formats, metadata catalog entries, schema and event contract evidence, interoperability evidence, audit logs, evidence-safe logging, cloud-switching support, exportable data registers, secure transfer, erasure controls, non-personal data safeguards, mixed-dataset privacy handoff, trade-secret or sensitive-data handoff, contract evidence, complaint routing, database migration approval, Kafka schema compatibility, and release gates + And the skill reports conclusions and actions using the EU Data Act engineering review report template + And the skill overwrites the EU Data Act engineering review report at "examples/regulations/eu-data-act/DATA-ACT-DIRECT-MAIN-ENGINEERING-REVIEW-REPORT.md" + And any git changes produced during skill execution and verification are reset diff --git a/skills-generator/src/test/resources/gherkin/acceptance-tests-prompts-skills.md b/skills-generator/src/test/resources/gherkin/acceptance-tests-prompts-skills.md index 9ff785e3..44bd076d 100644 --- a/skills-generator/src/test/resources/gherkin/acceptance-tests-prompts-skills.md +++ b/skills-generator/src/test/resources/gherkin/acceptance-tests-prompts-skills.md @@ -69,3 +69,10 @@ and verify that acceptance-tests passes. execute @skills-generator/src/test/resources/gherkin/804-regulations-eu-nis2.feature and verify that acceptance-tests passes. ``` + +## 806-regulations-eu-data-act + +```bash +execute @skills-generator/src/test/resources/gherkin/806-regulations-eu-data-act.feature +and verify that acceptance-tests passes. +```