Define acceptance before KOKO arrives
Acceptance is a decision that the delivered product or service meets the agreed requirements. A box arriving or an account opening may be only one part of that decision. Homebot One's public overview did not specify a standard retail acceptance procedure when reviewed on October 2, 2026. Write the plan around the current offer, documentation, and agreement, including the meaning of any signature or payment.
The Federal Acquisition Regulation defines acceptance for government contracts in terms of conformance to applicable contract quality and quantity requirements. Household and private business agreements follow their own terms, so FAR is not the rule for every KOKO arrangement. Its useful planning lesson is to identify requirements, inspection authority, evidence, timing, and written acknowledgment before delivery rather than deciding them after a disagreement.
- Person authorized to test and person authorized to accept
- Configuration, quantity, services, and documents being accepted
- Test location, period, dependencies, and allowed assistance
- Deadline and process for reporting a nonconformance
Freeze a configuration and requirements baseline
Record the identifiers available for hardware, software, accessories, accounts, services, documentation, and support. If a serial number, build number, or version is not available, use another dated description supplied by the parties. State which items are required at delivery and which may follow later. A test result has limited value when nobody can identify the configuration that produced it.
Turn important needs into observable requirements. Replace useful around the home with a defined routine, starting condition, outcome, time boundary, permitted intervention, and recovery behavior. Replace secure or private with the specific control or documentation expected. Mark every requirement as mandatory, conditional, informational, or deferred. A roadmap statement should not become an acceptance criterion unless the written agreement makes it a deliverable.
- Unique configuration and version record
- Requirement identifier and source in the written agreement
- Observable pass condition and evidence to retain
- Priority and consequence of failure
- Owner and status for any deferred deliverable
Test normal use, boundaries, and recovery
Begin with the ordinary workflow exactly as documented, then repeat it under the agreed range of realistic conditions. For a physical home robot, boundaries may involve room layout, surface transition, lighting, network interruption, obstacle placement, user position, or an incomplete request, but only test conditions that are safe and within current instructions. Record each attempt, outcome, duration, intervention, and unexpected behavior instead of relying on memory.
Recovery is part of acceptance when the agreement requires it. Check what happens after a pause, failed step, disconnected service, moved object, low-resource state, or user stop request when those scenarios are within scope. Verify that the household or operator can reach the documented stop, reset, help, or support path. Do not invent emergency behaviors or deliberately create unsafe conditions to discover how the system reacts.
- Normal workflow with agreed starting conditions
- Repeated attempts sufficient to reveal variation
- Safe boundary conditions named in the plan
- Pause, stop, error message, recovery, and support path
- Human assistance recorded rather than hidden
Include controls, documentation, and support
Acceptance should cover more than visible movement. Verify accounts, roles, configuration controls, notice and consent workflow, data controls, update settings, documentation, training, and support contacts when the agreement includes them. NIST's AI RMF Playbook recommends documenting measurement methods and test details. Apply that recordkeeping habit to your evaluation; it supplies a method, not evidence that KOKO implements a particular control.
Ask the person who will operate or support the system to complete key steps using the supplied material. A control that only the demonstration team can find may not satisfy a usability requirement. Check that version-specific instructions match the delivered configuration and that escalation details work. If a required feature depends on a connected service, identify the expected behavior when that dependency is unavailable.
- Account creation, roles, authentication, and recovery
- Privacy notice, pause, review, export, and deletion controls in scope
- Update, status, logging, and support information in scope
- Training and documentation completed by the intended operator
Classify defects, retest, and sign one result
For every failed requirement, record the evidence, severity, owner, proposed remedy, and deadline. Possible dispositions include correct and retest, accept with a documented condition, reduce scope with an agreed adjustment, defer under a signed plan, or reject under the applicable terms. The agreement should identify who may approve each outcome and whether acceptance triggers payment, a support period, ownership transfer, or another milestone.
The price is right when the delivered scope passes the agreed checks and the confirmed cost reflects what you accept. Sign a dated report naming the configuration, passed and failed requirements, open actions, attachments, and final decision. If a condition remains unresolved, show its owner and deadline in the report. Keep that result with the quote and invoice so acceptance can be distinguished from later corrections or upgrades.
- Pass, fail, conditional, deferred, or not tested for every requirement
- Evidence and retest result linked to each issue
- Agreed consequence for unresolved nonconformance
- Dated approval by the authorized person
Frequently asked questions
Does Homebot One publish a standard KOKO acceptance test?
The official pages reviewed on October 2, 2026 did not publish a standard retail acceptance test. Build acceptance criteria from the current configuration, documentation, and written agreement with Homebot One.
Is delivery the same as accepting KOKO?
That depends on the applicable agreement. Plan separately for receipt, inspection, testing, issue reporting, correction, and authorized acceptance so that a signature or payment does not have an unintended meaning.
How many times should an acceptance routine be tested?
Choose repetition based on the importance of the requirement, expected variation, time available, and written plan. Record every attempt and avoid claiming broad reliability from one successful run.
Can I use a Coco robot test plan for KOKO?
Do not assume so. KOKO is Homebot One's official product name, and a Coco or Co Co result may concern another product or configuration. Match every test to the identified system and agreement.
Sources & further reading
From Homebot One, the team building KOKO in Fremont, California.
