CareTV is an open, room-based assistive communications, media, sensing, automation, and household communications platform. The immediate prototype is being built in a real home and is intended to become a reproducible appliance platform rather than a collection of unrelated apps.
The simplest family explanation is: CareTV is like FaceTime, except the house itself helps choose the right room, camera, microphone, speaker, and display automatically.
Windows and Chrome are prototype acceleration tools, not the permanent CareTV platform. Near-term work uses a fast Windows agent and Chrome-based headend because this enables rapid iteration.
Within roughly five years, the goal is a self-contained CareTV appliance stack: an OS-like environment with hardware abstraction, communications, AI, updates, diagnostics, UI, storage, and device control owned by CareTV rather than dependent on the Windows desktop experience.
CareTV should prefer documented, locally controllable interfaces and avoid unnecessary proprietary lock-in. Hardware should remain useful if a vendor cloud service disappears.
CareTV must be API-first from the beginning. The visible UI should consume CareTV-owned APIs rather than directly integrating with individual vendors, cameras, telecom providers, AI services, databases, or operating-system-specific services.
The API contract is intended to survive the transition from today's Windows/Chrome prototype to the future CareTV appliance platform.
CareTV APIs should be explicitly versioned so deployed appliances do not silently break when internals change.
Conceptual examples include /api/v1/rooms, /api/v1/cameras,
/api/v1/sessions, /api/v1/messages, and /api/v1/fax.
Request/response APIs can handle configuration and commands. Real-time state should use WebSocket, WebRTC data channels, Server-Sent Events, or another CareTV-controlled event transport. The front end should be able to subscribe to room changes, call state, incoming messages, fax delivery events, camera state, AI detections, and device faults.
Core in-home CareTV functions should continue working locally when the public internet is unavailable whenever the required devices are on the home network. Cloud services may extend CareTV but should not unnecessarily become dependencies for local room-to-room communications, camera viewing, or local automation.
During prototyping, Chrome is the visible headend and the Windows agent is the low-latency hardware/service layer. Chrome is an API client. Hardware-specific logic belongs behind CareTV APIs.
Mom's room camera is simultaneously a family-communication camera, documentary camera, machine-vision sensor, AI tracking source, and development platform.
Cameras are sensors, not storage appliances. A camera advertised as 8K does not meet the CareTV requirement if the 8K stream is only available to onboard memory. The useful image must be available live to CareTV.
CareTV should eventually hand communications from room to room as people move through the home. The system may choose the active camera, microphone, speaker, and display automatically while preserving manual override and observable state.
The first external-family prototype is an IP-only iPad experience for Grandma with one large action: CALL MOM. Grandma should see Mom's selected room camera and Grandma should appear automatically on Mom's television.
CareTV is intended to consolidate communication modes now split across separate products and legacy "lines":
MagicJack is a legacy dependency to be replaced. CareTV should own the user experience, identity, routing, transcription, room behavior, and communications history. External telecom providers should be treated as carrier gateways where public-number access or regulated telephone functions are needed.
CareTV's long-term communications platform should follow an open research-lab philosophy: public architecture, public protocol documentation, public capability descriptions, and open interfaces wherever practical.
Traditional VoIP must not define the limits of CareTV audio. Medical, assistive, machine-perception, or archival audio may use independent high-fidelity streams such as PCM, FLAC, or high-bitrate Opus while a telephone or WebRTC conversation is occurring.
Fax is not treated as a separate appliance. Fax is a legacy document transport attached to CareTV's unified communications system.
The first real-world fax workflow is communication with Social Security. CareTV should make the process substantially easier than manually operating a fax machine or disconnected web portal.
When a fax arrives, CareTV should automatically:
For an outbound fax, CareTV should be able to:
Automation should remove repetitive work, not blindly send sensitive documents to the wrong place. For government, medical, financial, or legal destinations, the system should support a human verification step for destination, document selection, and any required cover-page information before the initial transmission.
A fax should appear in CareTV alongside voice calls, SMS, documents, notes, and related events rather than in a separate silo. A Social Security interaction might therefore contain:
CareTV should not require an analog fax machine, fax modem, MagicJack, paper workflow, or telephone handset for normal fax operations. Fax becomes an API-driven legacy gateway managed by CareTV.
The CareTV front end must never be tied directly to a particular fax vendor. A logical CareTV API such as
/api/v1/fax/send, /api/v1/fax/jobs, and /api/v1/documents should sit in
front of whatever cloud fax provider is used today. Providers can be replaced later without redesigning the UI.
Video, audio, fax, messages, screenshots, documents, timestamps, and carrier receipts should remain preserved as source records. AI interpretation must remain distinguishable from the underlying source.
A waste-collection dispute is an early CareTV test of event documentation. A manually activated Trash Pickup Watch mode can record high-quality exterior PTZ video, timestamps, notes, and AI-assisted event markers while preserving the original source media.
CareTV is intended to enable lawful documentation and assistive operation, not indiscriminate surveillance. Camera placement, audio capture, call recording, retention, access, disclosure, and publication must remain subject to applicable law and explicit system controls.
CareTV / 8K Lab networking requires a standalone network appliance that performs switching and/or routing without depending on a Windows PC, digitizer workstation, or any other general-purpose computer.
This requirement exists because the lab must eventually support uncompressed or minimally compressed 8K research traffic on demand, even though most normal day-to-day media traffic will remain compressed.
More than four 100Gb ports, 25Gb breakout capability, multiple 10Gb RJ45 ports, and 200/400Gb uplinks are desirable higher tiers, but not substitutes for the minimum mixed fiber/copper requirement.
The CareTV / 8K Lab platform is also evolving into a distributed rendering and publishing environment. Multiple computers may operate as a coordinated cluster for generating, transcoding, localizing, and publishing 8K media rather than treating one workstation as the permanent center of all compute.
The cluster should be able to divide work across available machines for:
Rendering and publishing should be controlled through CareTV-owned APIs and a durable job queue rather than by manually operating individual machines. A front end should be able to submit a job once and let the cluster decide which machine performs each stage.
Conceptual resources include /api/v1/render-jobs, /api/v1/transcode-jobs,
/api/v1/localization-jobs, and /api/v1/publish-jobs.
A single source program should be able to produce multiple language-specific outputs from one versioned master. Each language variant should retain links back to the same canonical source asset, project, render settings, captions, audio track, metadata, and publication history.
YouTube uploads should become automated jobs rather than manual browser operations. The system should maintain versioned records of the exact rendered file, title, description, language, captions, thumbnail, destination channel/account, upload state, returned platform identifiers, and publication result.
The 100Gb fiber fabric is part of this compute architecture. Large 8K source files should move directly between storage and rendering nodes over the network without forcing the digitizer workstation to remain a routing or storage bottleneck.
The cluster controller should not be permanently tied to Windows. Windows may host early worker agents, but the long-term design should use CareTV-owned APIs, job definitions, manifests, and worker protocols that can run on future CareTV appliance nodes or other supported operating systems.
Every render and publication should be reproducible from versioned inputs and settings. The system should record source asset IDs, software/encoder version, language, codec, resolution, frame rate, render options, checksums, timestamps, worker node, and publication result.
Prototype equipment may cost more when it proves the correct architecture. The long-term goal is to reduce the system toward under $1,000 per installed CareTV room/unit where feasible, with potential future assistive-technology funding subject to actual program rules and approvals.
CareTV intends to publish its equipment lists. Hardware recommendations should favor reproducibility, documented interfaces, clear model numbers, replaceable components, and alternatives when products disappear.
CareTV development uses dated build roots:
https://8k.art/beta/_daily-builds/YYYY-MM-DD/
Meaningful iterations should receive new versioned filenames instead of silently overwriting historically referenced builds.
Every CareTV HTML artifact delivered by ChatGPT should include:
Daily build root: https://8k.art/beta/_daily-builds/2026-08-15/
Canonical spec: https://8k.art/beta/_daily-builds/2026-08-15/caretv-canonical-spec-2026-08-15-v004.html