Core Concepts

Version: 0.1.0

Table of contents

  1. Conceptual Hierarchy
  2. Protocol-Level Concepts
    1. FieldSpace
    2. Channel
    3. Capability
    4. Action
    5. State
    6. View (Optional)
  3. Client-Level Concepts
    1. Space
    2. Screen
    3. Pane / Frame
    4. Channel Binding
  4. Actor Roles
    1. User
    2. Agent
    3. Channel (as actor)
    4. Client System
  5. Key Principles
    1. 1. Protocol Boundary
    2. 2. State Exposure Requirement
    3. 3. Capability Declaration
    4. 4. Consumer Safety
    5. 5. Interaction Adaptivity

Conceptual Hierarchy

FieldSpace (protocol)
  └─ Channel (external service)
       └─ Capability (declared function)
            ├─ Data (read-only content)
            ├─ State (inspectable condition)
            └─ Action (invocable operation)

Client (e.g., ScreenSpace)
  └─ Space (persistent container)
       └─ Screen (logical display)
            └─ Pane / Frame (content region)
                 └─ Channel Binding (connection)

Protocol-Level Concepts

FieldSpace

The protocol itself. FieldSpace defines how channels expose capabilities and how clients consume them. The protocol is:

  • Declarative: Channels describe what they can do
  • Stateful: Channels maintain and expose current state
  • Capability-driven: Clients and agents reason over declared capabilities
  • Rendering-agnostic: Channels may suggest but do not control presentation

Channel

An external service that implements the FieldSpace protocol. A channel:

  • Exposes a manifest describing its identity and capabilities
  • Serves data through declared endpoints
  • Maintains and exposes state
  • Accepts action invocations
  • Optionally provides view hints for rendering

Channels are identified by reverse-domain identifiers (e.g., com.example.weather).

Capability

A declared function or feature that a channel exposes. Capabilities are typed:

Type Description Example
data Read-only content retrieval Video feed, weather data
state Inspectable current condition Playback position, selected item
action Invocable operation Play, pause, search
control Stateful control surface Volume, brightness
status Passive status indicator Online/offline, sync state

Action

An explicit, named operation that can be invoked on a channel. Actions:

  • Have declared inputs (parameters) and outputs (results)
  • Declare side effects (none, local, external)
  • Specify permission requirements (user, agent, confirmation)
  • Are idempotent where possible

State

The current condition of a channel or capability. State:

  • Is inspectable by clients and agents at any time
  • Is structured according to a declared schema
  • May be subscribed to for real-time updates
  • Is channel-authoritative (clients cache but don’t own)

View (Optional)

An advisory rendering suggestion from a channel. Views:

  • Are non-authoritative: clients may ignore them
  • Are platform-specific: web, tvOS, mobile hints
  • Are fallback-capable: channels declare degradation paths
  • Do not replace data/state exposure requirements

Client-Level Concepts

These concepts are defined by clients (like ScreenSpace), not the protocol. They are documented here for context.

Space

A named, persistent container for screens. Analogous to a “room” or “context”:

  • “Living Room”
  • “Office”
  • “Car Dashboard”

Spaces persist across sessions and devices.

Screen

A logical display surface within a space. A screen:

  • May map 1:1 with a physical display
  • May be virtual (e.g., a saved layout)
  • Contains one or more panes

Pane / Frame

A bounded region of a screen that displays content from a single channel binding. Panes:

  • Have position and size within a screen
  • Receive focus for navigation
  • Connect to exactly one channel binding

Channel Binding

A configured connection between a pane and a channel instance. A binding includes:

  • Channel identifier
  • Authentication credentials (if required)
  • Instance-specific configuration
  • Current state cache

Actor Roles

User

A human interacting with the client. Users:

  • Have full control within their permissions
  • Can override agent permissions per-channel
  • Authenticate with channels via the client

Agent

An AI companion that operates at the protocol level. Agents:

  • Observe: Read state from all channels freely
  • Reason: Understand capabilities and context
  • Suggest: Recommend actions to users
  • Act: Invoke actions (with declared permissions)

Agents operate on structured protocol data, not pixels. They never need to “see” the screen.

Channel (as actor)

The external service. Channels:

  • Expose capabilities to clients and agents
  • Cannot act on other channels
  • Cannot access client-side state directly

Client System

The platform itself (e.g., ScreenSpace). The client:

  • Manages sessions, layout, navigation
  • Mediates all channel communication
  • Enforces permission policies
  • Owns the rendering surface

Key Principles

1. Protocol Boundary

Everything above the protocol boundary is the client’s responsibility. Everything below is the channel’s responsibility. Agents operate at the protocol level, not the pixel level.

2. State Exposure Requirement

Even channels with custom rendering must expose semantic state via the protocol. This enables:

  • Agent understanding without vision
  • Cross-channel reasoning
  • Session persistence and resume
  • Accessibility

3. Capability Declaration

Channels declare what they can do. Clients and agents discover and reason over these declarations. Undeclared capabilities do not exist.

4. Consumer Safety

The protocol is designed for home, family, and public environments. Channels must:

  • Declare side effects honestly
  • Respect permission boundaries
  • Support graceful degradation
  • Avoid attention-hijacking patterns

5. Interaction Adaptivity

The protocol supports the full spectrum of interaction models:

Surface Input Interaction Level
TV + remote D-pad, select, voice Minimal
Phone/tablet Touch, gestures, keyboard Rich
Desktop Mouse, keyboard, shortcuts Full
Voice assistant Voice commands Agent-mediated
Signage None or touch Configurable

Channels declare capabilities; clients adapt interaction based on surface capabilities. A channel that works on a TV remote also works with full touch—the client mediates.


FieldSpace Protocol v0.1.0 — Core Concepts