← Ambient Intelligent Systems

Appendix: the lexicon

Appendix

The load-bearing nouns, spelled exactly as the system spells them. If prose elsewhere disagrees with this page, this page wins.

The programs

  • Seer — the reasoning server: voice, server-side retrieval, identity, attribution spans. Owns every spoken word. Serves chat and speech over HTTP, and runs a gRPC "mothership" channel that Totem nodes dial into.
  • Totem — the local memory node: vectors + knowledge graph, persisted as store files the user owns, their names embedding the node's UUID. Serves gRPC for query, library, and graph calls, plus a gated administrative surface. The node UUID is the database identity.
  • Bonnie — the macOS ambient assistant; acts, supervises the other two as child processes (or adopts healthy external ones).
  • Conduit — the shared wire-contract definitions all three programs build against.
  • Sinatra / Oracle / Gita — Seer's interior: the personalization engine (park→sentiment→train→infer); the P2P retrieval mesh with trust-scored edges; the attribution layer.

The ambient vocabulary

  • AmbientWorld — the closed vocabulary of places: one enum case per compiled plugin owner (23 cases), in bijection with the plugin catalog. Not extensible by packages, ever.
  • AmbientWorldClass — what kind of place a world is: workspace, dataSource, service, perceptionOnly.
  • hasEyes — the separate, narrower truth: whether a live observer currently ships (Xcode, Pages, TextEdit only). A taxonomy claim is not an observation claim.
  • AmbientRealm — where a fact lives; exactly two cases: .native(AmbientWorld) and .dynamic(logicalID). Singular "realm." A dynamic realm rides the .otherApps host lane and resolves its taxonomy through its ApplicationRegistration. There is no "browsing realm" or "chrome realm" — those are Ability packages; the browser is one shared workspace realm. Scrivener deliberately has no world case; it lives at .dynamic("scrivener").
  • Eyeless — an axis that cuts across both realm cases; never a third case.

The capability vocabulary

  • Ability — a portable family of behavior and operating policy (writing). Declares a paradigm: discipline, applicationExpertise, systemControl, or reasoning.
  • Skill (Bonnie's) — one machine-readable instruction inside an Ability (writing.type-at-cursor), with an access class (seamless or reversible).
  • Agent Skill / SKILL.md (Anthropic's) — a different thing entirely: a folder of markdown instructions loaded into an agent's context. Chapter 7 compares the two.
  • Capability — the typed contract (effect class, permissions, constraints, confirmation requirements) that makes a Skill safe to run. A hard floor owned by Bonnie; package preference cannot bypass it.
  • .bonnie package — canonical JSON carrying abilities, skills, capabilities, value schemas, Totem projections, and optionally a dynamic plugin; integrity-digested, optionally Ed25519-signed. Bounded data — never prose, never code.
  • Dynamic plugin — declarative application knowledge inside a package, interpreted by Bonnie's one compiled "Remote Hands" engine. No executable source travels in a package.
  • AbilityRuntimeSnapshot — the immutable, UUID-addressed registry revision frozen for exactly one turn.
  • Receipt — the privacy-safe record of what a Skill invocation actually did; raw text, prose, code, and secrets never enter it.
  • Projection — the redaction-and-persistence policy deciding what may reach Seer or Totem; the only door to durable memory.

The paradigm

  • Ambient Intelligent System (AIS) — an architecture in which the AI works with the user, not for the user: parallel to the human, composing with the person's world (the person included, as the component that always wins), on infrastructure the person owns.
  • Temporal / spatial composability — the two axes from the 2026 preprint chapter 8 maps onto this stack: complete reversal of a component's effects on removal; declared dependencies resolved reactively, where unmet means dormant, not broken.