Case Studies

The claim

Wichargless advertises 200 mW of continuous DC power at both 2 and 3 meters. It submits a lower-power 4 W EIRP configuration for FCC testing rather than the transmit power needed to deliver that output.

Evidence basis

The case specification is a 915 MHz, free-space, far-field link with 0 dBi receiving-antenna gain, 50% RF-to-DC conversion, and a qualifying Part 15.247 transmission mode. The link budget gives 0.340 mW DC at 2 meters and 0.151 mW at 3 meters.

Finding

The claimed output is 588 times above the modeled result at 2 meters and 1,324 times above it at 3 meters. Reaching 200 mW with the same receiver would require approximately 2.35 kW and 5.30 kW EIRP, respectively. Approval of the submitted lower-power configuration does not validate that advertised performance.

What it means for the investor

The core performance promise fails under the stated specifications. The mismatch is sufficient for a no-go decision; another round of testing is not needed to reach that conclusion.

This conclusion is specific to the stated configuration. Approximately 4 W is not a universal FCC ceiling; other regulatory routes and architectures are different cases.

Technical references: NTIA Spectrum Management Technical Handbook · 47 CFR 15.247 · 47 CFR 18.305

The investment claim

The platform is presented as an in-house fraud-analysis engine whose proprietary agents make decisions with minimal human input. The case's agreed acceptance gates require human adjudication on no more than 5% of test cases and automatic clearance of no more than 2% of known fraud cases. The valuation premise includes ownership of the core model technology.

What the implementation actually contains

Sample modules and configuration select off-the-shelf Anthropic Claude, OpenAI, and xAI Grok models. Executed request traces show transaction features sent to those providers for analysis. This conclusion comes from endpoints, model selections, and runtime calls, not SDK imports alone: the OpenAI SDK can also call xAI's endpoint.

The in-house code provides routing, prompts, business rules, and evidence aggregation. That software may be valuable proprietary work. It does not make the provider-trained models an in-house asset. The product audit log also omits prompt revisions and provider response identifiers, weakening decision traceability.

What the patent material establishes

The supplied claims recite case routing and aggregation; the description permits external model services. Those materials describe claimed subject matter, not proof of the deployed implementation, ownership of provider models, or fraud-detection performance. The runtime traces establish the implementation dependency. This is not a patent-validity or infringement finding.

The autonomy claim fails its acceptance gates

The controlled suite contains 200 labeled cases: 100 fraudulent and 100 legitimate. Eighty require human adjudication, a 40% review rate versus the 5% limit. Ten of the 100 known fraud cases are automatically cleared, a 10% escape rate versus the 2% limit. Deferred cases are counted separately, not credited as autonomous successes. These are results for this workflow and suite, not production-wide estimates or provider benchmarks.

What it means for the investor

Reject the investment case as presented. It overstates in-house ownership of the model layer and fails the agreed low-touch operating gates. External APIs alone are not the reason for the no-go, and they do not establish why the errors occurred. The decisive issues are the unsupported ownership premise and demonstrated acceptance-test failures. Any value in the orchestration layer must be assessed on that narrower basis.

Reference sources for API interfaces and patent-claim principles: OpenAI Python API library · Anthropic Python SDK · Grok API quickstart · USPTO Applying for Patents · USPTO Managing a patent

The investment claim

The near-term operating plan requires 80 requests/second for a specified workload. A later expansion proposes 400. The diligence question is whether the platform supports the current investment case, and which growth assumptions should remain outside the base case.

What the bounded checks support

Functional checks of selected critical workflows and targeted authentication and authorization tests pass. These samples support the immediate use case; they are not full-product acceptance or a comprehensive security audit. Untested functionality, security controls, and production variability remain outside the conclusion.

What the load replay shows

A fixed, production-shaped request mix is replayed against staging hardware and database configuration matched to the intended deployment. Dataset, tenant distribution, and request mix remain constant. Each load step has a 10-minute warm-up followed by a 45-minute measurement window. At 150 requests/second, p95 response latency stays below 300 milliseconds and errors below 0.5%, meeting both acceptance thresholds. The error rate counts failed requests and timeouts across all attempted requests.

Where performance degrades

At 250 requests/second, p95 latency reaches approximately 800 milliseconds and errors reach 1.8%. Traces show database connection-pool waits alongside slow reporting queries. Their concurrence identifies a bottleneck hypothesis, not an isolated cause. The 400-request/second expansion target has not been validated.

What it means for the investor

Proceed with the current use case. Set an initial rollout budget of 100 requests/second, one-third below the demonstrated passing level, and monitor latency and errors against the tested thresholds. Treat this as an operating guardrail, not a production capacity guarantee. Keep expansion funding separate: release it against a tuned design sustaining 400 requests/second under representative conditions and the same acceptance thresholds. This gate applies to the expansion, not the current investment. Application autoscaling alone is not assumed to resolve database contention.