PASSED APART — System-Feasibility Prototype by Faadil BoussariPASSED APART — System-Feasibility Prototype by Faadil Boussari

PASSED APART — System-Feasibility Prototype

Faadil Boussari

Faadil Boussari

Every stage approved its part. The system still could not exist.
PASSED APART is an interactive prototype about a common operational mistake: approving components separately, then discovering incompatibility only after commitment has already been made.
Four modules pass their individual dimensional and tolerance checks. A shared master spine then forces them to exist as one system. A small misalignment at the third module creates resistance, pressure, displacement, a visible gap, and finally a bent spine.
Nothing failed independently. The failure appeared only after integration.
The apparatus in its initial state: four modules aligned along the master spine, each individually approved
The apparatus in its initial state: four modules aligned along the master spine, each individually approved

The problem

Most approval processes inspect components locally.
A dimension can be valid. A tolerance can be accepted. A module can pass its own inspection.
But local approval does not prove that the complete system can exist.
Organizations often approve parts, stages, vendors, or requirements independently. Each local decision can be correct while the combined system remains impossible.
Compatibility is frequently discovered only after fabrication, scheduling, purchasing, or operational commitment.

Research insight

A recurring failure pattern appears when organizations validate dependencies separately and assume integration will follow automatically.
The real risk is not necessarily a defective part. It is the relationship between individually acceptable parts.

Design thesis

Every stage approved its part. The system still could not exist.
Rather than designing a dashboard, alert, or AI-generated diagnosis, I translated the problem into a direct interactive artifact. The user physically tests whether all approved components can coexist around one shared constraint: the master spine.

The interaction

The user advances a master spine through four approved modules.
The first two accept it cleanly. At the third, a small axis mismatch produces resistance. Continued commitment shifts one module, opens a gap, and bends the spine.
Discovery: the misalignment at Module 3 becomes visible as the spine encounters resistance
Discovery: the misalignment at Module 3 becomes visible as the spine encounters resistance
The interaction reveals the causal chain:
Collision at Module 3
Resistance
Pressure
Module shift
Gap
Bent spine
The final state preserves every local approval while exposing the system failure.
The final evidence: all four modules still read APPROVED, but the bent spine proves the system cannot exist
The final evidence: all four modules still read APPROVED, but the bent spine proves the system cannot exist

The signature moment

The same line that begins as a measurement and approval reference becomes the physical spine, then bends into the final proof of failure.
The prototype makes one distinction visible:
APPROVED SEPARATELY → BOUND TOGETHER → FAILED AS A SYSTEM

What makes it different

No dashboard abstraction
No warning modal
No artificial intelligence layer
No fabricated integration
No success checkmarks
The failure is demonstrated through direct physical causality

Responsive design

The desktop version uses a wide horizontal apparatus with all four modules mounted along one shared spine.
For mobile, I rebuilt the composition as a portrait layout rather than shrinking the desktop mechanism.
Mobile: the portrait composition preserves the full interaction logic in a vertical format
Mobile: the portrait composition preserves the full interaction logic in a vertical format
Mobile discovery state: the misalignment revealed in the vertical apparatus
Mobile discovery state: the misalignment revealed in the vertical apparatus
The interaction logic remains identical across both orientations.

Why it matters

The prototype reframes integration testing as a decision that must happen before commitment, not as a final verification after every component has already passed.

Outcome

The final result includes:
A functional React and TypeScript prototype
Desktop and mobile experience
Deterministic failure sequence
Signature cover composition
Case-study captures
A Remotion product film
A live GitHub Pages deployment

Closing

Every stage approved its part.
The system still could not exist.
Like this project

Posted Jul 21, 2026

Four components passed independently. One shared constraint proved the system could not exist.