How we deliver Excavator

Recover requirements from a system that already exists.

Excavator is a second way to populate Blueprint. Greenfield work starts from human intent. Excavator starts from a running legacy system, recovering what it actually does so the same machinery rebuilds it.

Why it matters

The requirements are already encoded in the system.

The common enterprise situation is a custom system that has grown over years into something nobody fully understands, was built by many hands who have moved on, is too expensive and risky to rebuild by hand, and is still running the business every day. The requirements are already encoded, implicitly, in the system.

Excavator reads the existing system and recovers its requirements, behaviors, and data model into the same Blueprint context used for greenfield work, plus a data-migration context describing how the legacy data maps into the rebuilt system. Everything downstream of Blueprint is unchanged.

What makes this work where prior automated migration struggled is the role of the people who use the system. Recovered requirements become a test suite that verifies against the legacy system's actual behavior, and day-to-day users are the authority on which behaviors matter and which are vestigial.

Recovery pipeline
  1. 1. ReadRunning legacy system
  2. 2. RecoverRequirements · behaviors · data model
  3. 3. VerifyTest suite · users as oracle
  4. 4. MapData-migration context
  5. 5. BlueprintSame machinery rebuilds
Feeds Blueprint · everything downstream unchanged
In practice

What it does.

Requirements recovery

Reads the running system and recovers what it does.

Users as oracle

The people who use it decide what matters.

Data migration

Maps the legacy data into the rebuilt system.

Want the detail?

The harness paper documents the full architecture.