Inner Sky Labs Launches Physical AI Models and Kavach Safety Layer

What was announced on October 12

On October 12, 2026, Indian technology publication Express Computer reported that Inner Sky Labs had introduced a modular foundation-model platform for physical artificial intelligence. The announcement describes components for machine perception, planning and safety authorization, including a separate mechanism named Kavach. This is a relevant development for readers following companion robots, but it is not the launch of a new consumer companion device. The announcement concerns technology that could be integrated into different kinds of machines.

The company presents the work as the result of more than a decade of development associated with Miko, a social robot designed for children. That background gives the story a clear connection to the wider market for machines that interact with people. However, the distinction between a research lineage and independently demonstrated deployment remains crucial: an announcement can establish what a company offers or intends to offer without establishing that every model has been validated in every environment.

This article uses the October 12 report alongside Inner Sky Labs' public documentation. It explains why physical safety is distinct from conversational safety and what questions manufacturers would need to answer before such technology could be trusted in private homes. Neither source establishes any partnership between Inner Sky Labs and Realbotix, RealDoll or Lovense, and no such relationship is implied here.

The three layers of the platform

Inner Sky Labs describes a modular architecture rather than a single program that controls every task. Its perception family includes Drishti for vision, Shruti for audio and Sparsh for touch. These components address how a system obtains information about its surroundings. A robot must identify relevant objects, people and physical contact before deciding whether an action makes sense. Good perception may be necessary for reliable operation, but it is not a complete safety guarantee.

The action layer includes Kriya, Karma and Prana. The company's website describes Kriya as a vision-language-action policy family, Karma as a predictive world-model family, and Prana as a broader physical intelligence model. Its materials distinguish capabilities described as currently operating from later-generation ambitions. Those distinctions are important because a visitor could otherwise mistake a description of an architecture roadmap for proof that every component is already generally available.

Kavach forms the advertised safety layer. According to the company, it is intended to evaluate proposed actions before an actuator executes them. That places a possible check between an AI system's plan and its physical consequences. The effectiveness of such a design must ultimately be judged through implementation details, failure cases and independent testing, not through the reassuring meaning of a product name.

Why physical safety is more demanding than chat moderation

A conversational AI can generate a mistaken answer without directly moving an object. A physical robot can alter the environment, collide with furniture or approach a person unexpectedly. Its control software therefore faces additional constraints, including available space, speed, force and whether sensors give a reliable account of what is nearby. A model that performs well at rejecting unsafe words has not automatically demonstrated the ability to prevent unsafe physical movement.

The October 12 report says Kavach is designed to evaluate whether an action stays within locally defined limits. It illustrates how a proposed robot-arm movement might be checked for people in the operating area, permitted speed and workspace boundaries. That is a description of intended operation rather than an independent certification. Buyers should ask which sensors supply these measurements and what happens when sensor readings are incomplete or contradictory.

This distinction matters especially for companion devices, which could operate in homes rather than controlled industrial settings. The user may expect spontaneous interaction, but a device still needs predictable rules when someone crosses its path. A useful safety mechanism can reject a request, pause movement or request clarification even if the conversation model believes it understands the instruction.

What Kavach claims and what remains unverified

Inner Sky Labs' website presents several generations of Kavach, from textual and multimodal checks to a proposed physical-action safety framework. The company also publishes benchmark figures for specific versions. These are company-reported results unless a reader has the complete test methodology and independent replication. They should not be represented as an externally certified probability that a robot will avoid injuries in an ordinary home.

Physical reliability depends on much more than a language benchmark. A relevant assessment would consider hidden obstacles, sensor faults, sudden changes in position, unusual lighting, software interruptions and the mechanical limits of the particular robot. It would also need to explain how fast a stop takes effect and whether an operator can override the system's rules. The same software may behave differently when installed on devices with different motors and sensors.

An independent test report would identify test hardware, operating environments, software versions, measured failures and restrictions on use. Until such evidence is available for a particular product integration, a buyer should treat broad safety claims as design goals supported by the company's own materials. That is not an accusation that the system fails; it is the ordinary difference between a vendor claim and a verified outcome.

Companion robots present different edge cases

A social or companion robot may be designed to communicate with people at close range. Unlike an isolated factory arm, it can share space with visitors, pets, household objects and people who have not agreed to use the device. Its designers must consider interruptions and ambiguous situations rather than rely on a scripted demonstration. An engaging human-like personality may increase the need for clear limitations because the interface can encourage unrealistic confidence.

An important design question is where conversational decisions stop and physical permissions begin. For example, an instruction to bring an object should not itself authorize the robot to move if the path is blocked. The machine needs a separate way to assess reachability and movement limits. The example is an illustration of general engineering requirements, not a published Inner Sky Labs field test.

Potential buyers should look for readily accessible emergency stops, documented speed limits, safe behavior after connectivity loss and understandable controls for camera or microphone activation. Those requirements apply whether a companion has a humanoid body, moves on wheels or remains stationary. They cannot be replaced by claims that an AI assistant feels natural or understands emotions.

The contribution of tactile and audio processing

Vision alone cannot describe every physical interaction. A robotic gripper may appear to hold an object while actually applying too much pressure or losing contact. A touch sensor may help identify these differences, provided that the software interprets it correctly. Inner Sky Labs describes Sparsh as its tactile component and includes touch information in its wider roadmap. That could be relevant to future companion robotics without showing that a particular consumer device already implements it.

Audio adds another source of ambiguity. A television or another person's voice may sound like an instruction, and background noise can hide a warning. If a robot can both listen and move, it should distinguish deliberate commands from surrounding conversation. The company describes Shruti for speech processing, but its existence alone cannot answer how well the system performs with every accent, acoustic environment or hardware microphone.

A strong evaluation would look at what happens when camera, touch and audio signals disagree. Does the machine pause? Is uncertainty reported? Can the owner review why an action was cancelled? Transparent behavior during uncertainty may be a more useful consumer feature than a carefully edited video showing a robot completing a simple task without interruption.

Cloud, on-device and offline deployment

The October 12 report says the platform can be supplied to qualified partners in several configurations, including cloud, on-premises and on-device arrangements. Inner Sky Labs' own website also emphasizes modular licensing. These options matter because a future companion product may need to maintain essential controls even when the internet is unavailable. A promise of offline support must nevertheless be checked against the features actually deployed on a device.

Local movement control can reduce dependence on network latency, while cloud computation may provide additional capabilities or updates. Neither arrangement is automatically secure. A locally executing program can contain vulnerabilities, while a networked system can be designed with strict access controls. The right questions concern where data goes, which decisions depend on connectivity and whether loss of a remote service leaves the machine in a stable state.

Buyers should separate three issues that marketing sometimes combines: where conversations are processed, where sensor information is stored, and which component finally authorizes physical movement. The answers can be different within the same product. Asking for a plain-language architecture description is more useful than accepting an undefined claim that the robot is either fully private or completely autonomous.

Privacy is not solved by physical safety software

Even a robot that never makes an unsafe movement could expose sensitive information. Companion systems may process audio, camera images, chat histories, preferences and user-generated memories. Those data flows require independent examination. The presence of a physical safety layer does not establish what is recorded, which vendors receive it or how long it remains available after the owner requests deletion.

An adequate privacy explanation should identify whether cameras and microphones can be disabled, whether on-device signals are retained, and whether extracted memories survive deletion of the conversation that created them. It should also describe how third-party AI providers are involved. Data protection matters for any connected consumer product, but it is especially sensitive when the product is designed for extended social interaction in a private setting.

The experience of Miko with children is relevant as company background, not as a privacy guarantee for every possible licensing partner. A consumer should review the policy attached to the specific hardware, application and model provider. For additional context, BizarreSexuality has separate guides on robot camera privacy, conversation deletion and offline versus cloud operation.

What this means for Realbotix, RealDoll and Lovense

Realbotix, RealDoll and Lovense appear in public conversations about humanoid robots, interactive companions and connected products, but they are distinct businesses with different offerings. The Inner Sky Labs announcement does not show that any of them has adopted Kavach, Drishti, Kriya or another part of this new stack. A news report that silently converted the announcement into a new feature of an unrelated product would mislead readers.

Realbotix maintains its own corporate news page and has recently discussed humanoid demonstrations and pilots. RealDoll has its own product and ordering information, while Lovense describes separate companion-device concepts. Those primary sources are the correct places to verify concrete product availability and policies. An advance in underlying robotics software may be relevant to the broader sector without changing what a customer can buy now.

For readers evaluating a specific brand, evidence should come from named integrations, product manuals, confirmed deliveries, live demonstrations with documented conditions and published support policies. A benchmark reported by a different company cannot substitute for testing the actual machine. This distinction also reduces the risk of presenting speculative partnerships as news.

Why manufacturer claims need independent measurement

Inner Sky Labs states that elements of its technology have been used in real products and other settings. Its website includes descriptions of work associated with social robots, education and industrial operations. These statements help explain the company's positioning, but the details of each claimed deployment may not be available for external review. The report should therefore attribute the deployment statements rather than treating them as audited industry statistics.

Independent verification would ideally cover both ordinary successes and abnormal cases. A test should show how often a machine rejects legitimate actions, misses an actual hazard, recovers after sensor loss and behaves following software updates. These measurements are necessary to compare safety claims meaningfully. A perfect score on a narrowly defined test cannot be generalized to all activities that a household companion might perform.

A publisher can be useful here without sensationalism. Instead of declaring one model the safest in the world, it can list the available evidence and identify what manufacturers have not published. Readers then understand the difference between a proposed architecture, a working component, a partner deployment and a consumer device independently tested under real-world conditions.

Commercial availability and the roadmap

The October 12 industry report describes availability to qualified partners by invitation. That is more specific than a vague research announcement, but it is not evidence that any consumer can purchase a robot containing the full technology stack today. The company website also describes model generations and future embodied-safety capabilities. The distinction between available modules and planned releases should remain visible as the platform develops.

A practical milestone would be a documented integration with named hardware, complete with the version of the safety module, its failure behavior and the testing standard used. Other useful milestones include independent benchmark documentation, long-term reliability data and clear information about support after deployment. The existence of funding or an impressive investment list does not answer these product-level questions.

Companion robotics companies may eventually benefit from modular perception and safety technology, but that remains a future possibility until particular agreements or devices are verified. Reporting such possibilities as questions rather than confirmed sales protects readers and gives the industry a more accurate record of its actual progress.

The most useful takeaway for buyers

Inner Sky Labs' October 12 announcement is important because it focuses attention on something conversational AI marketing frequently underplays: intelligent machines must do more than produce convincing language. A device that acts in the physical world needs separate perception, planning and controls over which actions it may execute. The company offers one architecture addressing those layers, but its claims require device-specific validation.

For companion robot owners, a realistic purchase checklist should cover emergency stops, motion limits, cameras and microphones, personal-data retention, model-provider access, offline behavior, independent testing and the availability of spare parts. None of these checks depends on being impressed by a robot's appearance. The safety and privacy documents should be understandable before a device is placed in a home.

BizarreSexuality will treat additional announcements as news only when there is a verifiable event: a published technical assessment, a confirmed partnership, a documented product release or a meaningful change in consumer protections. Until then, this development should be understood as a vendor-announced physical AI platform with unanswered questions about third-party evaluation and companion product integration.

Sources checked

• Inner Sky Labs — company architecture — Primary documentation and company-reported model descriptions
• Express Computer — 12 October 2026 — Dated industry reporting on the launch
• Realbotix — company news — Independent product context only; no Inner Sky Labs partnership is asserted

Further reading on BizarreSexuality

AI companion privacy · Camera and microphone privacy · Offline versus cloud · Humanoid robotics guide