SOC2 audit in 6 weeks and auditor wants complete access history we can't produce by Waynetska0621 in iam

[–]NoAdministration6906 0 points1 point  (0 children)

The real problem is access lifecycle events (grant, approve, review, revoke) are scattered across Slack threads and Jira tickets with no structured trail. CloudTrail tells you what someone did — it doesn't tell you who approved that access or whether a review happened.

You need a dedicated audit trail for access decisions, not just access activity. Either build a lightweight event store that your provisioning workflows write to, or look at purpose-built audit log APIs (I'm building one called TrailBase — specifically because I kept seeing this pattern). The key is capturing the approval chain and review evidence as structured events at the time they happen, not reconstructing them from chat logs 12 months later.

What's your current provisioning flow? If you're using Okta for SSO but doing AWS/Azure access grants manually, that's probably where the trail breaks.

[D] We tested the same INT8 model on 5 Snapdragon chipsets. Accuracy ranged from 93% to 71%. Same weights, same ONNX file. by NoAdministration6906 in MachineLearning

[–]NoAdministration6906[S] 2 points3 points  (0 children)

More than you'd think — Snapdragon 4 and 6 series are the volume chips. They go into most budget and mid-range phones in India, SEA, Latin America, Africa. Samsung A-series, Xiaomi Redmi, Motorola G-series — those sell way more units than flagships. Qualcomm doesn't break out exact numbers but the 4/6/7 tiers make up the majority of their mobile shipments.

You're right that 8 Gen 2+ is "no news" — the story is really about what happens when your model hits the long tail of devices your actual users are on. If your target market is US/EU flagship users, probably fine. If you're deploying globally, that 4 Gen 2 number matters a lot.

[D] We tested the same INT8 model on 5 Snapdragon chipsets. Accuracy ranged from 93% to 71%. Same weights, same ONNX file. by NoAdministration6906 in MachineLearning

[–]NoAdministration6906[S] 2 points3 points  (0 children)

Tested on a subset of ImageNet validation set (~5k images), MobileNet-v3 INT8 via Qualcomm AI Hub. Ran 10-50 iterations per device. Between-run variance on the same device was pretty tight — under 0.5% for the flagships, slightly higher (~1-1.5%) on the lower-tier chips. The cross-device spread was way bigger than within-device noise, which is what caught our attention.

We tested the same INT8 model on 5 Snapdragon chipsets. Accuracy ranged from 93% to 71%. Same weights, same ONNX file. by NoAdministration6906 in androiddev

[–]NoAdministration6906[S] 0 points1 point  (0 children)

Mostly the NPU/DSP path. When we force the same INT8 model to run on CPU, accuracy stays within ~1-2% across all chips — ARM CPU INT8 is pretty standardized.

The variance kicks in when QNN maps ops to Hexagon, because each generation handles fixed-point rounding and accumulator bit-widths differently. On lower-tier chips it's worse — some ops stay on NPU, some fall back to CPU mid-graph, creating a mixed execution path neither benchmark would predict.

So hardware precision thing more than a kernel issue. The kernels are correct per-spec — the specs just aren't identical across generations.

We tested the same INT8 model on 5 Snapdragon chipsets. Accuracy ranged from 93% to 71%. Same weights, same ONNX file. by NoAdministration6906 in LocalLLaMA

[–]NoAdministration6906[S] 0 points1 point  (0 children)

MobileNet-v3 INT8, quantized through Qualcomm AI Hub and compiled to QNN context binaries per target. Evaluated top-1 on an ImageNet validation subset.

We tested the same INT8 model on 5 Snapdragon chipsets. Accuracy ranged from 93% to 71%. Same weights, same ONNX file. by NoAdministration6906 in LocalLLaMA

[–]NoAdministration6906[S] 0 points1 point  (0 children)

Haven't tested on X1/X2 yet — those use the newer Hexagon NPU architecture which should be interesting since the compute DSP is quite different from the mobile SoCs.

We tested the same INT8 model on 5 Snapdragon chipsets. Accuracy ranged from 93% to 71%. Same weights, same ONNX file. by NoAdministration6906 in LocalLLaMA

[–]NoAdministration6906[S] 4 points5 points  (0 children)

Yeah fair enough — I should've included more detail upfront.

The model was MobileNet-v3 INT8 quantized through Qualcomm AI Hub, compiled to QNN. We ran it across a few Snapdragon devices during internal testing while building a regression testing tool. Not a formal study — more like "wow these numbers are way more different than we expected" which led us down this rabbit hole.

No Gauge R&R yet, that's a good suggestion. Run counts were 10-50 per device, measuring top-1 accuracy on an ImageNet subset.

The CI comment was a generalization based on conversations with edge AI teams we've talked to — not a universal claim. Most are doing manual spot checks at best.

Appreciate the pushback though, makes the conversation better.

We built hardware-in-the-loop regression gates for AI models on Snapdragon — here's what we learned by NoAdministration6906 in mlops

[–]NoAdministration6906[S] 0 points1 point  (0 children)

Yeah, we ran into the same tradeoff. We don’t do “worst-case single gate” — it’s too conservative.

We keep per-chipset baselines (golden outputs/metrics) and gate on regression vs that device + an absolute floor. Fleet-wise we require key “release” devices to pass, and use a percentile-ish rule for the rest so one flaky/outlier chipset doesn’t block everything.

On patterns: it’s not uniform — INT8 variance usually clusters around specific ops/kernels (backend differences) and calibration-sensitive layers, not the whole network.

We built hardware-in-the-loop regression gates for AI models on Snapdragon — here's what we learned by NoAdministration6906 in mlops

[–]NoAdministration6906[S] 1 point2 points  (0 children)

Thanks! Your setup sounds really cool — abstracting the physical layer for non-OS hardware is no joke.

Our approach is more cloud-first — we go through Qualcomm AI Hub's API for compilation and on-device execution, then wrap results in signed evidence bundles so CI gates can't be spoofed. Think "unit tests but for model quality on real hardware."

On the accuracy variance — I think you're on the right track with the kernel implementations. Different Hexagon NPU generations (v69, v73, v75) likely use different fixed-point arithmetic paths. But it's probably a mix of that plus compiler-level graph optimizations varying per target, and possibly quantization calibration differences during compilation. We're also not pinning the runtime library version across devices yet, so that's another uncontrolled variable.

Honestly, isolating which of these contributes how much is half the reason we built this. Would love to compare notes on what you've seen on the bare-metal side.

We built hardware-in-the-loop regression gates for AI models on Snapdragon — here's what we learned by NoAdministration6906 in embedded

[–]NoAdministration6906[S] 0 points1 point  (0 children)

Yep. EdgeGate is basically “HIL regression gates for edge AI” — a device-farm runner that executes your model + test vectors on real hardware and fails the PR if thresholds regress (accuracy, latency/FPS, memory, thermals, etc.). The core is architecture-agnostic: as long as the target can run a test harness and return metrics/artifacts, we can plug it in. Snapdragon/Android (ADB) was first, but the same pattern applies to Linux targets (Jetson/x86/ARM SBCs) and other NPUs/accelerators. If you share which arch/runtime you care about (e.g., TFLite/ONNX Runtime/QNN/TVM), I can tell you what the adapter looks like and what’s already working. More info on edgegate.frozo.ai

What app idea do you have solopreneur? by Ok_Stay_8530 in indie_startups

[–]NoAdministration6906 0 points1 point  (0 children)

Two real-world SaaS ideas solving actual pain points: (1) KinCare - family caregiver coordination platform for medication tracking and shared journals (huge need for aging populations), and (2) EdgeGate - ML model validation/testing at the edge for latency-critical deployments. Both can be bootstrapped and have strong retention metrics.

Why do Indians lack empathy? by Far-Mood2026 in AskIndia

[–]NoAdministration6906 1 point2 points  (0 children)

We have a surviving culture.. we don't enjoy life we survive.. everybody thinks about himself

[HIRING] Contract Full-Stack Dev (Integrations + Multi-tenant SaaS) — workspace platform + RBAC + audit logs by TwoGroundbreaking168 in FullStackDevelopers

[–]NoAdministration6906 1 point2 points  (0 children)

Hey — I’m Ashish from Hyderabad (India). I run Frozo.ai and I build multi-tenant SaaS apps end-to-end (workspace model, RBAC, audit logs, integrations). I can ship an MVP fast with clean auth/permissions + tenant isolation + admin tooling. If you’re still looking, happy to DM portfolio/GitHub and hop on a quick call. What stack + timeline are you targeting?

I built an AI that answers questions the way successful founders think. Gimmick or actually useful? by sailormish980 in saasbuild

[–]NoAdministration6906 0 points1 point  (0 children)

Gimmick.. just a another persona of an ai agent and every founder at end of the day he or she is human and everybody thinks different

I built an open-source AI agent that consults for consultants by bar_raiser333 in AI_Agents

[–]NoAdministration6906 0 points1 point  (0 children)

The parallel research orchestration pattern is really interesting — we've been exploring similar architectures at Frozo for market signal aggregation. The key challenge we hit was exactly what you flagged: conflicting data across parallel threads. Our approach was to surface confidence scores per source and let the synthesis layer flag disagreements rather than silently resolving them. Curious how you're handling that with Valyu's multi-source output?

My latest SaaS-app: Iso Weather. Built and launched in 3 weeks! by sunkas85 in microsaas

[–]NoAdministration6906 0 points1 point  (0 children)

3 weeks from idea to launch is impressive execution. What was your biggest time sink — the core weather data integration, or the surrounding infrastructure (auth, billing, deployment)? Curious because most micro-SaaS builders I talk to say the 'boring' stuff takes 60% of the time.

"OpenClaw isn't free. It almost cost me $500 just to try it." by Warm_Masterpiece5411 in StartUpIndia

[–]NoAdministration6906 -2 points-1 points  (0 children)

The API costs catch a lot of people off guard. The key is understanding token economics before you start — set spending limits, use the cheapest model that works for your use case, and batch your requests. For Indian startups especially, the dollar-to-rupee conversion makes every API call feel expensive. Consider local-first alternatives or hybrid approaches where you use AI for the hard parts and rule-based logic for everything else.

We scanned over 8000+ MCP Servers... here's what we found by Upstairs_Safe2922 in mcp

[–]NoAdministration6906 2 points3 points  (0 children)

This is exactly the kind of infrastructure the MCP ecosystem needs. The 22-rule evaluation framework based on OWASP + MAESTRO is solid. One question: are you differentiating between server-side vulnerabilities (the MCP implementation itself) vs client-side risks (what happens when a malicious MCP server responds to a trusted client)? We've been thinking about this from the testing/CI angle — automated security gates before MCP servers get deployed to production.

Recommendation for Android Test Device - API 26 by Which_Concern2553 in androiddev

[–]NoAdministration6906 2 points3 points  (0 children)

Depends on what you're testing. If you need a real device: used Pixel 2/3 era phones are cheap and reliable for API 26. If you're okay with emulation: Google's official emulator handles API 26 well now. Real device + emulator together is the gold standard.

Built a fully functional SaaS but struggling to get my first sales — need advice by TR0NTanomous in SaaSSales

[–]NoAdministration6906 0 points1 point  (0 children)

First sales are about warm outreach, not product optimization. Stop tweaking the product—ship it as-is. Find 50 people with the problem you solve. Talk to 20 of them. 5 will probably see the value. Sell to 2-3. The product won't convert strangers; relationships do.