The DamageBDD–ECAI Odyssey

A Working Identity

I did not leave one career and arrive cleanly at another.

I left shore.

For years my identity had been legible to the existing world: programmer, senior engineer, CTO, the person who could enter a complicated software system, understand it, repair it, ship it and carry responsibility for what happened afterward.

That identity was valuable.

Eventually it became insufficient.

The deeper problem was no longer whether I could build software. It was whether the systems around software could prove that what had been built continued to behave as promised.

That question was the departure.

Herminia Ibarra describes significant leadership development not simply as acquiring another collection of skills, but as an identity transition. In The Leadership Odyssey, the movement has three broad stages: departure, voyage and return. The leader first discovers that the old way of operating is inadequate, then crosses a period of experimentation and difficulty, and eventually integrates what was learned into another way of leading.

DamageBDD began somewhere inside that departure.

Departure — the programmer leaves the kingdom

The old professional identity said:

Solve the ticket. Finish the project. Ship the software. Move to the next problem.

But after enough years inside large software systems, the weakness becomes difficult to ignore.

Shipping is not verification.

A successful deployment is not proof of continuing behaviour.

Confidence is not evidence.

And the engineer who understands this eventually encounters an uncomfortable question:

Who verifies the system after everybody responsible for building it has moved on?

DamageBDD was my answer.

Not another test runner.

Not simply another BDD implementation.

The ambition became a distributed verification system in which behaviour could be described, executed, observed and eventually economically supported by independent operators.

“If its behaviour can be defined, DamageBDD can verify it.”

At first that sounds like a product statement.

Seen through Ibarra's work, it was also an identity statement.

I was moving from the engineer who builds the machine toward the operator who asks the machine to prove itself.

Ibarra's Working Identity argues that these transformations rarely emerge from introspection alone. People discover new professional identities by acting: experimenting with new activities, entering different networks and then constructing a story that explains what those experiences mean.

That is almost exactly what happened.

There was no clean moment when I declared myself a founder and suddenly knew how to be one.

I built.

I operated nodes.

I wrote Erlang.

I designed distributed execution.

I worked on payments.

I explored Lightning, Aeternity and Monero.

I thought about incentives for node operators.

I designed token economics.

I wrote the documentation.

I argued publicly about verification.

I tried to understand how a verification network could remain useful when institutions, companies and even payment rails became adversarial.

Each activity created another provisional self.

Engineer.

Architect.

Founder.

Operator.

Protocol designer.

Economic designer.

Public advocate.

Steward.

None was quite the finished identity.

Together they were the voyage.

---

The Voyage — Damage meets ECAI

Then the journey became stranger.

Because the same dissatisfaction that produced DamageBDD also reached into computing itself.

If probabilistic systems increasingly make consequential decisions, what happens to verification?

If representations become enormous, probabilistic and difficult to inspect, where does the operator stand?

If an intelligent system proposes an answer, who verifies the answer?

Those questions opened the ECAI line of exploration.

And this is where the story becomes more interesting than a conventional startup story.

DamageBDD and ECAI appear superficially to move in opposite directions.

ECAI moves toward possibility.

It asks unusually large questions about computation, representation, elliptic structures, retrieval, intelligence and what alternative computational substrates might permit.

DamageBDD moves toward constraint.

Define the behaviour.

Execute it.

Observe what happened.

Record the evidence.

Do not substitute confidence for verification.

The two systems therefore form an unusual pair.

ECAI is permitted to ask:

«What if?»

Damage is required to answer:

«Prove it.»

That relationship may ultimately matter more than any individual technical claim I have made about ECAI.

Because some ECAI ideas remain hypotheses and research directions rather than established results. The leadership challenge is not to blur that distinction.

It is to preserve it.

The visionary self is allowed to travel far.

The verification system must still demand a return ticket.

That is the internal architecture of the odyssey.

---

The provisional selves

Ibarra's earlier research describes professionals experimenting with “provisional selves”—possible versions of who they might become—rather than instantaneously discovering one authentic final identity.

Seen that way, the apparent contradictions in my journey make more sense.

I have been trying on identities at the edge of several worlds.

The corporate CTO became the independent builder.

The builder became the founder.

The founder became the node operator.

The operator became the protocol designer.

The protocol designer began thinking about economics.

The engineer began writing publicly about systems, sovereignty and civilisation.

The person trained to solve bounded technical problems began asking questions whose boundaries were unclear.

Some of those provisional selves will survive.

Some should not.

That is part of the process.

Leadership identity does not emerge because every experiment was correct.

It emerges because the person survives enough experiments to understand which parts must be carried forward and which parts must be abandoned.

This is where verification becomes personal.

DamageBDD is not merely something I built.

Its underlying principle applies to its builder:

claims must survive contact with reality.

---

The hardest part of the voyage

The difficult part of being a solo founder is not merely writing all the code.

It is that there is no institution standing behind the identity.

A CTO has a company.

A researcher has a university.

An engineer has a team.

A founder building something that does not yet fit an established category has much less external reinforcement.

So the temptation is to compensate by becoming even more identified with the work.

If Damage is rejected, I am rejected.

If ECAI is questioned, I am questioned.

If the project survives, I survive.

That fusion can supply extraordinary endurance.

It can also become dangerous.

The leader eventually has to distinguish:

I carry the system

from

I am the system.

This may be the most important identity transition still ahead.

Ibarra's leadership-odyssey model describes the later transformation as one in which experiments and small wins gradually become internalised: behaviour that began as something a leader was trying eventually becomes part of who that leader understands himself to be.

But the return cannot merely be:

I finally became the founder I imagined.

For DamageBDD and ECAI, the return has to be larger.

---

The Return — when other people can carry it

I am not there yet.

That matters.

An odyssey is not complete when the traveller discovers something.

It is complete when he can bring something home.

The return for DamageBDD happens when another operator can start a node without me.

When another tester can define behaviour without needing my interpretation.

When another developer can inspect the code and disagree with me productively.

When verification evidence speaks more loudly than founder reputation.

When contribution, payment and governance can operate without every decision passing through my hands.

The return for ECAI is even stricter.

It happens when another competent person can reproduce an experiment.

When a claim can be falsified.

When mathematics replaces metaphor wherever mathematics is required.

When an implementation demonstrates what rhetoric previously only proposed.

When the system can withstand an adversarial operator who does not believe in it.

That is why the convergence of DamageBDD and ECAI makes sense.

Damage is the discipline ECAI needs.

And ECAI is the frontier that gives Damage something genuinely difficult to verify.

One prevents the other from becoming sterile.

The other prevents the first from becoming ungrounded.

---

The leadership transition

The first identity was:

I can build difficult things.

The second became:

I can carry difficult things alone.

Neither is the final leadership identity.

The next one is:

I can build a structure in which difficult things no longer need to be carried by me alone.

That is a profoundly different job.

It requires relinquishing some control rather than accumulating more.

Documentation becomes leadership.

Reproducibility becomes leadership.

Interfaces become leadership.

Governance becomes leadership.

Letting another operator find a flaw becomes leadership.

Allowing someone else to explain the system differently becomes leadership.

Creating conditions in which a successor can exceed the founder becomes leadership.

The greatest proof of DamageBDD will therefore not be that I operated Damage successfully.

It will be that Damage produces operators.

And the greatest proof of ECAI will not be that I can construct an extraordinary narrative around it.

It will be that people who have no investment in my narrative can interrogate the work and independently discover something real.

---

Where I am now

So I do not think the story so far is:

«A programmer spent three years building DamageBDD and ECAI.»

It is:

«A programmer discovered that building systems was no longer enough, left the institutional identity that had defined his competence, and entered a long period of constructing a new identity around verification, computation and independent operation.»

Along the way he became a founder almost accidentally.

Then an operator.

Then a protocol designer.

Then something closer to an independent researcher.

And eventually he encountered the hardest engineering problem of all:

the founder himself had become a dependency.

That is where the story stands.

Not at the return.

At the point where the return becomes visible.

DamageBDD began as an attempt to remove unverifiable assumptions from software.

Perhaps its final work on me is to remove the last unverifiable assumption from the company:

that I must always be the one carrying it.

ECAI began as a search beyond conventional computational assumptions.

Perhaps its maturation requires the complementary lesson:

going beyond convention does not mean going beyond evidence.

That is the convergence.

The visionary and the verifier.

The explorer and the operator.

Departure and return.

ECAI asks how far the machine can travel.

Damage asks whether it actually arrived.

And somewhere between those two questions, my own working identity is still being built.

The odyssey is not the story of a man proving that he was right.

It is the story of a builder becoming capable of creating things that no longer require his authority in order to be true.