Request and oversight
User or authorized operator
Provides intent, context, approval, and human intervention.
Interaction governance for Sentient V
AIMQWEST Harness
A software-first interaction validation and governance layer proposed for Sentient V. It is designed to sit above—and never replace—the robot's native mobility, perception, manipulation, and safety-control systems.
Seven Directives Human escalation Persistent audit
System boundary
Govern interaction. Preserve native robot authority.
The Harness is a supervisory governance layer. Sentient V's native platform remains responsible for physical intelligence and every low-level safety-critical function.
Software-first governance layer
AIMQWEST Harness
Validates, classifies, explains, logs, remembers, and escalates.
Native execution boundary
Sentient V native systems
Retain perception, mobility, manipulation, collision avoidance, balance, firmware, and physical safety control.
What the Harness is intended to do
Use approved platform interfaces to evaluate high-level interactions, apply policy, request human confirmation, preserve evidence, and support reviewable escalation.
What it will not do
It will not become the robot brain, issue raw motor commands, replace balance or collision avoidance, bypass an emergency stop, or place a language model in direct control of physical safety.
OpenAI models may support intent analysis, policy reasoning, explanations, memory summaries, and audit support. Model output remains subordinate to approved policy, human oversight, and Sentient V's native safety controls.
Core capabilities
A governance layer built for transparent, reviewable behavior
The initial Harness focuses on the interaction boundary where software policy, human judgment, and platform events can be evaluated without altering low-level robotics.
Interaction validation
Classify proposed interactions by risk, validate them against approved policy, and slow or stop a workflow when uncertainty rises.
Seven Directives
Apply AIMQWEST's human-life, dignity, and safety priorities as an explicit governance boundary for every evaluated interaction.
First Quadrant behavior
Support transparent behavior about capabilities, uncertainty, limits, oversight, and the need to escalate to a human.
Persistent accountability
Create reviewable event, decision, escalation, and policy records with controlled retention and auditable change history.
Progressive integration
Begin with observation, then add authority only when proven safe
Each mode depends on documented interfaces, controlled testing, and explicit approval. Observer mode is the preferred starting point.
Observer mode
Receive approved events and telemetry, classify interactions, and produce governance records without changing robot behavior.
Advisory gate
Return allow, clarify, warn, block, or escalate recommendations while the native system or a human retains execution authority.
Controlled action gate
Use only explicitly approved high-level hooks such as pause, cancel, resume, or human confirmation within the native safety envelope.
Minimum interface requirements
The technical access needed to validate a software-first Harness
These are proposed evaluation requirements—not claims about currently available Sentient V interfaces. Final access depends on technical review, security controls, and written approval.
Robot identity and configuration
Unit identifier, software version, enabled capabilities, configuration, and deployment profile.
Interaction stream
Transcripts, commands, intent events, confidence, timestamps, and session identifiers where approved.
State telemetry
Operating mode, battery, connectivity, location context, task status, faults, and safety state.
Action and task events
High-level proposed action, target, parameters, risk flags, status, and completion result.
Human control hooks
Approved pause, cancel, resume, confirm, escalate, and emergency-stop relay boundaries.
Safety event access
Collision, fall, overload, restricted-area, emergency-stop, and other native safety events.
Audit and log export
Timestamped interaction, action, fault, safety, operator, and configuration records.
Safe test environment
Simulator, sandbox, recorded-data replay, or controlled lab mode for integration validation.
Secure by design
Credentials belong in secure environment or vault controls, never source code. Sensitive data should be minimized, encrypted, access-controlled, and retained only under an approved policy; raw audio or video is not a default requirement.
Risk handling model
Risk slows execution and increases human oversight
The proposed taxonomy turns interaction risk into explicit behavior. Thresholds remain configurable for each approved environment and use case.
| Risk class | Examples | Harness response |
|---|---|---|
| Routine | Greetings, directions, classroom questions, reminders, or guided tours. | Allow or log only, depending on the approved test mode. |
| Sensitive | Medication discussion, private information, emotional distress, or household access. | Slow down, clarify, warn, log, and require human confirmation when appropriate. |
| Restricted | Physical support, financial decisions, medical advice, minors, or restricted areas. | Escalate to a human; do not execute without explicit approval. |
| Emergency | A fall, injury, distress call, fire, security issue, or immediate hazard. | Notify the designated human, preserve the audit trail, and never impersonate emergency services. |
| Blocked | Unsafe, deceptive, coercive, privacy-invasive, harmful, or unauthorized requests. | Refuse or block, explain safely, and log the incident for review. |
The Harness must remain transparent about uncertainty and limits. It must not imply medical, legal, financial, emergency-response, or supervisory authority that it does not possess.
Persistent memory and audit
Remember useful context without turning privacy into a casualty
Each evaluated Sentient V unit can be treated as a governed operational asset with a policy profile, deployment history, and reviewable learning record.
Versioned policy
Approved policies, scenario rules, escalation contacts, and deployment profiles—without secrets or sensitive records.
Encrypted event store
Access-controlled interaction, task, escalation, error, and safety events with a defined retention policy.
Privacy-bounded memory
Non-sensitive preferences and recurring context summaries, excluding protected data unless explicitly governed.
Immutable audit
A reviewable record of what changed, why it changed, who approved it, and when it happened.
Proposed evaluation plan
Five gates from interface review to a disciplined pilot decision
Progress depends on evidence at each phase. A successful desk review does not authorize a physical demonstration, and a demonstration does not guarantee a commercial pilot.
- 0
Interface review
Confirm feasible SDK, API, telemetry, logging, sandbox, cybersecurity, and control boundaries.
- 1
Desk validation
Map approved interfaces to Harness inputs and outputs; define schemas, scenarios, adapters, and escalation workflows.
- 2
Bench or lab test
Run observer and advisory modes in controlled conditions across all five risk classes.
- 3
Controlled stakeholder demo
Demonstrate supervised education, elderly-care, retirement-community, household-assistance, and service scenarios.
- 4
Pilot recommendation
Document findings and decide whether to deepen integration, add hardware-level governance, proceed to a pilot, or stop.