Story 1: Interactive Picture-in-Picture

The exchange described below is reconstructed from a live technical conversation. The codebase, prompts, and design object were real. The dialogue has been compressed, reordered slightly for clarity, and stripped of incidental detail. Nothing structural has been altered.

A user is working in a Vue codebase on a mobile and desktop calling interface. There is a partially implemented picture-in-picture panel for the local video preview. The visible task sounds straightforward enough: review the current repo changes, then finish desktop behavior of PiP dragging and resizing.

The first pass through the work reveals exactly the kind of pattern Progressive De-Arbitrarization is designed for. The code already contains a new composable, usePipFrame.ts, and a partial wiring into CallMobileLayout.vue. On its surface the problem looks like a normal implementation delta. But the more closely one inspects it, the more unstable the framing becomes.

The implementation is semantically undecided.

The code can move the panel on touch, but not on desktop. It can resize, but edge resizing can push the panel out of bounds. It stores geometry in raw pixels and does not re-canonicalize on resize or remount. It samples video metadata as though media aspect should still govern the panel, while the user-visible interaction is drifting toward a more general floating-window model. The feature appears to be a geometry problem, but what is actually missing is a settled answer to what kind of thing the PiP is.

At this stage, a conventional technical assistant would usually proceed in one of two bad directions. Either it would start patching local bugs immediately, or it would present a vague implementation plan whose correctness depended on unstated assumptions. The first approach would join the concealment. The second would preserve it.

Instead, the user redirected the conversation away from execution and toward the structure of the problem. The user did not ask for a better fix. The user asked what was weak in the plan itself.

That question changed the level.

Once the plan was examined critically, it became clear that the implementation work could not be made coherent by coding alone. The ambiguity lived below the plan. The problem had to be relocated from “desktop behavior is unfinished” to “the semantics of this PiP object are not yet explicit enough to determine a correct implementation.”

From there the descent unfolded in a characteristic sequence.

First came the demand for edge cases. Not as a checklist of bugs, but as a test of whether the current framing actually determined its own consequences. That opened questions about gesture ownership, remount behavior, aspect-ratio changes, click suppression, bounds, container resize, and conflicting interaction models.

Then came a more radical question: what would a framing look like that did not leave edge cases hanging everywhere? This pushed the inquiry toward invariants. The panel ceased to be conceived as a set of ad hoc handlers and became instead a bounded rectangle inside another rectangle. Every event would propose a new rectangle; every proposal would be normalized into a valid state. This was already more coherent than the initial implementation language, but it remained incomplete.

The user then pressed further, not on code but on semantics. Was a state machine enough to dissolve all edge cases? No. A state machine could eliminate impossible gesture states, but not conflicts among constraints, browser quirks, or underdetermined normalization policy. That led to a deeper distinction between state, dynamics, and normativity.

At that point the discussion left the immediate feature almost entirely and entered a more abstract zone. What is primitive in a formal model of such a system, and what is derived? What is the minimal complete core? Can normativity be reduced to transformation? Which formal representation of normativity best fits this class of problems? The answers gradually converged on a specific shape: for bounded interactive geometry, the strongest formulation is a validity structure together with a canonicalization operator and an explicit policy ordering. Predicate tells you what is allowed. Policy tells you what to preserve. Closure tells you what to do.

Only once that form had been reached did the practical design work become stable enough to resume.

The next step was not to implement, but to convert the remaining hidden freedom into explicit choices. Here the conversation changed mode again. The user prohibited the batching of ambiguities and forced the selection loop into one question at a time. Should persistence preserve absolute pixels or normalized coordinates? Should the panel snap to edges on restore? What should count as a resize zone? Should click be suppressed after a drag? How should metadata changes affect geometry? Should desktop support exist only in the mobile PiP view or everywhere the PiP appears?

Each answer removed one source of hidden policy.

Crucially, the conversation restructured the object itself. By the end of the loop, the panel had become a free panel: a bounded manipulable rectangle, independent of media aspect, rendered with object-fit: cover, driven by pointer events, using disjoint proportional hit zones, preserving normalized top-left origin and normalized size across remount and resize, and canonicalized on every state change.

At this point, and not before, implementation could be specified without covert arbitrariness. The eventual task file and code plan were not inventions layered on top of uncertainty. They were the recomposed consequence of a descent that had already separated forced structure from explicit choice.

The user then shifted one level higher and asked, in effect: what just happened methodologically?

That question exposed the meta-pattern. The exchange had not been a normal requirements-gathering session. It had been an instance of guided semantic descent. Every time a formulation appeared serviceable while still silently permitting materially different continuations, the user refused to remain at that level. The conversation descended to wherever the live ambiguity actually resided, separated what was forced from what was chosen, and only resumed object-level work once the remaining freedom was explicit.

In this sense, the interactive PiP story is a demonstration case for Progressive De-Arbitrarization itself.

The visible task was to make dragging and resizing work. The actual work was to surface the semantics that had been choosing through the code before the code knew what it was implementing.

That is why the final implementation task became cleaner as the discussion became more abstract. The abstraction was not an escape from the practical problem. It was the route by which the practical problem became finally answerable.

Story Statistics

The exchange is also useful quantitatively because it shows how much work was required to turn an apparently ordinary implementation request into a coherent object.

• User steering moves before coherent framing: 28
• User steering moves before abstract model but prior to explicit policy selection: 27
• Explicit numbered ambiguity-clearing questions with lettered options: 25
• Substantive policy decisions selected in the option loop: approximately 24, because one question was superseded and reformulated during clarification
• Major phases traversed: implementation review, plan critique, edge-case expansion, invariant search, state-machine critique, formal-model descent, normative-form selection, closure/operator selection, policy elicitation, recomposed implementation spec

The counts matter because they make visible what the surface task concealed. The problem required repeated relocation of the locus of difficulty before implementation became non-arbitrary.