Skip to content

OUR LONG-TERM PRODUCT VISION

How OR.BIT.Ai works

Adaptive life automation, built around local intelligence, clear permissions and meaningful human control.

This page describes the long-term product vision. It is not a list of features available in the first release.

INTELLIGENCE FOR EVERYDAY LIFE

Your environment, learning to support you.

OR.BIT.Ai is a life automation platform designed for buildings and the people who live and work in them.

At its core is an intelligent device that brings supported connected systems together. Through local intelligence, pattern recognition and preferences you choose to share, it is designed to understand recurring needs and adapt as everyday life changes.

What the smartphone is to the individual, OR.BIT.Ai aims to become for the spaces around them: a central point of connection, intelligence and coordination.

The goal is to reduce the effort of navigating separate systems, repeating instructions and managing everyday tasks individually. Its intelligence should become more useful over time, while its permissions remain yours to define.

OR.BIT.Ai Base device with its green light guide illuminated

THE INTENDED EXPERIENCE

From connection to useful, bounded action.

Learning changes its understanding. Only your approval changes its authority.

  1. Connect

    Connect supported devices, sensors and building systems. Choose which information OR.BIT.Ai can access and which functions it can control.

    Integration depends on compatible equipment and supported interfaces.

  2. Understand

    Process permitted information locally to recognise routines, understand relevant conditions and identify recurring needs.

    Inputs can include room conditions, equipment status, schedules and user-provided preferences.

  3. Anticipate

    Use recurring patterns and current conditions to suggest what may be useful next, with room for you to correct its assumptions.

    A prediction is an estimate, not a certainty.

  4. Act within permission

    Carry out familiar tasks within the boundaries you have approved. Ask before taking actions that require additional permission.

  5. Check and explain

    Where connected systems provide feedback, check whether an action succeeded and make the result understandable.

    An unconfirmed action remains unconfirmed.

  6. Adapt

    Use your feedback and permitted local history to refine future responses as your routines change.

CURRENT SOFTWARE DEMONSTRATOR

A visible decision path, from signal to evidence.

The reviewed OR.BIT.Ai demo is an architecture simulation. It explores how device states, proposals, policy checks, permissions, fallback behaviour and audit evidence could work together. It is not proof of production security, released integrations or certified building control.

  1. 01

    Device abstraction and validation

    DEMONSTRATED IN UI

    The demo normalises lighting, climate, energy, access and sensor categories, then rejects unsupported, offline or read-only writes instead of treating every device alike.

  2. 02

    Proposal before action

    DEMONSTRATED IN UI

    Tasks are represented as proposals with a reason, intended impact, target actions and risk context before anything is eligible to proceed.

  3. 03

    Layered governance checks

    DEMONSTRATED IN UI

    State validity, operational risk, energy conditions, safety policy and human approval are evaluated as separate gates. A plausible action is not automatically an authorised action.

  4. 04

    Execution feedback

    DEMONSTRATED IN UI

    Permitted actuator writes return a confirmed, failed or unconfirmed state. Missing equipment feedback is kept visible and is never presented as success.

  5. 05

    Resource-aware fallback

    ARCHITECTURE SIMULATION

    The simulation explores local inference and deterministic fallback when power, thermal, connectivity or integrity conditions change. A tamper event can suspend scheduling and require recovery.

  6. 06

    Evidence and memory boundaries

    ARCHITECTURE SIMULATION

    An event stream, decision trace, action history and separate retention zones explore how operators could inspect the chain without making all stored context equally available.

  7. 07

    Ownership and update lifecycle

    ARCHITECTURE SIMULATION

    Provisioning, active ownership, staged A/B updates, health checks, rollback and decommissioning are represented as one controlled device lifecycle.

  8. 08

    Multi-node trust boundaries

    ARCHITECTURE SIMULATION

    Peer auditing, portfolio coordination, scoped trust contracts and revocation are explored as concepts for larger deployments, not stated as released federation features.

ILLUSTRATIVE SCENARIOS

Everyday automation, shaped by permission.

Contemporary residential environment at dusk

A morning with fewer small tasks

Situation
A familiar morning routine begins.
Permitted inputs
An approved schedule, room conditions and saved preferences.
Intended response
Coordinate supported lighting, shading and climate settings within permitted limits. Offer an adjustment when the day differs from the usual pattern.
Human control
Choose the routine, adjust preferences, skip it or pause automation.
Practical benefit
Fewer repeated adjustments before the day gets started.

Authored simulations only. These examples do not use visitor data, cloud-based guest profiling or live building connections.

Notice earlier. Understand the situation. Respond with control.

Our vision extends to helping people recognise unusual events and manage risks around their spaces. By bringing permitted signals together locally, OR.BIT.Ai is designed to provide context, suggest appropriate next steps and coordinate supported responses within clearly defined permissions.

An unusual event is a reason to check, not proof of a threat.

Access and physical security

Water and environmental risks

Equipment and operational risks

Connected-device and system health

01An entrance left open after closing
Situation
A monitored entrance remains open beyond the configured closing period.
Inputs
A supported door contact, the approved operating schedule and authorised access-system events where available.
Interpretation
Show the observed event and possible explanations, such as an authorised late departure or a door that has not closed properly.
Response
Notify the designated authorised user, identify the entrance and provide the relevant event timeline.
Control
Ask the user to verify the situation. Any supported access-control action remains governed by explicit permissions and the access system's own safeguards.
Benefit
Less reliance on someone remembering to check every entrance.
Boundary
Never infer criminal intent, automatically lock people inside or obstruct emergency exit routes.
02A possible water leak
Situation
A supported moisture sensor reports water in an area expected to remain dry.
Inputs
Sensor status, location and compatible flow measurements where available.
Interpretation
Explain which sensor triggered and whether another signal supports the alert. Do not state that a leak is confirmed solely from an ambiguous reading.
Response
Raise an alert and show the location. Where a compatible isolation valve and a validated policy exist, request approval or apply a previously authorised response.
Control
The owner or operator determines whether a specific valve may be operated automatically.
Benefit
Earlier awareness and a clearer path to limiting potential damage.
Boundary
Never operate fire-suppression water supplies or other critical services. Valve control must be limited to explicitly supported installations.
03Equipment behaving unusually
Situation
A monitored device reports an abnormal temperature or a sustained change in operating behaviour.
Inputs
Compatible equipment telemetry, documented limits and permitted local operating history.
Interpretation
Identify the observed deviation without claiming to know the root cause or predict a failure with certainty.
Response
Explain the change, flag it for inspection and prepare a proposed maintenance task.
Control
Staff approve service actions. Automatic load reduction or shutdown is only considered for supported, non-critical equipment under an approved policy.
Benefit
More focused maintenance attention and less manual inspection of routine readings.
Boundary
Do not promise fire prevention or interrupt critical systems. Certified alarms and equipment protections operate independently.
04Unexpected activity from a connected device
Situation
A supported integration reports repeated failed sign-ins, a configuration change or an unfamiliar device.
Inputs
Authorised security events from compatible devices or network-management systems.
Interpretation
Describe the event as unusual activity requiring review. Do not label it a confirmed cyberattack without evidence.
Response
Notify the administrator and present options to review the event or revoke the affected OR.BIT.Ai integration's access.
Control
Broader network isolation requires an explicitly supported management integration and appropriate authorisation.
Benefit
Clearer visibility into changes that might otherwise go unnoticed.
Boundary
Do not imply universal network inspection, guaranteed attack detection or protection of every connected device.
05A sensor stops reporting
Situation
A connected sensor misses its expected reporting interval.
Inputs
Last-seen time, connection status and the configured reporting interval.
Interpretation
State that current conditions are unknown, rather than assuming everything is normal.
Response
Show the missing signal, flag affected routines and use their documented fallback behaviour.
Control
Users can inspect the issue and choose an appropriate manual response. Dependent automation follows preconfigured limits.
Benefit
People know when monitoring is incomplete and which functions may be affected.
Boundary
Never show stale readings as live data or display "All safe" when essential signals are unavailable.
06Several signals need attention
Situation
A leak alert appears while related equipment also reports an error.
Inputs
Permitted events, timestamps and the installation's documented device relationships.
Interpretation
Group related observations without inventing a confirmed cause.
Response
Present one understandable incident view with the affected area, observed signals, proposed actions and response status.
Control
Only authorised users can review private incident details or approve restricted actions.
Benefit
Less fragmented information and a clearer sequence of next steps.
Boundary
Do not automatically contact emergency services, insurers or external responders. External escalation must be separately supported and explicitly authorised.

SIMULATION

Explore a possible water-leak response.

Choose a permission mode and inspect how the example changes. This walkthrough uses authored content only.

  1. ObservedSensor reports moisture.
  2. Possible issueOR.BIT.Ai presents the available context.
  3. Awaiting approvalThe configured permission determines the response.
  4. Not attemptedAvailable feedback confirms or fails to confirm the action.

Permission mode

Available feedback

ObservedSupported moisture sensor reports water in a dry area.

InterpretationPossible issue. The alert is not treated as a confirmed leak.

ResponseA valve action is proposed. Nothing proceeds until an authorised user approves it.

FeedbackNo valve action has been attempted, so there is no completion signal.

Simulation only. It cannot connect to real devices, collect information, operate a valve or send a notification.

You set the boundaries. OR.BIT.Ai works within them.

Human control should not mean approving every small action. It means choosing where automation is welcome and where your decision is required.

AUTOMATIC WITHIN LIMITS

Familiar, permitted tasks can happen without repeated instructions.

ASK FIRST

Sensitive actions, unfamiliar circumstances and changes beyond existing permissions require approval.

NEVER ALLOWED

Excluded actions and systems remain outside the device's authority.

INTENDED CONTROLS

Authority stays visible and changeable.

  • Review and change permissions.
  • Inspect and correct saved preferences.
  • Review available action history.
  • Pause routines or automation.
  • Delete learned personal information.
  • Retain supported manual controls.
  • Define who may view alerts and approve restricted actions.

Recognising a pattern does not grant permission to change a lock, isolate equipment or contact another person.

Personal intelligence should remain personal.

Private data, learned patterns and personal preferences are intended to remain local and private on your OR.BIT.Ai device. Personalisation is designed to happen locally, without sending that private information to the cloud for learning or prediction.

LOCAL PROCESSING

Build understanding where the device is installed.

PERMISSION-BASED ACCESS

Access only the information and functions you permit.

CONTROL OVER MEMORY

Review, correct and delete the personal information the device remembers.

DEFINED CONNECTION BOUNDARIES

Connecting an external service does not grant it access to your private context.

Activity histories and incident details can reveal private routines. Their visibility, retention and any export must remain under authorised user control.

One vision. A family of devices.

OR.BIT.Ai is being developed across Base, Pro and Enterprise models, with configurations intended to serve different installation needs.

OR.BIT.Ai Base shown in the label-free product family image

PLANNED POSITIONING

OR.BIT.Ai Base

Pilots and bounded zones.

A compact entry point to the OR.BIT.Ai platform, with a focus on straightforward installation and everyday local automation.

Current public direction: a compact edge hub for focused pilot programs, smaller buildings and defined operational areas.

Detailed specifications and supported integrations will be published for each release.

OR.BIT.Ai Pro shown in the label-free product family image

PLANNED POSITIONING

OR.BIT.Ai Pro

Offices, hospitality and multi-site operations.

A more expandable configuration for installations that need additional capacity and flexibility as their connected environment grows.

Current public direction: a higher-performance direction for more demanding local workloads and broader building operations.

Detailed specifications and supported integrations will be published for each release.

OR.BIT.Ai Enterprise shown in the label-free product family image

PLANNED POSITIONING

OR.BIT.Ai Enterprise

Larger managed environments.

A configuration intended for larger or more demanding managed environments, with deployment options suited to organisational needs.

Current public direction: a modular direction for larger operational environments requiring expandable local compute.

Detailed specifications and supported integrations will be published for each release.

DEVELOPMENT AND AVAILABILITY

A platform that develops over time.

The first version will establish a practical foundation. The broader vision, including richer adaptation, deeper coordination and more capable automation, will develop progressively.

Each release should clearly identify its available features, supported integrations and operating requirements.

Current readiness: Architecture prototype. Production pilot program in development.

Security and risk release information should identify:

  • Supported sensors and systems.
  • What can be monitored.
  • Which actions are advisory or executable.
  • Required approvals and safeguards.
  • Known limitations and fallback behaviour.

Simulations remain distinct from validated functionality. No release date, universal compatibility, guaranteed saving or perfect-security claim is implied.

QUESTIONS

Clear answers for a developing platform.

Do I need to give it instructions for every task?

The goal is for familiar tasks to happen within permissions you have already set. New or sensitive decisions may still need your input.

Does OR.BIT.Ai learn about me?

The vision includes local learning from information you permit, such as routines and preferences. You control what it may remember and can correct its assumptions.

Does private information leave the device?

The platform's design principle is to keep private data and learned personal context local. External connections must have clearly documented boundaries and must not silently share that context.

Can I override an automated action?

Manual control and the ability to pause automation are core design requirements. Specific controls depend on the connected equipment and release.

Will it work with my existing devices?

Compatibility depends on supported integrations and equipment. Release-specific information will identify what can be connected and controlled.

Can it help with security and risk management?

The vision includes bringing permitted events together, highlighting unusual conditions and coordinating approved responses. Capability depends on connected systems and the release.

Will it automatically lock doors or shut off equipment?

Such actions must never be assumed. Any supported intervention requires explicit permissions, installation-specific safeguards and appropriate operating limits. Emergency exits and critical systems must remain protected.

Does it replace an alarm or fire-safety system?

No. OR.BIT.Ai is intended to complement supported systems. Certified safety equipment and established emergency procedures remain independent.

What happens if it misinterprets an event?

Users should be able to inspect the observations, correct assumptions and adjust routines. Uncertain events should be presented as uncertain.

What if a sensor goes offline?

The intended behaviour is to show the missing information, identify affected functions and follow documented fallback rules rather than assume conditions are normal.

Does everything described exist in the first version?

No. This page explains the long-term vision. Features and integrations will be introduced progressively.

Does it need an internet connection?

Core intelligence is intended to run locally. Internet requirements for updates and optional services will be documented for each release.

Less to manage. More space to live.

An environment that becomes more useful over time, while keeping you in control.