[ reference · methodology ]
How this implementation library makes claims
This library is a practical synthesis, not a benchmark, certification, security assessment, legal opinion, or claim that one architecture is universally superior.
We compare deployment options by the actual workload and the conditions around it: data flow, quality threshold, fleet, network, lifecycle, cost model, governance, and failure behavior. A deployment label—local, cloud, or hybrid—does not supply these facts.
We use primary framework and platform documentation for general concepts and implementation paths. Platform documentation demonstrates supported capabilities; it does not prove a particular product’s privacy, security, speed, cost, or suitability. Those require system-specific evidence.
Where a decision depends on performance, measure representative workloads on the intended device and network population. Record methodology, model/runtime versions, sample limits, percentiles rather than only averages, quality failures, energy or thermal effects where relevant, and changes over time.
Terms this library avoids unless evidence is supplied
“Private,” “secure,” “sovereign,” “offline,” “low-latency,” and “cost-effective” are conditional claims. Use a narrower, testable statement instead: identify the processing boundary, transfer, device set, measured condition, timeframe, and remaining dependency.
Sources
- NIST Privacy Framework ↗
Used for its risk-management framing: processing location is only one factor in a privacy outcome.
- NIST Cybersecurity Framework 2.0 ↗
Used as a general reference for managing cybersecurity risk, not as evidence that a product is secure.
- Apple Core ML documentation ↗
A platform implementation reference for on-device model execution and integration.
- Google LiteRT documentation ↗
A platform implementation reference for model conversion, optimization, and deployment across edge targets.
- MPS/0.1 specification ↗
Defines the Maha Provenance Standard’s claim-status vocabulary and its limits.
[ MPS implementation library ]
Choose a boundary, then test it.
Decision framework
Compare privacy, capability, cost, latency, resilience, and device fit.
On-device vs cloud
The canonical workload-level deployment comparison.
Individuals
Choose a bounded, reversible personal workflow.
Schools
Plan classroom use with student-data and access boundaries.
Small organizations
Start with a managed, testable operational use case.
Developers
Build and measure a local, cloud, or hybrid boundary.
Glossary
Plain-language deployment and provenance terms.
Methodology & sources
What this library measures, assumes, and does not claim.