@grainulation/silo 1.0.0 → 1.0.1

package/packs/architecture-decision.json

@@ -0,0 +1,152 @@
+{
+  "name": "Architecture Decision (Enterprise)",
+  "description": "Extended enterprise ADR framework with governance, stakeholder alignment, and compliance integration. Builds on the base adr pack with enterprise-specific constraints for regulated environments.",
+  "version": "1.0.0",
+  "extends": "adr",
+  "claims": [
+    {
+      "id": "adec-001",
+      "type": "constraint",
+      "topic": "enterprise ADR governance",
+      "content": "Enterprise ADRs require approval chain: (1) Technical lead proposes and researches. (2) Architecture review board (ARB) reviews evidence quality. (3) Security and compliance sign off on regulated decisions. (4) VP/Director approves budget implications. Each approval is a claim in the sprint with 'documented' evidence tier.",
+      "source": {
+        "origin": "best-practice",
+        "artifact": null,
+        "connector": null
+      },
+      "evidence": "documented",
+      "status": "active",
+      "phase_added": "define",
+      "timestamp": "2026-03-21T00:00:00.000Z",
+      "conflicts_with": [],
+      "resolved_by": null,
+      "tags": ["adr", "enterprise", "governance", "approval-chain"]
+    },
+    {
+      "id": "adec-002",
+      "type": "constraint",
+      "topic": "compliance impact assessment",
+      "content": "Architecture decisions that affect data flow, storage, or access patterns must include a compliance impact assessment. For each option: (1) Does it change data residency? (2) Does it affect audit logging? (3) Does it require new BAAs or DPAs? (4) Does it change the attack surface?",
+      "source": {
+        "origin": "best-practice",
+        "artifact": null,
+        "connector": null
+      },
+      "evidence": "documented",
+      "status": "active",
+      "phase_added": "define",
+      "timestamp": "2026-03-21T00:00:00.000Z",
+      "conflicts_with": [],
+      "resolved_by": null,
+      "tags": ["adr", "compliance", "impact-assessment", "enterprise"]
+    },
+    {
+      "id": "adec-003",
+      "type": "constraint",
+      "topic": "cost analysis requirement",
+      "content": "Enterprise ADRs must include a cost analysis with estimate claims: (1) Implementation cost (engineering hours * loaded rate). (2) Operational cost (infrastructure, licensing, support). (3) Migration cost if changing from current state. (4) Opportunity cost of alternatives not chosen. All estimates must specify confidence range.",
+      "source": {
+        "origin": "best-practice",
+        "artifact": null,
+        "connector": null
+      },
+      "evidence": "documented",
+      "status": "active",
+      "phase_added": "define",
+      "timestamp": "2026-03-21T00:00:00.000Z",
+      "conflicts_with": [],
+      "resolved_by": null,
+      "tags": ["adr", "cost-analysis", "estimates", "enterprise"]
+    },
+    {
+      "id": "adec-004",
+      "type": "recommendation",
+      "topic": "stakeholder communication",
+      "content": "ADR output should have two formats: (1) Technical brief — full evidence, conflict resolution, detailed trade-offs for engineering. (2) Executive summary — decision, cost impact, timeline, and top 3 risks for leadership. The wheat /brief command should produce both from the same claims.",
+      "source": {
+        "origin": "best-practice",
+        "artifact": null,
+        "connector": null
+      },
+      "evidence": "stated",
+      "status": "active",
+      "phase_added": "define",
+      "timestamp": "2026-03-21T00:00:00.000Z",
+      "conflicts_with": [],
+      "resolved_by": null,
+      "tags": ["adr", "communication", "stakeholder", "enterprise"]
+    },
+    {
+      "id": "adec-005",
+      "type": "risk",
+      "topic": "decision fatigue",
+      "content": "Enterprise teams often over-ADR, creating decision records for trivial choices (which testing library, tab vs spaces). This wastes research time and creates ADR fatigue. Guideline: only create ADRs for decisions that are (1) hard to reverse, (2) affect multiple teams, or (3) have significant cost/risk implications.",
+      "source": {
+        "origin": "best-practice",
+        "artifact": null,
+        "connector": null
+      },
+      "evidence": "documented",
+      "status": "active",
+      "phase_added": "define",
+      "timestamp": "2026-03-21T00:00:00.000Z",
+      "conflicts_with": [],
+      "resolved_by": null,
+      "tags": ["adr", "decision-fatigue", "risk", "governance"]
+    },
+    {
+      "id": "adec-006",
+      "type": "factual",
+      "topic": "cross-team dependency mapping",
+      "content": "Architecture decisions in enterprise contexts frequently affect multiple teams. Before finalizing, map upstream and downstream dependencies: which teams consume or produce data/APIs affected by this decision? Each affected team should contribute at least one constraint or risk claim to the sprint.",
+      "source": {
+        "origin": "best-practice",
+        "artifact": null,
+        "connector": null
+      },
+      "evidence": "documented",
+      "status": "active",
+      "phase_added": "define",
+      "timestamp": "2026-03-21T00:00:00.000Z",
+      "conflicts_with": [],
+      "resolved_by": null,
+      "tags": ["adr", "dependencies", "cross-team", "enterprise"]
+    },
+    {
+      "id": "adec-007",
+      "type": "recommendation",
+      "topic": "ADR review cadence",
+      "content": "Schedule quarterly ADR reviews: (1) Are accepted ADRs still valid? (2) Have any assumptions changed? (3) Are deprecated ADRs properly linked to replacements? (4) Do new team members know where to find ADRs? Use the wheat graph to find ADRs with stale evidence or unresolved conflicts.",
+      "source": {
+        "origin": "best-practice",
+        "artifact": null,
+        "connector": null
+      },
+      "evidence": "stated",
+      "status": "active",
+      "phase_added": "define",
+      "timestamp": "2026-03-21T00:00:00.000Z",
+      "conflicts_with": [],
+      "resolved_by": null,
+      "tags": ["adr", "review-cadence", "maintenance", "enterprise"]
+    },
+    {
+      "id": "adec-008",
+      "type": "constraint",
+      "topic": "technology radar alignment",
+      "content": "Enterprise ADRs for technology choices should reference the organization's technology radar (adopt/trial/assess/hold). Proposing a 'hold' technology requires exceptional evidence. Moving a technology from 'assess' to 'adopt' should be backed by a prototype phase with 'tested' evidence tier.",
+      "source": {
+        "origin": "best-practice",
+        "artifact": "https://www.thoughtworks.com/radar",
+        "connector": null
+      },
+      "evidence": "documented",
+      "status": "active",
+      "phase_added": "define",
+      "timestamp": "2026-03-21T00:00:00.000Z",
+      "conflicts_with": [],
+      "resolved_by": null,
+      "tags": ["adr", "technology-radar", "enterprise", "governance"]
+    }
+  ]
+}

package/packs/architecture.json

@@ -8,7 +8,11 @@
       "type": "constraint",
       "topic": "microservices operational overhead",
       "content": "Microservices add operational overhead proportional to service count: each service needs its own CI/CD pipeline, monitoring, alerting, and on-call rotation. Below ~10 engineers, this cost often exceeds the benefit.",
-      "source": { "origin": "best-practice", "artifact": null, "connector": null },
+      "source": {
+        "origin": "best-practice",
+        "artifact": null,
+        "connector": null
+      },
       "evidence": "documented",
       "status": "active",
       "phase_added": "define",
@@ -22,7 +26,11 @@
       "type": "risk",
       "topic": "distributed transaction complexity",
       "content": "Distributed transactions across microservices require saga patterns or two-phase commit. Both add complexity and failure modes that don't exist in a monolith.",
-      "source": { "origin": "best-practice", "artifact": null, "connector": null },
+      "source": {
+        "origin": "best-practice",
+        "artifact": null,
+        "connector": null
+      },
       "evidence": "documented",
       "status": "active",
       "phase_added": "define",
@@ -36,7 +44,11 @@
       "type": "factual",
       "topic": "event-driven eventual consistency",
       "content": "Event-driven architectures decouple producers from consumers but introduce eventual consistency. Any user-facing flow that requires strong consistency must use synchronous calls or compensating transactions.",
-      "source": { "origin": "best-practice", "artifact": null, "connector": null },
+      "source": {
+        "origin": "best-practice",
+        "artifact": null,
+        "connector": null
+      },
       "evidence": "documented",
       "status": "active",
       "phase_added": "define",
@@ -50,7 +62,11 @@
       "type": "recommendation",
       "topic": "modular monolith first",
       "content": "Start with a modular monolith (clear module boundaries, separate data access per module) and extract services only when a module has a distinct scaling, deployment, or team-ownership need.",
-      "source": { "origin": "best-practice", "artifact": null, "connector": null },
+      "source": {
+        "origin": "best-practice",
+        "artifact": null,
+        "connector": null
+      },
       "evidence": "documented",
       "status": "active",
       "phase_added": "define",
@@ -78,7 +94,11 @@
       "type": "constraint",
       "topic": "SQL vs NoSQL decision criteria",
       "content": "SQL databases provide ACID transactions and are the correct default for structured data with relationships. NoSQL is justified when: (a) schema is truly unpredictable, (b) horizontal write scaling is required, or (c) access patterns are pure key-value.",
-      "source": { "origin": "best-practice", "artifact": null, "connector": null },
+      "source": {
+        "origin": "best-practice",
+        "artifact": null,
+        "connector": null
+      },
       "evidence": "documented",
       "status": "active",
       "phase_added": "define",
@@ -106,7 +126,11 @@
       "type": "risk",
       "topic": "shared database coupling",
       "content": "Shared databases between services create hidden coupling. Schema changes in one service break others. Each service should own its data store, exposing data only through APIs.",
-      "source": { "origin": "best-practice", "artifact": null, "connector": null },
+      "source": {
+        "origin": "best-practice",
+        "artifact": null,
+        "connector": null
+      },
       "evidence": "documented",
       "status": "active",
       "phase_added": "define",
@@ -134,7 +158,11 @@
       "type": "constraint",
       "topic": "per-client rate limiting",
       "content": "API gateway rate limiting must be set per client, not globally. Global limits allow a single misbehaving client to consume the entire quota. Use token bucket or sliding window algorithms.",
-      "source": { "origin": "best-practice", "artifact": null, "connector": null },
+      "source": {
+        "origin": "best-practice",
+        "artifact": null,
+        "connector": null
+      },
       "evidence": "documented",
       "status": "active",
       "phase_added": "define",
@@ -148,7 +176,11 @@
       "type": "recommendation",
       "topic": "circuit breaker pattern",
       "content": "Circuit breakers (open after N failures, half-open after timeout, close after success) prevent cascade failures. Every synchronous cross-service call should have a circuit breaker with configurable thresholds.",
-      "source": { "origin": "best-practice", "artifact": null, "connector": null },
+      "source": {
+        "origin": "best-practice",
+        "artifact": null,
+        "connector": null
+      },
       "evidence": "documented",
       "status": "active",
       "phase_added": "define",
@@ -162,7 +194,11 @@
       "type": "factual",
       "topic": "p99 latency over average",
       "content": "Latency at the 99th percentile (p99) matters more than average latency for user experience. A system with 50ms average but 2s p99 feels worse than one with 100ms average and 200ms p99.",
-      "source": { "origin": "best-practice", "artifact": null, "connector": null },
+      "source": {
+        "origin": "best-practice",
+        "artifact": null,
+        "connector": null
+      },
       "evidence": "documented",
       "status": "active",
       "phase_added": "define",

package/packs/ci-cd.json

@@ -8,7 +8,11 @@
       "type": "constraint",
       "topic": "pipeline time budget",
       "content": "CI pipelines should complete in under 10 minutes for the critical path (lint, test, build). Pipelines over 15 minutes measurably reduce PR throughput and encourage developers to batch changes, increasing merge conflict risk. Parallelize test suites and cache dependencies aggressively.",
-      "source": { "origin": "best-practice", "artifact": null, "connector": null },
+      "source": {
+        "origin": "best-practice",
+        "artifact": null,
+        "connector": null
+      },
       "evidence": "production",
       "status": "active",
       "phase_added": "define",
@@ -22,7 +26,11 @@
       "type": "factual",
       "topic": "blue-green deployment mechanics",
       "content": "Blue-green deployment maintains two identical production environments. Traffic routes to blue (current) while green receives the new version. After green passes health checks, traffic switches via load balancer. Rollback is instant (switch back to blue). Cost: 2x infrastructure during deployment window. Database migrations must be backwards-compatible since both versions share the database.",
-      "source": { "origin": "best-practice", "artifact": null, "connector": null },
+      "source": {
+        "origin": "best-practice",
+        "artifact": null,
+        "connector": null
+      },
       "evidence": "documented",
       "status": "active",
       "phase_added": "define",
@@ -36,7 +44,11 @@
       "type": "recommendation",
       "topic": "canary deployment percentage",
       "content": "Canary deployments should start at 1-5% of traffic, bake for 10-15 minutes while monitoring error rates and latency, then expand to 25%, 50%, 100% with automated rollback if error rate exceeds 1% above baseline or p99 latency increases by more than 50%. Full rollout should take 30-60 minutes minimum.",
-      "source": { "origin": "best-practice", "artifact": null, "connector": null },
+      "source": {
+        "origin": "best-practice",
+        "artifact": null,
+        "connector": null
+      },
       "evidence": "production",
       "status": "active",
       "phase_added": "define",
@@ -50,7 +62,11 @@
       "type": "risk",
       "topic": "database migration coupling",
       "content": "Deploying application code and database migrations simultaneously causes failures if the migration is slow or fails mid-deploy. Decouple migrations: deploy migration first (must be backwards-compatible with current code), verify, then deploy application code. Use expand-and-contract pattern for schema changes.",
-      "source": { "origin": "best-practice", "artifact": null, "connector": null },
+      "source": {
+        "origin": "best-practice",
+        "artifact": null,
+        "connector": null
+      },
       "evidence": "production",
       "status": "active",
       "phase_added": "define",
@@ -64,7 +80,11 @@
       "type": "recommendation",
       "topic": "feature flag lifecycle",
       "content": "Feature flags should have an owner, a creation date, and a planned removal date. Flags older than 90 days without removal should trigger a tech debt alert. Stale feature flags accumulate as dead code paths and make testing combinatorially complex. Use a flag management service (LaunchDarkly, Unleash, or custom) rather than config files.",
-      "source": { "origin": "best-practice", "artifact": null, "connector": null },
+      "source": {
+        "origin": "best-practice",
+        "artifact": null,
+        "connector": null
+      },
       "evidence": "documented",
       "status": "active",
       "phase_added": "define",
@@ -78,7 +98,11 @@
       "type": "constraint",
       "topic": "immutable build artifacts",
       "content": "Build artifacts must be immutable: the exact same artifact (Docker image, binary, package) that passes CI is the one deployed to staging and production. Never rebuild for different environments. Use environment variables or config injection for environment-specific settings. Tag artifacts with git SHA for traceability.",
-      "source": { "origin": "best-practice", "artifact": null, "connector": null },
+      "source": {
+        "origin": "best-practice",
+        "artifact": null,
+        "connector": null
+      },
       "evidence": "documented",
       "status": "active",
       "phase_added": "define",
@@ -92,7 +116,11 @@
       "type": "risk",
       "topic": "rollback without data rollback",
       "content": "Code rollbacks do not roll back data. If version N+1 wrote data in a new format, rolling back to version N may leave incompatible data in the database. Design writes to be forward-compatible: version N should tolerate data written by N+1. This constraint makes additive-only schema changes critical.",
-      "source": { "origin": "best-practice", "artifact": null, "connector": null },
+      "source": {
+        "origin": "best-practice",
+        "artifact": null,
+        "connector": null
+      },
       "evidence": "production",
       "status": "active",
       "phase_added": "define",
@@ -120,7 +148,11 @@
       "type": "recommendation",
       "topic": "trunk-based development",
       "content": "Trunk-based development (short-lived branches merged to main within 1-2 days) correlates with higher DORA metrics than Gitflow. Long-lived feature branches (over 3 days) have exponentially higher merge conflict probability. Use feature flags instead of feature branches for incomplete work.",
-      "source": { "origin": "best-practice", "artifact": null, "connector": null },
+      "source": {
+        "origin": "best-practice",
+        "artifact": null,
+        "connector": null
+      },
       "evidence": "documented",
       "status": "active",
       "phase_added": "define",
@@ -134,7 +166,11 @@
       "type": "recommendation",
       "topic": "test pyramid enforcement",
       "content": "Enforce the test pyramid in CI: 70% unit tests (fast, isolated), 20% integration tests (database, APIs), 10% end-to-end tests (browser, full stack). Inverted pyramids (heavy E2E, few unit tests) result in slow, flaky pipelines. Quarantine flaky tests immediately rather than retrying them.",
-      "source": { "origin": "best-practice", "artifact": null, "connector": null },
+      "source": {
+        "origin": "best-practice",
+        "artifact": null,
+        "connector": null
+      },
       "evidence": "documented",
       "status": "active",
       "phase_added": "define",
@@ -148,7 +184,11 @@
       "type": "risk",
       "topic": "secret exposure in CI logs",
       "content": "CI systems frequently leak secrets in build logs through debug output, error messages, or environment variable dumps. Use secret masking features in your CI platform. Never pass secrets as command-line arguments (visible in process listings). Audit CI logs quarterly for accidental secret exposure.",
-      "source": { "origin": "best-practice", "artifact": null, "connector": null },
+      "source": {
+        "origin": "best-practice",
+        "artifact": null,
+        "connector": null
+      },
       "evidence": "production",
       "status": "active",
       "phase_added": "define",
@@ -172,4 +212,4 @@
       "tags": ["ci-cd", "deploy-frequency", "mttr", "reliability"]
     }
   ]
-}
+}

package/packs/compliance.json

@@ -8,7 +8,11 @@
       "type": "constraint",
       "topic": "HIPAA encryption at rest",
       "content": "Protected Health Information (PHI) must be encrypted at rest using AES-256 or equivalent, per HIPAA Security Rule 45 CFR 164.312(a)(2)(iv).",
-      "source": { "origin": "regulation", "artifact": "45 CFR 164.312", "connector": null },
+      "source": {
+        "origin": "regulation",
+        "artifact": "45 CFR 164.312",
+        "connector": null
+      },
       "evidence": "documented",
       "status": "active",
       "phase_added": "define",
@@ -22,7 +26,11 @@
       "type": "constraint",
       "topic": "HIPAA encryption in transit",
       "content": "PHI in transit must be encrypted via TLS 1.2 or higher. Unencrypted transmission channels (HTTP, FTP) are prohibited for PHI.",
-      "source": { "origin": "regulation", "artifact": "45 CFR 164.312(e)(1)", "connector": null },
+      "source": {
+        "origin": "regulation",
+        "artifact": "45 CFR 164.312(e)(1)",
+        "connector": null
+      },
       "evidence": "documented",
       "status": "active",
       "phase_added": "define",
@@ -36,7 +44,11 @@
       "type": "constraint",
       "topic": "HIPAA business associate agreements",
       "content": "A Business Associate Agreement (BAA) must be signed with every third-party vendor that processes, stores, or transmits PHI, including cloud providers.",
-      "source": { "origin": "regulation", "artifact": "45 CFR 164.502(e)", "connector": null },
+      "source": {
+        "origin": "regulation",
+        "artifact": "45 CFR 164.502(e)",
+        "connector": null
+      },
       "evidence": "documented",
       "status": "active",
       "phase_added": "define",
@@ -50,7 +62,11 @@
       "type": "constraint",
       "topic": "HIPAA minimum necessary access",
       "content": "Access to PHI must follow minimum necessary standard — users see only the data required for their role. Role-based access control (RBAC) is the typical implementation.",
-      "source": { "origin": "regulation", "artifact": "45 CFR 164.502(b)", "connector": null },
+      "source": {
+        "origin": "regulation",
+        "artifact": "45 CFR 164.502(b)",
+        "connector": null
+      },
       "evidence": "documented",
       "status": "active",
       "phase_added": "define",
@@ -64,7 +80,11 @@
       "type": "constraint",
       "topic": "HIPAA audit log retention",
       "content": "Audit logs of all PHI access events must be retained for a minimum of 6 years. Logs must include user identity, timestamp, and action performed.",
-      "source": { "origin": "regulation", "artifact": "45 CFR 164.312(b)", "connector": null },
+      "source": {
+        "origin": "regulation",
+        "artifact": "45 CFR 164.312(b)",
+        "connector": null
+      },
       "evidence": "documented",
       "status": "active",
       "phase_added": "define",
@@ -78,7 +98,11 @@
       "type": "constraint",
       "topic": "SOC 2 Type II observation period",
       "content": "SOC 2 Type II requires demonstrating that security controls operated effectively over a minimum observation period of 6 months (typically 12 months).",
-      "source": { "origin": "standard", "artifact": "AICPA Trust Services Criteria", "connector": null },
+      "source": {
+        "origin": "standard",
+        "artifact": "AICPA Trust Services Criteria",
+        "connector": null
+      },
       "evidence": "documented",
       "status": "active",
       "phase_added": "define",
@@ -92,7 +116,11 @@
       "type": "constraint",
       "topic": "SOC 2 change management",
       "content": "Change management controls must track all production changes with approval records, rollback plans, and post-deployment verification.",
-      "source": { "origin": "standard", "artifact": "AICPA CC8.1", "connector": null },
+      "source": {
+        "origin": "standard",
+        "artifact": "AICPA CC8.1",
+        "connector": null
+      },
       "evidence": "documented",
       "status": "active",
       "phase_added": "define",
@@ -106,7 +134,11 @@
       "type": "constraint",
       "topic": "SOC 2 incident response",
       "content": "Incident response plan must define severity levels, escalation paths, communication templates, and post-incident review process. Annual tabletop exercises required.",
-      "source": { "origin": "standard", "artifact": "AICPA CC7.3-CC7.5", "connector": null },
+      "source": {
+        "origin": "standard",
+        "artifact": "AICPA CC7.3-CC7.5",
+        "connector": null
+      },
       "evidence": "documented",
       "status": "active",
       "phase_added": "define",
@@ -120,7 +152,11 @@
       "type": "constraint",
       "topic": "SOC 2 access reviews",
       "content": "Logical access reviews must be performed quarterly. Terminated employee access must be revoked within 24 hours of separation.",
-      "source": { "origin": "standard", "artifact": "AICPA CC6.1-CC6.3", "connector": null },
+      "source": {
+        "origin": "standard",
+        "artifact": "AICPA CC6.1-CC6.3",
+        "connector": null
+      },
       "evidence": "documented",
       "status": "active",
       "phase_added": "define",
@@ -134,7 +170,11 @@
       "type": "constraint",
       "topic": "GDPR cross-border data transfer",
       "content": "Personal data of EU residents cannot be transferred outside the EEA without an adequacy decision, Standard Contractual Clauses (SCCs), or Binding Corporate Rules.",
-      "source": { "origin": "regulation", "artifact": "GDPR Articles 44-49", "connector": null },
+      "source": {
+        "origin": "regulation",
+        "artifact": "GDPR Articles 44-49",
+        "connector": null
+      },
       "evidence": "documented",
       "status": "active",
       "phase_added": "define",
@@ -148,7 +188,11 @@
       "type": "constraint",
       "topic": "GDPR right to erasure",
       "content": "Data subjects have the right to erasure ('right to be forgotten'). Systems must support complete deletion of a user's personal data within 30 days of request.",
-      "source": { "origin": "regulation", "artifact": "GDPR Article 17", "connector": null },
+      "source": {
+        "origin": "regulation",
+        "artifact": "GDPR Article 17",
+        "connector": null
+      },
       "evidence": "documented",
       "status": "active",
       "phase_added": "define",
@@ -162,7 +206,11 @@
       "type": "constraint",
       "topic": "GDPR breach notification",
       "content": "Data breaches affecting personal data must be reported to the supervisory authority within 72 hours of discovery. Affected individuals must be notified without undue delay if risk is high.",
-      "source": { "origin": "regulation", "artifact": "GDPR Articles 33-34", "connector": null },
+      "source": {
+        "origin": "regulation",
+        "artifact": "GDPR Articles 33-34",
+        "connector": null
+      },
       "evidence": "documented",
       "status": "active",
       "phase_added": "define",
@@ -176,7 +224,11 @@
       "type": "constraint",
       "topic": "GDPR lawful basis for processing",
       "content": "Processing personal data requires a lawful basis (consent, contract, legal obligation, vital interest, public task, or legitimate interest). Consent must be freely given, specific, and withdrawable.",
-      "source": { "origin": "regulation", "artifact": "GDPR Article 6", "connector": null },
+      "source": {
+        "origin": "regulation",
+        "artifact": "GDPR Article 6",
+        "connector": null
+      },
       "evidence": "documented",
       "status": "active",
       "phase_added": "define",
@@ -190,7 +242,11 @@
       "type": "constraint",
       "topic": "GDPR data protection impact assessment",
       "content": "A Data Protection Impact Assessment (DPIA) is mandatory before processing that is likely to result in high risk to individuals, including large-scale profiling or systematic monitoring.",
-      "source": { "origin": "regulation", "artifact": "GDPR Article 35", "connector": null },
+      "source": {
+        "origin": "regulation",
+        "artifact": "GDPR Article 35",
+        "connector": null
+      },
       "evidence": "documented",
       "status": "active",
       "phase_added": "define",