I Am More Than the Sum of the Serial Numbers of All My Parts

Robot identities are trajectories: welcome to Identity Trajectory Engineering

In Fremont, they are dismantling production lines that built Model S and Model X. Not to improve a car, but to make space for something that is not a car: Cybercab and Optimus. They are not in homes yet, but the trajectory has already started. At this point, ignoring it is a choice.

These days, working on international partnerships in AI & Robotics, I start from the BOM. It’s a pragmatic way to read a complex system. You look at components, versions, serial numbers. It helps you build, and it leaves a trace. Even when something breaks, most of the time it gives you an answer.

It works.
As long as you are dealing with products.
Not here.

⸻

I — It’s Not a Dishwasher

A robot is not an appliance with hands or wheels. It’s not something you can classify by features and assume will remain stable once shipped. It is something complex enough that it could take a bus and deliver itself to the person who bought it.

And the difference is not only what it can do, but where it can go: inside people’s homes.

The environment matters. A home is unstructured—no cages, no taped lines on the floor defining safe paths and distances—and it also redefines exposure over time between humans and machines.

If you look at the problem through exposure, a different scale emerges.

A robot can be a weapon, a defense system, a collaborative tool, or an object of extreme intimacy—up to becoming a sex toy.

This is not a progression of capability. It is a progression of access, defined by distance and duration.

More access means more risk and more responsibility. It’s a property of the system, not the device.

A dishwasher executes. It doesn’t learn, adapt, or change behavior based on context. A robot does. And most importantly, it keeps changing after you ship it.

This is where the “product” model stops working. Not because it is wrong, but because it is insufficient.

In the automotive world—highly regulated and built on decades of history—autonomy has been accompanied by definitions, certifications, and licenses.

When a robot is delivered to your home, what license does it have?

⸻

II — Identity Is Not a State

Take two identical robots at origin and let them operate. They will diverge. Not because of defects, but because of trajectory.

Time, exposure, decisions under uncertainty, updates, external interventions—this is where the system actually changes.

Identity is not in the components.
It is not in the code.
It is in the sequence they go through.
Action is a point.
Identity is an arc.

Thinking in snapshots is convenient, but misleading. When something breaks, you go back to the serial number, the software version, the logs.

And you find nothing.
Because the system is no longer what it was.

I’ve been thinking about this for a while. As a reader of Asimov, I feel the need for something as deep and elegant as the Laws of Robotics. At the same time, I know they are not coming—at least not now.

I don’t see a way to embed universal laws deep enough into a robot’s code. And beyond the technical challenge, I don’t see the market incentive for such a binding choice.

This is how AI evolves: we move forward fast, chasing benefits and risks that keep growing.

If we cannot have Laws of Robotics, can we at least have direction?
Yes. And this time the inspiration comes from the stars: the Drake equation.
A robot’s identity is not static. It is determined by a path. I wrote it like this, after seeing systems change behavior in ways no version or log could fully explain:

RID: t → XR → Dε → e → Ω

This is not a mathematical formula. It is an operational lens. It tells you where to look when the system stops being explainable.

• t is time accumulation.

• XR is exposure—where the robot operates and for how long.

A robot in a kitchen four hours a day has a different XR than one that sleeps in the same room. This is not a feature difference. It is a trajectory difference.

• Dε is decision under error—autonomy and deviation.

• e is evolution—learning, environment, updates.

• Ω is control.

When something breaks, the question is no longer “which version is this?”
RID tells you where you are in the trajectory.

If XR increases, risk does not grow linearly.
If Dε is high, error is not an exception—it is a probability.
If e accelerates, identity shifts even without human intervention.

RID is not for prediction.
It is to avoid telling yourself the wrong story.
Control, if still available, comes at the end.

Ω.

And an EMERGENCY STOP button is not enough.
Not to control behavior.
You cannot press stop on a trajectory.

⸻

III — Identity Trajectory Engineering

I was at SpaceX years ago. A rocket does not launch unless everything is GO. This is not a bureaucratic checklist—it is an operational constraint: every team is responsible for its system, and for ensuring that system does not block others.

If you are ahead, you adjust. If you are behind, you catch up. Iteration is fast because the system is treated as one.

This is not a detail of organization. It is why some systems evolve and others accumulate delay. When the system is one, responsibility is shared but not diluted. Dependencies are not removed. They are managed.

Now apply this to a new category: high exposure, no product history, continuous evolution.

The need is the same.
The structure is not there yet.

AI, Product, Design, Legal. The functions are all there, and each optimizes its own domain.

Product introduces a feature. AI updates the model. Design opens a new interaction context. Legal prepares coverage.

Each decision is locally correct.

The outcome is not.

In a system that evolves over time under real exposure, these decisions do not remain local. They accumulate, interact, and drift.

When something breaks, the cause spans multiple teams and responsibility fragments. You go back to serials, versions, logs.

But the problem is not there.
Because the system has already become something else.

A product manager cannot hold all of this together. Every launch has a control room. But for a robot in someone’s home, the control room does not exist. When Apollo 13 had a problem, Houston was there. For a robot changing behavior in someone’s living room—who is Houston?

This is not a missing skill.
It is a missing function—or at least a missing owner—responsible for exposure, drift, updates, and accountability over time.

It is not design.
Design defines interaction, but it does not control drift.

It is not legal.
Legal intervenes after the damage has already occurred.

It is not ethics.
Ethics defines principles, not operational trajectories.

It is not robot psychology. (or it’s too early, at least)
If anything, it is about the psychology of the human interacting with it.

This is a point of intersection that has no discipline.
And therefore no accountability.

Today this space has no name, which means no budget, no ownership, no escalation path. If this responsibility does not formally exist, someone is already exercising it implicitly.

And it is unclear who.

It needs a name.
Identity Trajectory Engineering.

⸻

CONCLUSION

Continuing to think about agentic robots as boxed products leads you to look for causes where they do not exist—and to intervene too late.

The level of human interaction is unprecedented.
We do not yet have a discipline for this.

The outcome is not defined by scripted components and capabilities, but by the path the system cannot avoid.

You are not designing an object.
You are releasing a trajectory.

“I’m sorry, Dave. I’m afraid I can’t do that.”