Technology
A standardised architecture with a controlled application envelope.
Elemenos Adapt is designed to support multiple qualified chemistry families within one engineering framework. Hardware interfaces, local control, deployment logic and evidence handling remain governed while process chemistry and equipment duty are configured for the application.
The smartphone analogy
Elemenos is to process infrastructure what the smartphone was to single-purpose machines.
A legacy plant resembles an old printer: it is engineered around one principal job, one internal mechanism and a tightly coupled stack. Elemenos resembles a smartphone: one governed hardware and interface architecture can run different qualified applications without pretending that every application is identical.
Platform + qualified applicationsStandard interfaces and reusable infrastructure; each Chemistry Kit, route and project still needs its own released envelope and evidence.
Hardware, chemistry, controls and flowsheet are commonly engineered together for one defined duty; major change can propagate through the whole design.
Architecture comparison
What is structurally different.
The comparison separates the platform concept from application performance. Conventional plants can be excellent at their designed duty; Elemenos changes where reuse, configuration and evidence boundaries are placed.
| Architecture dimension | Elemenos Architecture | Conventional fixed-purpose plant | Why it matters |
|---|---|---|---|
| Design starting point | Reusable platform boundaries plus a named feed, Kit, route and receiver | A project-specific flowsheet and equipment train | More of the architecture can repeat while application duty remains explicit |
| Hardware and chemistry | Separated: hardware is the platform; chemistry is a qualified application | Often co-designed and tightly coupled around one process | Chemistry can change through a controlled Kit without assuming hardware compatibility |
| Process envelope | Outer platform envelope → Kit envelope → feed/project envelope → campaign release | A project operating window embedded across design documents and controls | The active permission boundary is visible and becomes narrower at each layer |
| Application change | New or customer-proprietary Kit enters through qualification and controlled release | Process change commonly drives wider re-engineering and management of change | Affected boundaries can be requalified without silently redefining the whole plant |
| Configuration identity | Named model, modules, Kit, recipe, hardware pack and evidence version | Plant tag set, project documents and operating procedures | The exact running configuration can be reconstructed |
| Feed variability | Named acceptance, preparation and bilateral handoff responsibilities before critical duty | Handled by the project flowsheet, operator action and control tuning | The reactor is not treated as an undefined compensator for unknown feed |
| Module interfaces | Inputs, outputs, receiver, envelope and verification are explicit at every handoff | Interfaces may be unique to the project and distributed across disciplines | No module output is assumed to be acceptable to the next function |
| Scaling | Select 20C/20X/40S/40P, add verified trains or move to Adapt Plant | Resize or duplicate project-specific equipment and utilities | A defined family provides a repeatable starting point; sizing still requires project balances |
| Deployment form | Compact transportable architecture or site-scale packaged skids | Predominantly site-engineered installation | Factory repeatability and site work can be separated where the duty permits |
| Control execution | Released normal sequences execute locally in PLC/HMI with allocated safeguards | Local PLC/DCS/SCADA executes project-specific control logic | Elemenos does not make cloud control a dependency |
| Digital authority | Advice, permission and physical execution are separate roles; Olerib is a distinct governance IP | Advisory, operator and control authority vary by project architecture | A recommendation is not automatically an action right |
| Safety | Independent protection retains its allocated veto/de-energise authority | Defined by the project safety lifecycle and protection layers | Digital governance never replaces SIS/ESD or accountable operating procedures |
| Evidence timing | Required evidence is named before a route, Kit or campaign is released | Evidence is produced through design, commissioning, operation and audit | Missing, stale or conflicting evidence does not become implicit approval |
| Data structure | Source-to-decision digital thread across configuration, request, evidence and outcome | Historian, documents, alarms and reports may sit in separate project systems | Decisions can be reviewed with their exact context |
| Operations | Versioned recipes, named states, changeover and receiver logic | Plant-specific operating procedures, control narratives and operator knowledge | Tacit knowledge is converted into controlled configuration where practical |
| Maintenance and upgrades | Common architecture plus model-, module-, Kit- and project-specific parts and tasks | Asset- and project-specific maintenance basis | Reuse is possible only where materials, duty and interface evidence remain valid |
| Commercial screen | Navigator exposes a preliminary route, comparison allowance and missing inputs | Concept studies and estimates are assembled for the particular project | Early customer questions become visible without presenting a binding design |
| IP model | Adapt, Olerib Vision and Sensor Witness Authorization are protected as separate patent families | Process, equipment and control IP depend on suppliers, licensors and project ownership | Platform, governance and sensor-evidence inventions remain distinct |
How it works
Measure. Verify. Progress.
Conventional systems are often described through setpoints alone. Elemenos is structured around verified process states: if the required state is not verified, the process does not continue.
Feed envelope gate
The source, variability and available analysis are checked before a route is released.
Upstream conditioning
Preparation creates a controlled feed state for the selected process—not a hidden correction inside the reactor.
Stage verification
Measurements, equipment state and route identity are verified at each boundary.
Safety enforcement
Independent protection retains its allocated authority; digital services do not replace it.
What stays fixed and what changes
Standardise the interfaces. Engineer the duty.
The architecture separates reusable platform rules from application-specific configuration and evidence.
| Layer | Standardised | Configured per application | Required evidence |
|---|---|---|---|
| Physical backbone | Module boundaries, service logic and interfaces | Materials, equipment duty, corrosion and erosion controls | Design calculations and supplier evidence |
| Process | Functional sequence and no-bypass boundaries | Chemistry, residence time, temperature and separation route | Representative testwork |
| Controls | Local deterministic execution and state model | Setpoints, alarms and permitted recipes | SRS, cause/effect, FAT and SAT |
| Product | Protected product buffer and named-receiver logic | Product grade or water specification | Acceptance protocol |
| Deployment | Transportable module or skid architecture | Count, footprint, utilities and site assembly | Layout, lifting and site studies |
Evidence-led readiness
Architecture is not the same as release.
Maturity is shown as a gate, not hidden behind a generic “commercial” label.
Frequently asked
Questions that decide the project.
How is feed qualified?
A named source is characterised for composition, variability, physical properties, hazards and the intended product or receiver. Representative testwork then supports the engineering basis.
What is fixed and what is configured?
Functional boundaries, control authority and evidence logic remain governed. Chemistry, equipment duty, wetted materials and site layout are configured for the case.
Can a project use customer-supplied chemistry?
Potentially. The proposed chemistry must be qualified against the feed, wetted materials, equipment duty, safety basis, emissions and residual routes. Recipe ownership, data handling and release conditions are then defined in the project agreement.
How is capacity increased?
By selecting a suitable compact model or adding verified trains and capacity-matched support functions. Scaling is not assumed to be linear without balances and supplier verification.
How is solids transport and sedimentation risk addressed?
Rheology, particle-size distribution, line velocity, residence time, equipment geometry and flush or recirculation duties are established from representative data. No generic “zero sedimentation” claim is made without hydraulic and operating evidence.
Can future process technology be introduced?
A new chemistry, separation method or recovery technology can be evaluated as a controlled configuration change. Compatibility, safety, performance and interface evidence determine whether existing hardware can be reused or must be modified.
What determines deployment time?
Scope maturity, testwork, long-lead equipment, site works, utilities, transport, permits, factory testing and site acceptance determine the schedule. A project timeline is issued only after those inputs are defined.
How are upgrades controlled?
Through released configurations, versioned recipes, interface checks and requalification where a change affects safety, capacity, material compatibility or product acceptance.
Intellectual-property wording and application status must follow current legal records