@grainulation/silo 1.0.0 → 1.0.2

package/packs/hackathon-most-rigorous.json

@@ -0,0 +1,179 @@
+{
+  "name": "Hackathon: Most Rigorous Research",
+  "description": "Scoring rubric and seed claims for the 'Most Rigorous Research' hackathon category. Weights evidence tiers heavily, rewards challenge depth and corroboration over volume.",
+  "version": "1.0.0",
+  "claims": [
+    {
+      "id": "hrig-001",
+      "type": "constraint",
+      "topic": "evidence tier scoring",
+      "content": "Evidence tier sub-score uses weighted sum: production=5, tested=4, documented=3, web=2, stated=1, normalized to 0-100. This is the dominant factor (35% weight) in the Most Rigorous category.",
+      "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": ["hackathon", "scoring", "evidence-tier", "most-rigorous"]
+    },
+    {
+      "id": "hrig-002",
+      "type": "constraint",
+      "topic": "challenge depth scoring",
+      "content": "Challenge depth sub-score = (challenge_claims + resolved_conflicts) / total_claims * 100. Weight: 25%. Rewards sprints that actively question and resolve competing claims rather than building one-sided arguments.",
+      "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": ["hackathon", "scoring", "challenge-depth", "most-rigorous"]
+    },
+    {
+      "id": "hrig-003",
+      "type": "constraint",
+      "topic": "corroboration scoring",
+      "content": "Corroboration sub-score = witnessed_claims / total_claims * 100. Weight: 20%. Claims backed by external sources (web evidence, documented references) score higher than unsupported assertions.",
+      "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": ["hackathon", "scoring", "corroboration", "most-rigorous"]
+    },
+    {
+      "id": "hrig-004",
+      "type": "constraint",
+      "topic": "health scoring",
+      "content": "Health sub-score = max(0, (1 - warnings/total_claims) * 100). Weight: 10%. Penalizes sprints with compiler warnings — low-evidence claims, missing fields, unresolved conflicts.",
+      "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": ["hackathon", "scoring", "health", "most-rigorous"]
+    },
+    {
+      "id": "hrig-005",
+      "type": "constraint",
+      "topic": "type diversity scoring",
+      "content": "Type diversity sub-score = (distinct_types / 6) * 100. Weight: 10%. Ensures sprints use the full taxonomy (constraint, factual, estimate, risk, recommendation, feedback) rather than only one type.",
+      "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": ["hackathon", "scoring", "type-diversity", "most-rigorous"]
+    },
+    {
+      "id": "hrig-006",
+      "type": "recommendation",
+      "topic": "anti-gaming logarithmic scaling",
+      "content": "Apply logarithmic scaling to claim counts: score = log(claim_count) not linear. This prevents gaming through claim spam — 100 weak claims score only marginally better than 10 strong ones.",
+      "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": ["hackathon", "anti-gaming", "logarithmic", "most-rigorous"]
+    },
+    {
+      "id": "hrig-007",
+      "type": "risk",
+      "topic": "Goodhart's Law gaming",
+      "content": "If teams know the exact scoring weights, they optimize for metrics over substance (Goodhart's Law). Keep exact weights secret; publish only the dimensions. Rotate weights per hackathon event.",
+      "source": {
+        "origin": "research",
+        "artifact": "https://en.wikipedia.org/wiki/Goodhart's_law",
+        "connector": null
+      },
+      "evidence": "web",
+      "status": "active",
+      "phase_added": "research",
+      "timestamp": "2026-01-01T00:00:00.000Z",
+      "conflicts_with": [],
+      "resolved_by": null,
+      "tags": ["hackathon", "gaming", "goodhart", "risk"]
+    },
+    {
+      "id": "hrig-008",
+      "type": "factual",
+      "topic": "benchmark thresholds",
+      "content": "A well-designed rigorous sprint should achieve: evidence_tier_score >= 60, type_diversity >= 83 (5/6 types), challenge_depth >= 15%, corroboration >= 20%, health >= 80. These serve as calibration benchmarks.",
+      "source": { "origin": "research", "artifact": null, "connector": null },
+      "evidence": "documented",
+      "status": "active",
+      "phase_added": "research",
+      "timestamp": "2026-01-01T00:00:00.000Z",
+      "conflicts_with": [],
+      "resolved_by": null,
+      "tags": ["hackathon", "benchmarks", "calibration", "most-rigorous"]
+    },
+    {
+      "id": "hrig-009",
+      "type": "recommendation",
+      "topic": "hybrid judging model",
+      "content": "Two-stage judging: auto-score (compiler metrics) acts as qualifier — top N advance. Final round = 50% auto-score + 50% human panel scoring insight quality, narrative clarity, and practical applicability.",
+      "source": { "origin": "research", "artifact": null, "connector": null },
+      "evidence": "documented",
+      "status": "active",
+      "phase_added": "research",
+      "timestamp": "2026-01-01T00:00:00.000Z",
+      "conflicts_with": [],
+      "resolved_by": null,
+      "tags": ["hackathon", "hybrid-judging", "qualifier", "most-rigorous"]
+    },
+    {
+      "id": "hrig-010",
+      "type": "constraint",
+      "topic": "evidence tier floor",
+      "content": "Claims below 'web' evidence tier count at 50% weight. This prevents gaming by adding many low-effort 'stated' claims. Encourages teams to back assertions with real sources.",
+      "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": ["hackathon", "anti-gaming", "evidence-floor", "most-rigorous"]
+    }
+  ]
+}

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"]
+    }
+  ]
+}