A squaring-line RFQ often mixes two different things under one document: what the factory has actually verified about its tiles, its site, and its process, and what the responding supplier is proposing as a solution. When those two categories blur, competing quotes stop answering the same question, and the factory ends up comparing architectures rather than comparing how well each architecture satisfies one confirmed brief.
Freeze the Factory Requirement Before Reviewing Architecture
Before any machine layout or wheel configuration enters the conversation, the factory needs a written statement of its own requirement, independent of what any supplier might propose. This means recording the squaring and chamfering task itself, the tile input envelope the line must accept, the outputs the line must deliver, and the points where the new equipment ties into existing upstream and downstream stages. It also means recording the installation location, the site conditions available there, the operating context the line will run under, and the kind of evidence or acceptance check the factory expects before it will sign off on performance.
This step exists because a requirement description and a proposed architecture answer different questions. The requirement describes what the factory needs regardless of who supplies it. The architecture describes one way of meeting that need. If the two are written together, in the order a salesperson happens to present them, the factory’s own conditions start to look negotiable and the supplier’s design choices start to look mandatory. Separating them in writing, before any proposal is reviewed, keeps the direction of authority clear: the requirement constrains the architecture, not the reverse.
General guidance on buying machinery supports this same discipline outside the ceramic sector. HSE guidance on buying new machinery supports defining where and how machinery will be used, what tasks it performs, who will use it, what risks apply, and what custom requirements the buyer wants to discuss with potential suppliers, before those suppliers start proposing designs. The same logic applies to a squaring line: the tasks, the users, the site, and the risk and interface conditions belong to the factory’s description, not to the supplier’s response.
A related principle appears in the UK Cabinet Office’s guidance on technical specifications, which supports giving suppliers a full description of requirements and a common basis for response. That guidance sits inside UK public-procurement law and does not govern a private commercial transaction such as a purchase from BASAIR; the applicable principle here is only the practice of writing a complete, shared requirement description before comparing what different suppliers propose against it. Where the factory has not yet verified a condition — a dimensional range, a site utility limit, an interface detail from an adjacent line — that gap should be recorded as unresolved rather than filled in with an assumption borrowed from a supplier’s brochure or a competitor’s installation.
Classify Each Input as Fixed, Bounded, Unknown, or Supplier-Confirmed
Once the requirement is written down, each individual input inside it needs a classification, because not every line in a requirement document carries the same weight. Some values are verified facts the factory has measured or confirmed and that any proposed line must respect without deviation. Others are ranges the factory can accept, where a supplier’s proposal may sit anywhere inside the stated band without triggering a clarification request. Others are simply not yet known, because the factory has not measured or decided them, and pretending otherwise creates a false constraint that a supplier will design against unnecessarily. The last category covers points the supplier itself must define — an interface detail, a duty allocation, a design choice — because the factory is deliberately leaving that decision open for the supplier to propose and justify.
The distinction between “fixed” and everything else matters most in practice, because the label “fixed” removes flexibility from the comparison entirely. If a preference is labeled fixed when it was only ever a preference, competing suppliers may be forced into an unnecessarily narrow design, or may quietly ignore the label once they realize it isn’t load-bearing, which reintroduces exactly the ambiguity the classification was meant to remove. The same risk applies to values copied from a competitor’s equipment description or from a previous line’s specification sheet: a number that was true for a different install, a different tile format, or a different supplier’s architecture is not automatically true for this one, and treating it as fixed without independent verification manufactures a constraint that does not actually exist at this site.
Unknown values deserve equal discipline in the opposite direction. An unverified value should be marked unknown, assigned to whoever in the factory is responsible for resolving it, and left open rather than estimated. A supplier who receives an invented number instead of an honest “unknown, to be confirmed” will design against that invented number, and any deviation discovered later becomes a change to the supplier’s design rather than a simple correction to the factory’s brief.
This classification exercise is a practitioner framing tool for organizing an RFQ, not a technical or regulatory standard; it does not certify a value, and it does not substitute for the factory’s own measurement or verification work.
| Classification | Meaning in the RFQ | Required handling |
|---|---|---|
| Fixed | A verified factory condition the proposed line must respect | State the source and do not allow silent deviation |
| Bounded | A factory input or outcome that may vary within an explicitly accepted range | Give the range and ask the supplier to show where its proposal sits |
| Unknown | A value or condition the factory has not yet verified | Mark it unknown, assign an owner, and do not invent a value |
| Supplier-confirmed | A demand, interface, or design choice the supplier must define | Require the proposed value, basis, assumptions, and effect on the offer |
Require the Supplier to Expose Its Proposed Line Architecture
With the requirement frozen and its inputs classified, the supplier’s job becomes visible as a distinct deliverable: showing exactly how its proposed architecture answers that brief. This means the supplier should return the module sequence it proposes, the position and duty of each wheel station along that sequence, the transfer and cleaning interfaces connecting one stage to the next, and whether the proposed route is dry, wet, or some other confirmed process context. It also means stating explicitly which assumptions the proposal depends on, which scope it excludes, what alternative configurations exist, and what evidence — a trial, an agreed output check, a specified test — the supplier proposes as the basis for accepting the result.
Architecture varies because the same functional requirement — squaring, dimensional control, cleaning, transfer, centring, chamfering — can be distributed across machines and modules in more than one defensible way. BMR’s current catalog structure, for example, separates these functions into distinct product categories: squaring, dimensional control, cleaning devices, transfers, centring, and chamfering appear as separate units rather than being folded into a single machine. This is market precedent showing that architecture can legitimately distribute responsibilities across distinct modules; it says nothing about how BASAIR configures a line, and it should not be read as a template BASAIR follows or as evidence of what any BASAIR configuration includes.
The practical consequence for a buyer comparing quotes is that a wheel-position and duty map is not optional detail — it is the only way to check whether every required duty in the frozen requirement actually has an owner somewhere in the proposed sequence, or whether a duty has been assumed away, merged into a station that wasn’t designed for it, or left for the factory to solve later. A module count by itself does not answer this question; two lines with the same number of stations can allocate duties differently, and a line with more stations is not automatically the one that covers the requirement more completely.
The same logic applies to interfaces. Where the factory’s requirement specifies an upstream or downstream tie-in, the supplier’s proposal needs to state where its boundary of responsibility ends and the factory’s begins — which side supplies the transfer mechanism, which side owns the cleaning step at that junction, which side is responsible for the control signal that coordinates the two. Left unstated, these boundaries surface later as commissioning disputes rather than as design decisions made with full information.
The requirement information the factory has already frozen and classified is what any legitimate architecture proposal must respond to point by point; this is the material that enters BASAIR’s own configuration and quotation review when the equipment under discussion falls within the squaring and chamfering machine line, and the same discipline applies when the proposal’s wheel-position map needs to be checked against a separate diamond squaring wheel selection, since a machine architecture and its abrasive interface are configured and confirmed separately.
| Supplier response item | What must be shown | Buyer review question |
|---|---|---|
| Module sequence | Ordered functions and transfer points | Does every required duty have a clear owner? |
| Wheel-position map | Position, side, tool family, and assigned duty | Is the sequence explained rather than implied by count? |
| Process route | Proposed dry, wet, or other confirmed context | Are route-specific interfaces and assumptions visible? |
| Supporting interfaces | Proposed cleaning, transfer, control, and site connections that apply | Are factory and supplier boundaries explicit? |
| Alternatives and exclusions | Optional routes, omitted scope, dependencies, and unresolved data | Can differences be compared without hidden assumptions? |
| Validation basis | Proposed evidence, trial, or agreed output check | Does the evidence match the stated duty without promising an unsupported result? |
Compare Proposals Against One Shared Requirement Baseline
Comparison only produces a meaningful result if every proposal is checked against the same fixed and bounded inputs the factory recorded at the outset, rather than against each proposal’s own internal logic. This means going back to each fixed value and confirming the proposal respects it without silent deviation, and going back to each bounded range and locating exactly where the proposal’s stated performance or configuration falls within it. A proposal that quietly redefines a fixed input to suit its own architecture has not answered the brief; it has substituted a different brief.
The harder comparison work concerns the unknowns and the supplier-confirmed items, because these are exactly where competing proposals will differ most and where the differences carry the most consequence. One supplier may treat an unresolved value conservatively, building margin into its design; another may treat it optimistically, producing a tighter but more exposed configuration. Neither approach is inherently preferable — the correct choice depends on what the factory eventually confirms about that value, and until it is confirmed, the comparison should record the difference rather than resolve it by preference. The same applies to interfaces and lifecycle implications: where one proposal assumes the factory will supply a transfer mechanism and another proposes to include it, the commercial figures are not directly comparable until that scope difference is made explicit and normalized.
Validation basis deserves the same scrutiny. A proposal that offers to validate its result against evidence matching the stated duty is answering the brief; a proposal that offers a validation method disconnected from what was actually asked for, or that implies a result beyond what the proposed evidence can support, has not.
One reasoning shortcut is worth naming and setting aside deliberately: the assumption that a more detailed proposal, or an architecture with more modules and more stated capability, is automatically the stronger answer. Detail and scale describe the proposal’s presentation, not its fit to the frozen requirement. Where a project’s requirement is narrow and its interfaces are simple, a compact architecture that answers each fixed input directly may fit better than an elaborate one that introduces capability the requirement never asked for. Where a project’s requirement includes more complex upstream and downstream tie-ins or a wider bounded range, a more distributed architecture may be justified — but only because the requirement calls for it, not because more modules read as more thorough.
Any deviation a proposal introduces from the frozen and classified requirement — whether in a fixed value, a boundary interface, or a validation method — should be returned to that supplier for clarification before the proposals are placed side by side commercially. Resolving these deviations first is what keeps the eventual comparison a comparison of how well each architecture satisfies one shared brief, rather than a comparison of which supplier wrote the more persuasive document.
Frequently Asked Questions
Q: Should our preferred module layout be treated as a fixed factory constraint?
A: Treat it as fixed only if a verified factory condition genuinely requires it. Separate preferences and copied competitor details from actual site, production, and handoff constraints so suppliers can propose alternatives against the same required result.
Q: How can we request quotations when some factory values are still unknown?
A: Mark those values as unknown and assign someone to verify them. Distinguish them from fixed conditions, acceptable ranges, and interfaces the supplier must define, and ask suppliers to show any assumptions and their effect on the offer rather than filling gaps silently.
Q: What information lets us compare different squaring-line architectures fairly?
A: Request the module sequence, wheel-position and duty map, process route, applicable transfer, cleaning and site interfaces, alternatives, exclusions, and validation basis. Compare how each proposed arrangement answers the same verified factory brief instead of assuming a larger or more detailed layout is better.
Q: What should we do before comparing prices if an offer deviates from our brief?
A: Clarify the deviation and its consequences first. Check it against the fixed and bounded inputs, identify affected interfaces, validation and lifecycle implications, and request a supplier response so the commercial comparison uses visible scope and assumptions.
