sandolab.xyz/ar

Tracking & Overlay Systems

Public surface for the repos that actually exist: attention tracking, world models, overlay experiments, Learn, and desktop attention services.

This is no longer framed as a single AR product. It is a set of connected systems: sando-tracker, learning-overlay, Learn, and personal-usability.

CURRENT SURFACE
$ ./run_chord_focus.sh --survey monitor_survey_results.json
/api/world-model -> room layout editor live
learning-overlay -> serve | x11-overlay | both
learn -> /workbench | /library | /recall | /proofs
personal-focus-daemon.service -> local attention hooks

What Exists

Four separate codebases, each with a concrete role, rather than one implied headset product.

Attention Tracking

sando-tracker

Monitor-focus service, world-model editor, and room-layout experiments for understanding where attention is directed across a multi-monitor setup.

Monitor focus service can use camera pose, WT901 IMU, or fallback paths

World-model editor serves room and monitor geometry through local APIs

Chord-focus launcher loads survey results and dual-camera defaults

Learning report tooling summarizes monitor prediction logs

Overlay Systems

learning-overlay

Standalone consumer of control-plane APIs with browser and native overlay surfaces.

Runs as HTTP server, X11 overlay, or both

Exposes study-session, proof-capture, activity, and target-run endpoints

Defines a canonical learning schema shared across the surface

Tests cover focus, images, Emacs context, and activity/event reads

Learning Workbench

Learn

Standalone React/Vite personal learning workbench that surfaces Mesh learning APIs on learn.sandolab.xyz.

Today card aggregates streak, recent reading, resume threads, stale concepts, recall, and ontology progress

Library route covers resource catalog, PDF reader, annotations, reader state, and chapter maps

Recall, glossary, ontology, bridge, proofs, sessions, and diagnostics routes expose the learning loop

Ships as a private Tailscale SPA behind Caddy with /api proxied to Mesh

Desktop Utilities

personal-usability

Local desktop helpers and operator-attention services that make the workstation itself part of the loop.

Defines stable provider contracts for screen focus and operator attention

Ships installable user services for focus daemon and operator attention

Includes status tooling for checking the active desktop stack

Keeps the desktop boundary explicit instead of hiding it inside a browser app

How The Pieces Fit

The common thread is not "AR." It is attention, context, and surfaced state across desktop, browser, and study workflows.

CAPTURE
sando-tracker
monitor focus
room model
INTERPRET
learning-overlay
schema
target runs
ROUTE
personal-usability
focus daemon
operator attention
SURFACE
Learn
study desk
proof workflow
↓ shared context and event flow ↓
monitor layout
focus windows
prediction logs
activity reads
study sessions
proof capture
browser UI
X11 overlay
desktop services

Attention First

The tracking work asks where attention is actually directed before deciding what to surface.

Overlay As Surface

The overlay work is a consumer of existing context, not an excuse to pretend the whole stack is a headset product.

Learning Loop

Learn turns context, reading state, recall, proofs, and sessions into explicit study workflows rather than leaving them buried in logs.

Public Boundary

This page is intentionally narrower than the old pitch.

What is real: monitor-focus experiments, room/world models, X11 overlay code, Learn study routes, and local desktop attention services.

What is not claimed: a single shipped AR headset product, a field deployment system, or a unified commercial suite.

The useful idea here is the interface boundary between attention tracking, surfaced context, and Learn-backed study work. The repos are early, but they are real.

Current Questions

The next work is about deciding which boundaries are worth hardening.

Q1
active

Attention Model

  • -How far can monitor layout, webcam pose, and IMU signals be pushed before they become noisy?
  • -What kinds of world models are actually worth maintaining by hand?
  • -Which attention transitions matter enough to route onward?
Q2
active

Overlay Boundary

  • -What belongs in an X11 HUD versus a browser route versus a status log?
  • -How little information can be surfaced while still changing behavior?
  • -When does an overlay help, and when is it just another distraction surface?
Q3
active

Learn Workflows

  • -How should reading activity, recall, proofs, and study sessions line up?
  • -What event history is actually useful inside the Learn workbench?
  • -How much of the learning loop belongs in Mesh versus the browser UI?
Q4
open

Desktop Agency

  • -How should personal-usability stay separate from the browser surfaces?
  • -Which desktop hooks are durable enough to be treated as provider contracts?
  • -Where should operator attention live as the control plane grows?

Relevant Background

Relevant context for this slice of the work: University of Manitoba psychology and HCI research, software work across consulting, SkipTheDishes, Datomar Labs, and ReLease / Cios, and the current private control-plane stack.

U of M
Psychology + Computer Science
APGV / PacificVis
Verified HCI publication venues
Tracker / Overlay / Learn
Current repo surfaces

Talk About The Interface Boundary

If you want to talk about attention tracking, overlay surfaces, Learn workflows, or adjacent control-plane design, reach out.

[email protected]