Most systems are never questioned.

We add features. We add abstractions. We add dependencies, configurations, workflows, services. We celebrate what is new. We promote what is built. We measure output by what was created.

Nobody gets promoted for removing a feature.

Subtraction is the most underused action in engineering. It has no lobby, no conference talks, no metrics dashboard. Deletion does not appear in sprint velocity. Simplification is not a line item on a product roadmap. The absence of unnecessary code is invisible — and so it is never rewarded.

And yet, subtraction is where coherence lives.

Complexity is not a sign of sophistication. It is uninspected waste. A system with forty modules where twelve would suffice is not mature — it is neglected. The complexity was never questioned because questioning it was never anyone's job.

PRUNE makes it someone's job.

Coherence compounds. Every unnecessary element taxes every future decision. Every dormant feature confuses every new team member. Every decorative abstraction creates a false floor that the next developer must work around. The cost is not in the element itself — it is in the drag it creates across everything else.

The best architecture is the one that survives its own audit.

Elegance is not aesthetic. Elegance is operational. An elegant system is one where every element earns its place, every connection is symbiotic, and every abstraction can justify its cost. Elegance is the absence of waste, not the presence of beauty.

Dead code is not harmless. It is a lie embedded in your system. It tells new developers that it matters. It occupies space in searches, in reviews, in mental models. It decays quietly until someone tries to change it and discovers it was never alive.

Dormant features are promises your product no longer keeps. Users do not see them. The team does not maintain them. But they remain — consuming attention during audits, creating false complexity in planning, and giving the illusion that the system does more than it does.

Decorative abstractions are the most dangerous — they feel like progress. A wrapper that wraps a wrapper. A service that delegates to another service. An interface that exists for theoretical extensibility that will never arrive. They pass code review because they look like engineering. They are not. They are weight.

The five filters are not a framework. They are a habit. Can this be removed entirely? Is this essential? Is this symbiotic? Is this traceable? Can this be removed later? Ask these five questions of every element, every sprint, every quarter — and the system stays honest.

Good systems can be traced, questioned, and removed cleanly. That is the standard. Not testability alone. Not performance alone. Traceability. Questionability. Removability. If you cannot explain why something exists, it probably should not.

PRUNE exists because subtraction needs a discipline, a name, and a practice. It is not a tool for minimalism. It is a tool for honesty. It forces the question that systems are designed to avoid: what here should not exist?

Other tools help you build more. PRUNE helps you decide what should not exist.