Owned Technology Map
A candidate project idea for using the Project Board to map a device or app you own: its components, dependencies, documentation, control and recovery options, preferring open source.
- 1Record knowledge (what you can inspect) separately from control (what you can modify or recover).
- 2Unknown internals stay in the map as explicit unknowns.
- 3A component graph, automatic inventory and agent access would need new implementation.
Designed Candidate undertaking; only the basic Project Board exists.
Words on this page, decoded click one for its card
Start with a device or application you own and a question about maintaining it. A useful map should let you trace its components, dependencies, data, interfaces, current state, available source, and ways to change or recover it. The same inquiry applies to a PC, phone, router, appliance, or application. Prefer more FOSS, better documentation, and greater replaceability, while recording where closed components limit that understanding and control.
This candidate undertaking, developed 2026-10-09, uses Atlas to keep its brief, questions, evidence, and judgments together. The direction is independent of Companion or the phone's operating system. The current Project surface can hold the undertaking; a dedicated component graph, automatic inventory, and agent access to its dossiers would need their own implementation. State of Work retains AtlasProject Board's delivery boundary.
What the map should retain
Start from one actual device or system and identify its parts. A GPU's silicon, firmware, kernel driver, userspace driver, compute runtime, libraries, and calling application are distinct components. Record relationships such as contains, runs on, initializes, depends on, exposes an interface to, and can replace. Each relation needs its own meaning and evidence.
The following is proposed dossier content, not a new LychD record family:
| Account | Material to retain |
|---|---|
| Identity and state | Exact model, hardware revision, installed versions, configuration, relevant limits, and dated observations. |
| Knowledge | Source revisions, manuals, schematics, programming references, protocol/format schemas, and the claims each supports. |
| Dependencies | Hardware, firmware, drivers, runtimes, libraries, services, required accounts, and compatibility constraints. |
| Control | Actual read/write operations, privilege and signing boundaries, modification/install paths, and independent local operation. |
| Recovery | Backups, export/restore, replacement options, failure detection, reconciliation, and tested recovery procedures. |
| Uncertainty | Missing source, undocumented behavior, unavailable observations, inferred interfaces, disputed claims, and tests that could resolve them. |
Aim to account for every identified component within the declared scope. Unknown internals remain part of that account. A list of nodes does not prove that hidden components are absent or that their behavior is fully understood.
Knowledge and control have different coverage
Ask separately what you can inspect, what is documented, what you have observed, what you can modify or install, whether it works independently of a vendor, and how you could recover it. These dimensions often diverge. Public source may be readable while installation is restricted. An opaque firmware image may have a documented interface and a verified update path. You may understand a hardware design without having a practical way to manufacture it. Keeping each fact separate makes the map useful for an actual decision.
FOSS increases the material available for inspection, testing, maintenance, and replacement. An open layer should improve its own entry in the map without making its dependencies open by association. Procurement compares these dimensions alongside the required capability: prefer greater openness and fewer opaque dependencies, and retain the limits of the selected equipment. Manufacturing every component is not a prerequisite for this undertaking.
Reverse engineering can target a missing format, protocol, or replaceable implementation. Recovered behavior remains tied to tested versions and cases. An inferred schema is a hypothesis until verified; passing one case does not establish all hidden behavior or a working replacement.
CPU firmware as a worked distinction
AGESA supplies AMD platform/silicon initialization in the host firmware stack. AMD openSIL opens a particular host initialization layer; AMD also describes substantial initialization by embedded microcontrollers before the x86 cores begin. Its presence therefore does not establish source coverage of every underlying firmware component, nor compatibility with an arbitrary motherboard.
CPU microcode patches have a separate loading path. The open Linux microcode loader consumes vendor patch binaries and applies matching updates to CPU cores. Record the patch identity, loading path, applicability, and observed version separately from AGESA and the surrounding BIOS.
Public interface schemas can still explain closed parts. The coreboot PSP integration guide documents firmware table structures and component types while leaving further firmware details to other, sometimes NDA-bound publications. Such a guide can support a precise structural map without claiming access to the implementation inside each image.
NVIDIA software as a worked distinction
NVIDIA's open GPU kernel modules publish a kernel-driver layer. The repository requires corresponding NVIDIA userspace components and GSP firmware. Its firmware integration documentation describes GSP-RM binaries obtained from the proprietary driver package. Kernel source, userspace implementation, and GPU firmware therefore need separate entries.
CUDA is a collection of interfaces, tools, runtimes, and libraries with different source and license coverage. Its SDK terms cover proprietary components and recognize separately licensed components; CCCL publishes source for Thrust, CUB, and libcu++. Inspect the actual components a workload uses rather than giving the entire ecosystem one openness label.
Mesa NVK implements Vulkan for NVIDIA GPUs. That is a different interface from CUDA's runtime and libraries. A workload could use an alternative compute backend only where its implementation, device support, and behavior are established; choosing an open driver alone supplies no application-portability evidence.
Make an agent's questions answerable
An agent examining a component should be able to answer a connected set of questions: what is it, what depends on it, which exact documentation applies, what has been observed, and which operations are available? The remaining gaps determine how far a proposed task can responsibly proceed. Keep every claim's versions, evidence, and conditions attached, and identify whether it is source-supported, experimentally established, inferred, disputed, or unknown.
Schemas describe shape; tests and observations establish particular behavior. An action contract also needs effects, current authority, limits, outcomes, and recovery. Reading a map grants no device access or authority to change firmware. Linking a dossier in AtlasProject Board does not automatically put it in model ContextBriefing Pack; Context owns that admission.
The first useful case is one system with a finite scope: identify its layers, trace one dependency from application to device, retain one opaque component, and answer one maintenance question from exact references. Change a version and verify that affected claims need review. A later agent integration should refuse to treat a missing reference as knowledge or an unverified operation as available control.
Keep each owner in place
AtlasProject Board keeps the undertaking and its judgments. Homestead may supply asset identity, custody, and maintenance facts while their owners retain them. Actual personal inventories, configuration, credentials, and device dossiers live outside the repository checkout; this guide retains only the reusable example.
Containers governs LychD's FOSS host support. A device's presence in a knowledge map does not make it a supported LychD host. Packaging owns source/build evidence, and Assimilation owns the separate study and promotion of foreign craft. The undertaking creates no new CompositionApp, device authority, or automatic execution path.