My role and the limits of this account
I am Yihang Mao, a founder and founding shareholder of Auren Innovation Limited. There is an unresolved internal dispute concerning governance, development status and crowdfunding representations. Readers should consider that interest when assessing my account.
In my 2 September statement, I said that I did not control or approve the Indiegogo account, payment arrangements, current campaign representations, delivery commitments or privacy claims.
The five verification questions retain my original 2 September evidence boundary. I added my current concerns about staffing, demonstrations and delivery on 4 September. Those additions are my attributed account and assessment, not independently corroborated findings. Public website wording was checked separately; no new audit of September firmware, source code, samples or test data was completed for this update.
The disclosure concerns the project using the names AUREN, AURENPET, Auren Pet, Auren M1, Ouren, Ourenpet and Ouren M1. Engineering activity, component planning, design work and separate software demonstrations exist; these do not by themselves establish a validated integrated product.
Who actually owns engineering and delivery?
Based on my direct knowledge of current staffing and work allocation as of 4 September, the in-house technical team is small and the hardware program depends substantially on outsourced work. To my knowledge, no current internal team member has personally taken a comparable smart-hardware product through the complete path from initial development to integrated validation, pilot production and shipment. This is my first-hand account; it is not an independently audited personnel finding.
This needs a concrete answer: who is actually working on each critical subsystem, how much responsibility and availability they have, who resolves integration failures, and who signs off acceptance? A biography, advisor title or supplier relationship does not on its own answer those questions.
Outsourcing is not itself proof of failure. My concern is whether there is an experienced, accountable internal owner who can accept or reject supplier work and close cross-system failures. Earlier company materials attributed hardware experience to certain personnel or partners; those descriptions are relevant counter-evidence, but do not by themselves establish present responsibility or a comparable delivery record. I do not claim that no engineering activity exists or reduce every individual’s abilities to an unverified label.
A promotional film is not a product-performance test
In the promotional work known to me, AI-generated concept material and manually assembled edits illustrate the intended experience. I have not verified that those finished examples were automatically selected and produced by the M1 device-to-App system. Using AI to make a film is different from proving that the product can detect a pet event, select it and generate that result in ordinary use.
As of my 4 September account, I have not been shown a current, continuous real-device demonstration of that complete process or evidence of an independently evaluated integrated sample. A housing or wearing shot can illustrate appearance; it does not establish working electronics, firmware, connectivity or AI performance.
These observations do not establish that every public asset is artificial, that no sample exists anywhere, or why a demonstration has not been supplied. I cannot infer that the team is afraid to demonstrate the product or is deliberately concealing it. The practical gap is the missing verifiable demonstration and test record.
The creator-program page checked on 4 September says sample availability and creator terms remain under review. This is relevant context, but it does not rule out a private sample arrangement or later testing.
Read the creator-program page ↗Five questions that need evidence
01Does the complete product work together?
What I can reportAs of my statement, I had not received sufficient evidence of a repeatable chain from the wearable’s capture and connectivity through the App, AI memories, FindPet and functioning privacy controls. Separate demos or an enclosure do not establish that chain.
What would help verify itA current, continuous demonstration using an identified hardware and software build, with realistic use conditions, failures and test limits disclosed.
02Which promotional assets show a real device?
What I can reportThe production materials described in my statement document commissioned and planned AI-generated promotional work. I have not completed a match between every public asset and its source. I therefore do not claim that every public image or video is AI-generated.
What would help verify itAsset-by-asset labels distinguishing real prototype footage, renders, simulated interfaces and AI-generated elements; original device footage where operating performance is claimed.
03What supports manufacturing and delivery claims?
What I can reportWithin the materials available to me, I had not found a completed current set of integration, validation, certification, pilot-production and shipment evidence sufficient to verify delivery readiness. A planned date is not proof of readiness.
What would help verify itCurrent development stage, remaining validation and certification work, production dependencies, dated acceptance results and an explanation of how they support any delivery estimate.
04Are the advertised privacy controls implemented?
What I can reportPrivacy policies and architecture work exist. My concern is the gap between a documented policy and demonstrated behavior. I had not received enough implementation and end-to-end test evidence to verify the advertised controls. This is not an allegation of a demonstrated security exploit.
What would help verify itTests covering permission, capture indication, default sync, encryption, access control, retention and deletion across device, App and backend, with unimplemented controls explicitly labeled as planned.
05How reliable are the AI experiences?
What I can reportMy review did not establish representative product-level validation for highlight selection, emotion interpretation or personality claims. Technical definitions and isolated outputs are not accuracy measurements. This does not mean no algorithm development or data exists.
What would help verify itRepresentative real-device evaluation, a stated task definition, test conditions, error rates, confidence limits and a clear distinction between behavior interpretation and medical diagnosis.
What unresolved validation could mean for users
The following are potential consequences to evaluate, not measured defect rates or claims that shipped units have already failed. They are the tests I would want to see before relying on the advertised experience.
Performance stability
Why it mattersAn attractive demo does not establish reliable capture, sync and App behavior over repeated use. Unresolved interruptions could mean missing recordings or unavailable functions.
Evidence to ask forRepeated-use logs across devices and conditions, with interruption frequency, recovery behavior, battery use and thermal behavior disclosed.
Output consistency
Why it mattersOne selected result does not show how often processing succeeds, how long it takes or whether different pets and settings produce useful output.
Evidence to ask forA representative batch of successes and failures, processing completion and latency, and the amount of human intervention required.
Physical reliability
Why it mattersAn enclosure’s appearance cannot demonstrate durability, water resistance, charging reliability or safe long-term attachment and wear.
Evidence to ask forDated tests of the integrated configuration, pass/fail criteria, failures found and the changes made to address them.
Highlight capture
Why it mattersThe system could miss important moments or repeatedly select irrelevant footage; hand-picked clips do not measure this.
Evidence to ask forOriginal recordings, independently labeled target moments, missed-event and false-selection results, with no selective removal of failures.
Pet-event recognition
Why it mattersIncorrect event labels could mislead owners. An emotion or personality interpretation needs especially clear uncertainty and limits.
Evidence to ask forDefined event categories, representative examples and error analysis by condition, with confidence limits and unsupported interpretations excluded.
Enjoyable, faithful content
Why it mattersA polished manual edit does not establish that normal users receive engaging automated stories—or that generated content accurately reflects their pet’s recordings.
Evidence to ask forUncurated source-to-output examples, human editing disclosed, factual-error checks and clearly described owner evaluations rather than a promise that every output is compelling.
Data collected is not the same as product validation
My concern is not accurately expressed as “all pet data is zero.” Historical project records describe acquisition of public pet datasets. Those records do not establish a current, representative M1 evaluation set, and this update has not inventoried all data held by the team.
The unanswered question is whether there are appropriately sourced, labeled recordings matching the device and target tasks, covering different pets and settings, with a separate test set and reproducible acceptance results. Until that basis is shown, I cannot verify product-level accuracy or reliability from the materials available to me.
My assessment of delivery in 2026
On the information available to me, I do not consider delivery of the advertised scope and quality in 2026 to have a demonstrated engineering basis. My concern is serious: an enclosure, a limited demonstration or shipment of a reduced-function device would not establish delivery of the integrated AI experience being promoted.
This is my assessment, not proof that delivery is impossible. I cannot exclude later progress, narrower specifications, additional technical staff or a different manufacturing arrangement. Those changes should be evidenced and disclosed, not assumed. I do not claim an industry-wide requirement for 30–50 engineers or a fixed six-month minimum; no verified basis for that universal threshold is supplied here.
Backers and investors should ask for a dated, accountable plan that connects the actual working build to remaining integration, validation, certification and production work. Any reduced scope, dependency or uncertainty affecting the promised experience should be explicit. Current evidence that resolves these gaps would change my assessment.
Important qualifications already on the website
In the public product page checked on 4 September, Ourenpet describes the App presentation as product intent and acknowledges unfinished validation of battery, water resistance, connectivity and comfort. It also qualifies product imagery and disclaims guaranteed exact location and veterinary use.
Read the project’s product page ↗
These are meaningful disclosures. They must be considered fairly; the page is not wholly silent about development uncertainty. The remaining question is whether each claim and payment decision makes its evidence and limitations sufficiently clear.
Before paying
The early-bird page checked on 4 September advertises a 15 September launch. Its $1 payment is described as a non-refundable digital perk—not an M1 purchase, product deposit or credit against a future pledge. Qualifying future backing is required for the accessory benefit. These are the project’s terms, not my endorsement.
- Check the live campaign and current payment terms; do not rely on an old screenshot or a planned launch date.
- Ask which functions are demonstrated now, which are targets and which depend on later updates.
- Compare current test evidence with the claims most important to your decision. Crowdfunding entails development and delivery uncertainty.
Sources, limits and corrections
Public sources are linked below. The underlying internal contracts, chats, identity documents and technical records are not published here. Readers therefore cannot independently inspect all the basis of my account from this page alone.
- Creator program and sample availability ↗Public wording checked 4 Sep 2026; not proof that no private samples exist.
- Ouren M1 product page ↗Public wording checked 4 Sep 2026; the page may change.
- Early Bird Perk terms ↗Public wording checked 4 Sep 2026; verify terms before paying.
- Project privacy policy ↗Policy wording is not independent proof of implementation.
- Indiegogo project listing ↗Link to the project, not a platform endorsement of this statement. Live campaign status is not certified by this page.
- My original founder disclosure ↗Author’s statement, 2 Sep 2026. Not an independent corroborating source; external access restrictions may apply.
If current, verifiable evidence resolves a concern, I will update or correct this account. Any response reproduced here should be dated and linked to its source. No platform investigation, legal finding or independent technical verdict is asserted by this page.
Please evaluate the evidence. Do not harass individuals, impersonate customers, submit false reports or organize mass complaints.