Thank you for your questions. The primary target users would be systems where integrity verification and auditing are critical requirements, such as: - Financ

Thank you for your questions. The primary target users would be systems where integrity verification and auditing are critical requirements, such as: - Financial/banking systems that need cryptographic proof of all operations - Medical devices where operation verification is essential for safety - High-security environments requiring complete system attestation - Research systems that need reproducible and verifiable execution paths Though, my end goal with this to be sincere is making it general purpose in the future. I am a firm believer in the privacy of the user, and that's really what I wanted to achieve with this. An OS that can be run anywhere, including hardware that can't be trusted, having the confidence that there won't be a third actor watching every action the user takes. Regarding the performance impact: The verification system is actually quite efficient since it uses hardware-accelerated operations where available (SHA-256 instructions on modern CPUs) and an optimized FNV-1a fallback implementation. The proof generation adds roughly 3-5% overhead for memory operations and 7-9% for filesystem operations in the benchmarks. This is achieved by: - Batching proof generation for small allocations - Using a zone-based memory allocator that pre-verifies large memory regions - Implementing an efficient proof storage system with automatic pruning - Taking advantage of modern CPU crypto acceleration You're absolutely right about adding this to the README - I'll create a dedicated section covering use cases and performance characteristics.