Supervisory governance & witness
Olerib Vision
Evaluates policy, identity, route, evidence and the requested action.
May permit, deny or escalate; does not actuate final control elements.Digital ecosystem · Runtime architecture
A digital architecture built around explicit authority.
The physical process remains local. Digital services organise state, permission, evidence and traceability while local automation and allocated safety functions retain physical authority.
01 Measured input02 Explicit permission03 Local execution04 Traceable outcome
Architecture stack
One connected map with an explicit control boundary.
Commercial services, supervisory governance and plant execution are connected, but they are not interchangeable. The map shows who may advise, who may permit and who physically acts.
Industrial logic & coordination
Elemenos Runtime (ERA)
Organizes validated state, configuration, orchestration and traceability across the platform.
Prepares and records released work; local control remains the execution authority.Feed-reference evaluation
FRNE
Structures measured feed data, compares it with the configured envelope and identifies required correction or review.
A project-specific envelope and qualified measurements are required before release.Bounded deterministic advisory
Olerib Foresight
Evaluates a questioned signal or proposed action inside approved collective context and projects its governability across three evidence horizons.
Advises Olerib only; cannot authorise, deny, stop, verify or originate execution.PLC · HMI · SIS / ESD
Local automation
Executes released sequences, provides operator interaction and enforces allocated interlocks and protective functions.
The PLC executes; independent safety retains its allocated veto and de-energise authority.Telemetry & lifecycle data
Adapt Connect
Moves approved plant and fleet data between defined services for remote support and lifecycle visibility.
Connectivity is not a substitute for local control or site operating procedures.Adapt Intelligence · ADI / Adapt Radar · Adapt Exchange
Intelligence & commercial services
Supports analytics, diagnostics, deployment intelligence and commercial collaboration.
Advisory and commercial services have no plant command authority.Runtime at a glance
Inputs become a request. A verified request becomes local work.
Inputs, digital gates, execution authority and recorded outputs remain visibly separated throughout the decision path.
Observed & configured
- Laboratory and sensor data
- Device and module state
- Kits, recipes and envelopes
- Operator identity and request
- Approved external-system context
Digital gatesState→Route→Rules→PermissionUnknown, stale or conflicting evidence is not implicit approval.
Acted & recorded
- Released PLC sequence
- Asset operation and protective response
- Time-stamped data and events
- Alarm and operator acknowledgement
- Outcome evidence and engineering report
IDIdentity & access
DATAData service
CFGConfiguration
AUDAudit record
APIIntegration
TIMETime service
Runtime overview
Eight cross-cutting orchestration roles.
The overview uses eight broad roles. The detailed architecture below separates the same work into fifteen named service engines.
| Runtime role | Functional responsibility | Authority boundary |
|---|---|---|
| FRNE | Structure and compare feed condition against the configured reference | Requires qualified measurement and a released envelope |
| State | Maintain the current configured state of modules, equipment, routes and material | State record is not physical confirmation unless linked evidence supports it |
| Route | Evaluate the intended path, lineup, isolation and resource availability | Local feedback and interlocks remain authoritative |
| Rules | Apply configured constraints, limits and applicable operating rules | Cannot override allocated safety functions |
| Execution | Sequence a permitted request for release to local automation | PLC executes; cloud and advisory services do not actuate |
| Safety | Evaluate digital permissives and monitor the status of allocated protections | SIS / ESD retains its allocated veto and de-energise authority |
| Convergence | Evaluate stability and movement toward a target using an approved basis | No predictive result is accepted without a qualified model or test basis |
| Alarm | Classify events, preserve context and present required intervention | Operators and site procedures govern accountable response |
Decision progression
A process step earns the right to proceed.
A failed gate pauses progression and directs the process to a defined correction, rejection, safe state or accountable operator decision.
01MeasureNamed source, unit and time
02Structure stateFeed, signal, route and module tokens
03Compare envelopeReleased application limits
04Evaluate requestPolicy, role and available evidence
05Execute locallyPLC sequence and allocated safeguards
06Verify outcomeRecord result or reopen the loop
If the evidence does not support release: pause, correct, reject or escalate
S0 SafeS1 PrepareS2 PrimeS3 RunS4 Abnormal / tripS5 Service / recovery
Operative runtime architecture
Fifteen named engines, grouped by control function.
The engine set is grouped by feed and equipment truth, configuration, authorisation, evidence and fleet support. Names describe intended responsibilities; project implementation still requires released software, interfaces and test evidence.
Feed & equipment truth
3 engines- 01Feed Reference Neutralisation
Structures feed measurements, compares them with the configured reference and records required correction or review.
- 03Sensor Truth
Reconciles available signals and records freshness, disagreement, drift and the evidence used to accept a value.
- 04Valve Truth
Compares commanded position with available position, flow and pressure feedback.
Configuration & routing
4 engines- 02Kit Envelope
Holds the released operating window and kit-specific limits for the selected application.
- 05Liquid Routing Truth
Checks the requested path against configured valves, isolation, flush and recirculation routes.
- 06Module State
Maintains named module states such as prepare, run, pause, clean, isolate and fault.
- 07Setpoint Translation
Translates an authorised correction into a bounded setpoint request for local automation.
Safety & authorisation
3 engines- 08Safety Permission
Checks the digital permissive record while PLC and independent safety functions retain their allocated authority.
- 10Alarm & Intervention
Classifies events and presents the operator with the available context and required response.
- 11Operator Authorisation
Associates identity and role with the set of requests an operator may submit or acknowledge.
Evidence & lifecycle
3 engines- 09CIP / Cleaning Trigger
Records when cleaning is due and the evidence required before a subsequent configuration is released.
- 12Digital Thread
Links source, configuration, request, decision, execution record and available outcome evidence.
- 15Olerib Verification
Records the policy and evidence considered when a request is permitted, denied or escalated.
Fleet & support
2 engines- 13Fleet Data
Organizes approved operating history for comparison, service and engineering review across deployed units.
- 14Remote Operations
Supports supervised remote assistance within the site's access, cyber-security and authority rules.
FRNE · Feed Reference Neutralisation Engine
Turn measured feed reality into an explicit release decision.
FRNE is presented as a deterministic feed-reference workflow. It does not infer an approved process envelope: that envelope must come from qualified project work.
01MeasureLab, sensors and field records
02TokeniseSource, unit, quality and time
03EvaluateCompare with the released envelope
04RecommendPropose a bounded correction
05PredictCheck response against an approved model
06ReleaseIssue a setpoint request only when permitted
07ExecuteLocal automation performs the action
08VerifyNew evidence re-enters the loop
Examples of detected deviation
- Solids or viscosity outside the released window
- pH, ORP, conductivity or density outside limits
- Unexpected feed drift or signal disagreement
- Route, equipment or module state not confirmed
Candidate response—not an automatic command
- Dilute, blend, heat, cool or recirculate
- Pause for laboratory or operator review
- Reject the feed or isolate the route
- Trigger cleaning review before configuration change
Olerib Foresight · Advisory runtime
Evaluate collectively. Judge locally.
Foresight evaluates one questioned signal or proposed action inside the available approved context and projects its expected governability across three evidence horizons. It returns a bounded recommendation to Olerib Vision—not permission and never a plant command.
3 × 3STEP 1STEP 2STEP 3
Signal 1Expected evidenceExpected evidenceExpected evidence
Signal 2Expected evidenceExpected evidenceExpected evidence
Signal 3Expected evidenceExpected evidenceExpected evidence
BOUND OUTPUT
One advisory recommendation
- Questioned signal or action
- Suggestion source and collective context
- Step 1 / 2 / 3 projection
- Current path versus proposed path
- Governability and superiority result
- Recoverability, interruptibility and collapse conditions
- Confidence result and witness record
01FRNE / operator / advisory sourceProposes or questions
02ForesightReturns bounded advice
03Reality / witnessSupplies current evidence
04OleribIndependently permits, denies or escalates
05Local automationCombines release with local permissives
06Physical executionPLC acts; SIS / ESD remains independent
Token language
Eight token families make the decision inspectable.
A token is a structured record, not a physical asset or a performance claim. Together the families describe what was observed, requested, permitted, executed and verified.
Feed state
Measured feed value with unit, source, quality and time.
Action
Proposed bounded correction or operational action.
Setpoint
Released target linked to the evidence and action that justified it.
Verification
Available sensor, laboratory or reconciliation evidence.
Route
Configured material path, including isolation, flush and recirculation.
Signal quality
Freshness, agreement and status of the contributing measurement.
Module state
Named operating state visible to the relevant runtime functions.
Policy
Permission, role and boundary applicable to the requested action.
| State | Required evidence | Setpoint status | Feed progression |
|---|---|---|---|
| Outside envelope | One or more accepted parameters outside released limits | Blocked | Blocked |
| Correction planned | Bounded response proposed; authority and model basis open | Pending | Blocked |
| Converging | Approved model or test basis predicts entry into target window | Pending | Blocked |
| Neutral / in window | Accepted parameters inside target window and stable for the specified criterion | Ready for review | Project inputs required |
| Released | Required policy, route, state and verification gates satisfied | Issued | Released to local execution |
| Maintaining | Monitoring remains valid inside the released operating window | Active | Continue with monitoring |
Digital ecosystem products
Eight services around one local plant authority.
Information can move across the ecosystem; command authority does not move with it. Each service has a named role and an explicit boundary.
Independent governance IP
Olerib Vision originated with Adapt but remains a standalone product that can be integrated with third-party industrial environments.
Understand Olerib Vision →Physical process boundaryAdapt equipment + local automationPLC executes · HMI interacts · safety vetoes where allocated
ADI / Adapt Radar
Market and deployment intelligenceFeedstock and tailings mapping, partner and opportunity research, regional demand context
No process authorityAdapt Exchange
Industrial collaboration layerFeedstock and capacity coordination, solution and kit collaboration
No process authorityAdapt Connect
Connected data backboneTelemetry, fleet visibility, configuration delivery, maintenance signals and supervised remote support
Transport only; local authority remainsAdapt Intelligence / Fleet Intelligence
Analytics layerDiagnostics, unit and hub comparison, capacity context and advisory forecasting
Recommendation onlyAdapt HMI
Operator interfaceState, alarm, permissive and operating-window presentation
Operator requests; PLC executesOlerib Vision
Governance and witnessPolicy evaluation, evidence context and allow / deny decision
No final-element actuationOlerib Foresight
Bounded advisory engineCollective context, three evidence horizons, governability comparison and a traceable recommendation
Advice only; Olerib independently decidesAI / deployment advisory
Concept-scope advisory servicePattern detection, scenario support and summaries using governed data
No permission or execution authority| Service | Primary role | Information handled | Authority boundary |
|---|---|---|---|
| ADI / Adapt Radar | Market and deployment intelligence | Feedstock and tailings mapping, partner and opportunity research, regional demand context | No process authority |
| Adapt Exchange | Industrial collaboration layer | Feedstock and capacity coordination, solution and kit collaboration | No process authority |
| Adapt Connect | Connected data backbone | Telemetry, fleet visibility, configuration delivery, maintenance signals and supervised remote support | Transport only; local authority remains |
| Adapt Intelligence / Fleet Intelligence | Analytics layer | Diagnostics, unit and hub comparison, capacity context and advisory forecasting | Recommendation only |
| Adapt HMI | Operator interface | State, alarm, permissive and operating-window presentation | Operator requests; PLC executes |
| Olerib Vision | Governance and witness | Policy evaluation, evidence context and allow / deny decision | No final-element actuation |
| Olerib Foresight | Bounded advisory engine | Collective context, three evidence horizons, governability comparison and a traceable recommendation | Advice only; Olerib independently decides |
| AI / deployment advisory | Concept-scope advisory service | Pattern detection, scenario support and summaries using governed data | No permission or execution authority |
Intended operational value
Benefits must be earned by implementation and evidence.
Each intended outcome is paired with the evidence needed before it can become a public performance claim.
| Intended outcome | Architecture contribution | Evidence required before claiming performance |
|---|---|---|
| More stable qualified feed | Explicit feed envelope, deviation handling and release state | Representative feed campaign, acceptance criteria and trend data |
| Lower transition risk | Named route, state, permission and cleaning gates | HAZOP / risk review, cause-and-effect, FAT / SAT and operating procedures |
| Operator accountability | Identity, role, acknowledgement and linked decision record | Access-control design, audit policy and record-retention verification |
| Faster troubleshooting | Source-to-outcome digital thread and time-correlated events | Commissioned instrumentation, time synchronisation and service records |
| Repeatable commissioning | Controlled configuration, recipes and acceptance gates | Approved commissioning plan and comparable site evidence |
| Fleet comparison | Consistent data definitions and approved cross-unit records | Data-quality rules, comparable operating context and governance approval |
| Reduced dependence on tacit knowledge | Released procedures, configured envelopes and visible decision context | Training, competency assessment and controlled-document review |
| AI-ready analytics | Structured, traceable data for advisory models | Model validation, monitoring and a documented non-actuation boundary |
Control boundary
Credibility begins with explicit authority and evidence boundaries.
Deterministic target
Local execution
Released sequences and interlocks run at the plant, not through an internet-dependent control loop.
Supervisory
Olerib permission
Policy and evidence can permit, deny or escalate a request without directly driving a valve or motor.
Evidence required
Formal claims
No public SIL level, zero-latency, immutability, cyber-security or universal performance claim is made without a released conformity basis.
From architecture to project
Define the feed, route and evidence before configuring the digital layer.
Navigator creates a preliminary functional flowsheet and records the missing project inputs. The digital architecture is then engineered around the selected process and authority model.