Skip to content

Rapid Configuration Prototype

Design method — instantiates Inventory-Bounded Resource Recomposition

Builds a cheap, reversible stand-in of a candidate configuration first — to surface incompatibilities and prove the idea before any scarce inventory is committed irreversibly.

The riskiest moment in recomposition is the irreversible cut — welding, soldering, drilling, or reformatting a scarce, one-of-a-kind resource into a configuration that might not work. Rapid Configuration Prototype buys that risk down by building a reversible stand-in first: a mock-up, a dry-fit, a simulation, or a partial build made from cheap or plentiful material that represents the candidate configuration well enough to test its fit. Its defining property is reversibility — everything it consumes can be recovered or thrown away without loss — which lets the team learn whether parts actually interoperate before spending anything that cannot be unspent. Where the sprint commits and the salvage workflow destroys, the prototype exists precisely to defer commitment until a configuration has earned it.

Example

A scenic shop must hang a heavy chandelier from a gallery ceiling on a one-off bracket cut from a length of architectural bronze salvaged from a demolition — there is exactly enough bronze for one bracket and no more. Cut it wrong and the only stock is gone. So before touching the bronze, the fabricator builds a Rapid Configuration Prototype: the same bracket geometry in foam-core and scrap plywood, dry-fitted to the actual ceiling mount and load-tested with sandbags to a fraction of the rated weight.

The mock-up reveals what a drawing hid — the bolt pattern fouls a conduit, and the bracket needs a ~15 mm offset. They adjust the cardboard, re-check the fit, and photograph the corrected configuration with its measurements. Only then is the bronze cut, once, to a geometry already proven to fit and clear. The prototype cost an afternoon and a sheet of foam-core; getting it wrong in bronze would have cost the whole job. The cardboard is recycled — its entire value was the fit-check and the recorded configuration it leaves behind.

How it works

  • Represent, don't commit. Build the candidate configuration in the cheapest, most reversible medium that still exercises the risky interfaces — cardboard, a spreadsheet model, a staging copy, a dry-fit with clamps instead of welds.
  • Check the fits that matter. Focus the prototype on the incompatibilities a drawing can't settle: does it physically mate, clear, seat, or interoperate? Surface those where they are cheap to fix.
  • Record the proven configuration. Capture the geometry, settings, or parameters that passed, so the irreversible build reproduces a known-good arrangement rather than re-deriving it.
  • Keep the way back open. Nothing scarce is altered until the prototype clears; the default state stays fully recoverable.

Tuning parameters

  • Fidelity — how closely the stand-in mimics the real configuration. Higher fidelity catches subtler incompatibilities but costs more and starts to consume the very scarcity you are protecting; lower fidelity is faster but misses fit problems.
  • Reversibility margin — how strictly the prototype avoids consuming anything scarce. A pure throwaway (cardboard, simulation) keeps the way back fully open; a partial build on real stock is more informative but begins to burn the option.
  • Scope of the mock — whether you prototype the whole configuration or only the one risky interface. Narrow prototypes are cheap and fast; whole-system mocks catch interaction effects but cost more.
  • Number of iterations — how many prototype-and-adjust cycles before committing. More cycles converge on a safer geometry at the cost of time.

When it helps, and when it misleads

Its strength is that it converts an irreversible bet into a reversible experiment — a classic throwaway prototype whose only job is to retire risk and then be discarded.[1] It is most valuable exactly when the target resource is scarce, unique, or expensive to alter, because it moves the mistakes to a medium where mistakes are free and leaves a recorded, proven configuration for the real build.

Its failure modes cluster around the prototype outliving its purpose. A mock built for a fit-check gets pressed into service as the real thing — prototype creep — carrying none of the durability the field needs. Or a low-fidelity stand-in gives false confidence: it fit in cardboard but the bronze flexes differently, so the prototype must match the risky property, not just the shape. And it can be run backwards, built after the fact to bless a cut already made. The discipline that guards against these is to fix what the prototype is for before building it, match its fidelity to the specific risk it must retire, and treat a passing mock as permission to commit — not as the deliverable.

How it implements the components

Rapid Configuration Prototype realises the reversible-trial side of the archetype — the components that let a configuration be tried without being committed:

  • rollback_path — its essence: a stand-in whose every consumption is recoverable, keeping the pre-commit state fully restorable.
  • compatibility_check — the fit-and-interoperate test the mock exists to run cheaply, before the incompatibilities become expensive.
  • configuration_record — the proven geometry, settings, or parameters the prototype captures, so the irreversible build reproduces a known-good arrangement.

It deliberately spends nothing irreversible: the irreversible_consumption_budget and keystone_resource_reserve belong to the Salvage and Cannibalization Workflow, the mechanism that actually consumes. The prototype's whole value is postponing that draw-down until a configuration is proven.

Notes

The prototype's value is entirely in what it lets you not do yet — cut, weld, consume. If a mock cannot be reverted, it is no longer a prototype but a first draft of the real build, and it should be judged by the real build's durability standard, not the prototype's cheapness.

References

[1] Throwaway (or rapid) prototyping is the established practice of building a disposable model to learn something specific — here, whether a configuration fits — then discarding it rather than evolving it into the product. The learning, and the recorded known-good configuration, are the deliverable; the mock itself is not. ↩