CareTV Canonical Specification

1. Purpose

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.

2. Prototype vs. Product

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.

3. Open-System Requirement

CareTV should prefer documented, locally controllable interfaces and avoid unnecessary proprietary lock-in. Hardware should remain useful if a vendor cloud service disappears.

• Prefer Ethernet/IP, RTSP, ONVIF, NDI, WebRTC, SIP, HDMI, USB, SDI, documented APIs, and standard interfaces.
• Avoid mandatory vendor phone apps for basic operation.
• Keep architecture and protocol boundaries public wherever practical.
• Restricted capabilities must not become secret backdoors; they should be explicit, permissioned, logged, and auditable.

4. API-First Architecture

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.

4.1 Durable Resources

• people
• rooms
• cameras
• microphones
• speakers
• displays
• communications sessions
• voice calls
• messages
• fax jobs
• documents
• events
• recordings
• AI observations
• device health
• automations
• permissions and audit records

4.2 API Versioning

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.

4.3 Real-Time API

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.

4.4 Local-First Operation

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.

5. Chrome Headend and Local Agent

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.

• camera discovery and ingest
• physical and software PTZ
• GPU/NPU processing
• machine vision
• audio routing
• stream conversion and WebRTC
• telecom gateway integration
• fax and messaging gateway integration
• storage routing
• event logging and health monitoring

6. Mom's Room Camera

Mom's room camera is simultaneously a family-communication camera, documentary camera, machine-vision sensor, AI tracking source, and development platform.

• compact enough for dresser placement beneath the television
• excellent natural-looking faces in low household light
• continuous external power
• live output into CareTV; onboard recording is not part of the architecture
• 8K strongly preferred when genuine live 8K is available
• software PTZ is acceptable and may be preferable to physical PTZ

7. Live Output Is Mandatory

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.

8. Automatic AI Room Switching

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.

9. Grandma One-Button Intercom

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.

10. LAN and WAN Transport Policy

• Same home: prefer direct local high-quality media.
• Remote: use encrypted IP real-time transport.
• More upstream bandwidth: raise media quality automatically.
• Constrained upstream: degrade gracefully rather than fail.

11. Unified Communications Layer

CareTV is intended to consolidate communication modes now split across separate products and legacy "lines":

• voice calling
• video calling
• intercom
• SMS-style messaging
• fax/document delivery
• alerts and notifications
• caregiver messages
• room routing
• PSTN/SIP gateways where required

12. MagicJack Replacement

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.

13. Open Phone Company Principle

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.

14. High-Fidelity Medical and Assistive Audio

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.

15. Automated Fax Handling

Fax is not treated as a separate appliance. Fax is a legacy document transport attached to CareTV's unified communications system.

15.1 Immediate Use Case

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.

15.2 Inbound Fax Automation

When a fax arrives, CareTV should automatically:

1. receive the fax through the configured cloud fax/carrier API;
2. store the original received document unchanged;
3. assign a stable CareTV document/event ID;
4. record sender number, receiver number, timestamps, page count, and carrier status data;
5. generate a viewable PDF representation when necessary;
6. extract searchable text using document parsing/OCR when needed;
7. classify the document cautiously;
8. associate it with the appropriate contact, agency, case, or CareTV conversation;
9. surface it in the Chrome/CareTV headend;
10. create a durable audit trail without altering the original fax payload.

15.3 Outbound Fax Automation

For an outbound fax, CareTV should be able to:

1. select an existing CareTV document or generate a PDF;
2. show the intended destination before transmission;
3. send through the fax provider API;
4. track carrier transmission states;
5. record attempted, queued, transmitting, delivered, failed, and retry states where available;
6. retain the exact version of the document that was transmitted;
7. store the final delivery result with timestamps;
8. associate that fax with the relevant agency/contact/case timeline.

15.4 Human Verification for Sensitive Destinations

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.

15.5 Fax as a Conversation Transport

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:

• phone call
• call transcript
• faxed form
• fax delivery confirmation
• incoming response document
• human notes
• AI-generated summary linked to the original sources

15.6 No Physical Fax Dependency

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.

15.7 Fax API Abstraction

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.

16. Storage and Evidence Integrity

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.

17. Exterior Legal/Evidentiary Test Case

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.

18. Privacy and Legal Compliance

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.

19. Networking

• Wi-Fi is acceptable for immediate prototypes.
• Permanent endpoints should move toward wired Ethernet where practical.
• PoE is preferred where useful.
• The long-term lab/home backbone is expected to include 100Gb fiber.
• The bedroom/8K lab requires at least 16 RJ45 copper ports eventually.
• 10Gb copper is the target for high-performance endpoints where practical.
• Noise and heat are hard constraints because the lab is also a sleeping space.

20. Prototype Economics

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.

21. Equipment Publishing

CareTV intends to publish its equipment lists. Hardware recommendations should favor reproducibility, documented interfaces, clear model numbers, replaceable components, and alternatives when products disappear.

22. Daily Build and Versioning Rule

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.

23. Complete HTML Delivery Rule

Every CareTV HTML artifact delivered by ChatGPT should include:

• exact filename;
• complete HTML file;
• dated daily-build directory;
• expected full permalink;
• machine-readable permalink metadata inside the file;
• a visible human-readable permalink inside the page.

24. Current Canonical Reference

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-v003.html

25. Immediate Priorities

1. Get MOMS-CARETV working reliably over Wi-Fi.
2. Establish Mom's speakerphone and room endpoint behavior.
3. Build Grandma's one-button IP intercom.
4. Make Grandma appear automatically on Mom's television.
5. Add Mom's compact high-quality live camera.
6. Add the exterior evidentiary PTZ camera.
7. Stand up cloud-backed voice, SMS, and fax gateways.
8. Implement the first Social Security fax workflow through the CareTV fax API.
9. Replace MagicJack after the replacement path is proven.
10. Continue evolving the API-first front end and versioned canonical specification.