Start with one capability that can be demonstrated and dated
A capability claim is most useful when it names the KOKO version, the task, the setting, the date, and the amount of human help involved. Homebot One describes KOKO as a project moving through development and in-home testing. That context means a public concept, a laboratory result, a prepared demonstration, and a generally available household function should not be treated as the same kind of evidence.
Begin with a direct question: what can this KOKO version do today under the conditions that matter to me? Have the team separate that answer from work being evaluated and from longer-term ideas. A roadmap can explain direction, but it is not a delivery promise unless Homebot One provides specific, current terms to that effect.
Use three evidence labels instead of one feature list
A simple three-column record can prevent an exciting presentation from becoming an accidental promise. Label an item demonstrated when you have seen the current system perform a defined task and the conditions are documented. Label it under evaluation when the team is testing an approach but has not described it as a stable offering. Label it future question when it appears in a vision, discussion, or requested use case without current evidence.
The labels should travel with the details. A result in one mapped room may not answer how the same task works after furniture moves, in another home, or without a staff member present. Record who started the task, what preparation occurred, how often it succeeded, what happened when it could not continue, and which part of the process remained manual.
- Demonstrated today: identify the build, environment, task boundary, supervision, and observed result.
- Under evaluation: identify the open test question and what evidence would move it forward.
- Future question: record the desired outcome without assigning a date or promised implementation.
- Unknown: ask the team rather than completing the claim from a headline, video, or search snippet.
Read demos as bounded evidence
A demonstration can answer a focused question well. It can show how a particular KOKO build responds to a request, moves through a prepared area, presents a control, or recovers from a planned interruption. It cannot by itself establish performance across every room, household, user, network condition, or unexpected event. Ask for the conditions that made the demonstration representative of your intended use.
Request at least one ordinary variation rather than only the prepared path. For example, change the starting position, interrupt the sequence, ask for a pause, or introduce a harmless layout difference approved by the operator. The goal is to understand boundaries and recovery, not to force a failure. Keep any safety-critical or high-consequence scenario outside the evaluation unless Homebot One provides an appropriate, documented process.
Treat dates, software versions, and dependencies as part of the claim
Development systems change. A capability shown in an earlier build may improve, move behind a different workflow, depend on a service, or no longer match the current program. Note the demonstration date and ask whether hardware, software, accounts, connectivity, maps, accessories, or staff preparation were required. Avoid assuming that an observed result transfers to another KOKO version or access program.
Ask how updates are communicated and whether a written summary is available after the session. If the answer depends on a third-party service or compatible device, verify that dependency separately. A clear dependency list makes comparison possible and helps prevent a roadmap item from being mistaken for a self-contained capability.
- Which KOKO build and software version produced the result?
- Which accounts, network services, maps, accessories, or staff actions were required?
- Is the behavior part of the current evaluation program, a limited prototype, or a stated future direction?
- What changed since the source, video, or article was published?
Create a decision record that keeps uncertainty visible
After a demo or conversation, write a short decision record with four parts: what you observed, what Homebot One stated, what remains unknown, and what you would need to verify next. Link each important statement to its source and date. This format is useful for a household, a research team, or a developer because it prevents assumptions from blending into the evidence over time.
Revisit the record before making a purchase, pilot, or integration decision. Confirm current availability, pricing, support, privacy terms, and the exact scope being offered. The practical question is not whether every roadmap idea sounds useful; it is whether the documented current program addresses your defined need with acceptable limits and a clear human fallback.
Frequently asked questions
Does a KOKO roadmap describe features available today?
Not by itself. A roadmap describes direction or planned work. Have the Homebot One team identify what the demonstrated version can do, under which conditions, and whether those functions are included in the access program being discussed.
Is a successful demo proof that KOKO will work the same way in my home?
A demo is evidence for the build, task, and conditions observed. It does not establish performance in every home. Compare the demo environment with your rooms, users, network, routines, and supervision plan.
How should I verify a KOKO capability mentioned in an article or video?
Check the publisher and date, identify whether the item is a concept or observed behavior, and ask Homebot One for current confirmation tied to a specific KOKO version and use case.
What should I record during a KOKO evaluation?
Record the build and date, the exact task, preparation and dependencies, human assistance, observed outcome, failure recovery, and unanswered questions.
Sources & further reading
From Homebot One, the team building KOKO in Fremont, California.
