@grainulation/silo 1.0.0 → 1.0.1

package/packs/hackathon-sprint-boost.json

@@ -0,0 +1,173 @@
+{
+  "name": "Hackathon: Sprint Boost",
+  "description": "Business-aligned hackathon category pack. Teams tackle real backlog items or OKR-driven research questions. Judging weights: 40% business impact, 30% research rigor, 30% creativity. Rewards sprints that ship real value.",
+  "version": "1.0.0",
+  "judging": {
+    "weights": {
+      "impact": 0.4,
+      "rigor": 0.3,
+      "creativity": 0.3
+    },
+    "auto_score_dimensions": {
+      "impact": {
+        "constraint_satisfaction": 0.4,
+        "evidence_tier": 0.3,
+        "corroboration": 0.3
+      },
+      "rigor": {
+        "evidence_tier": 0.35,
+        "challenge_depth": 0.3,
+        "health": 0.2,
+        "corroboration": 0.15
+      },
+      "creativity": {
+        "type_diversity": 0.35,
+        "recommendation_ratio": 0.35,
+        "cross_topic_breadth": 0.3
+      }
+    },
+    "human_score_dimensions": [
+      "decision_clarity",
+      "stakeholder_awareness",
+      "actionability"
+    ],
+    "final_blend": {
+      "auto": 0.5,
+      "human": 0.5
+    }
+  },
+  "claims": [
+    {
+      "id": "hsb-001",
+      "type": "constraint",
+      "topic": "sprint boost format",
+      "content": "Sprint Boost is a business-aligned hackathon format. Each team picks a real task from their backlog or a strategic OKR key result, runs a wheat research sprint on it, and submits the compiled brief. The output is a sprint deliverable, not a side project.",
+      "source": {
+        "origin": "stakeholder",
+        "artifact": null,
+        "connector": null
+      },
+      "evidence": "stated",
+      "status": "active",
+      "phase_added": "define",
+      "timestamp": "2026-03-21T00:00:00.000Z",
+      "conflicts_with": [],
+      "resolved_by": null,
+      "tags": ["hackathon", "sprint-boost", "business-aligned", "format"]
+    },
+    {
+      "id": "hsb-002",
+      "type": "constraint",
+      "topic": "impact scoring",
+      "content": "Business impact is the dominant judging dimension at 40%. Scored across: (1) Does the research address a real business constraint? (2) Are findings backed by evidence strong enough to act on? (3) Are claims corroborated by external sources? A sprint that solves a real problem with weak evidence still outscores a polished sprint on a hypothetical problem.",
+      "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": ["hackathon", "sprint-boost", "impact", "scoring"]
+    },
+    {
+      "id": "hsb-003",
+      "type": "constraint",
+      "topic": "rigor scoring",
+      "content": "Research rigor is weighted at 30%. Scored across: (1) Evidence tier distribution — higher tiers (tested, production) score exponentially better. (2) Challenge depth — did the team stress-test their own findings? (3) Health — clean compilation with few warnings. (4) Corroboration — external witnesses back up claims.",
+      "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": ["hackathon", "sprint-boost", "rigor", "scoring"]
+    },
+    {
+      "id": "hsb-004",
+      "type": "constraint",
+      "topic": "creativity scoring",
+      "content": "Creativity is weighted at 30%. Scored across: (1) Type diversity — using multiple claim types shows multi-angle thinking. (2) Recommendation ratio — novel, actionable recommendations signal creative problem-solving. (3) Cross-topic breadth — drawing from diverse domains demonstrates creative synthesis.",
+      "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": ["hackathon", "sprint-boost", "creativity", "scoring"]
+    },
+    {
+      "id": "hsb-005",
+      "type": "recommendation",
+      "topic": "challenge tracks",
+      "content": "Sprint Boost should offer challenge tracks tied to real OKRs: (1) 'Accelerate' — pick a backlog item and deliver research that unblocks it. (2) 'Rethink' — same task, novel approach. (3) 'Cross-pollinate' — research a problem from another team's backlog. Track 2 prevents Sprint Boost from becoming a crunch sprint.",
+      "source": { "origin": "research", "artifact": null, "connector": null },
+      "evidence": "web",
+      "status": "active",
+      "phase_added": "research",
+      "timestamp": "2026-03-21T00:00:00.000Z",
+      "conflicts_with": [],
+      "resolved_by": null,
+      "tags": ["hackathon", "sprint-boost", "tracks", "okr"]
+    },
+    {
+      "id": "hsb-006",
+      "type": "risk",
+      "topic": "crunch sprint risk",
+      "content": "Risk: If Sprint Boost only rewards shipping backlog items, it becomes unpaid overtime disguised as a hackathon. The creativity weight (30%) and the 'Rethink' track are guardrails. Human judges should penalize submissions that are pure task execution with no research insight.",
+      "source": { "origin": "research", "artifact": null, "connector": null },
+      "evidence": "web",
+      "status": "active",
+      "phase_added": "research",
+      "timestamp": "2026-03-21T00:00:00.000Z",
+      "conflicts_with": [],
+      "resolved_by": null,
+      "tags": ["hackathon", "sprint-boost", "risk", "crunch"]
+    },
+    {
+      "id": "hsb-007",
+      "type": "recommendation",
+      "topic": "human judge criteria",
+      "content": "Human judges for Sprint Boost score on: (1) Decision clarity — could a VP act on this brief? (2) Stakeholder awareness — are constraints from real decision-makers? (3) Actionability — are next steps concrete with owners and timelines? These map 1:1 to the three scoring dimensions (impact, rigor, creativity).",
+      "source": { "origin": "research", "artifact": null, "connector": null },
+      "evidence": "stated",
+      "status": "active",
+      "phase_added": "research",
+      "timestamp": "2026-03-21T00:00:00.000Z",
+      "conflicts_with": [],
+      "resolved_by": null,
+      "tags": ["hackathon", "sprint-boost", "human-judging", "criteria"]
+    },
+    {
+      "id": "hsb-008",
+      "type": "factual",
+      "topic": "OKR hackathon precedent",
+      "content": "The OKR Hackathon is an established corporate format (documented by Devpost) where teams compete to complete OKR goals within a hackathon timebox. Intel ties innovation hackathons directly to strategic OKRs. This validates Sprint Boost: real work, hackathon energy, research-backed output.",
+      "source": {
+        "origin": "research",
+        "artifact": "https://info.devpost.com/blog/8-types-of-internal-hackathons",
+        "connector": null
+      },
+      "evidence": "web",
+      "status": "active",
+      "phase_added": "research",
+      "timestamp": "2026-03-21T00:00:00.000Z",
+      "conflicts_with": [],
+      "resolved_by": null,
+      "tags": ["hackathon", "sprint-boost", "okr", "precedent"]
+    }
+  ]
+}

package/packs/incident-postmortem.json

@@ -0,0 +1,219 @@
+{
+  "name": "Incident Postmortem",
+  "description": "Structured framework for blameless incident review sprints. Covers timeline reconstruction, root cause analysis, contributing factors, action items, and organizational learning. Aligned with SRE best practices.",
+  "version": "1.0.0",
+  "claims": [
+    {
+      "id": "inc-001",
+      "type": "constraint",
+      "topic": "blameless postmortem culture",
+      "content": "Postmortems must be blameless. Focus on systemic causes, not individual mistakes. Language matters: 'the deploy pipeline lacked rollback automation' not 'engineer X deployed without testing'. Blame drives hiding, which prevents learning.",
+      "source": {
+        "origin": "best-practice",
+        "artifact": "Google SRE Book, Chapter 15",
+        "connector": null
+      },
+      "evidence": "documented",
+      "status": "active",
+      "phase_added": "define",
+      "timestamp": "2026-03-21T00:00:00.000Z",
+      "conflicts_with": [],
+      "resolved_by": null,
+      "tags": ["postmortem", "blameless", "culture", "sre"]
+    },
+    {
+      "id": "inc-002",
+      "type": "constraint",
+      "topic": "incident timeline",
+      "content": "Every postmortem must include a precise timeline: (1) First customer impact (not first alert). (2) Detection time. (3) Escalation and response milestones. (4) Mitigation applied. (5) Full resolution. (6) Verification of recovery. Use UTC timestamps. Each entry is a factual claim with 'documented' evidence from logs and metrics.",
+      "source": {
+        "origin": "best-practice",
+        "artifact": "Google SRE Book, Chapter 15",
+        "connector": null
+      },
+      "evidence": "documented",
+      "status": "active",
+      "phase_added": "define",
+      "timestamp": "2026-03-21T00:00:00.000Z",
+      "conflicts_with": [],
+      "resolved_by": null,
+      "tags": ["postmortem", "timeline", "documentation", "sre"]
+    },
+    {
+      "id": "inc-003",
+      "type": "constraint",
+      "topic": "severity classification",
+      "content": "Classify incident severity: SEV1 — widespread outage, revenue-impacting, all-hands response. SEV2 — partial outage, degraded experience for subset of users. SEV3 — minor issue, workaround available, limited impact. SEV4 — cosmetic or edge case, no user impact. Postmortem required for SEV1 and SEV2. SEV3 optional.",
+      "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": ["postmortem", "severity", "classification", "sre"]
+    },
+    {
+      "id": "inc-004",
+      "type": "constraint",
+      "topic": "root cause analysis",
+      "content": "Use the '5 Whys' technique or fault tree analysis to identify root causes. Most incidents have multiple contributing causes. Distinguish: (1) Triggering cause — the immediate action that started the incident. (2) Root cause — the systemic weakness that allowed the trigger to cause impact. (3) Contributing factors — conditions that worsened severity or delayed response.",
+      "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": ["postmortem", "root-cause", "5-whys", "fault-tree"]
+    },
+    {
+      "id": "inc-005",
+      "type": "constraint",
+      "topic": "action items",
+      "content": "Every postmortem must produce prioritized action items: (1) Each action has an owner and deadline. (2) Actions are typed: 'mitigate' (prevent recurrence), 'detect' (catch it faster), 'respond' (improve response). (3) Track completion — unfinished action items from past postmortems are a leading indicator of future incidents.",
+      "source": {
+        "origin": "best-practice",
+        "artifact": "Google SRE Book, Chapter 15",
+        "connector": null
+      },
+      "evidence": "documented",
+      "status": "active",
+      "phase_added": "define",
+      "timestamp": "2026-03-21T00:00:00.000Z",
+      "conflicts_with": [],
+      "resolved_by": null,
+      "tags": ["postmortem", "action-items", "tracking", "sre"]
+    },
+    {
+      "id": "inc-006",
+      "type": "risk",
+      "topic": "action item decay",
+      "content": "The most common postmortem failure: action items are written but never completed. Studies show 40-60% of postmortem action items go unfinished. Counter: link action items to sprint tickets, review completion in weekly standups, escalate overdue items, and track completion rate as a team metric.",
+      "source": { "origin": "research", "artifact": null, "connector": null },
+      "evidence": "web",
+      "status": "active",
+      "phase_added": "research",
+      "timestamp": "2026-03-21T00:00:00.000Z",
+      "conflicts_with": [],
+      "resolved_by": null,
+      "tags": ["postmortem", "action-items", "decay", "risk"]
+    },
+    {
+      "id": "inc-007",
+      "type": "factual",
+      "topic": "impact quantification",
+      "content": "Quantify incident impact across dimensions: (1) Duration (time to detect + time to mitigate + time to resolve). (2) User impact (affected users / total users). (3) Revenue impact (lost transactions, SLA credits owed). (4) Reputation impact (social media mentions, support tickets). (5) Engineering cost (person-hours spent responding).",
+      "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": ["postmortem", "impact", "metrics", "quantification"]
+    },
+    {
+      "id": "inc-008",
+      "type": "recommendation",
+      "topic": "wheat-powered postmortem workflow",
+      "content": "Map wheat sprint to postmortem: (1) Sprint question = 'What caused incident X and how do we prevent recurrence?' (2) Factual claims = timeline events backed by logs. (3) Constraint claims = SLA requirements and detection targets. (4) Risk claims = contributing factors and systemic weaknesses. (5) Recommendation claims = action items with owners. (6) The compiled brief IS the postmortem document.",
+      "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": ["postmortem", "wheat", "workflow", "recommendation"]
+    },
+    {
+      "id": "inc-009",
+      "type": "constraint",
+      "topic": "postmortem timeline requirement",
+      "content": "Postmortem sprint must begin within 48 hours of incident resolution for SEV1, within 1 week for SEV2. Memory degrades rapidly — the timeline becomes unreliable after 72 hours. The postmortem review meeting should happen within 5 business days of the sprint.",
+      "source": {
+        "origin": "best-practice",
+        "artifact": "Google SRE Book, Chapter 15",
+        "connector": null
+      },
+      "evidence": "documented",
+      "status": "active",
+      "phase_added": "define",
+      "timestamp": "2026-03-21T00:00:00.000Z",
+      "conflicts_with": [],
+      "resolved_by": null,
+      "tags": ["postmortem", "timeline", "sre", "process"]
+    },
+    {
+      "id": "inc-010",
+      "type": "factual",
+      "topic": "detection and response metrics",
+      "content": "Key incident metrics: MTTD (mean time to detect) — from first impact to first alert. MTTR (mean time to respond) — from alert to first responder action. MTTM (mean time to mitigate) — from response to customer impact stopped. MTTResolve — from mitigation to root cause fixed. Track trends across incidents, not just individual values.",
+      "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": ["postmortem", "mttd", "mttr", "metrics", "sre"]
+    },
+    {
+      "id": "inc-011",
+      "type": "risk",
+      "topic": "recurrence patterns",
+      "content": "If the same category of incident recurs 3+ times, the postmortems are failing. Common reasons: (1) Action items address symptoms not root causes. (2) Systemic issues span team boundaries with no single owner. (3) Technical debt prioritized below feature work. Escalate recurring incident categories to engineering leadership.",
+      "source": {
+        "origin": "best-practice",
+        "artifact": null,
+        "connector": null
+      },
+      "evidence": "documented",
+      "status": "active",
+      "phase_added": "research",
+      "timestamp": "2026-03-21T00:00:00.000Z",
+      "conflicts_with": [],
+      "resolved_by": null,
+      "tags": ["postmortem", "recurrence", "systemic", "risk"]
+    },
+    {
+      "id": "inc-012",
+      "type": "recommendation",
+      "topic": "learning dissemination",
+      "content": "Postmortem value is maximized when learnings spread beyond the incident team. Recommended: (1) Publish postmortem to internal wiki within 1 week. (2) Present at engineering all-hands for SEV1. (3) Add to onboarding reading list for the affected service. (4) Use wheat /witness to link related incidents across teams — the knowledge graph surfaces patterns humans miss.",
+      "source": {
+        "origin": "best-practice",
+        "artifact": null,
+        "connector": null
+      },
+      "evidence": "stated",
+      "status": "active",
+      "phase_added": "research",
+      "timestamp": "2026-03-21T00:00:00.000Z",
+      "conflicts_with": [],
+      "resolved_by": null,
+      "tags": ["postmortem", "learning", "knowledge-sharing", "enterprise"]
+    }
+  ]
+}

package/packs/migration.json

@@ -8,7 +8,11 @@
       "type": "constraint",
       "topic": "migration rollback safety",
       "content": "Production migrations must be reversible. Every schema change, data transform, or infrastructure swap needs a tested rollback procedure with a maximum rollback time SLA.",
-      "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": "dual-write consistency risk",
       "content": "Dual-write periods introduce data consistency risks. During cutover, writes must go to both old and new systems, and a reconciliation process must detect drift.",
-      "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": "risk",
       "topic": "migration window overrun",
       "content": "Data migrations that run longer than the maintenance window force a choice between extended downtime and incremental migration. Estimate data volume transfer rates early.",
-      "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": "constraint",
       "topic": "minimum viable migration scope",
       "content": "Feature parity with the legacy system is rarely achievable on day one. Define a 'minimum viable migration' scope that covers the critical path and defer edge cases.",
-      "source": { "origin": "best-practice", "artifact": null, "connector": null },
+      "source": {
+        "origin": "best-practice",
+        "artifact": null,
+        "connector": null
+      },
       "evidence": "stated",
       "status": "active",
       "phase_added": "define",
@@ -64,7 +80,11 @@
       "type": "recommendation",
       "topic": "strangler fig migration pattern",
       "content": "Use the strangler fig pattern for large migrations: route traffic incrementally to the new system while the old system continues to serve unmodified paths.",
-      "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": "risk",
       "topic": "character encoding corruption",
       "content": "Character encoding mismatches (UTF-8 vs Latin-1, collation differences) are the most common silent data corruption source in database migrations. Test with production-representative data.",
-      "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 +130,11 @@
       "type": "constraint",
       "topic": "API versioning during migration",
       "content": "API contract changes during migration require versioned endpoints. Clients must be able to continue using the old API for a deprecation period (minimum 3 months is standard).",
-      "source": { "origin": "best-practice", "artifact": null, "connector": null },
+      "source": {
+        "origin": "best-practice",
+        "artifact": null,
+        "connector": null
+      },
       "evidence": "documented",
       "status": "active",
       "phase_added": "define",
@@ -120,7 +148,11 @@
       "type": "recommendation",
       "topic": "shadow traffic validation",
       "content": "Run shadow traffic (replay production reads against the new system without serving responses) for at least 2 weeks before cutover. Compare results for correctness and latency.",
-      "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": "risk",
       "topic": "legacy knowledge decay",
       "content": "Team knowledge of the legacy system degrades over time. If migration stalls, institutional knowledge may be lost before it completes. Document as you migrate, not after.",
-      "source": { "origin": "best-practice", "artifact": null, "connector": null },
+      "source": {
+        "origin": "best-practice",
+        "artifact": null,
+        "connector": null
+      },
       "evidence": "stated",
       "status": "active",
       "phase_added": "define",

package/packs/observability.json

@@ -8,7 +8,11 @@
       "type": "constraint",
       "topic": "structured logging format",
       "content": "All application logs must be structured JSON with mandatory fields: timestamp (ISO 8601), level (debug/info/warn/error/fatal), message, service, and trace_id. Unstructured string logs break log aggregation queries and make correlation impossible at scale.",
-      "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": "recommendation",
       "topic": "RED method for services",
       "content": "Every service should expose the RED metrics: Rate (requests per second), Errors (failed requests per second), and Duration (latency histogram). These three metrics cover 80% of service-level debugging. Use histograms with buckets at 5ms, 10ms, 25ms, 50ms, 100ms, 250ms, 500ms, 1s, 2.5s, 5s, 10s.",
-      "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": "SLO error budget calculation",
       "content": "An SLO of 99.9% availability allows 43.2 minutes of downtime per 30-day window (0.1% error budget). An SLO of 99.95% allows 21.6 minutes. Error budget = total time * (1 - SLO target). When budget is exhausted, freeze feature work and focus on reliability.",
-      "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": "alert fatigue",
       "content": "Alert fatigue occurs when on-call engineers receive more than 2-3 actionable alerts per shift. Non-actionable alerts must be demoted to dashboards or deleted. Every alert should have a runbook link, a clear threshold, and an expected action. Pages without runbooks erode trust in the alerting system.",
-      "source": { "origin": "best-practice", "artifact": null, "connector": null },
+      "source": {
+        "origin": "best-practice",
+        "artifact": null,
+        "connector": null
+      },
       "evidence": "production",
       "status": "active",
       "phase_added": "define",
@@ -64,21 +80,34 @@
       "type": "recommendation",
       "topic": "distributed trace propagation",
       "content": "Propagate W3C Trace Context headers (traceparent, tracestate) across all service boundaries including HTTP, gRPC, and message queues. Without trace propagation, latency debugging in distributed systems requires manual log correlation which takes 10-50x longer.",
-      "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": ["observability", "tracing", "distributed-systems", "opentelemetry"]
+      "tags": [
+        "observability",
+        "tracing",
+        "distributed-systems",
+        "opentelemetry"
+      ]
     },
     {
       "id": "obs-006",
       "type": "constraint",
       "topic": "no PII in logs",
       "content": "Logs must never contain PII (emails, names, IP addresses, session tokens, passwords). Use hashed or tokenized identifiers for correlation. Accidental PII in logs creates GDPR/CCPA compliance risk and makes log retention policies complex. Enforce with automated log scrubbing or allowlist-based field serialization.",
-      "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 +121,11 @@
       "type": "recommendation",
       "topic": "USE method for infrastructure",
       "content": "For infrastructure resources (CPU, memory, disk, network), track the USE metrics: Utilization (% of capacity used), Saturation (queue depth or wait time), and Errors (error count). Alert when utilization exceeds 80% sustained over 5 minutes or saturation is non-zero.",
-      "source": { "origin": "best-practice", "artifact": null, "connector": null },
+      "source": {
+        "origin": "best-practice",
+        "artifact": null,
+        "connector": null
+      },
       "evidence": "documented",
       "status": "active",
       "phase_added": "define",
@@ -120,7 +153,11 @@
       "type": "recommendation",
       "topic": "incident severity definitions",
       "content": "Define incident severity levels with quantitative criteria: SEV1 (total service outage or data loss, all hands, 15-min response), SEV2 (degraded for >50% of users, team response, 30-min), SEV3 (degraded for <50% or non-critical feature down, next business day), SEV4 (cosmetic or minor, backlog). Ambiguous severity wastes escalation time.",
-      "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 +171,11 @@
       "type": "risk",
       "topic": "cardinality explosion in metrics",
       "content": "High-cardinality labels (user IDs, request IDs, full URLs) on metrics cause cardinality explosion, which degrades query performance and inflates storage costs exponentially. Prometheus recommends keeping total time series under 10 million. Use logs or traces for high-cardinality data, not metrics.",
-      "source": { "origin": "best-practice", "artifact": null, "connector": null },
+      "source": {
+        "origin": "best-practice",
+        "artifact": null,
+        "connector": null
+      },
       "evidence": "production",
       "status": "active",
       "phase_added": "define",
@@ -148,7 +189,11 @@
       "type": "recommendation",
       "topic": "postmortem blamelessness",
       "content": "Postmortems must be blameless and focus on systemic causes, not individual actions. Required sections: timeline, impact (users affected, duration, revenue impact), root cause, contributing factors, action items with owners and due dates. Publish postmortems within 48 hours of incident resolution.",
-      "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 +217,4 @@
       "tags": ["observability", "opentelemetry", "migration", "cost"]
     }
   ]
-}
+}