Lessons from the Fuchsia/Pixel-9 Custom-OS Specification (Prior Art)

The chosen software approach, specified in depth. This 60-page document details the plan the programme committed to from the start: fork Fuchsia/Zircon and build the product layer on top. Zircon, DFv2, FIDL, Magma, and Starnix are taken as-is; the entity/agent product layer is written from scratch; hardware comes up on a separate track. The Pixel-9 hardware target has since been archived in favor of the demo brick (ADR-0007), but the Fuchsia-fork software approach is current, not superseded. Original illustrations are retained under diagrams/prior-art-fuchsia-spec/ with provenance.

Status and Provenance
What Transfers vs What Is Superseded
The Reuse Taxonomy (carried forward)
The Two-Track Strategy (carried forward)
Substrate / Platform / Shell Decoupling
Entity / Agent Data Model
Camera and Telephony Ceilings
Reverse-Engineering Legal Frame
Precedent Lessons
MVP Configuration Ladder
Module Inventory by Status
Related Documents

Status and Provenance

Source: a founder-supplied 60-page engineering specification, "Custom Mobile OS Specification Based on a Fuchsia/Zircon Fork · Pixel 9" (original title was in Russian; translated here) — the detailed specification of the chosen fork-Fuchsia approach. SHA-256 and redistribution status recorded in sources/provenance/PROVENANCE.md. The binary is not redistributed (integrate-not-store); seven key illustrations are retained locally as prior art. This document is the English digest of its transferable, platform-independent content.

What Is Current vs What Changed

Concept	Status now	Where it lives in AgentOS
Reuse taxonomy (as-is/wrap/port/reverse/fork/from-scratch)	Transfers	This doc; applied to demo-brick modules
Two-track strategy (product-in-emulator / hardware separately)	Transfers	QEMU track + demo brick (HW-017)
substrate/platform/shell + typed contracts	Transfers (as our IDL + capabilities)	AOS-ARCH-005, AOS-ARCH-022
entity/agent data model, CRDT, global history	Transfers (core product)	AOS-ARCH-001, product vision
Camera two-layer tuning, HDR+, honest ceiling	Transfers	AOS-HW-018 tuning rule, RES-011
RE legal frame, clean-room	Transfers	AOS-LEGAL-003, PROD-014
Precedent lessons (Asahi/Replicant/dahliaOS/Genode)	Transfers	This doc
Fuchsia/Zircon as the kernel base	Current — the chosen base	Forked, per AOS-ARCH-002
FEMU as acceptance target	Current (Fuchsia emulator)	FEMU/QEMU harness
Starnix as compat basis	Current — taken as-is	Linux/Android compat via Starnix
Pixel 9 / Tensor G4 (hardware target)	Archived (hardware only)	ADR-0007, demo brick
Exynos 5400 modem RE (Pixel-9 only)	Archived with Pixel 9	Pre-certified module on demo brick (HW-018)

The Reuse Taxonomy (carried forward)

Every module is classified by one of six statuses; the status sets the effort, the legal regime, and the risk. This is platform-independent and is the recommended lens for demo-brick modules too.

Status	Meaning	When	Typical risk
AS-IS	take ready-made unchanged	fits directly	low
WRAP	run existing in a wrapper/compat layer	Linux-form userspace not worth rewriting	medium (ABI)
PORT	move code/knowledge to our platform	RE knowledge exists under another framework	high (volume)
REVERSE	clean-room reverse engineering	closed interface, no open implementation	very high
FORK	fork and maintain a branch	need a divergent base	medium (maintenance)
FROM-SCRATCH	write new code	original functionality	scales with scope

Applied to the demo brick, most hardware is AS-IS (pre-certified modules), drivers are PORT (from RP1/PiSP docs), the product layer is FROM-SCRATCH, and there is almost no REVERSE — which is precisely why the demo brick is faster than the Pixel-9 plan, where REVERSE dominated.

The Two-Track Strategy (carried forward)

The central strategic decision transfers directly: decouple product from hardware into two parallel tracks with different risk profiles. Track A (product) is built and demonstrated in emulation now, delivering most of the vision with no hardware blockers; Track B (hardware) is the slower bring-up. They converge only at the end. For AgentOS this is the QEMU/simulator track (product, capability model, instant modes, entity/agent) running now, and the demo-brick hardware track proceeding in parallel — exactly the PLAN-018 lane structure.

Substrate / Platform / Shell Decoupling

Three horizons with explicit contracts so the product never depends on hardware: substrate (kernel, drivers, HAL, firmware), platform services (entity store, sync, history, integrations, camera/modem as services), and shell/UI. The contract between platform and substrate is stable typed interfaces, so the same product runs on a mock substrate in emulation and on real drivers on hardware without changes above the contract line. In AgentOS this is the IDL/type system (AOS-ARCH-005) plus the capability model (AOS-ARCH-022): the mock-substrate idea becomes the simulator target of AOS-DEMO-012.

Entity / Agent Data Model

The product core is a typed entity graph — nodes (person, project/task, document, event/place, message, device) with typed edges (participates-in, relates-to, derived-from) carrying time, source, and confidence — over which agents with scoped capabilities extract, deduplicate, and link entities and maintain a global history. Deduplication is reversible and auditable (false merges destroy trust). State is local-first with optional CRDT sync; the cloud is transport/backup, never the source of truth. This is the platform-independent heart of the product and aligns with the portable system architecture (AOS-ARCH-001) and the voice agent's typed-action model (AOS-PROD-015).

Camera and Telephony Ceilings (honest)

Two ceilings stated plainly in the source, both still true and already reflected in current docs:

Camera. Open computational photography (HDR+ / Halide, libcamera) is real and portable, but the quality ceiling is manual per-sensor tuning (CCM, black level, noise profile, AWB/AE), not the algorithm. Result is "decent," not flagship, without closed tuning. This is the two-layer tuning-portability rule now in AOS-HW-018.
Telephony. On the Pixel-9 plan, the modem was a black box requiring transport + boot-sequence + command-set reverse engineering, with voice the riskiest milestone. The demo brick sidesteps this entirely by using a pre-certified cellular module with a documented interface (AOS-HW-018) — a concrete example of choosing AS-IS over REVERSE.

Reverse-Engineering Legal Frame

Interoperability RE is broadly permitted: EU Software Directive Art. 6 (decompilation for interoperability), US DMCA §1201(f) exception. Safe practice is clean-room: one side observes and documents the hardware interface and writes a specification; another implements from the specification without seeing original code (how Panfrost/Freedreno were built). Firmware blobs are used as-is, never modified; radio behavior is never altered. This is consistent with AOS-LEGAL-003 and the hard rules of AOS-PROD-014, and it applies unchanged regardless of kernel choice.

Precedent Lessons

Asahi Linux — a small team reverse-engineering modern silicon takes years, and its key multiplier was targeting Linux, where the driver ecosystem exists. Targeting a bespoke stack on undocumented silicon is harder — which is why decoupling tracks is mandatory. (Reinforces the demo-brick choice: buy documented modules, don't reverse a flagship.)
Replicant / libsamsung-ipc — years on one modem class, still not covering modern models: the modem is the most time-consuming block; live on data/SMS and treat voice as a risky milestone. (The demo brick avoids this via a pre-certified module.)
dahliaOS — a real Fuchsia fork exists; the value is not the act of forking but what is built on it. (Confirms the approach: forking Fuchsia is feasible and done before; the value is the product and the bring-up on top, not the fork itself.)
postmarketOS / Megapixels — open computational photography is real and portable, but the ceiling is sensor tuning, not the algorithm; calibrate camera expectations to "decent."
Genode / Sculpt — a microkernel capability OS can be a daily driver on open phone hardware (PinePhone); on a closed flagship the driver wall remains the barrier. (Supports building on documented hardware first.)

MVP Configuration Ladder (carried forward)

The spec defined cut-down configurations so value ships earlier; this ladder transfers, re-mapped to the demo brick and the fork:

Config	Includes	Deferred
MVP-A (product in emulation)	full product layer L6 + Starnix interop, in the Fuchsia emulator	all hardware
MVP-B0 (hardware alive)	kernel + display + input + Wi-Fi on the demo brick	GPU accel, modem, camera
MVP-B1 (with data)	+ cellular data/SMS via the pre-certified module	voice, camera
MVP-B2 (with camera)	+ basic photo (HDR+, before tuning polish)	flagship quality
Full	everything incl. voice and per-sensor tuning	—

Pragmatic order: get MVP-A demonstrable first (product in emulation, zero hardware blockers), then MVP-B0 (a Wi-Fi "tablet" without telephony), and only then modem/camera. This is exactly the two-track lane structure of AOS-PLAN-018.

Module Inventory by Status (reference)

The spec's full module map, re-expressed for the fork + demo brick. Kernel/userspace frameworks are FORK/AS-IS from Fuchsia; hardware is mostly AS-IS pre-certified modules (not REVERSE, unlike the Pixel-9 plan):

Layer	Module	Status
L0	Fuchsia tree	FORK
L0	Zircon, DFv2, FIDL, Magma, Scenic/Flatland, Starnix	AS-IS
L1	Board bring-up (demo brick: RP1/PiSP documented)	PORT
L1	Power island (nRF/ESP32)	FROM-SCRATCH firmware
L2	GPU/Magma driver	PORT
L3	Cellular (pre-certified module)	AS-IS
L4	Camera capture + libcamera	WRAP
L4	HDR+/Halide	AS-IS
L4	Sensor tuning	FROM-SCRATCH
L5	Starnix compat	AS-IS
L6	Shell, entity/agent, history, sync, integrations	FROM-SCRATCH

Fuchsia/Zircon-Fork Specification — Engineering Digest