Direct answer: release the route, not a rectangle

A booth layout is ready for physical-envelope release only when every release-critical workpiece case is paired with its actual carrier or handling state, and every named stationary state and transition is checked in the orientation that will exist. The definition must follow the combined workpiece and carrier through loading, approach, passage, the working position, exit, and unloading. A maximum-workpiece box, two clear endpoints, a nominal door opening, or a clean model screenshot does not establish that complete route.

Include a buffer only when it is an actual position in the customer-approved operating concept, and only where it applies. Include a physical stopped-state occupation only when the responsible project authority identifies it. That entry records occupied space; it does not provide emergency-stop design, safety validation, a recovery procedure, control logic, or compliance design. If any release-critical variant, carrier, orientation, transition, opening state, buffer occupation, stopped-state input, or current site condition is unknown, hold the affected layout. A controlled conditional release may record the unknown, its owner, and validation gate. It does not freeze the affected geometry or interface or authorize manufacture; both remain held until the gate closes.

This state-envelope package is a geometric coordination basis. It does not prove airflow, coating performance, throughput, handling-system safety, fire protection, legal compliance, commissioning, or acceptance of the completed installation.

In this article, responsible project authority means the one named decision owner for a specific state, assumption, or release condition. Depending on the subject, that owner may be the customer's product/process/production authority, the handling-equipment authority, the site authority, or StelBooth for a decision explicitly assigned within the written project scope. The register must name the owner; the phrase must not remain a placeholder or imply that several undefined parties share one decision.

Three different routes may share the same floor or opening, but they answer different questions:

This table separates route scope only; it does not show that any workpiece, opening, movement, or route has been approved or checked.

Route What moves Decision covered here
Production workpiece flow The project-named workpiece case plus its carrier or handling state Primary scope: physical occupation from the agreed inbound boundary through the working and outbound states
Module delivery and local assembly Packed booth modules, loose items, and installation equipment A separate module delivery and local-assembly route, not evidence that the production workpiece can pass
Maintenance movement People, tools, filters, panels, doors, and replaceable equipment Separate task-based maintenance and removal envelopes, checked only as an adjacent interface here

Clearing one route does not prove either of the other two, even when they use the same door.

A workpiece size is not a physical state

The first input is not simply “maximum length by width by height.” Identify the release-critical cases by stable variant ID and explain which one governs height, width, protrusion, turning, support, or orientation. Record whether each dimension comes from a controlled design, verified item, representative sample, estimate, or unresolved input. The initial custom-booth project brief can start intake; it is not release evidence. The state-envelope review still needs controlled geometry, state, ownership, and recorded checks.

For a rigid body, motion-planning literature represents a configuration by position and orientation, and represents motion as a continuous path through configurations rather than only a start and goal.[1] That formal model supports recording both translation and orientation and checking intermediate states. This is a bounded method transfer: the cited rigid-body propositions do not supply booth datums, tolerances, clearance margins, or a validated handling route, and they do not establish how this project should represent an articulated mechanism, flexible workpiece, hose or cable, sag, dynamic deviation, or control error.

Lozano-Perez likewise frames collision-free arrangement and movement by treating an object's position and orientation as a configuration and other objects as constraints on permitted configurations.[2] That abstract-level result supports using the actual combined moving geometry and current surroundings, not a nominal part box. It does not provide a clearance, a booth algorithm, deformation behavior, or evidence that a checked digital path is physically achievable.

Define the combined object for each state. It may include the workpiece, trolley, skid, rack, hanger, hook, turntable, fixture, handles, clamps, temporary protection, and any project-defined moving interface. Record how the workpiece is located on the carrier and whether the carrier is empty, loaded, raised, lowered, coupled, rotated, or otherwise changed. If the responsible equipment source has not provided controlled geometry and the load relationship, do not replace it with an optimistic placeholder box.

Name the states before drawing the envelope

Start with the customer's real operating concept. Give every state and transition a stable ID, then omit anything that does not apply. The sequence below is an identification pattern, not a universal booth flow:

Read top to bottom along the approved production flow; include branches only when they apply.

Kind Project state / transition Release question
State Inbound position, if the approved concept contains one Which workpiece/carrier case occupies it, and what route must remain open?
Transition Load and approach What changes in support, orientation, protrusion, or handler occupation?
Transition Passage into the booth Which opening state, threshold, turn, lift, or rotation is used?
State Working position What establishes location and orientation, and which adjacent states coexist?
Transition Exit and unload Is the outbound orientation or carrier state different from entry?
State Outbound, hold, reject, or empty-carrier position, as applicable Is this an actual approved position, and which later movement can it block?
Exception Physical stopped occupation identified by the responsible project authority What space is occupied, which route is blocked, and which controlled project recovery input is referenced?

Name each transition's start, end, movement method, responsible operator or system, prerequisite state, and opening condition. Straight travel is only one possibility: turning, tilting, lifting, reversing, transferring supports, or changing carrier height may create a different intermediate occupation.[1] This rigid-body path reasoning identifies configurations to check; it does not prove project clearance, physical achievability, dynamic or safety behavior, or StelBooth capability. Flexible, articulated, suspended, or dynamically controlled objects need an additional representation and verification basis from the responsible supplier or named decision owner.

Use a project datum and viewing convention to identify the leading end, handedness, support face, coating face, and allowed rotations in each state.

The release tool: state-envelope map and register

Use two linked text artifacts. The state map shows the sequence, optional branches, simultaneous occupations, and holds. The state-envelope register binds each state or transition to controlled input, evidence, ownership, and release status. Neither tool should be prefilled with invented project dimensions.

The map should make visible:

  • the agreed inbound and outbound boundaries;
  • every required stationary state and transition;
  • the exact opening state used for each passage;
  • customer-approved buffers or hold positions, only where applicable;
  • empty-carrier or return movement only when it exists;
  • physical stopped occupations identified by the responsible project authority; and
  • the state, transition, or zone currently held open.

The six blocks below are a project-defined editorial checklist. They are not a standard, conformity scheme, release authorization, or proof that the underlying geometry or evidence is correct.

Identity

Record: State/transition ID, workpiece variant, carrier or handler ID, input revision, and maturity.

Release purpose: Keeps evidence tied to the case it actually covers.

Configuration

Record: Position and datum, orientation, moving protrusions, attachments, and loaded or empty carrier state.

Release purpose: Defines the combined occupied object rather than a part size.

Transition

Record: Start and end states, movement or rotation, opening condition, and simultaneous neighboring states.

Release purpose: Exposes intermediate and concurrent occupation.

Evidence

Record: Controlled plan, elevation, section, or 3D-check reference; stationary or swept check; and model or document revision.

Release purpose: Lets a reviewer retrieve the referenced check; it does not validate the result.

Exception

Record: Physical stopped-state occupation identified by the responsible project authority, blocked route or interface, and project recovery-space input reference.

Release purpose: Records physical occupation without claiming safe recovery.

Decision

Record: Conflict or open item, owner, review result, release, conditional, or hold status, and validation gate.

Release purpose: Records the project's current disposition; no release or conditional label authorizes manufacture while its validation gate remains open.

Revision and source priority matter because the state map, site basis, carrier data, and layout can otherwise describe different configurations. ISO's public record identifies ISO 16792:2021 as addressing digital product-definition data practices.[3] That public subject supports keeping controlled product-definition identity and revision visible when the project invokes the framework; it does not prescribe this register, supply missing geometry, prove project release, establish applicability, or demonstrate conformity. An adjacent guide on drawing-handoff record discipline shows how document identity and unresolved inputs can be preserved; it does not define booth workpiece flow or validate this register.

Read the tool in both directions. Top to bottom asks whether each planned move has enough information from identity through decision. Bottom to top starts from the released working and passage relationships and identifies which earlier state, branch, or assumption could invalidate them. If an entry cannot name the real object, orientation, transition, current surrounding geometry, owner, and evidence, mark that entry open.

Challenge passages, buffers, and stopped positions

Unless a module-delivery or maintenance interface is explicitly named, the passages, buffers, and stopped positions below refer to production workpiece flow.

The two exception fields below are project-defined editorial fields, not universal external rules. Their purpose is to expose physical occupation assumed by this layout, not to create operating, safety, or performance requirements.

Passage is a transition, not an opening dimension

Check the loaded carrier through the complete passage in its actual orientation, including frames, leaves, tracks, thresholds, guides, handles, tow features, hanging points, temporary protection, and simultaneous objects. A fully open leaf can conflict during its swing, and a carrier clear in plan can conflict while turning or lifting.[2] The abstract configuration-space result supports checking intermediate configurations only; it does not prove project clearance, physical achievability, dynamic or safety behavior, or StelBooth capability. Include approach and withdrawal, not only crossing the opening plane.

Hsu and Lin studied component accessibility and assemblability in a general design-for-assembly context.[4] Their work supports the distinct, bounded claim that access and approach should be made explicit rather than inferred from a visible destination or final position. It does not provide a booth passage, workpiece route, carrier path, clearance, tool approach, handling method, safe-access result, acceptance value, or evidence of StelBooth capability.

A digital check proves only the controlled geometry and states represented. It cannot absorb an unmodeled hose, flexible cover, articulated handler, suspended-part sag, wheel play, dynamic overshoot, control error, or site difference. The project must identify which effects require allowance, supplier evidence, a physical trial, or another competent review. This article supplies none of those values.

Buffer occupation: project-defined editorial field

Record only actual inbound, in-process, outbound, hold/reject, or empty-carrier positions in the customer-approved operating concept, as applicable. For each one, state the governing workpiece/carrier case, approved simultaneous occupancy, entry and exit order, and any required transition that occupation blocks.

Do not infer buffer capacity from unused floor area. Do not turn the map into a queue formula, line balance, reliability claim, dwell rule, or throughput promise. If the named operating decision owner has not approved a position or occupancy assumption, leave it open rather than reserving or consuming space on its behalf.

Stopped position: project-defined occupied-envelope field

Include a stopped position only when the named decision owner identifies it and the layout relies on space around it. Record the occupied workpiece/carrier envelope, supported condition as provided by its controlled source, blocked openings or routes, named decision owner, and reference to the approved project recovery-space input.

This record does not design or validate an emergency stop, stability condition, interlock, safe recovery, procedure, control behavior, risk reduction, or compliance. If those responsible parties have not supplied the state and input on which the layout depends, hold the affected transition and geometry.

Who owns the missing answer, and when must layout stop?

Do not solve an ownership gap with an assumed dimension. These are project-specific responsibility prompts, not a universal contract allocation. Confirm every owner and scope in the controlled project record.

Customer's named product/process/production authority

Provides or decides: Workpiece families and maturity, production states, orientation policy, actual buffers, and process basis.

Not assumed: Product mix, rate, future variants, or process acceptance.

Named handling-equipment authority

Provides or decides: The controlled equipment source and the carrier or handler geometry, load relationship, motion interfaces, and stopped or recovery inputs within its documented authority.

Not assumed: Rating, control logic, safe operation, or recovery procedure.

StelBooth, only within the written project scope

Provides or decides: Agreed enclosure, opening, and module geometry; selected-equipment interfaces; state-envelope coordination; and open-item records included in that scope.

Not assumed: Customer process decisions, unverified equipment data, local licensed work, or any capability not confirmed for the project.

Named site/local authority

Provides or decides: Current floor, opening, obstruction, and building geometry plus local design and as-built confirmation.

Not assumed: Site accuracy, permits, building acceptance, or local compliance decisions.

These blocks allocate information and decisions; they are not capability evidence. Any StelBooth design, manufacture, coordination, or verification activity must be confirmed by the written project scope and applicable first-party records. The external sources cited in this article do not prove StelBooth machine capacity, handling capability, engineering authority, inspection capability, or a completed-project result.

Use the project's current site datums and route conditions as the destination basis. The site-utilities and interface-responsibility guide shows which inputs and owners should be identified; it does not validate this project's as-built opening or turn.

Hold the affected state, transition, zone, or interface when any of these is missing or stale: a release-critical variant or protrusion; real loaded carrier geometry; a changed turn, tilt, lift, or transfer; the actual opening or simultaneous state; an approved buffer occupation; a stopped-state input identified by the named decision owner and relied upon by the route; current site geometry; or the named decision owner needed to decide the condition.

A conditional release is a controlled record of an unresolved dependency, not permission to manufacture around it. It must name the assumption, affected register entry and geometry/interface, decision owner, evidence still required, validation gate, and disposition if the assumption fails. Until the gate closes, the affected geometry or interface must remain unfrozen and must not be used for manufacture. “Verify on site,” “allow clearance,” or “use the maximum part” alone is not a closed condition.

What releases the layout, and what reopens it?

Use four non-ranked record categories for geometric coordination. They are not safety, conformity, commissioning, acceptance, or supplier-capability levels, and one category does not automatically supersede another:

  • Reference-only input: a photograph, sketch, representative item, estimate, or unverified scan used to frame questions.
  • Controlled input: approved workpiece, carrier, site, or equipment data with identity, revision, state, and owner.
  • Digital check: a recorded stationary or swept-geometry review performed with those controlled inputs and named limitations.
  • Project or physical confirmation: an identified route trial, mock-up, first-item check, or as-built confirmation when the project requires it.

Each record supports only its recorded condition. A digital clearance does not prove an unbuilt site; a physical pass with one variant does not approve a family; a trial under manual control does not establish an automatic system's dynamic behavior; and none of these alone proves throughput, safety, commissioning, or acceptance.

Changes reopen the affected entries. Research on change propagation in a complex rotorcraft design case supports the general point that a change to one connected part can have consequences elsewhere.[5] That source does not predict a booth impact or mean every change affects every feature. It supports an impact-based question: when the workpiece, carrier, orientation, opening, selected equipment, site, buffer assumption, or movement method changes, which state, transition, register evidence, and released interface must be reviewed again?

Bring one controlled package to review

Bring one package that lets the review team assign a project disposition to every state and transition: input identified, geometry check recorded with stated limitations, conditionally open, or held. These labels are not safety, commissioning, or final-acceptance results.

  • Workpiece cases: the controlled family register, the governing case for each passage or occupied zone, and variants not represented.
  • Moving system: actual carrier or handler data and the combined-object definition for each state.
  • Route basis: the project datum and orientation convention, state-and-transition list, current site and opening basis, approved buffers where applicable, and stopped-state inputs identified by the named decision owner.
  • Evidence: the exact plan, elevation, section, or model revision for every check; label each input's source status as controlled, project-confirmed for the named geometry, estimated, or unknown. None of these source-status labels proves route safety or final acceptance.
  • Decisions: named decision owners, open conditions, validation gates, and the review disposition for every state and transition.

One representative item reaching the working position does not complete the package. The record must show which release-critical cases and intermediate configurations the decision covers.

The final stop line is simple: if the team cannot identify the combined moving object, the state and orientation, the complete transition, the current surroundings, the responsible project authority, and the evidence that closes the release condition, it cannot yet defend freezing that part of the booth layout.

References

  1. Steven M. LaValle, Planning Algorithms, Cambridge University Press, 2006. Official DOI. The cited formal model supports rigid-body configuration and continuous-path concepts only. Back to citation, occurrence 1 Back to citation, occurrence 2
  2. Tomas Lozano-Perez, “Spatial Planning: A Configuration Space Approach,” IEEE Transactions on Computers, C-32(2), 108-120, 1983. DOI. Use is limited to the accessible abstract-level configuration-space proposition. Back to citation, occurrence 1 Back to citation, occurrence 2
  3. International Organization for Standardization, ISO 16792:2021, Technical product documentation - Digital product definition data practices. Official ISO catalog record. Public title and subject only; no register, missing geometry, project release, applicability, or conformity is supplied. Back to citation
  4. Hung-Yao Hsu and Grier C. I. Lin, “Quantitative measurement of component accessibility and product assemblability for design for assembly application,” Robotics and Computer-Integrated Manufacturing, 18(1), 13-27, 2002. DOI. The source supports a bounded access/assemblability distinction, not a booth route, clearance, method, safe-access result, or project acceptance. Back to citation
  5. P. John Clarkson, Caroline Simons, and Claudia Eckert, “Predicting Change Propagation in Complex Design,” Journal of Mechanical Design, 126(5), 788-797, 2004. DOI. The rotorcraft case supports connected-change awareness, not a predicted booth result. Back to citation