All is Motion

Tag: robotics

  • Robot Learns the World as Motion

    A robot that learns the world as motion — companion notes
    Companion notes · read alongside the demo

    A robot that learns the world as motion

    It acts, remembers, and even uses tools — without ever needing to know what anything is.

    This is a short guide to a small working system. The animated demo shows it step by step; these notes explain what you are watching and why it is unusual. The one idea underneath everything: technology is fundamentally motion, not objects.

    01The idea, plainly

    Almost every robot today is taught to recognise objects — this is a cup, that is a door — and then to act on them. This system does the opposite. It never stores what a thing is. It stores only what its movements do: touch this, turn that way, and the world changes so. To the robot a dial is not “a knob” — it is a place where a turning motion changes something, reversibly. The object dissolves into the relationship between a motion and its effect. Names turn out to be a story we add on top; underneath, it is all motion.

    This comes from a theory with two halves that are mirror images of each other. Using a tool is a motion that produces a trace in the world (a scratch, a turned dial, a knapped stone). Reading a trace — what an archaeologist does — is the same thing run backwards: from the mark, recover the motion that made it. One process, two directions.

    FORWARD · use a tool motion trace INVERSE · read a trace trace motion
    The robot runs the forward direction. The archaeologist runs the inverse. Same problem, opposite ways.

    The robot in the demo is the forward half, built. The inverse half — reading traces — is what we build next, and it matters for the robot too (see the last section).

    02The cycle, step by step

    This is the core, and it mirrors the demo exactly. Each line is a stage the robot passes through, the function that runs it, and what it means in plain terms. The first nine are how it discovers a move from scratch; the last three are how it reuses what it learned.

    Discover — learning a move with no labels

    1. agent.engage()
      Reach toward something. No contact yet — just moving closer.
    2. world.contact_begin()
      Touch. The instant of contact opens a “move” — touching is what starts recording.
    3. record() · apply_step()
      Move through the contact, measuring force, distance and speed. This trio is Θ — the single currency everything is recorded in.
    4. world.contact_end()
      Let go. Releasing ends the move. One clean unit of motion has been captured.
    5. segment_stream()
      Cut the continuous stream of experience into moves — at every touch-and-release.
    6. cluster_symmetry_first()
      Recognise the kind of move from its shape alone — a turn, a push — by its symmetry. No object label is used.
    7. bind_effects()
      Notice what the move did: the dial’s angle changed, and it can be turned back — reversible.
    8. memory.add()
      File the experience — as a motion, tied to where and when. It never stores the word “knob”.

    Reuse — acting on a goal with what it knows

    1. Goal(…) → notice_problem()
      A goal arrives (“nudge that angle”). It searches memory and finds a match: “I already know a move for this — right here.” No need to explore again.
    2. execute() · compare() · revise()
      Do the move, check that what happened matches what it expected, and update the record.
    3. — result —
      Now the robot “knows” there is a turnable thing here it can operate — learned entirely as motion.
    The modules behind those calls
    controlsthe world: things that turn a motion into a change (Δ = T(Θ)) agentthe effector and its low-stakes “childhood” exploration segmentationcut the stream into moves at contact / release primitivesrecognise the kind of move by its symmetry bindingwhat the move did, and whether it can be undone memorytime-stamped records, keyed by place and motion — never by name action_cycledecide: do I know a move for this goal, or do I need something new? executeact, compare to prediction, write the outcome back extensionuse a tool when a goal is out of reach (below) profilesthe force-vs-motion curve of a contact (below)

    03What makes it unusual

    No objects. The whole cycle runs without a single object category. This isn’t an omission — the currency it thinks in (force, distance, speed) simply has no slot for “what a thing is”. So it can meet a dial it has never seen, recognise the turn, and act — because it transfers by what a motion does, not by what a thing is called. A new object that behaves oddly can’t break a category, because there are no categories to break.

    τ1 · here (x,y) TURN → angle ▲ reversible · “knob” A single memory: a motion, its effect, a place and a time. Notice the missing noun.
    What the robot stores. Experience accumulates as motion-records, never as a list of objects.

    One currency. Because every engagement — a turn, a push, a reach — is recorded in the same three measures, they can all be compared, remembered, and reasoned about together. That shared currency is what lets the robot carry a lesson from one situation to another.

    The shape of a touch. Instead of just recording how much force a contact used, the system keeps the whole curve of how force changed as it pushed. From that one curve, several things it used to work out separately just fall out: how much effort the move cost, whether it was reversible (does the curve return the way it came?), and — the vivid one — the signature of a material breaking under pressure (force climbs, then suddenly collapses). That break is exactly the moment a camera’s view of “sudden movement” could be bound to, giving the picture its meaning.

    04Using a tool

    This is the theory’s central claim, and the demo’s companion scene shows it: when something is out of reach, the robot reads the problem as distance, finds a stick, and extends its own body so the same reach now works — then remembers that new ability for next time. That is “technology as boundary-extending motion” in action. Notably, finding-and-using a tool is the same operation as choosing a known move — the robot just searches the environment for something whose length closes the gap, instead of searching its memory for a motion.

    can’t reach entrain a stick → same motion now reaches
    Reach falls short → find something whose length closes the gap → the boundary extends. A new skill is banked.

    05What comes next — reading the world backwards

    So far the robot only knows what it did. The next piece to build is the inverse model — reading a trace to recover the motion that made it. This is the archaeological half of the theory, and it is not a side-quest: the robot needs it to reason about a world it did not fully witness. When it returns to a place and finds something changed, or must judge the state of a machine from the marks of past use, it is reading a trace — inferring a motion it never saw. Change-detection in the current system is already a first, tiny version of this. The full inverse model turns the robot from something that only remembers its own actions into something that can read what happened.

    Where this stands. Everything above runs as working code. That proves the ideas are coherent and buildable — the whole thing behaves as one system. It does not yet prove they survive the messiness of the real world: real sensors are noisy and real materials are harder than a simulation. Showing that is the next order of work. For now, the honest claim is the strong one: a philosophy built for archaeology and human evolution turned out to compile, unchanged, into a functioning robot mind — and it did so without ever needing to know what anything is.
    Companion to the animated demo (how_it_works.html) and the motion_sim code · allismotion.org
    A cartoon of the mechanism, faithful in order and idea, simplified in detail.
    How the robot learns — a motion, not a thing
    Objectless motor cycle

    How the robot learns — a motion, not a thing

    allismotion.org · Θ = (ΔF, Δd, Δv)
    Discover
    ? not yet explored S¹ · rotary symmetry Θ F d v GOAL · nudge angle +0.8
    Memory — what it stores (motion records, no nouns)
    Call sequence — what runs, in order
      STEP 01

      A cartoon, not the real geometry — but the order of operations is faithful to the code.

    1. Universal Maintenance Design: Making Infrastructure R2-Accessible

      How Designing for Robots Creates Better Systems for Everyone

      Part 3 of the R2 Astromech Project series

      In the previous posts, I explained why we need helper droids and traced how we lost the modular design philosophy that would have made them possible. Now I want to introduce a concept that could actually change how we build infrastructure: Universal Maintenance Design.

      This isn’t science fiction. It’s a practical extension of existing accessibility principles that could be implemented by governments, standards bodies, and forward-thinking organizations tomorrow. More importantly, it might be the only way we successfully integrate helpful robotics into society at scale.

      The core insight is simple but profound: when you design infrastructure to be maintainable by robots, you make it better for humans too.

      The Universal Design Foundation

      Let’s start with what already works.

      How Curb Cuts Changed Cities

      In the 1970s, disability rights activists fought for curb cuts—those sloped transitions between sidewalks and streets. The argument was straightforward: wheelchair users couldn’t navigate cities designed only for walking.

      Cities resisted. Curb cuts would be expensive. They’d require redesigning thousands of intersections. Was it really worth it for such a small percentage of the population?

      Then something unexpected happened. Once cities installed curb cuts, everyone benefited. Parents with strollers found navigation easier. Delivery workers with hand trucks moved more efficiently. Cyclists had smoother transitions. Travelers with wheeled luggage appreciated the design. Even pedestrians found the gentle slopes easier on their knees.

      This is the essence of Universal Design: modifications made for specific accessibility needs often create better experiences for everyone.

      The seven principles of Universal Design are:

      1. Equitable Use – usable by people with diverse abilities
      2. Flexibility in Use – accommodates wide range of preferences and abilities
      3. Simple and Intuitive Use – easy to understand regardless of experience
      4. Perceptible Information – communicates effectively regardless of conditions
      5. Tolerance for Error – minimizes hazards and adverse consequences
      6. Low Physical Effort – efficient and comfortable to use
      7. Size and Space for Approach and Use – appropriate regardless of user size or mobility

      These principles transformed public infrastructure. Automatic doors help wheelchair users and parents carrying children. Audio signals at crosswalks aid blind pedestrians and distracted phone users. Tactile paving guides vision-impaired travelers and warns everyone of platform edges.

      Universal Design doesn’t just solve accessibility—it reveals better design that was always possible.

      The Robotic Maintenance Challenge

      Now apply this thinking to infrastructure maintenance.

      The Current Problem

      Modern electronic and mechanical systems are designed exclusively for human maintenance. This creates barriers for robotic systems that could provide more consistent, safe, and cost-effective maintenance in many environments.

      Just as buildings designed only for non-disabled users created barriers for people with disabilities, infrastructure designed only for human hands and cognition creates barriers for robotic maintenance systems.

      Consider what humans bring to maintenance:

      • Binocular vision with excellent pattern recognition
      • Dexterous hands with tactile feedback
      • Ability to improvise with available tools
      • Contextual understanding of “normal” operation
      • Communication skills to ask for clarification
      • Decades of accumulated experience

      Now consider what robots bring:

      • Consistent, repeatable procedures without fatigue
      • Work in hazardous environments (radiation, toxic gas, extreme temperatures)
      • 24/7 operation without breaks
      • Perfect memory and documentation
      • Parallel operation across multiple locations simultaneously
      • Sensing capabilities beyond human range (infrared, ultrasonic, electromagnetic)

      These aren’t competing approaches—they’re complementary. But current infrastructure design assumes only human maintenance, forcing robotic systems to overcome unnecessary barriers.

      Universal Maintenance Design: Core Principles

      Let me propose an extension of Universal Design principles specifically for infrastructure maintainability by both human and robotic systems.

      Principle 1: Equitable Use

      Definition: Infrastructure systems should be maintainable by any appropriately equipped maintenance system, regardless of whether it is human-operated, robotic, or hybrid.

      Implementation requires:

      • Standardized diagnostic interfaces accessible to both human technicians and robotic systems
      • Multiple access methods accommodating different maintenance approaches
      • No maintenance procedures that inherently exclude robotic execution

      Real-world example: A network router that provides both traditional CLI access for human administrators and a standardized robotic diagnostic port (SCOMP link) with the same functional capabilities. The human can SSH in and run commands. The robot can connect physically and query the same information through a machine-optimized protocol. Neither approach is privileged—both work equally well.

      Why this helps humans: When diagnostic interfaces are standardized for robots, human technicians also benefit. No more hunting for vendor-specific tools. No more memorizing different command syntaxes for each manufacturer. The standardization that makes robotic access possible also makes human access more consistent.

      Principle 2: Flexibility in Use

      Definition: Systems should accommodate a wide range of maintenance capabilities, techniques, and preferences.

      Implementation requires:

      • Multiple interface options (physical, wireless, optical) for the same diagnostic functions
      • Scalable access levels from basic status to deep diagnostic information
      • Support for different robotic form factors (wheeled, tracked, flying, manipulator-based)

      Real-world example: An industrial motor controller that offers SNMP for network-based monitoring, a physical diagnostic port for direct connection, thermal signatures readable by infrared sensors for contactless analysis, and acoustic patterns detectable through vibration analysis. A human technician might use SNMP from their laptop. A wheeled robot might use the physical port. A drone might use thermal imaging. All approaches access the same underlying status information.

      Why this helps humans: Multiple access methods mean you can diagnose problems without physically accessing equipment. The thermal signature that helps a drone identify overheating also helps a human with a thermal camera spot issues from a safe distance. The acoustic patterns that enable robotic vibration analysis also help experienced human technicians hear problems developing.

      Principle 3: Simple and Intuitive Use

      Definition: Device interfaces should be predictable and self-explanatory to maintenance systems, minimizing the need for specialized knowledge about specific manufacturers or models.

      Implementation requires:

      • Consistent interface patterns across device types and manufacturers
      • Self-describing capabilities and status reporting
      • Standardized error codes and diagnostic procedures

      Real-world example: All Ethernet switches use the same physical connector type, orientation, and diagnostic protocol regardless of manufacturer, similar to how USB ports are universally recognizable. When a robotic maintenance unit encounters an unfamiliar switch model, the device itself describes its capabilities: “I am a 24-port managed switch, I support these diagnostic commands, my current status is X, here are my available interfaces.”

      Why this helps humans: Self-describing devices are a gift to human technicians too. Imagine arriving at an unfamiliar facility and having equipment that tells you how to interact with it. No more frantically searching for documentation. No more guessing which ports do what. The machine explains itself clearly to both robots and humans.

      Principle 4: Perceptible Information

      Definition: Critical system information should be available through multiple sensing modalities to accommodate different robotic capabilities and environmental conditions.

      Implementation requires:

      • Visual status indicators machine-readable through standardized patterns
      • Electromagnetic signatures for contactless status detection
      • Acoustic patterns for system diagnosis
      • Physical indicators readable through tactile sensors

      Real-world example: A building’s electrical panel includes LED status arrays with standardized patterns for visual inspection (green pulse = normal, red flash = fault, amber solid = warning). It also emits distinct electromagnetic field patterns readable by Hall effect sensors without any physical contact. Different components produce characteristic acoustic signatures indicating component health. Physical labels use raised text and Braille for tactile identification.

      Why this helps humans: Multi-modal status indication means you can diagnose problems even when some sensing methods aren’t available. Electrical panel labels in Braille help vision-impaired technicians, but they also help anyone working in poor lighting. LED patterns optimized for machine vision are also clearer for human color-blind technicians. Acoustic signatures that robots detect mathematically are the same sounds experienced humans learn to recognize by ear.

      Principle 5: Tolerance for Error

      Definition: Systems should minimize hazards and consequences of accidental or erroneous maintenance actions.

      Implementation requires:

      • Fail-safe mechanisms preventing damage from incorrect robotic procedures
      • Clear identification of high-risk operations requiring human oversight
      • Reversible diagnostic procedures with automatic state restoration

      Real-world example: Diagnostic ports that automatically disconnect power when accessed, preventing damage from probe insertion during energized operation. When a diagnostic session ends, the system automatically restores normal operation. High-voltage or high-risk procedures require explicit multi-factor authorization that a robot cannot bypass without human confirmation. All diagnostic actions are logged with before/after snapshots, allowing rollback of configuration changes.

      Why this helps humans: Safety mechanisms designed for robots protect humans too. Automatic power disconnection during diagnostic access protects both robotic probes and human fingers. Explicit authorization requirements for dangerous procedures prevent both robotic mistakes and human errors made under time pressure. Automatic state restoration means both robots and humans can perform diagnostics without fear of leaving systems in undefined states.

      Principle 6: Low Physical Effort

      Definition: Maintenance operations should be efficient and comfortable for both human and robotic systems.

      Implementation requires:

      • Minimal force requirements for connections and access
      • Ergonomic positioning for human reach and robotic manipulation
      • Automated or semi-automated procedures reducing repetitive operations

      Real-world example: Magnetic coupling diagnostic ports that require minimal insertion force and provide secure, aligned connections through magnetic attraction. A human technician can connect with one hand without looking. A robotic manipulator achieves reliable connection despite positioning imprecision. The connection is self-aligning and provides tactile/magnetic feedback confirming proper seating.

      Why this helps humans: Low-force connections help everyone. The magnetic coupling that makes robotic connection reliable also helps human technicians working in cramped spaces, wearing thick gloves, or dealing with reduced grip strength. Ergonomic positioning that accommodates wheeled robots also helps humans who can’t stand for long periods or have limited reach.

      Principle 7: Size and Space for Approach and Use

      Definition: Appropriate space should be provided for approach, reach, manipulation, and use regardless of user body size, posture, mobility, or maintenance equipment type.

      Implementation requires:

      • Clearance specifications accommodating both human technicians and various robotic form factors
      • Multiple approach angles for maintenance access
      • Consideration of robotic reach envelopes and manipulation constraints

      Real-world example: Network equipment racks with diagnostic ports accessible from multiple angles and heights. A standing human technician can reach ports at chest height. A wheelchair user can access ports positioned lower. A wheeled robotic unit can approach from the front or side. A flying drone can access ports on top of the rack. No single “correct” position is assumed—the infrastructure accommodates diverse maintenance approaches.

      Why this helps humans: Space for diverse approaches helps humans with different body types and abilities. The clearance that lets a wheeled robot navigate also accommodates technicians using mobility aids. Multiple approach angles help humans working in cramped spaces reach equipment from whatever direction is available. Height variations that accommodate different robotic form factors also help humans of different statures work comfortably.

      The SCOMP Link: A Universal Interface Standard

      Let’s get specific. What would a modern implementation of the SCOMP link actually look like?

      Physical Layer

      Connector Design: The physical connector needs to balance several requirements. It should use magnetic coupling for self-alignment and low insertion force—a robot with imperfect positioning can still make reliable contact, and a human can connect without precise alignment. The connector provides both power and data through the same interface, eliminating the need for separate connections. Weatherproof variants exist for outdoor infrastructure, sealed against moisture and dust. The form factor is small enough for embedded systems but robust enough for industrial environments.

      Multiple Form Factors: Different infrastructure types need different approaches. Network equipment uses panel-mount versions integrated into rack hardware. Industrial machinery employs robust IP67-rated versions surviving harsh factory environments. Building systems incorporate low-profile versions mounting flush with walls. Outdoor infrastructure deploys weatherized versions with UV-resistant materials and sealed contacts.

      Logical Layer

      Protocol Architecture: The SCOMP protocol operates on a hierarchical access model. Level 1 provides surface status—basic operational state, performance metrics, and last maintenance timestamp. Level 2 offers subsystem diagnostics including component-specific health indicators, interface statistics, and configuration validation. Level 3 enables deep analysis with internal state variables, historical performance data, and predictive failure indicators.

      Self-Description: Devices advertise their capabilities upon connection. They declare their type, model, and manufacturer. They list available diagnostic interfaces and supported maintenance procedures. They report current operational status and environmental operating conditions. They specify security and access requirements. This self-description means a maintenance system encountering an unfamiliar device can immediately understand how to interact with it.

      Authentication and Security: Security is built into the protocol from the beginning, not added as an afterthought. Cryptographic authentication verifies both device and maintenance system identities. Read-only access is the default; write operations require explicit authorization and are always logged. Rate limiting prevents denial-of-service attacks through repeated queries. All communications can be encrypted end-to-end when required by security policy.

      Information Architecture

      State Exposure: Devices expose their state through standardized schemas. Operational status indicates whether the device is functioning normally, in warning state, or experiencing faults. Performance metrics provide quantitative measurements like throughput, temperature, power consumption, and resource utilization. Environmental data reports ambient conditions affecting operation. Dependency information shows relationships to other systems.

      Historical Context: Beyond current state, devices provide historical context. Maintenance logs record all service activities with timestamps and outcomes. Component wear tracking uses standardized metrics for degradation assessment. Predictive indicators flag potential failures before they occur. Trend data shows performance evolution over time.

      Human-Readable Translation: The SCOMP protocol includes provisions for human-readable interpretation. Technical status gets mapped to operational impact—”disk utilization 95%” becomes “storage capacity critical, recommend cleanup within 24 hours.” Maintenance recommendations are prioritized by urgency and business impact. Risk assessments automatically evaluate failure consequences.

      The Network Fuse Concept: Security Through Design

      One of the most powerful applications of Universal Maintenance Design is the concept of R2 units functioning as “network fuses”—sacrificial components that protect larger systems.

      How Network Fuses Work

      Traditional electrical fuses protect circuits by creating an intentional failure point. When current exceeds safe levels, the fuse breaks the circuit, protecting downstream equipment. The fuse is designed to fail; that’s its job.

      R2 units as network fuses operate on the same principle:

      Normal Operation Mode: The R2 unit positions itself as a trusted intermediary within a network segment. It facilitates communication between devices while continuously monitoring their behavior. It provides translation and diagnostic services to human operators. It maintains complete logs of all device interactions and state changes.

      Anomaly Detection: The R2 unit continuously compares device self-reported state against observed network behavior. It watches for patterns indicating compromise—unusual traffic volumes, unexpected communication patterns, devices claiming normal operation while exhibiting abnormal behavior, or attempts to access resources outside normal parameters.

      Failure Mode Activation: When the R2 unit detects compromise with high confidence, it immediately transitions to failure mode. It disconnects itself from the network segment, breaking the trust relationship. It alerts human operators with complete forensic data about the detected anomaly. It isolates the affected segment, preventing lateral movement of the compromise. The R2 unit has “failed” in the sense that it’s no longer providing services, but that failure protects the larger infrastructure.

      Recovery: After investigation and remediation, the R2 unit can be restored from known-good state. The compromised segment can be examined in isolation. The complete activity log enables forensic analysis. The network resumes normal operation with confidence in containment.

      Why This Improves Security

      Current security approaches try to make every device impenetrable. Universal Maintenance Design with network fuses takes a different approach: assume compromise will happen, but design for rapid detection and containment.

      Current approach problems: Compromised devices often operate normally from external perspective. Anomalous behavior has no baseline for comparison since devices don’t expose standardized state. Breaches go undetected for an average of 207 days according to IBM research. Lateral movement happens easily because there are no circuit breakers.

      Network fuse advantages: Device state is continuously monitored through standardized SCOMP interfaces. Any discrepancy between claimed state and observed behavior is immediately flagged. Compromise is contained within minutes, not months. The R2 unit’s logs provide complete attack timeline for forensic analysis. The intentional failure point prevents cascade effects into critical infrastructure.

      Implementation: A Practical Roadmap

      This isn’t theoretical. Universal Maintenance Design can be implemented progressively, starting tomorrow.

      Phase 1: Standards Development (Year 1)

      Open Standards Body: Establish an international working group for Universal Maintenance Design standards. Include representatives from robotics, infrastructure, accessibility, and security communities. Develop open specifications with public comment periods. Create reference implementations demonstrating feasibility.

      SCOMP Protocol Specification: Define the physical connector standard with multiple form factors for different applications. Specify the protocol layers from physical through application level. Establish the device self-description schema. Create the authentication and security framework. Develop conformance testing procedures.

      Device Profile Repository: Build a community-maintained database of device capabilities and standard interfaces. Establish versioning and update procedures. Create validation frameworks for profile accuracy. Enable crowdsourced contributions with peer review.

      Phase 2: Pilot Programs (Years 1-3)

      Government Buildings: Implement Universal Maintenance Design in new public infrastructure projects. Retrofit existing critical facilities with SCOMP-compatible monitoring. Deploy R2-style maintenance units in pilot locations. Measure maintenance cost reductions and reliability improvements.

      Academic Research: University programs develop prototype robotic maintenance systems. Research programs validate the principles in diverse environments. Student projects contribute to the device profile repository. Publications document successes and challenges.

      Industry Partnerships: Forward-thinking manufacturers adopt SCOMP interfaces in new products. Retrofit adapter modules get developed for legacy equipment. Early adopters gain competitive advantages through superior maintainability. Case studies demonstrate return on investment.

      Phase 3: Regulatory Integration (Years 3-5)

      Building Codes: Update building codes to require Universal Maintenance Design in new construction. Establish minimum requirements for diagnostic interface accessibility. Create incentives for retrofitting existing infrastructure. Phase in requirements progressively by building type.

      Industry Standards: Professional organizations incorporate UMD principles into best practices. Certification programs for UMD-compliant infrastructure emerge. Insurance companies offer premium reductions for compliant facilities. Procurement requirements include UMD specifications.

      Right to Repair Alignment: Leverage existing right-to-repair legislation momentum. Frame UMD as extending repair rights to both humans and robots. Build coalitions with consumer advocacy groups. Use economic arguments about reduced total cost of ownership.

      Phase 4: Ecosystem Development (Years 5+)

      Robotic Maintenance Industry: Specialized maintenance robots emerge for different infrastructure types. Service companies offer robot-augmented maintenance contracts. Competition drives innovation in maintenance automation. Human-robot collaborative maintenance becomes standard practice.

      Training and Education: Technical schools teach Universal Maintenance Design principles. Technician training includes working alongside robotic systems. Engineering programs incorporate UMD into curriculum. Professional development programs enable career transitions.

      Continuous Improvement: Standards bodies update specifications based on field experience. New device profiles are continuously added to the repository. Security research identifies and addresses emerging threats. The ecosystem evolves organically while maintaining backwards compatibility.

      Why This Matters: The Broader Implications

      Universal Maintenance Design isn’t just about making R2-D2 possible. It’s about fundamentally reimagining our relationship with infrastructure.

      Economic Benefits

      Reduced Maintenance Costs: Standardized procedures eliminate the need for vendor-specific training. Robotic maintenance reduces labor costs for routine tasks. Predictive maintenance catches failures before they cause downtime. Extended equipment lifecycle through better maintenance practices.

      Improved Reliability: Consistent, repeatable maintenance procedures reduce human error. 24/7 monitoring catches problems earlier. Parallel operation across multiple locations enables rapid response. Better documentation enables more effective troubleshooting.

      Enhanced Safety: Robots handle hazardous maintenance tasks, reducing human exposure. Confined spaces, toxic environments, and dangerous heights become safer. Emergency response improves through robotic reconnaissance. Accident rates decline when robots take the most dangerous work.

      Social Benefits

      Improved Accessibility: Infrastructure becomes more maintainable by people with diverse physical capabilities. The standardization that helps robots also helps human technicians with disabilities. Remote diagnosis enables maintenance work from anywhere. Career opportunities expand for people previously excluded by physical requirements.

      Better Working Conditions: Technicians focus on interesting problems rather than routine checks. Physical demands of maintenance work decrease. Career longevity improves as work becomes less physically taxing. Human expertise gets augmented by robotic capabilities rather than replaced.

      Environmental Sustainability: Extended equipment lifecycle reduces electronic waste. Better maintenance improves energy efficiency. Predictive failure prevention reduces resource waste. Modular design enables repair rather than replacement.

      The Integration Challenge

      Here’s the crucial point: Universal Maintenance Design might be necessary for successful robotic integration into society.

      Without standardized interfaces, every robot needs custom programming for every infrastructure type. Without predictable access patterns, robots can’t reliably perform maintenance tasks. Without security built into the design, robotic access creates new vulnerabilities. Without consideration for diverse form factors, infrastructure accessibility limits robotic capabilities.

      We can keep building robots that struggle with infrastructure designed for humans, or we can design infrastructure that welcomes both human and robotic maintenance. One path leads to expensive, fragile automation that never quite works. The other leads to robust, reliable systems that benefit everyone.

      The Archaeological Perspective

      I keep returning to my archaeological background because it provides crucial insight into how technologies succeed or fail.

      Lost technologies weren’t inferior—they were unsupported: Roman concrete wasn’t forgotten because we found something better. The economic and social systems that transmitted that knowledge collapsed. The technology was excellent. The support structure disappeared.

      Universal Maintenance Design is an investment in infrastructure knowledge preservation: When maintenance procedures are standardized, documented, and machine-executable, that knowledge becomes much harder to lose. When devices self-describe their interfaces, the information stays with the artifact. When robotic systems can query unfamiliar devices, we’ve created a resilient knowledge system.

      We’re designing not just for today’s robots, but for future systems we can’t yet imagine: Just as curb cuts helped wheeled luggage users decades before luggage wheels were common, SCOMP-compatible infrastructure will benefit robotic systems we haven’t invented yet. The accessibility we build in today creates opportunities for innovations we can’t predict.

      This is infrastructure as archaeology in reverse: We’re deliberately designing artifacts with sufficient context and standardization that future systems—whether human or robotic—can understand and maintain



      All Is Motion – Enhanced Homepage

      them. We’re embedding the maintenance manual into the infrastructure itself.

      Next Time

      In Part 4, I’ll dive into the actual implementation on the Jetson Nano—the real code, the real challenges, and what I’ve learned from building a prototype R2 network scanner. We’ll explore the discovery sequence, protocol handling, the AI translation layer, and yes, procedural R2 sound generation.

      We’ll also examine the training data challenge: how do you teach an AI to translate technical device status into human-readable language? What does expert knowledge look like when digitized? How do we capture the intuition experienced technicians bring to diagnosis?

      The technology exists. The principles are sound. The economic case is compelling. What we need now is the will to build infrastructure that serves both humans and robots—and the vision to see that those aren’t opposing goals.

      Previously in this series:

      Next: Part 4 – Building in Public: Network Discovery & The Curious Astromech

      The R2 Astromech Project is open source and welcomes collaboration on Universal Maintenance Design principles. If you’re interested in SCOMP protocol specification work, government infrastructure applications, or accessibility research, join the conversation. Together we can build the infrastructure we should have had all along.

      Github link

      About the author: I’m an archaeologist and AI researcher who studies how societies preserve (or lose) technical knowledge across generations. Universal Maintenance Design applies archaeological methodology to modern infrastructure: designing today’s systems to remain comprehensible to tomorrow’s maintainers, whether human or robotic.

    2. The Death of the Helper Droid: How Modular Design Philosophy Gave Way to Vendor Lock-in

      A History of Lost Technologies and Changed Incentives

      Part 2 of the R2 Astromech Project series

      In the first post, I explained why I’m building an R2-D2 style helper droid—a universal translator for machines that can diagnose infrastructure, speak multiple protocols, and tell you what’s actually wrong in plain language. But that raises an obvious question:

      If this is such a good idea, why doesn’t it already exist?

      The answer isn’t technical. We have all the necessary components. The answer is historical and economic—and it follows a pattern archaeologists recognize immediately: technologies get abandoned when the incentive structures that sustained them collapse.

      Today, I want to trace exactly how we got from Industrial Automaton’s brilliant R2 design philosophy to the vendor-locked nightmare we inhabit now. This isn’t just about Star Wars droids. This is about a fundamental shift in how we build technology, and what we lost in the transition.

      Industrial Automaton: A Case Study in Modular Design

      Let’s start with what made the R2 series revolutionary, according to the (admittedly fictional) history.

      The Merger That Changed Everything

      Industrial Automaton was formed from the merger of Industrial Intelligence and Automata Galactica—two companies with very different philosophies. The merger was contentious:

      • Automata Galactica acquired Industrial Intelligence through superior profits
      • Industrial Intelligence employees resisted, encrypting their project files
      • Hackers eventually cracked the encryption, revealing plans for the “Intellex” computer system
      • Industrial Intelligence sued over use of their blueprints, but the legal attention to their own encrypted files forced them to abandon the case
      • The legal battle lasted a decade, damaging the P-series reputation and costing enormous sums

      This origin story is actually perfect for understanding tech industry dynamics. The legal warfare over proprietary technology, the encryption of internal knowledge, the decade-long dispute—these are patterns we see constantly in modern tech.

      But what emerged from this messy merger was something remarkable.

      The R2 Design Philosophy: Four Core Principles

      1. Standardized Universal Interfaces

      The R2’s SCOMP link (Ship Computer Access Port) was a universal interface that could connect to any ship system. Physical standardization meant the same connector worked across all manufacturers. Logical standardization ensured consistent query protocols regardless of ship type. No vendor-specific adapters were required, and power plus data flowed through a single connection point.

      The Intellex IV computer core contained over 700 different spacecraft configurations—not because each ship type required custom code, but because the interface layer was standardized. R2 didn’t need to “know” every ship; it knew how to ask ships about themselves.

      2. Deliberate Modularity and “Wasted Space”

      Industrial Automaton’s engineers did something counterintuitive: they included empty space inside the R2 chassis specifically for user modifications. This was inspired by Corellian ship-building practices—the Millennium Falcon philosophy of “hot-rodding” standard designs. The R2 body wasn’t packed tight with components. It had room for additional tool appendages, upgraded sensors, extended battery packs, and user-specific customizations that couldn’t have been predicted at design time.

      Standard appendages could be quickly swapped out. Arms were fully retractable with consistent mounting interfaces. This wasn’t just “nice to have”—it was designed in from the beginning.

      3. Transparent State Exposure

      R2 units were designed to interface with ships that wanted to be understood. Systems in the Star Wars universe exposed their internal state through standardized diagnostic protocols. Reactor status was clearly reported through standard channels. Hyperdrive diagnostics remained accessible via SCOMP link without proprietary tools. Life support systems broadcast their operational state. Navigation computers provided complete telemetry without vendor-specific software requirements.

      This wasn’t a security vulnerability—it was infrastructure designed for maintenance. The Death Star’s systems could be accessed by R2-D2 precisely because Imperial engineers followed (mostly) standard protocols for critical infrastructure.

      4. Aftermarket Ecosystem as Business Model

      Here’s the brilliant part: Industrial Automaton made money from openness. They offered after-market modification packages including underwater propellers for aquatic environments, jet thrusters for atmospheric flight, enhanced sensor packages, and specialized tool complements for specific mission profiles. Users equipped R2s with diverse accessories, creating a competitive modification community. This extended product lifespan, created ongoing revenue streams, built user loyalty, and established R2 as a platform rather than a product.

      The modularity wasn’t charity—it was smart business. Industrial Automaton monopolized the droid market by being open, not closed.

      The Unix Philosophy: Earth’s Industrial Automaton Moment

      We actually had this. For a brief, shining moment in computing history, we built systems on these exact principles.

      The Unix Design Philosophy (1970s-1990s)

      Early Unix embodied modular design thinking:

      “Do one thing and do it well”:

      • Small, composable tools (grep, sed, awk)
      • Standard input/output interfaces (pipes, text streams)
      • No tool needed to understand every other tool
      • Chain simple components to build complex behaviors

      “Everything is a file”:

      • Devices, processes, hardware—all exposed through consistent file interfaces
      • /dev/ provided standard access to hardware
      • You could query system state by reading files
      • Transparency was a design goal, not an afterthought

      “Expect output to become input”:

      • Tools designed to interoperate
      • No vendor-specific formats required
      • Plain text as universal interchange format
      • Pipeline philosophy: ps aux | grep python | awk '{print $2}' | xargs kill

      Open standards as default:

      • TCP/IP: open protocol, anyone could implement
      • SMTP: email standard, not vendor-controlled
      • HTTP: web built on open specifications
      • DNS: distributed, standardized name resolution

      This was the Industrial Automaton approach applied to operating systems. And it worked brilliantly.

      The Internet’s Open Era (1990s-early 2000s)

      The early internet was built on radical interoperability:

      Open protocols:

      • Anyone could run a web server (Apache was free and open-source)
      • Email servers talked to each other regardless of vendor
      • IRC, Usenet, Gopher—open standards, multiple implementations
      • View source: you could learn by reading how others built things

      Interchangeable services:

      • Switch email providers without losing functionality
      • Host your website anywhere, DNS just worked
      • RSS feeds let you aggregate content from any source
      • No platform could lock you in because everything spoke standard protocols

      Right to tinker:

      • You owned your hardware and could modify it
      • Software came with source code or at least documentation
      • Hardware repair manuals were available
      • Tinkering was expected, not prohibited

      This era felt like living in the Star Wars universe—your droid (computer) could talk to any ship (server), using standardized protocols, without vendor permission.

      The Turning Point: When Incentives Changed

      So what happened? How did we get from that to iPhones you can’t repair and smart home devices that only work with specific apps?

      The Dotcom Crash and the “Walled Garden” Solution (2000-2007)

      The dotcom crash changed everything. Companies that survived learned a harsh lesson: you can’t make money giving things away. AOL’s model suddenly looked prescient with its curated content instead of the open web, proprietary client instead of standard browsers, dial-up network users couldn’t leave, and monthly subscription revenue that actually worked.

      Apple’s iPod/iTunes ecosystem (2001) demonstrated the new model masterfully. The proprietary connector (30-pin, later Lightning) meant you needed Apple cables. DRM-protected music only played within Apple’s ecosystem. Tight hardware/software integration prevented third-party modification. Everything “just worked”—but only within the walled garden. The market rewarded this approach handsomely. Apple’s market cap exploded. The lesson was clear: control the ecosystem, control the revenue.

      The Smartphone Revolution (2007-2012)

      The iPhone launched in 2007 and fundamentally changed the rules. It was closed by design from the beginning. You couldn’t replace the battery initially. Installing apps from outside the App Store was prohibited. Accessing the filesystem like a normal computer was impossible. Repairs required Apple-authorized technicians or would void your warranty.

      But it worked beautifully. The seamless user experience, apps that “just worked” together, no command line or configuration files, and no tinkering required created something consumers genuinely wanted. The security through obscurity and vendor control meant fewer malware problems than open platforms faced.

      The market spoke loudly: consumers preferred “it just works” to “you can modify it.” And who could blame them? The Unix command line intimidated normal users. Configuring X11 was arcane magic. The open web was increasingly full of malware and security nightmares. The tradeoff seemed reasonable: Give up control and modularity, get reliability and ease of use.

      Cloud Services and SaaS (2008-2015)

      Then came the cloud revolution. The new paradigm was “you’ll own nothing and be happy.” Google Docs replaced Word files you controlled. Spotify replaced MP3s you owned. Cloud storage replaced local files. Apps became services, not software you bought once and used forever.

      The data center model drove massive centralization of computing resources. APIs replaced open protocols, and crucially, APIs were vendor-controlled rather than standardized. Your data lived on their servers, under their terms. Interoperability only happened when vendors explicitly allowed it. The subscription economy emerged fully formed with monthly fees instead of one-time purchases, creating continuous revenue streams. Features were held hostage to payment—ask anyone using Adobe or Microsoft Office. You couldn’t use old versions anymore; forced upgrades became the norm.

      This was the complete opposite of Industrial Automaton’s model. Instead of selling you a droid you owned and could customize, companies rented you access to their droids, which you could only use according to their constantly evolving terms of service.

      IoT and the Smart Home Disaster (2012-present)

      The final nail in the coffin came with the Internet of Things. Every vendor created their own ecosystem with zero interoperability. Philips Hue requires a Hue bridge and Hue app. Google Nest demands a Google account and Google cloud services. Amazon Ring needs an Amazon account, Amazon servers, and Amazon AI. Samsung SmartThings insists on a Samsung hub and Samsung protocols.

      Fragmentation became a feature rather than a bug. Devices deliberately don’t interoperate with competitors. Hubs are required to “translate” between vendor protocols. Updates can brick devices—anyone remember Insteon? When a company goes bankrupt, your devices become expensive paperweights with no recourse.

      The “smart” home turned out to be incredibly stupid. Light bulbs now require firmware updates. Door locks need cloud services to function at all. Thermostats won’t work if the internet goes down. Cameras can’t record locally without a subscription. We went from “lights that turn on when you flip a switch” (100 years of reliable operation) to “lights that might turn on if the cloud service is operational and your Wi-Fi is working and the firmware hasn’t bricked itself during an overnight update.”

      The Economic Logic: Why Vendor Lock-in Won

      Here’s the uncomfortable truth: vendor lock-in is more profitable than openness, at least in the short term.

      The Razor and Blades Model

      Industrial Automaton sold R2 units and aftermarket modifications. Modern companies realized they could achieve far better financial outcomes with a different approach.

      The old R2-style model meant selling a droid for 4,245 credits, then selling optional modifications for additional revenue. The user owned the droid and kept it forever. Revenue was essentially one-time plus occasional upgrades—a transaction that concluded.

      The new subscription model flipped this entirely. Companies give away hardware at cost or even subsidize it, then require monthly subscriptions for the device to function properly. The user never owns the device, merely licensing its functionality. Revenue becomes perpetual, predictable, and consistently growing rather than a single transaction followed by silence.

      Consider the Ring doorbell as a concrete example. The device itself costs €100-200, often on sale to drive adoption. But cloud recording requires a €10/month subscription. Over five years, that’s €600 in subscription fees. Total revenue per customer reaches €800 compared to €200 for a one-time purchase. The strategic brilliance is that customers can’t leave without buying entirely new hardware, creating incredible switching costs and customer lock-in.

      The Support Contract Trap

      Enterprise equipment manufacturers took this logic even further by weaponizing complexity. Cisco switches require specialized IOS knowledge and device-specific command syntax. Their SNMP MIBs aren’t publicly documented, forcing dependence on vendor tools. Configuration backups use vendor-specific formats that don’t export cleanly to competitors. Interoperability is technically possible but practically prevented through intentional friction.

      This complexity makes support contracts mandatory rather than optional. Firmware updates hide behind support paywalls. Security patches require active support agreements—no support means you can’t deploy critical security fixes. TAC (Technical Assistance Center) access costs thousands annually. The security implications alone force you to maintain these contracts indefinitely.

      Certification programs complete the lock-in. CCNA, CCNP, and CCIE certifications cost thousands in training and exam fees. They create professional identities where certified individuals defend their expertise investment. These skills deliberately don’t transfer to other vendors, meaning switching costs apply to entire IT departments, not just infrastructure. Companies find themselves locked in through human capital investment, not just sunk equipment costs.

      The Platform Economy

      Software companies perfected the lock-in model through network effects. Everyone uses Microsoft Office, creating inescapable pressure for you to use Office too. All contractors use Adobe Creative Cloud, forcing subscription adoption. Company-wide deployment of Slack or Teams means individual employees must join whether they prefer it or not. You literally can’t collaborate effectively without joining the platform—individual choice becomes impossible.

      The data hostage situation compounds over time. Years of email accumulate in Gmail. Decades of files pile up in Dropbox. Photos fill iCloud storage. Migration is technically possible but practically prohibitive given the time investment, potential data loss, and workflow disruption. Companies understand this perfectly—they’re not selling you storage, they’re buying your future captivity.

      API access completes the trap. Want to build on our platform? Follow our rules, which we can change at any time. We can modify APIs without warning, breaking your integrations. We can revoke access for any reason, including building features that compete with our roadmap. Your business depends entirely on our goodwill, and that power imbalance isn’t accidental—it’s the business model.

      What We Lost: The Four Pillars

      Comparing Industrial Automaton’s R2 design to modern “smart” devices reveals exactly what we sacrificed:

      1. Universal Interfaces → Proprietary APIs

      Then (R2 SCOMP link):

      • Physical standard: same connector everywhere
      • Logical standard: consistent protocols
      • No vendor lock-in: any certified droid could interface
      • Openly documented: standard specifications available

      Now (IoT ecosystem):

      • Each vendor has different connector/protocol
      • Cloud APIs that vendors control completely
      • Deliberately incompatible to prevent competition
      • Documentation behind NDAs or nonexistent

      2. Transparent State → Security Through Obscurity

      Then (ship systems):

      • Diagnostic ports exposed system health
      • Status clearly reported through standard channels
      • Maintenance was designed-in, not retrofitted
      • Transparency = maintainability

      Now (modern devices):

      • Internal state hidden behind vendor apps
      • No standardized diagnostic interfaces
      • “Security” used as excuse for opacity
      • Maintenance requires vendor tools or isn’t possible at all

      3. User Ownership → Licensed Access

      Then (R2 ownership):

      • You bought the droid, you owned it
      • Modifications were expected and supported
      • Aftermarket was a feature, not a bug
      • Device worked forever without ongoing payments

      Now (subscription model):

      • You license access to functionality
      • Modifications void warranty or are technically prevented
      • Must maintain subscription or device stops working
      • Planned obsolescence through forced updates or discontinued support

      4. Modular Ecosystems → Walled Gardens

      Then (R2 aftermarket):

      • Third-party modifications thrived
      • Competitive modification communities
      • Extended lifespan through upgrades
      • Platform thinking: droid as base for expansion

      Now (closed ecosystems):

      • Third-party accessories prohibited or crippled
      • “Made for iPhone” certification required (with fees)
      • Devices designed for replacement, not repair
      • Product thinking: complete unit or nothing

      The Counterargument: “But It Just Works!”

      The defenders of the modern approach have a point: walled gardens do deliver better user experience, at least initially.

      The Apple Argument

      Tight integration genuinely enables valuable features. Seamless handoff between devices lets you start work on an iPhone and continue on a Mac without thinking. Consistent UI/UX across the ecosystem means you learn once and apply everywhere. Better security through code signing and app review catches many threats before they reach users. The famous “it just works” experience doesn’t require technical knowledge—my parents can use an iPhone confidently, something they absolutely couldn’t do with Linux.

      This is real value. It’s not marketing hype. The walled garden solves genuine problems that plagued open systems.

      But consider the cost: that €999 phone can’t have its battery easily replaced. When Apple decides the device is “obsolete,” it stops receiving updates regardless of functionality. You can’t install software Apple doesn’t approve. Your entire digital life becomes locked to one vendor whose business interests may not align with yours indefinitely.

      The Security Argument

      Closed systems demonstrably provide better security for average users. App Store review catches at least some malware before it reaches users. Code signing prevents unsigned executables from running without explicit user override. Sandboxing limits the damage from compromised apps. Average users receive protection from themselves and their potentially risky choices.

      This security benefit is also real. Open Android ecosystems do experience more malware infections. The Wild West of downloadable executables led to massive bot networks and ransomware. Security through centralized control works for many threat models.

      But consider the alternative approach: Open source allows security researchers to audit code directly. Community-found vulnerabilities often get fixed faster than vendor-discovered ones. No single point of failure exists if one company is compromised. Users can verify security claims rather than trusting vendor assertions. The question isn’t whether walled gardens provide security, but whether they’re the only way to achieve it.

      The “Tragedy of the Commons” Problem

      The open web developed real problems that walled gardens solved. Spam ruined email, necessitating Gmail’s aggressive filtering and centralized reputation systems. Malware ruined software downloads, necessitating app stores with review processes. Ad tech ruined the web experience, necessitating walled garden apps that controlled the advertising ecosystem. Trolls ruined public forums, necessitating heavily moderated platforms with centralized authority.

      The open internet had genuine, serious problems. Walled gardens solved them, often elegantly. Users flocked to these solutions because they worked better than the chaotic alternative.

      But we threw out the baby with the bathwater. We solved spam by centralizing email control. We solved malware by prohibiting unapproved software installation. We solved ad tech by… actually, we just moved it into the walled gardens, where it became even more invasive because vendors now controlled both the platform and the advertising. The solutions worked, but they came with costs we’re only now beginning to calculate.

      The Path We Didn’t Take: Modular Security

      Here’s what bothers me most: we didn’t have to choose between “open chaos” and “controlled gardens.”

      A modern R2 design would demonstrate how:

      Secure Modularity Is Possible

      Cryptographic signing works without centralization. Apps could be signed by developers and verified by users directly, eliminating the need for a central app store while still allowing stores to curate and recommend. Revocation remains possible without vendor control through distributed certificate transparency. F-Droid on Android proves this model works in production today, providing security without centralized gatekeeping.

      Sandboxing doesn’t require vendor lock-in. Apps can run in isolated containers with permissions managed by the operating system rather than platform vendors. Standard security models can work across platforms without vendor control. Flatpak, Snap, and AppImage on Linux demonstrate that sandboxing and open platforms coexist successfully.

      Open protocols can include robust authentication. SCOMP-style interfaces could require proper authentication without vendor gatekeeping. Cryptographic verification of identity uses well-established standards. Standard protocols don’t inherently mean insecure protocols—TLS, SSH, and mTLS prove that open standards can provide enterprise-grade security without vendor control.

      What Industrial Automaton Got Right

      The R2 design wasn’t “open” in the sense of “no security whatsoever.” It was standardized interfaces with proper authentication. SCOMP links required proper authorization before granting access. Diagnostic access was logged and auditable by system administrators. Emergency overrides existed but were controlled and traceable. The famous “garbage masher” scene worked because R2 had legitimate access credentials, not because systems had no security.

      This is the model we should have followed. Instead of “everything is locked down, trust no one, vendor controls all,” we could have built “standard interfaces, cryptographic authentication, user-controlled authorization.” Instead of “app store or nothing,” we could have “multiple trusted repositories, user choice of curators, open standards for distribution.” Instead of “cloud services or local control, pick one,” we could have “federated protocols, self-hostable instances, interoperable by design.”

      Why This Matters Now

      We’re at an inflection point. The current model is showing cracks:

      Right to repair legislation is forcing companies to provide parts and documentation. The EU’s Digital Markets Act is requiring interoperability. Open source AI is challenging proprietary model lock-in. Users are getting fed up with subscription fatigue and planned obsolescence.

      This is our chance to reclaim modular design philosophy.

      The R2 astromech project isn’t just a fun weekend hack. It’s a demonstration that we can build helper droids with modern security standards and open protocols. That vendor lock-in isn’t necessary for good user experience. That transparency and maintainability can coexist with security.

      Next Time

      In Part 3, I’ll introduce Universal Maintenance Design—an extension of Universal Design principles to make infrastructure inherently maintainable by both humans and robots. We’ll explore how designing systems to be “R2-accessible” actually improves security, reduces costs, and extends equipment lifespans.

      We’ll also dive into the SCOMP link specification I’m developing: what would a modern universal diagnostic interface actually look like? How do you balance security with accessibility? What can we learn from past attempts like SNMP, and why did they fail to become truly universal?

      The technology exists. The standards are achievable. What we need is the will to build infrastructure that serves users instead of vendors.

      Previously: Part 1 – Teaching an Old Droid New Tricks: Why I’m Building R2-D2

      Next: Part 3 – Universal Maintenance Design: Making Infrastructure R2-Accessible

      The R2 Astromech Project is open source. R2-astromech

      If you’re interested in helping design a SCOMP protocol specification, contributing device profiles, or just want to discuss why your “smart” doorbell stopped working after a firmware update, drop a comment below.

      About the author: I’m an archaeologist who studies how technologies get lost when economic incentives shift. Turns out you can apply archaeological methodology to modern infrastructure: systematic documentation, stratigraphic analysis of protocol layers, and asking “why did they stop building things this way?” Current research interests include astromech droids and why we can’t have nice things.

      Written in collaboration with Claude AI