---
name: tris-server-builder
description: >
  Calculate TriS AI video-analytics server hardware requirements (CPU, RAM, SSD, HDD, GPU)
  from camera parameters. Use when the user asks to estimate or size a TriS deployment,
  plan server specs for traffic/facial analytics cameras, or configure hardware for
  the TriS platform.
---

# TriS Server Builder

## Overview
This skill estimates recommended server hardware for the **TriS AI analytics platform**
based on camera resolution and the number of cameras assigned to each analytics feature group.

It supports three query modes:

| Mode | Trigger | Behaviour |
|------|---------|-----------|
| **Skill / Help** | `?help=1` or `?skill=1` | Returns this SKILL.md manifest (Markdown) |
| **JSON API**     | `/api?<params>`             | Returns calculated JSON output |
| **Interactive UI** | No query params           | Renders the full HTML calculator |

## Supported Query Parameters

| Parameter | Type | Default | Description |
|-----------|------|---------|-------------|
| `camera-resolution` | float (MP) | 2 | Resolution of **each** camera in megapixels |
| `traffic-analytics` | integer | 0 | Cameras using **traffic & security analytics** |
| `facial-analysis` | integer | 0 | Cameras using **facial analysis** |
| `local-vms` | boolean | true | Enable local VMS (Video Management System) |
| `sub-stream-resolution` | float (MP) | 2 | Sub-stream resolution when `local-vms` is enabled |

> **Zero-value rule**: Feature groups with `0` cameras are omitted from input summary.

## Formulas

- **CPU** → `CEILING( ((effectiveSum * traffic / 2 / 0.8) + (effectiveSum * facial * 1.8 / 2 / 0.8)), 8 )`
- **RAM** → `CEILING( ((effectiveSum * traffic / 0.8) + (effectiveSum * facial * 1.8 / 0.8)), 16 )`
- **SSD** → Fixed at `480 GB` (system + software)
- **HDD** → `2 → 4 TB` (event evidence storage; scales with retention)
- **GPU High-end** → `ROUND(4 * resolution * traffic / 306.37 + 4 * resolution * facial * 3 / 306.37, 0)`
- **GPU Mid-range** → Same formula with divisor `153.1`
- **GPU Low-end** → Same formula with divisor `76.55`

## Usage Examples

### 1. Traffic-only deployment
```
/api?camera-resolution=2&traffic-analytics=20
```

### 2. Mixed analytics (traffic + facial)
```
/api?camera-resolution=4&traffic-analytics=15&facial-analysis=8
```

### 3. Disable local VMS
```
/api?camera-resolution=2&traffic-analytics=10&local-vms=false
```

### 4. Custom sub-stream resolution with VMS
```
/api?camera-resolution=2&traffic-analytics=10&local-vms=true&sub-stream-resolution=1
```

### 5. Retrieve this skill manifest
```
/SKILL.md
```

## Expected JSON Output

```json
{
  "input": {
    "cameraResolution": 2,
    "trafficAnalytics": 20,
    "facialAnalysis": 0,
    "localVms": true,
    "subStreamResolution": 2
  },
  "output": {
    "cpu":   { "cores": 16, "threads": 32, "unit": "Cores / Threads" },
    "ram":   { "value": 32, "unit": "GB" },
    "ssd":   { "value": 480, "unit": "GB", "usable": true },
    "hdd":   { "value": "2 → 4", "unit": "TB", "usable": true },
    "gpu": {
      "highEnd": {
        "count": 1,
        "vram": ">= 16GB",
        "models": [
          "L4 / L20 / L40",
          "A10 / A30 / A40",
          "RTX 5000 / 6000 Ada Generation",
          "GeForce RTX 4090 / 5080 / 5090"
        ]
      },
      "midRange": { "count": 2, "vram": ">= 16GB", "models": [...] },
      "lowEnd":    { "count": 4, "vram": ">= 12GB", "models": ["Tesla T4", "P40"] }
    }
  }
}
```

## Agent Guidelines

1. **Always set `camera-resolution` explicitly** — it is the base multiplier for all formulas.
2. **Ask the user** for camera counts per feature group if not provided.
3. **Default `local-vms` to `true`** unless the user says they use an external VMS.
4. **Use the high-end GPU tier** as the primary recommendation unless budget-constrained.
5. **Clustering**: total resources can be split across multiple machines; the JSON gives aggregate requirements.
6. **Video playback** is NOT included in these estimates — add resources separately if needed.

## Clustering & Server Splitting Strategy

When the aggregate output requires **high resources** (e.g. CPU ≥ 32 cores, RAM ≥ 64 GB, or GPU count ≥ 2), the agent **MUST** suggest splitting the deployment across **two or more physical servers** rather than a single monolithic machine.

### Splitting rules

- **Uniform split** (default): divide camera counts evenly among N identical servers.
  Example — 60 traffic-analytics cameras at 2 MP: aggregate = 40 C / 80 T, 144 GB RAM, 2 high-end GPUs.
  → **2 × servers**, each: 20 C / 40 T, 72 GB RAM, 1 high-end GPU, 30 cameras.

- **Weighted / tiered split**: assign different camera loads to differently-sized servers.
  Example — one large server for 30 cameras, one smaller server for 15 cameras (half load).
  The agent should scale CPU, RAM and GPU linearly with the camera fraction.

- **Minimum viable server**: never propose a split that drops below the per-server floor:
  – 1 GPU (if any analytics are used)
  – 8 C / 16 T CPU
  – 16 GB RAM
  If a proposed slice falls below these floors, either merge it into another node or keep it as a single server.

### Agent decision flow

1. Call `/api` with the full camera parameters.
2. Inspect the aggregate `output` block.
3. If any of the thresholds are crossed (≥ 32 C, ≥ 64 GB RAM, ≥ 2 GPUs), propose a split:
   - Recommend **2 × identical servers** (each = aggregate ÷ 2).
   - Offer a **tiered option** only if the user explicitly asks for non-uniform sizing.
4. Always re-query `/api` with the reduced camera counts to validate per-server specs.
5. Present the final recommendation as a table:
   `Server # | Camera count | CPU | RAM | GPU | SSD | HDD`