Writing

My first instinct was to feed the learning system everything: full visual field, complete joint state, all force channels. That was not architecture thinking. Constraining what a system perceives is an architecture decision with direct consequences for latency, convergence speed and deployment stability. The smaller the state space, the faster and more reliably it learns.

The RL policy suggests an action. The safety layer decides whether that action is permitted. The boundary between them is an architecture decision — it must be specified before training begins, not added afterwards when the system misbehaves. How you draw that line determines whether the system is deployable or just impressive in simulation.

Mechanical, electronics and firmware all move at different speeds and carry different revision costs. This is how I architect the decision process so that a change in one layer surfaces its implications in the others before it is too late to course-correct cheaply.

The solar mill stakeholders wanted batteries. The answer was obvious once you mapped the consequences across cost, operating environment, service network and firmware complexity together. It is almost never obvious when you look at one layer in isolation. A framework for making product direction decisions that accounts for the full system, not just the loudest constraint.

Every hardware project has two paths: optimise what exists or go for the disruptive approach. The decision is not technical. It depends on market readiness, your actual capabilities and what failure costs at each stage. This is the risk framework I use from Arduino proof of concept through to production — on the solar mill and everything since.

Software teams iterate fast. Hardware teams cannot afford to. This is a breakdown of when to move quickly, when to hold, and how to structure the review points so that the cost of a bad decision stays low for as long as possible in the development cycle.

Most embedded system failures I have seen did not happen in the firmware. They happened in the translation from technical capability to market execution. The battery decision on the solar mill. The irrigation valve redesign after three states of farmer interviews. The gap between R&D and product is where the real architecture work happens.

Monolithic embedded systems fail at handoffs. Every change cascades. Every integration is a negotiation. The fix is specifying clear interface contracts between modules before anyone builds anything. When the contracts are stable, teams work in parallel. When they are not, every change ripples through everything downstream.

Formal design processes assume you can foresee all consequences. You cannot. Neither can your team. Bounded rationality is not a bug in the process, it is the environment the process runs in. This is how I structure decision points to work within cognitive limits rather than pretend they do not exist.