What Is Hardware / personal practice map

Gather resources.
Learn. Plan. Build.

Working source of truth
July 2026

A connected bank of physical and digital resources, concepts and vocabulary—joined to practical learning, executable plans and versioned prototypes.

The Resource Bank

This is everything the practice can draw from: verified physical inventory, the remaining Bill of Materials, digital tools and references, concepts and vocabulary, and the broader systems specification register. Availability and ownership remain explicit.

Bank architecture

52Verified purchase lines
0Digital resources
705System records
0Concept cards

Current inventory

Use material categories to answer a practical question: is this a durable machine, a tool, a reusable part, something that gets used up, bench infrastructure, or safety/reference material?

Digital tools and resources

Software you may install, reusable packages, GitHub repositories, datasets, research leads, inspiration and locally preserved source artifacts. “External” means available to consult—not installed or validated on your computer.

Concept bank, vocabulary and taxonomy

Concept Cards hold enduring creative grammar. Vocabulary entries explain technical terms and modalities. Taxonomy gives us a small shared language for connecting resources without forcing everything into one category.

Concept Cards

Ideas above individual builds

Open the concept library to see theses, invariants, tensions, protocols, ethical boundaries and descendant prototypes.

Open concept bank →
Specification register · not a purchase claim

Attention and articulation systems

This is the seeing-and-saying layer extracted from the larger BUS / WUT register. Construction materials were excluded. Each record preserves what it is, what role it plays, how it senses or articulates, where it lives in the stack, how mature the decision is, and what owned equipment already covers it. Download the source workbook ↗

IdentityItem, form and modelRoleSense, identify, interpret, coordinate, articulate, embody or governModalityRadar, vision, EEG, projection, audio, print and moreLayerPerson, object, room, edge, core, network or outputLifecycleRequired, recommended, optional or researchConnectionsProjects, dependencies, owned coverage and acceptance tests

System recordRole / modalityLifecycleProject / functionOwned coverage

How to read this: “Required” means required by the source design logic—not necessarily that you should buy it now. “Covered” means an owned item is an exact match or already covers the equipment class. Blank coverage is an explicit reconciliation gap, not proof that nothing you own could serve the role.

How the pieces fit together

Think in layers. A system can start simple—one local sensor and one output—and progressively add richer signals without replacing the whole foundation.

1
Local nodes
ESP32-S3 or Pico reads a radar, button, load cell, tag reader, or LED strip.
2
Room coordinator
Pi 5 logs events, serves a dashboard, holds state, and coordinates modules.
3
Experience output
Projectors, e-paper, light, sound, printed artifacts, or physical response.

Remaining / optional bill of materials

The things you just bought are marked covered or removed from the shopping queue. What remains is ordered by dependency, not novelty; prices are planning ranges, not live quotes.

Recognizable nameActual itemWhy it mattersQuantityUrgencyPlanning priceLink

Two safety rules worth memorizing: ESP32 and Pico GPIO are normally 3.3 V logic—a module accepting 5 V power does not mean its signal pins are safe at 5 V. You also now own leaded solder: label it separately, wash your hands after handling it, keep food and drink off the bench, and ventilate or extract the flux fumes.

Do not buy more of these yet

They would mostly create overlap, not new capability.

Current inventory · detail view

Quantity / source
Model / category
Start by learning
Use it with

Reliable evidence
Cannot establish
Start here
Use it with
Prototype intake worksheet