DEVPAIR
Appearance
EVIDENCE & CONTEXT

Numbers need
context.

What the project records describe, what was measured, and where the limits of those measurements sit.

These are snapshots from supplied project records. They are not live telemetry or an independent audit. Event totals, database timings, implementation inventories, and design targets describe different things.

Public records JSON ↗
30,000+ACTIVE USERSREPORTED MEASUREMENT

30,000+ active users during documented broadcast events

Reported audience activity during documented Schmobin broadcast events. This is an event-scale figure, not a claim of simultaneous socket connections or a continuous production load.

Source record: DevPair broadcast telemetry logs / Broadcast event results

View the project ↗
500,000+SUBMISSIONSREPORTED MEASUREMENT

500,000+ audience submissions during documented events

Reported submission volume across documented Schmobin broadcast events. This is an aggregate participation figure, not a per-second throughput measurement. ChatDuelForm references the same event record.

Source record: DevPair broadcast telemetry logs / Audience participation

View the project ↗
364.1 MBTOTAL DAEMON RSSREPORTED MEASUREMENT

364.1 MB total RSS memory footprint across 31 persistent socket daemons

Recorded aggregate resident memory for 31 persistent services at the time of inspection. This snapshot excludes other host processes and does not certify memory use at peak traffic.

Source record: Infrastructure systemd status & smem telemetry / Daemon memory footprint

View the project ↗
0.5–2.0 msDATABASE EXECUTION TIMEREPORTED MEASUREMENT

0.5–2.0 ms reported server-side database arbitration execution

Reported database transaction execution during buzzer arbitration. This is not end-to-end player latency: network transit, client rendering, and event delivery are outside the measurement.

Source record: Schmobin Face-Off benchmark ledger / Buzzer arbitration

View the project ↗
Supporting implementation records +

These records describe selected tooling, design targets, and operational exercises. Each includes its scope and the limits of what it establishes.

10,000CONNECTIONS/NODE TARGETDESIGN TARGET · NOT CAPACITY CERTIFIED

10,000 concurrent WebSockets per node target capacity model

Designed capacity target in Go sequence-aware WebSocket engine with circular ring buffers, NATS JetStream, and monotonic Redis fencing tokens (capacity model; not claimed continuous production concurrency).

Source record: Punch 100K_CAPACITY_MATRIX.md / WebSocket concurrency model

View the project ↗
9 toolsMCP SDK TOOLSSUPPLIED IMPLEMENTATION RECORD

9 first-party MCP tools with token ability scoping and agent audit logs

Native Model Context Protocol server built with @modelcontextprotocol/sdk v1.6.0 exposing daily briefings and sprint mutations to coding agents (Claude, Cursor, Antigravity) with Sanctum token abilities.

Source record: Relay Studio integration inventory / AI agent protocol integration

View the project ↗
5 surfacesANATOMICAL TOOTH MAPPINGSUPPLIED IMPLEMENTATION RECORD

5-surface interactive dental odontogram in React 19

Documented dental charting interface supporting five tooth surfaces. Client interface evidence establishes the visible capability, not backend authorization enforcement or clinical validation.

Source record: ClinBeam client bundle manifest / Specialized clinical UI

View the project ↗
14 endpointsAI EXECUTION ROUTESSUPPLIED IMPLEMENTATION RECORD

Dual-engine AI copilot with 14 execution endpoints and clinician confirmation gate

Dual-engine AI architecture pairing clinical documentation (patient summaries, cited medical provenance, mandatory clinician review confirmation gate) and operational triage with Model Context Protocol integration.

Source record: ClinBeam AI protocol & route definitions / Dual-Engine Clinical Copilot & MCP

View the project ↗
9.2 → 4.3SCORE IMPROVEMENTREPORTED MEASUREMENT

systemd security exposure score reduced from 9.2 UNSAFE to 4.3 OK

A reported change in the systemd-analyze security heuristic after service sandboxing changes. A lower exposure score is not a percentage reduction in attack surface or an independent security certification.

Source record: systemd-analyze security audit output / Linux host hardening

View the project ↗
<15 minREPORTED RECOVERY EXERCISEREPORTED MEASUREMENT

Under 15 minutes reported for a fleet recovery exercise

Reported duration of a documented recovery exercise. Actual recovery depends on available backups, data volume, dependencies, and the failure scenario; this is not an availability guarantee.

Source record: Fleet recovery exercise record / Disaster recovery automation

View the project ↗

Project pages describe the product, its audience, and our contribution. Detailed operational procedures and customer data are excluded.