TRUST / SECURITY
Trust, Data, and Security at Bontoys
The Xiaoran voice module is designed offline-first. This page records the current trust posture at R&D stage: what data categories can exist, the design posture for each, the retention policy targets set ahead of launch tooling, how to report a security issue, and how the security-support window will be published.
This page describes design postures and policy targets at R&D stage. It is not a certification statement, a completed audit, or legal advice. The measured behavior of any shipped product is documented per integration.
- Published
- Last reviewed
DATA / 01
Data dictionary
Four data categories can exist around a voice module. Each entry records what the category is and the design posture that governs it. Postures are design intents, verified per integration — they are not blanket guarantees about every configuration.
| Data category | What it is | Design posture |
|---|---|---|
| Raw audio | Sound captured by the module's microphone array while a voice interaction is active. | Offline-first design — the persistent retention target for raw audio is zero. Any connected path is mapped in the data-flow checklist per integration before a pilot starts. |
| Transcripts | Text or intent data derived from voice input on a bounded offline path or an optional connected path. | Designed to stay within the bounded response scope of each scenario. Where an integration adds a connected path, every transcript recipient is mapped per integration in the data-flow checklist. |
| Event logs | Operational records such as trigger counts, error states, battery events, and update status. | Engineered to record operational metadata rather than conversation content. Retention follows the policy targets below. |
| Form submissions | Information brands and factories submit through the application form, including attachments. | Used to evaluate collaboration fit and prepare an R&D pilot conversation. Retention follows the policy targets below. |
RETENTION / 02
Retention targets
Retention periods for the records Bontoys itself operates. These are the policy targets the launch tooling is being built against.
| Record | Retention target |
|---|---|
| Application body (applications that do not proceed) | 12 months |
| Application attachments | 90 days after evaluation ends |
| Administrator access logs | 180 days |
Policy targets — enforced tooling is part of the launch runbook.
REPORTING / 03
Security & vulnerability reporting
Reports about the module, the site, or the application flow are welcome. Response times below are operating targets, published so reporters know what to expect.
- Report to
- security@bontoys.online
- Acknowledgement target
- Within 2 business days
- Status-update target
- Every 30 days until the report is resolved
- Machine-readable record
- /.well-known/security.txt
SUPPORT / 04
Support window
We intend to publish an explicit security-support end date per module SKU before first production shipment.
SCOPE AND EVIDENCE
Posture is a starting point, not proof.
The complete toy, its operator, its target markets, and its actual configuration determine the real data flow. Use the checklists below to map a specific integration, and the public R&D record to see what has been demonstrated so far.
Bontoys by Benran is the international R&D-stage brand of Benran Zhiqu. Current public materials do not claim mass production, certification, named customers, sales, or commercial availability.