STANDARDS • RESEARCH • DEVELOPMENT
Testing before release.
RigWave uses recognised public guidance, controlled testing and explicit evidence gates to shape the product. The aim is credible engineering, not a wall of badges.
Accessibility target
RigWave targets WCAG 2.2 AA for the website. That means visible keyboard focus, avoiding author-created content that hides focused controls, practical target sizing, consistent help, reduced-motion support and honest testing of real rendered pages.
Evidence rule: static HTML checks support the target; browser, keyboard, zoom, high-contrast and assistive-technology checks remain separate evidence until actually run.
Secure development
Development practices are informed by the NIST Secure Software Development Framework and OWASP Application Security Verification Standard. RigWave uses fail-closed release switches, bounded inputs and network behaviour, exact artifact identities, negative tests, provenance and preservation of the first failing observation.
Evidence rule: a design, model or static test does not get promoted into runtime proof.
Windows trust & distribution
Signing, publisher identity and SmartScreen reputation are treated as separate release evidence. A signed new Windows binary can still receive reputation warnings, so RigWave does not promise a warning-free first download or tell customers to bypass Windows protection.
Evidence rule: final trust claims must be checked on the exact distributed bytes.
Privacy & customer protection
Research and testing favour data minimisation, purpose-specific consent, customer-controlled diagnostics, safe purchase states and clear separation between private beta, public trial and paid service.
R&D METHOD
From idea to evidence, one gate at a time
RigWave separates ideas, code checks, real Windows testing, online-service testing and human review. Each claim is only treated as proven when the right kind of test has actually been run.
- Research: compare the problem with recognised platform guidance, standards and real workflow constraints.
- Model and red-team: test normal, edge, failure, retry and ambiguous-outcome scenarios before trusting a happy path.
- Code and website checks: verify files, links, syntax, accessibility support and safe failure behaviour.
- Windows and real-host testing: prove Windows, OBS, audio and device behaviour on the exact build being tested.
- Online-service verification: prove network, consent, payment, delivery and recovery behaviour in the environment customers will actually use.
- Release assurance: retain evidence for signing, privacy, legal, accessibility, support and customer experience before public release.
PUBLIC REFERENCES
Guidance used in design and testing
- W3C Web Content Accessibility Guidelines (WCAG) — accessibility requirements and testable success criteria.
- NIST SP 800-218 Secure Software Development Framework — high-level secure software development practices and provenance-minded engineering.
- OWASP Application Security Verification Standard — a practical basis for web application security verification and secure-development requirements.
- Microsoft SmartScreen reputation guidance — publisher/file reputation and realistic expectations for newly distributed Windows binaries.
These references are engineering inputs. RigWave will state certification or independent assurance only if that evidence genuinely exists.