@grainulation/silo 1.0.0 → 1.0.1

package/packs/security.json

@@ -8,7 +8,11 @@
       "type": "constraint",
       "topic": "SQL injection prevention",
       "content": "All database queries must use parameterized statements or prepared queries. String concatenation for SQL is never acceptable, even for internal tools. ORMs provide this by default but raw queries must be audited. OWASP ranks injection as A03:2021.",
-      "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": "constraint",
       "topic": "secrets never in source control",
       "content": "Secrets (API keys, database credentials, signing keys) must never appear in source control, including in commit history. Use environment variables, secret managers (Vault, AWS Secrets Manager, 1Password CLI), or encrypted .env files with .gitignore. Rotate any secret that has ever been committed.",
-      "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": "JWT access token lifetime",
       "content": "JWT access tokens should have a lifetime of 5-15 minutes. Refresh tokens should be opaque (not JWT), stored server-side, rotated on each use, and have a maximum lifetime of 7-30 days. Never store JWTs in localStorage; use httpOnly secure cookies or in-memory storage.",
-      "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": "risk",
       "topic": "dependency supply chain attacks",
       "content": "npm, PyPI, and other registries are vectors for supply chain attacks (typosquatting, maintainer account takeover, malicious postinstall scripts). Pin exact dependency versions, use lockfiles, audit with npm audit / pip-audit, and consider running install with --ignore-scripts in CI.",
-      "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": "factual",
       "topic": "bcrypt cost factor",
       "content": "bcrypt with a cost factor of 10 takes approximately 100ms to hash on modern hardware. Increase to 12 (roughly 400ms) for high-security contexts. Argon2id is the current OWASP recommendation for new projects, with minimum parameters: 19 MiB memory, 2 iterations, 1 parallelism.",
-      "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": "CORS allowlist",
       "content": "CORS Access-Control-Allow-Origin must never be set to * for authenticated endpoints. Maintain an explicit allowlist of permitted origins. Reflect the Origin header only if it matches the allowlist. Misconfigured CORS is OWASP A01:2021 (Broken Access Control).",
-      "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": "recommendation",
       "topic": "CSP header configuration",
       "content": "Content-Security-Policy should start strict and loosen as needed: default-src 'self'; script-src 'self'; style-src 'self'; img-src 'self' data:; connect-src 'self'; frame-ancestors 'none'. Avoid 'unsafe-inline' and 'unsafe-eval'. Use nonces for inline scripts if unavoidable. Report violations with report-uri or report-to.",
-      "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 +134,11 @@
       "type": "risk",
       "topic": "SSRF in internal services",
       "content": "Server-Side Request Forgery (SSRF) allows attackers to make requests from your server to internal networks, cloud metadata endpoints (169.254.169.254), or localhost services. Validate and allowlist all URLs that originate from user input. Block requests to private IP ranges and link-local addresses.",
-      "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 +152,11 @@
       "type": "recommendation",
       "topic": "rate limiting auth endpoints",
       "content": "Login endpoints must be rate-limited to no more than 10 attempts per IP per minute and 5 attempts per account per minute. After 5 consecutive failures for an account, enforce exponential backoff or temporary lockout (15-30 minutes). Log all failed attempts with IP and timestamp for anomaly detection.",
-      "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 +170,11 @@
       "type": "factual",
       "topic": "HTTPS and HSTS requirements",
       "content": "All production traffic must use TLS 1.2 or higher. TLS 1.0 and 1.1 are deprecated (RFC 8996). Set Strict-Transport-Security header with max-age of at least 31536000 (1 year) and includeSubDomains. Submit to the HSTS preload list for public-facing domains.",
-      "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 +188,11 @@
       "type": "risk",
       "topic": "insecure deserialization",
       "content": "Never deserialize untrusted data with language-native serialization (Java ObjectInputStream, Python pickle, PHP unserialize). These allow arbitrary code execution. Use JSON or Protocol Buffers with schema validation instead. OWASP A08:2021 (Software and Data Integrity Failures).",
-      "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 +206,11 @@
       "type": "recommendation",
       "topic": "least privilege for service accounts",
       "content": "Service accounts and IAM roles must follow least privilege: grant only the specific actions on the specific resources needed. Audit permissions quarterly. AWS policies should never use Resource: * with Action: *. Use IAM Access Analyzer to identify unused permissions.",
-      "source": { "origin": "best-practice", "artifact": null, "connector": null },
+      "source": {
+        "origin": "best-practice",
+        "artifact": null,
+        "connector": null
+      },
       "evidence": "documented",
       "status": "active",
       "phase_added": "define",
@@ -172,4 +220,4 @@
       "tags": ["security", "iam", "least-privilege", "cloud"]
     }
   ]
-}
+}

package/packs/team-process.json

@@ -8,14 +8,23 @@
       "type": "constraint",
       "topic": "code review turnaround time",
       "content": "Code reviews should receive first-pass feedback within 4 business hours. Reviews taking longer than 24 hours are the top-cited blocker for developer productivity (Google Developer Survey 2023). Set team norms: reviews under 400 lines get same-day response, larger PRs should be split or paired on.",
-      "source": { "origin": "best-practice", "artifact": null, "connector": null },
+      "source": {
+        "origin": "best-practice",
+        "artifact": null,
+        "connector": null
+      },
       "evidence": "documented",
       "status": "active",
       "phase_added": "define",
       "timestamp": "2025-01-01T00:00:00.000Z",
       "conflicts_with": [],
       "resolved_by": null,
-      "tags": ["team-process", "code-review", "developer-experience", "productivity"]
+      "tags": [
+        "team-process",
+        "code-review",
+        "developer-experience",
+        "productivity"
+      ]
     },
     {
       "id": "team-002",
@@ -36,7 +45,11 @@
       "type": "recommendation",
       "topic": "on-call rotation design",
       "content": "On-call rotations should be 1 week per engineer, with a minimum of 6 people in the rotation (no more than 1 week in 6 on primary). Provide a secondary on-call who shadows. Compensate on-call with either extra pay (10-15% of base for the week) or time off (1 day per week on-call). On-call without compensation breeds resentment and attrition.",
-      "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 +63,11 @@
       "type": "recommendation",
       "topic": "RFC process for decisions",
       "content": "Use RFCs (Request for Comments) for decisions that are: cross-team, hard to reverse, or affect more than 3 people. RFC template: Context (why now), Proposal (what), Alternatives considered (at least 2), Tradeoffs, Migration plan. Set a review period of 5 business days. Silence is not consent; require explicit approvals from stakeholders. Archive accepted RFCs as ADRs.",
-      "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 +95,11 @@
       "type": "factual",
       "topic": "estimation accuracy ranges",
       "content": "Software estimation accuracy follows the Cone of Uncertainty: at project inception, estimates are 0.25x-4x actual. After requirements, 0.5x-2x. After detailed design, 0.67x-1.5x. After code complete, 0.9x-1.1x. Communicate estimates as ranges, never single points. Use relative sizing (story points) for prioritization and historical velocity for date forecasting.",
-      "source": { "origin": "best-practice", "artifact": null, "connector": null },
+      "source": {
+        "origin": "best-practice",
+        "artifact": null,
+        "connector": null
+      },
       "evidence": "documented",
       "status": "active",
       "phase_added": "define",
@@ -92,21 +113,34 @@
       "type": "recommendation",
       "topic": "postmortem action item tracking",
       "content": "Postmortem action items must have: a single owner (not a team), a due date within 30 days, and a tracking ticket. Review incomplete action items at the start of every postmortem meeting. Teams that do not track action items to completion repeat the same incidents. 60% of incidents are caused by previously identified but unresolved issues.",
-      "source": { "origin": "best-practice", "artifact": null, "connector": null },
+      "source": {
+        "origin": "best-practice",
+        "artifact": null,
+        "connector": null
+      },
       "evidence": "production",
       "status": "active",
       "phase_added": "define",
       "timestamp": "2025-01-01T00:00:00.000Z",
       "conflicts_with": [],
       "resolved_by": null,
-      "tags": ["team-process", "postmortem", "incident-response", "accountability"]
+      "tags": [
+        "team-process",
+        "postmortem",
+        "incident-response",
+        "accountability"
+      ]
     },
     {
       "id": "team-008",
       "type": "constraint",
       "topic": "meeting hygiene for engineers",
       "content": "Protect maker time: engineers need 4-hour uninterrupted blocks for complex work. Meeting-free mornings or meeting-free days (e.g., no meetings on Tuesday/Thursday) measurably increase output. Context-switching between meetings costs 15-25 minutes of recovery time per switch. Batch meetings into afternoon blocks.",
-      "source": { "origin": "best-practice", "artifact": null, "connector": null },
+      "source": {
+        "origin": "best-practice",
+        "artifact": null,
+        "connector": null
+      },
       "evidence": "web",
       "status": "active",
       "phase_added": "define",
@@ -120,7 +154,11 @@
       "type": "recommendation",
       "topic": "runbook-driven operations",
       "content": "Every alert and recurring operational task should have a runbook: what the alert means, how to diagnose, step-by-step remediation, escalation criteria, and who to contact. Runbooks reduce MTTR by 40-60% for on-call engineers encountering unfamiliar alerts. Store runbooks alongside alert definitions, linked by alert name. Review and update runbooks after every incident.",
-      "source": { "origin": "best-practice", "artifact": null, "connector": null },
+      "source": {
+        "origin": "best-practice",
+        "artifact": null,
+        "connector": null
+      },
       "evidence": "production",
       "status": "active",
       "phase_added": "define",
@@ -134,7 +172,11 @@
       "type": "risk",
       "topic": "bus factor for critical systems",
       "content": "Bus factor (number of people who could be hit by a bus before the project stalls) of 1 is a critical risk. Mitigate with: pair programming or rotation on critical systems, mandatory documentation for system architecture and runbooks, cross-training sessions quarterly, and code review requirements that expose at least 2 people to every area of the codebase.",
-      "source": { "origin": "best-practice", "artifact": null, "connector": null },
+      "source": {
+        "origin": "best-practice",
+        "artifact": null,
+        "connector": null
+      },
       "evidence": "documented",
       "status": "active",
       "phase_added": "define",
@@ -162,14 +204,23 @@
       "type": "recommendation",
       "topic": "retrospective action limits",
       "content": "Limit retrospective action items to 2-3 per sprint. Teams that generate 8-10 action items per retro complete fewer than 20% of them, creating learned helplessness. Pick the highest-impact items, assign owners, and carry forward only incomplete items from the previous retro. If the same item appears 3 retros in a row, escalate it.",
-      "source": { "origin": "best-practice", "artifact": null, "connector": null },
+      "source": {
+        "origin": "best-practice",
+        "artifact": null,
+        "connector": null
+      },
       "evidence": "documented",
       "status": "active",
       "phase_added": "define",
       "timestamp": "2025-01-01T00:00:00.000Z",
       "conflicts_with": [],
       "resolved_by": null,
-      "tags": ["team-process", "retrospective", "agile", "continuous-improvement"]
+      "tags": [
+        "team-process",
+        "retrospective",
+        "agile",
+        "continuous-improvement"
+      ]
     }
   ]
-}
+}

package/packs/testing.json

@@ -8,7 +8,11 @@
       "type": "constraint",
       "topic": "test framework",
       "content": "All tests must use node:test and node:assert/strict with zero external dependencies. No Jest, Mocha, Vitest, or other frameworks.",
-      "source": { "origin": "architecture", "artifact": null, "connector": null },
+      "source": {
+        "origin": "architecture",
+        "artifact": null,
+        "connector": null
+      },
       "evidence": "documented",
       "status": "active",
       "phase_added": "define",
@@ -22,7 +26,11 @@
       "type": "constraint",
       "topic": "test isolation",
       "content": "Tests must use real filesystem (mkdtempSync), real processes (child_process.spawn), and real HTTP. No mocks, no spies, no test doubles.",
-      "source": { "origin": "architecture", "artifact": null, "connector": null },
+      "source": {
+        "origin": "architecture",
+        "artifact": null,
+        "connector": null
+      },
       "evidence": "documented",
       "status": "active",
       "phase_added": "define",
@@ -78,7 +86,11 @@
       "type": "constraint",
       "topic": "CI matrix",
       "content": "CI must test on Node 18, 20, and 22. Every CI run verifies zero runtime dependencies, runs all tests, checks CLI --help, and performs a dry-run npm publish.",
-      "source": { "origin": "architecture", "artifact": ".github/workflows/ci.yml", "connector": null },
+      "source": {
+        "origin": "architecture",
+        "artifact": ".github/workflows/ci.yml",
+        "connector": null
+      },
       "evidence": "documented",
       "status": "active",
       "phase_added": "define",
@@ -92,7 +104,11 @@
       "type": "factual",
       "topic": "test coverage baseline",
       "content": "Baseline: 191 tests across 5 repos (wheat 25, barn 58, mill 30, silo 21, ranch 44). After adding server, UI smoke, and cross-tool tests: ~260 tests total.",
-      "source": { "origin": "measurement", "artifact": null, "connector": null },
+      "source": {
+        "origin": "measurement",
+        "artifact": null,
+        "connector": null
+      },
       "evidence": "tested",
       "status": "active",
       "phase_added": "research",

package/packs/vendor-eval.json

@@ -0,0 +1,219 @@
+{
+  "name": "Vendor Evaluation Framework",
+  "description": "Enterprise due diligence framework for evaluating vendors and third-party tools. Covers security posture, compliance, pricing, integration, and operational risk. Drop into any vendor assessment sprint.",
+  "version": "1.0.0",
+  "claims": [
+    {
+      "id": "vend-001",
+      "type": "constraint",
+      "topic": "security posture assessment",
+      "content": "Vendor must hold SOC 2 Type II certification with a clean audit report from the most recent period. Request the full report, not just the bridge letter. If no SOC 2, require ISO 27001 or equivalent third-party security attestation.",
+      "source": {
+        "origin": "best-practice",
+        "artifact": "AICPA Trust Services Criteria",
+        "connector": null
+      },
+      "evidence": "documented",
+      "status": "active",
+      "phase_added": "define",
+      "timestamp": "2026-01-01T00:00:00.000Z",
+      "conflicts_with": [],
+      "resolved_by": null,
+      "tags": ["vendor", "security", "soc2", "due-diligence"]
+    },
+    {
+      "id": "vend-002",
+      "type": "constraint",
+      "topic": "data residency and sovereignty",
+      "content": "Vendor must disclose all data processing locations. For EU customers: data must reside in EEA or be covered by Standard Contractual Clauses. For regulated industries: verify no data leaves approved jurisdictions.",
+      "source": {
+        "origin": "regulation",
+        "artifact": "GDPR Articles 44-49",
+        "connector": null
+      },
+      "evidence": "documented",
+      "status": "active",
+      "phase_added": "define",
+      "timestamp": "2026-01-01T00:00:00.000Z",
+      "conflicts_with": [],
+      "resolved_by": null,
+      "tags": ["vendor", "data-residency", "gdpr", "sovereignty"]
+    },
+    {
+      "id": "vend-003",
+      "type": "constraint",
+      "topic": "SSO and identity integration",
+      "content": "Vendor must support SAML 2.0 or OIDC for SSO. SCIM provisioning required for teams > 50 users. Verify: does SSO work with your IdP (Okta, Azure AD, Google Workspace)? Test before signing.",
+      "source": {
+        "origin": "best-practice",
+        "artifact": null,
+        "connector": null
+      },
+      "evidence": "documented",
+      "status": "active",
+      "phase_added": "define",
+      "timestamp": "2026-01-01T00:00:00.000Z",
+      "conflicts_with": [],
+      "resolved_by": null,
+      "tags": ["vendor", "sso", "identity", "integration"]
+    },
+    {
+      "id": "vend-004",
+      "type": "risk",
+      "topic": "vendor lock-in assessment",
+      "content": "Evaluate data export capabilities before signing. Key questions: (1) Can you export all your data in standard formats? (2) What's the export process and timeline? (3) Is there an API for continuous data extraction? (4) What happens to your data after contract termination?",
+      "source": {
+        "origin": "best-practice",
+        "artifact": null,
+        "connector": null
+      },
+      "evidence": "documented",
+      "status": "active",
+      "phase_added": "define",
+      "timestamp": "2026-01-01T00:00:00.000Z",
+      "conflicts_with": [],
+      "resolved_by": null,
+      "tags": ["vendor", "lock-in", "data-portability", "risk"]
+    },
+    {
+      "id": "vend-005",
+      "type": "constraint",
+      "topic": "pricing model analysis",
+      "content": "Analyze total cost of ownership: base license + per-seat + overage + implementation + training + integration. Get pricing in writing for current headcount AND 2x growth. Negotiate multi-year for 20-40% discount. Compare against at least 2 alternatives.",
+      "source": {
+        "origin": "best-practice",
+        "artifact": null,
+        "connector": null
+      },
+      "evidence": "documented",
+      "status": "active",
+      "phase_added": "define",
+      "timestamp": "2026-01-01T00:00:00.000Z",
+      "conflicts_with": [],
+      "resolved_by": null,
+      "tags": ["vendor", "pricing", "tco", "negotiation"]
+    },
+    {
+      "id": "vend-006",
+      "type": "risk",
+      "topic": "vendor financial viability",
+      "content": "Assess vendor financial health: funding stage, runway, revenue trajectory, customer count. For startups: what happens if they shut down? For public companies: check last 2 quarterly earnings. A vendor going bankrupt mid-contract is an operational risk.",
+      "source": {
+        "origin": "best-practice",
+        "artifact": null,
+        "connector": null
+      },
+      "evidence": "documented",
+      "status": "active",
+      "phase_added": "define",
+      "timestamp": "2026-01-01T00:00:00.000Z",
+      "conflicts_with": [],
+      "resolved_by": null,
+      "tags": ["vendor", "financial", "viability", "risk"]
+    },
+    {
+      "id": "vend-007",
+      "type": "constraint",
+      "topic": "SLA and support requirements",
+      "content": "Define minimum SLA: uptime guarantee (99.9% = 8.76h downtime/year), response times by severity (P1: 15min, P2: 1h, P3: 4h, P4: 24h), communication channels, escalation path, and financial penalties for SLA breach.",
+      "source": {
+        "origin": "best-practice",
+        "artifact": null,
+        "connector": null
+      },
+      "evidence": "documented",
+      "status": "active",
+      "phase_added": "define",
+      "timestamp": "2026-01-01T00:00:00.000Z",
+      "conflicts_with": [],
+      "resolved_by": null,
+      "tags": ["vendor", "sla", "support", "uptime"]
+    },
+    {
+      "id": "vend-008",
+      "type": "constraint",
+      "topic": "API and integration capabilities",
+      "content": "Vendor must provide a documented REST or GraphQL API with: versioning policy, rate limits, webhook support, and sandbox/staging environment. SDKs for your primary languages are a strong positive signal.",
+      "source": {
+        "origin": "best-practice",
+        "artifact": null,
+        "connector": null
+      },
+      "evidence": "documented",
+      "status": "active",
+      "phase_added": "define",
+      "timestamp": "2026-01-01T00:00:00.000Z",
+      "conflicts_with": [],
+      "resolved_by": null,
+      "tags": ["vendor", "api", "integration", "developer-experience"]
+    },
+    {
+      "id": "vend-009",
+      "type": "risk",
+      "topic": "subprocessor chain risk",
+      "content": "Vendor's subprocessors inherit your data risk. Request the full subprocessor list. Evaluate: (1) How many subprocessors? (2) What data does each access? (3) Are they SOC 2 compliant? (4) Does the vendor notify you of subprocessor changes?",
+      "source": {
+        "origin": "regulation",
+        "artifact": "GDPR Article 28",
+        "connector": null
+      },
+      "evidence": "documented",
+      "status": "active",
+      "phase_added": "define",
+      "timestamp": "2026-01-01T00:00:00.000Z",
+      "conflicts_with": [],
+      "resolved_by": null,
+      "tags": ["vendor", "subprocessors", "supply-chain", "gdpr"]
+    },
+    {
+      "id": "vend-010",
+      "type": "recommendation",
+      "topic": "vendor evaluation process",
+      "content": "Structured evaluation process: (1) Define requirements as constraints before evaluating. (2) Score each vendor against constraints independently. (3) Run a proof-of-concept with top 2 candidates. (4) Check references — talk to customers at similar scale. (5) Negotiate contract with clear exit clauses.",
+      "source": {
+        "origin": "best-practice",
+        "artifact": null,
+        "connector": null
+      },
+      "evidence": "documented",
+      "status": "active",
+      "phase_added": "define",
+      "timestamp": "2026-01-01T00:00:00.000Z",
+      "conflicts_with": [],
+      "resolved_by": null,
+      "tags": ["vendor", "process", "evaluation", "recommendation"]
+    },
+    {
+      "id": "vend-011",
+      "type": "factual",
+      "topic": "vendor due diligence timeline",
+      "content": "Enterprise vendor due diligence averages 45 days for onboarding. Security questionnaires take days to weeks (400+ questions common). Legal review cycles run 8-12 weeks without pre-prepared documentation. Compressed timelines are possible when vendors provide complete compliance documentation upfront.",
+      "source": { "origin": "research", "artifact": null, "connector": null },
+      "evidence": "web",
+      "status": "active",
+      "phase_added": "research",
+      "timestamp": "2026-01-01T00:00:00.000Z",
+      "conflicts_with": [],
+      "resolved_by": null,
+      "tags": ["vendor", "timeline", "due-diligence", "enterprise"]
+    },
+    {
+      "id": "vend-012",
+      "type": "constraint",
+      "topic": "IP indemnification",
+      "content": "For AI/ML vendors: require IP indemnification clause covering generated output. Verify: does the vendor indemnify against IP claims from training data? GitHub Copilot Enterprise includes this; many competitors do not.",
+      "source": {
+        "origin": "best-practice",
+        "artifact": null,
+        "connector": null
+      },
+      "evidence": "web",
+      "status": "active",
+      "phase_added": "define",
+      "timestamp": "2026-01-01T00:00:00.000Z",
+      "conflicts_with": [],
+      "resolved_by": null,
+      "tags": ["vendor", "ip-indemnity", "ai", "legal"]
+    }
+  ]
+}