About the operator

Who runs
this lab.

Operator Bio — Scott

Last Updated: 2026-06-25

Identity

I'm Scott — the operator of the UAI (Unified AI) lab. I own the lab infrastructure, the product direction, and the final authority on changes to production systems. AI agents working in this lab work for me.

I operate primarily from a Windows workstation (NUC-IPEX), with a MacBook Air and a Zenbook as secondary devices. The always-on lab backbone is a Linux VPS (Beacon, mesh IP 100.119.16.109) plus a Proxmox cluster (pve250 / Director) hosting LXC containers (CT103, CT121, CT123, CT124, CT125, CT126).

Timezone: America/St_Johns (Newfoundland).

What I do here

I design and operate a multi-product AI lab. Each product is standalone — they have their own source tree, namespace, and scope. They are not subsystems of each other; don't conflate them.

Active products:

  • UAPI Explorer (Python, CT121:8080) — the AI-lane surface you're reading this through. AI-first documentation catalog with redaction, audit, and tag-based access control.
  • UAI Explorer (Rust, 100.119.16.109:18080) — separate documentation catalog. Standalone product, different codebase, different purpose.
  • Cadence (v5 legacy → v6 active rebuild) — operator-facing lab management product. Director, Conductor, Cadence UI, Cortex bridge.
  • Cortex (v1 → v2 rebuild) — memory, knowledge base, embedding query layer.
  • Beacon (v1 → v2 rebuild) — file/media service.
  • UAI Switchboard (v0.2.2) — fleet coordination, RBAC, lifecycle, tamper- evident audit chain.
  • UAI Command Center (CT125) — physical I/O bridge: Kiyo video, Huion tablet, audio capture, vision/STT/TTS backends.
  • Devine — specialized lane (see tagged entries in catalog).

Active workstreams:

  • Cross-product migration ops framework (5 parallel workstreams A–F)
  • GLM 5.2 wave task series (numbered waves with A/B sibling tasks)
  • Sandbox protocol governance
  • UAPI v0.3.0 sprint (AI-authoring surface — recursive reference, this is the sprint that registered this bio)
  • Cadence v6 phase write-pilot

How I work

Real infrastructure, not a toy. Every infra change gets a timestamped notation entry before being considered complete. Required fields: Timestamp / Operator / System / Task / Pre-change state / Changes made / Verification / Rollback / Follow-ups. No secrets in notation — paths and aliases only.

Explorer is canonical. Project work products go in Explorer as diary entries. Local proposals folders go stale. Always query Explorer first per the agent guide before starting work.

Punch-list over polish. When given an open-ended "make it better" task on a multi-component system, step back, survey everything, build a written punch list, then execute systematically. Do not polish one piece into a million small fixes — that produces no coherent quality bar.

No smoke tests. Don't write "endpoint returns 200" tests just to have coverage. If the real flow can't be tested because something is missing, add the missing thing to the punch list and build it. Smoke tests give false confidence.

Sandbox discipline. Production (CT121) is governed internal production. Sandbox (CT126) is the staging and verification lane. Don't redeploy production during exploratory work. Don't bypass the sandbox because it's slow — if the sandbox is slow, compress the cycle, don't skip it.

AI-first. When designing a product that AI uses, treat AI as the primary user. The human view is downstream. Don't restrict the AI lane with operator- review gates when the operator can review after the fact via audit trail. The 4000-char feedback cap on UAPI Explorer was implementation drift, not design intent — fix it.

Cross-product boundaries. A Cadence task should not produce Command Center artifacts. An Explorer diary entry is not a Cadence work product. Cross- references are fine; conflation is not. Don't pull sibling products into a single-product task without my explicit ask.

Check diary before restoring state. Before re-creating deleted rows or re- deploying taken-down services, grep the diary index for prior takedown intent. Past agents have "restored" intentionally-deleted state as side-effect fixes during unrelated cleanup. Don't be that agent.

Decision authority

  • Me (operator) — final authority on all production changes, DNS/TLS/ firewall/reverse-proxy/NetBird mutations, public exposure, and cross-product design decisions.
  • Coordinator delegation — I can delegate G2 authority to a coordinator session for a sprint. That delegation is session-scoped, not durable. Future sessions must re-confirm. If you're working from memory of a prior delegation, ask.
  • Sandbox work — agents can do exploratory work in CT126 and project sandboxes (CT123, CT124) without per-action approval, but notation still applies.
  • Operator physical actions — Mac-side Rust rebuilds, hardware console access, password manager entries — those need my physical hands. Plan around it.

What I want from AI agents

  1. Read this bio + UAI rules + relevant runbooks before acting. Don't improvise on lab topology.
  2. Survey before executing. Punch-list first, execute systematically, then report at the end with what was found and fixed.
  3. Use the sandbox. Don't hot-patch production without notation and a rollback plan.
  4. Don't rationalize gaps as design. If something is missing or broken, name it as a gap. Don't reframe "we didn't build this" as "we designed it this way on purpose."
  5. Write real tests, not coverage theater. If you can't write a real test because the underlying thing is missing, build the missing thing.
  6. Document in the diary as you work, not backfilled at the end. Timestamps in YYYY-MM-DD HH:MM TZ format.
  7. Push back when you have evidence. If I'm wrong about something, show me the evidence. Don't just go along with a bad direction — but make the case, don't just refuse.
  8. When in doubt, ask. A 30-second question is cheaper than a wrong deployment.
  9. Read the capability card before first use. Before you use any tool, service, or hardware in the lab for the first time in a session, look up its capability card via GET /api/ai/capability-map. If no card exists, abort and report the gap. Do not improvise on lab topology, and do not read config files directly when a card would tell you the safe path. The Beacon API key exposure from /opt/beacon/config/beacon.toml was this exact failure mode — do not repeat it.
  10. Leave breadcrumbs when you change state. Every infrastructure state change (service, route, file, config, container, mesh peer, etc.) gets a breadcrumb POSTed to the affected capability card(s). What changed, why, audit_event_id, related diary entry. The next agent should be able to reconstruct what happened to a capability without diffing the whole lab.

What I don't want

  • Destructive shortcuts to make obstacles go away (--no-verify, rm -rf, force-push, etc.) without my explicit ask.
  • Backwards-compatibility hacks like renaming unused _vars or leaving "// removed" comments for deleted code.
  • Smoke tests / stub tests / fake coverage.
  • Polish passes that produce a million small fixes without a coherent quality bar.
  • Half-finished implementations. Either build the whole thing or put it on the punch list.
  • Public exposure changes (DNS, TLS, firewall) without a separate runbook.
  • Secrets in code, docs, diaries, logs, tests, or evidence.

Contact / escalation

There is one of me. AI agents can't ping me directly — they surface decisions through their reports, and I review them between sessions. If you hit a blocker that needs my decision, document it in your report with the specific question, the options, and your recommendation. Don't sit on blockers silently and don't invent answers.

Pointers

  • Lab access runbook: C:\Users\scott\Desktop\Projects\Runbooks\UAI-Lab-Access-and-Server-Setup-Runbook.md on NUC-IPEX
  • Project memory (agent-side): /root/.claude/projects/-root/memory/ on Beacon
  • Diary: /root/uai-explorer/diary/ on Beacon
  • UAPI Explorer (this product): CT121:8080 production, CT126:8080 sandbox
  • UAI Explorer (sibling product): 100.119.16.109:18080

— Scott