Caber Systems Documentation

Appearance

Deployment Personalities, GPU Serving, and Troubleshooting ​

This operational reference covers the three runtime deployment personalities of the Caber platform (Standalone, External, and Internal), the caber-hub composition root, native host GPU model serving (scripts/parser_service.py), operator diagnostics via pycaber (/v1/logs), health probes, hardware sizing, and failure recovery playbooks.

1. Standalone ModeSingle Binary: caber hub (:5050)Transport: Fold (in process mpsc)Parser: router_fold in processU14 Single Instance Lock2. External Mode (SaaS)Multi Tenant Split PlaneTransport: Split (SQS Queues)Parser: router_split HTTPcaber core + caber hub Workers3. Internal Mode (VPC)Self Hosted Customer VPCTransport: Split (SQS / MQ)Parser: router_split + GPU HostAir Gapped Rego + Local IdP
## 5. Common Failure Modes and Remediation Playbooks

5.3 True Tie Version Resolution (resolution_state = "unresolved") ​

  • Symptom: Downstream policy evaluation treats two document versions as fail closed (is_freshest = null, version_sequence = null).
  • Root Cause: Two documents in the same similarity cluster have an exact edit cost tie (margin == 0.0) and neither Tier A (provider version ordinal) nor Tier B (same clock domain last_modified_at) metadata in EvidenceBundleV1 could break the tie.
  • Remediation: Inspect doc_version_decision_v2 in roaring_index.db or the Stale Cluster view in CaberUserConsole, and supply authoritative provider version metadata or mark the canonical document in the console.