From practical experience to an operational system
This page documents an ongoing transition: from project knowledge held largely in one person, through explicit product rules and shared visual configuration, toward structured information that can move between customer communication, technical clarification, production and installation without being repeatedly re-explained.
What this page defines
Development is not a software showcase. It records how practical experience is being translated into a more explicit and repeatable operating system. Stable principles remain in System Laws. The general reasoning process remains in Approach. Real project domains remain in Applied. This page sits between them: it shows what is currently being built from that logic.
The problem began before production
In custom work, a client needs enough clarity to make a decision before the final technical package exists. That creates a recurring gap: the product must become understandable early, while the most specialised technical resources are usually needed later.
A custom product has to become visible before it can be ordered
A customer rarely buys a verbal description. Door proportions, divisions, opening direction, glass, handles and other visible decisions need a shared representation that can be discussed and corrected.
The person talking to the customer is not always the person drawing the product
Sales staff and project managers may understand the product well without working in CAD. Technical designers, meanwhile, are often occupied with confirmed production work. Early clarification can therefore depend on a scarce resource.
The first objective was not automation. It was to create a shared object that a customer and seller could understand together — and then preserve the decisions made around that object as the project moved forward.
Shortening the distance between an idea and something discussable
The practical bottleneck is simple: if every early variation requires a new drawing from a technical designer, clarification becomes slow, expensive and difficult to repeat. If the product logic is known, part of that early work can be represented directly.
The system is not intended to replace a technical designer. It is intended to reduce the amount of technical time spent recreating information that has already been defined earlier.
The same decision should not be explained five times
In a fragmented process, the customer explains something to sales, sales explains it to a manager, the manager explains it to a technical designer, and the resulting information is later interpreted again by production and installation. Every retelling creates another opportunity for drift.
Information should not be repeatedly retold. It should remain attached to the project and change representation according to the role that consumes it.
One project, different responsibilities
The system is being structured around roles even before a larger organisation exists. The reason is not organisational ambition. It is to make clear who needs which information, who can change what, and where responsibility moves from one stage to another.
What is being built now
The current system is still developing. It is being built from real project friction rather than from an attempt to reproduce a general-purpose software category.
A product that can be discussed before a final technical drawing exists
Geometry, divisions, opening logic, glass, handles and other visible choices are combined into one object that supports early clarification.
Decisions should remain attached to the project
The aim is to preserve what is open, proposed, verified, approved, locked or released instead of leaving those states implicit in messages.
Configuration should become usable downstream
A visual model becomes more valuable when the same underlying data can later support specifications, dimensions and production-oriented documents.
The site needs a different view of the same project
Installation does not need the complete sales history. It needs clear references, orientation, gaps, interfaces and conditions relevant to execution.
Issues should belong to the object they affect
A future objective is to bind comments, changes and production feedback to specific elements, decisions and revisions rather than leaving them in disconnected conversations.
Repeated problems should become rules
If production or installation repeatedly exposes the same limitation, the useful outcome is not another explanation. It is a new constraint, validation or rule inside the system.
Developed and tested inside current project work
This is not presented as a finished universal platform. Configuration systems, CPQ, PDM / PLM and production workflows already exist in many forms. The development documented here has a narrower purpose: to formalise a specific body of practical knowledge and reduce recurring information loss across one real product and project process.
Technical verification, specialist calculations and professional responsibility remain with the people qualified for those tasks. The objective is not to remove expertise, but to prevent expertise from being wasted on information that the process should already know.
Method, development and application
Development does not replace the existing author structure. It connects the reasoning layer to the applied project layer.
Approach
How constraints, references, tolerances and responsibility are clarified before decisions become irreversible.
PrinciplesSystem Laws
Stable principles that remain separate from the changing implementation of the current development work.
ApplicationApplied
Where the reasoning meets real project domains, commercial work and physical execution.
Move from development to principles or application
Development is one layer of the author system. The surrounding pages hold the stable method, vocabulary and applied project context.