Explore the professional data and method foundation.
Be Water Work · Features & specifications
Work · Ongoing tasks and human control
New product in developmentWork brings AI, tools, professional methods and people together around ongoing industrial tasks. Review the planned task features, integrations, deployment options and reference workloads, including how work resumes, changes and passes between people or systems.
Software features at a glance
| Function | Planned capability | Operating boundary |
|---|---|---|
| Role workspaces | Structured views for operators, engineers, managers, project leads and partner developers | Task and evidence views are the main interface; conversation provides another way to work on the same task. |
| Triggers & ongoing tasks | User requests, schedules, events, thresholds, model results, webhooks and external-system changes | Reference minimum scheduled interval: 1 minute. Sub-minute equipment coordination belongs to the site runtime, not language-model task scheduling. |
| Durable task lifecycle | Checkpoints, dependencies, timers, reasons for waiting, reminders, cancellation and handover | Waiting for data, approval, an expert or an operating window does not continuously occupy a model session. |
| Evidence & knowledge | Source references, data windows, model/tool versions, approved SOPs and task/incident context | Historical similarities remain distinct from a current diagnosis; approved knowledge retains its scope and validity. |
| Tool-assisted execution | Engineering calculations, existing-system adapters, drafts and permitted routine business actions | Reading, drafting, communicating and executing require different permissions; check uncertain external outcomes before retrying. |
| Controlled development | Capability-package creation, program drafting in an isolated environment, simulation and controlled release to production | A generated program or method does not obtain production credentials or action authority automatically. |
| Mobile work & limited connectivity | A PWA or qualified mobile client with approved documents, checklists, photos and drafts available locally | Unsynchronized work remains visibly local. Offline input does not imply an equipment command was executed. |
This is the planned Work software scope. The selected work packages, system adapters, client compatibility and support arrangements are identified for delivery; the table does not claim a released autonomous workforce.
A working record that survives the conversation
Chat can start the work. A persistent record lets an operator, colleague or support partner understand the task without reading the whole conversation again.
A persistent task record
- Objective and completion
- The operating outcome, affected objects, deadline, completion evidence and conditions for stopping.
- Responsibility and authority
- The task owner, executor, approver and verifier, together with permitted actions and when that authority is valid.
- Progress and dependencies
- Completed steps, outstanding work, reasons for waiting, external system references and the next expected event.
- Evidence and decisions
- Data time windows, document references, calculation results, tool outcomes and recorded approvals.
Where a CMMS, ERP or another customer system holds the official record, Work links to it and retains the analysis and execution context. Responsibility for each field and synchronization are agreed to avoid duplicate reporting.
Continue across interruptions and handovers
Define and prepare
Check the requested result, available evidence, tools, responsibilities and existing authority. Break a larger job into dependent work where needed.
Execute within the assignment
Retrieve approved information, run professional methods and carry out permitted steps. Associate results and external references with the same task.
Wait with a visible reason
Preserve the task while waiting for data, a person, an operating window or an external system. A waiting task can remain available without an open model conversation.
Resume with current conditions
Recheck permissions, data freshness, document versions and site state. An earlier plan does not make a revoked authorization valid again.
Verify and hand over
Compare the result with the agreed completion conditions. Retain unresolved issues, the next owner and follow-up observations when more work is required.
An analysis delivered, a work order created, a repair completed and an improvement verified are different outcomes. The selected work definition determines which one the task is responsible for.
Interfaces, tools and integration records
| Interface or integration | Planned specification | Integration conditions |
|---|---|---|
| Application integration | REST, event and SDK adapters; MCP as an optional adapter | Connect the approved documents, SCADA/data platforms, ERP, CMMS, communication and model services needed for the selected work. |
| Tool definitions | Structured input/output schemas, identity, read/write type, error category, retry and compensation behavior | Register and review each tool; a URL in a document does not become an authorized tool. |
| Engineering calculations | Core, existing customer models or approved deterministic services | Retain the input snapshot, units, version and returned calculation; a language response does not substitute for an agreed formula. |
| External records | Customer-system references and explicit field ownership | Keep the formal CMMS/ERP record in its existing system when appropriate; synchronize agreed fields and expose conflicts. |
| Model services | Local, private and cloud model routes selected by task and data policy | External model access can be prohibited. Local inference needs separately sized models and compute resources. |
| Files & knowledge | Isolated file parsing, versioned SOPs/manuals and evidence references | File macros/scripts are not executed by default; data destinations, knowledge use and retention remain governed. |
| Developer tooling | Capability-package studio, executable examples, simulators and permission checks | Versioned adapters and runnable examples are selected for the capability package. |
The deployment compatibility matrix identifies the actual adapters, schemas, tool versions and model dependencies. Work can use existing systems and models through the required interfaces. Add Core where the task needs Core’s industrial data context or calculations; existing systems can remain the source of record.
Delegate routine work and keep control of the boundaries
| Type of work | Within an approved assignment | When a new decision is needed |
|---|---|---|
| Observe & analyze | Read permitted sources, run approved calculations and organize evidence | A new source, sensitive data destination or professional scope is required. |
| Prepare & draft | Prepare an analysis, report, work order or proposed change | Publication, external communication or a commitment falls outside the assignment. |
| Routine business actions | Create allowed internal tasks, update agreed fields and send approved notifications | The scope, budget, responsibility or recipients change beyond the existing authority. |
| Operating actions | Request an authorized action through Edge or the customer’s approved local execution controls | Operating limits change, a new high-consequence path is introduced or site conditions invalidate the approval. |
| New methods | Develop and evaluate a candidate in an isolated test or shadow environment | Production use, model promotion or a new trial requires its defined approval. |
Routine authority can cover a defined class of work without repeated approval clicks. It has a visible scope, time window and pause or revocation route. AI confidence is not operating permission.
Deployment and runtime environment
| Option | Runtime arrangement | Important dependency |
|---|---|---|
| SaaS | Managed Work application, durable task state and approved remote tools | Agree data location, identity, sources, model routes and support scope. |
| Customer private cloud | Application/executors with a database and durable workflow engine in the selected customer environment | Provide network access and identities for each approved tool; scale executors around tool capacity. |
| Site server | Local persistent task state, plus the models and tools required for offline work | A disconnected task can continue only where its required data, methods and tools are available locally. |
| Edge + Work | Separate devices or qualified shared infrastructure where appropriate | An ordinary E-S node is not assumed to host the complete Work system. Equipment actions still pass through Edge or the customer’s approved execution controls. |
Host OS and dependency versions are confirmed for the selected configuration. Application resources, durable storage and local model compute are sized separately; choosing a local deployment alone does not make every tool available offline.
Resource and workload reference profiles
| Profile | Application resources | Workload to validate |
|---|---|---|
| WL-S · site or small team | Application starts at 8 vCPU and 16 GB RAM; database and durable workflow services are additional, or share a qualified Core deployment with separately accounted resources | 25 registered and 20 concurrent users; 20 executing tasks, 1,000 waiting tasks and 5 concurrent language-model requests. |
| WL-M · multiple teams | Application and executors total 16–32 vCPU and 32–64 GB RAM; independent database and durable workflow services | 100 registered and 50 concurrent users; 100 executing tasks, 10,000 waiting tasks and 20 concurrent language-model requests. |
These untested target profiles describe the software application and executor workload. They exclude local model accelerator memory and do not establish end-to-end response time. Model-provider and external-tool rate limits, model choice, task complexity and human waiting times remain separate limits; size persistent storage from evidence, files and retention.
Operation, recovery, upgrades and export
| Area | Planned behavior | Configuration or handover detail |
|---|---|---|
| Resume & retry | Restore durable checkpoints and recheck current authority, document versions, data freshness and tool state | For an uncertain external write, query the external result or request review before repeating it. |
| Backup & recovery | Recover persistent tasks, evidence, permissions and workflow dependencies from the selected backup/redundancy arrangement | Single-host recovery, single-node redundancy and site-disaster recovery are separate scopes; local state and model/tool dependencies must also be available. |
| Workflow upgrades | Pin running tasks to a workflow/capability version; allow continued use or controlled migration | Changes to tools, SOPs, models, permissions or roles identify tasks that can continue, need review or must stop. |
| Mobile synchronization | Distinguish saved-on-device records from synchronized records; resolve version/field-ownership conflicts | High-risk approvals do not automatically take effect offline. |
| Retention & knowledge | Separate temporary task memory, incident summaries, approved knowledge and formal evidence | Retention, deletion and data-use permissions are selected independently; customer material is not automatically used for general model training. |
| Customer export & exit | Export customer work definitions, tasks, inputs/outputs, evidence references, configuration, review records and license-permitted knowledge packages | Preserve task state and external-system IDs; hand over running tasks, pending approvals and external actions already performed. |
| Ongoing ownership | A work capability identifies delegated work, autonomous scope, exceptions, completion evidence and the support route | Professional support and coverage are agreed for that work; a software log does not replace contractual or site responsibility. |
The task record remains distinct from the equipment’s local protection and operating continuity. Backup scope, supported versions and service commitments are agreed for the selected configuration.