Use in Google Sheets
Use the manual setup path when your team already works in Google Sheets and wants a familiar starting surface without connecting any Google account to Vraimony.
Downloads
Pick the right tool for a cleaner proof path.
This page helps buyers understand what each tool does, who it is for, and what happens after download. Installable tools stay separate from the templates entry layer.
Vraimony tools are helper-sized on purpose. Packs carry the operational outcome; downloads make the workflow clearer, lighter, and easier to start.
How to choose fast
Start from your real situation
I run a WooCommerce store
Start with the WordPress Plugin when order disputes, delivery proof, or admin-side evidence work begins inside your site.
I need a browser-side verify helper
Start with the Browser Extension when operators keep checking packages, links, or evidence context directly in the browser.
I need verification on my own site
Start with the Verify Widget when you want a clean read-only verification path on a portal, site, or handoff page.
My team works in Word
Start with the Word Add-in when reviews already happen inside documents and you want a lighter helper there.
I want local verification
Start with the CLI / Local Verify when a browser-first path is not the right fit.
I want a familiar records surface first
Start with Free Operational Templates when your team already works in sheets and wants a CSV-first entry path before packaging.
Templates & Imports
Free entry paths for familiar operational records
These templates work without Vraimony. Vraimony adds packaging, verification, reusable outputs, and clearer review paths. No tracking. No lock-in. Google Sheets is optional.
CSV downloads
Use CSV as the canonical portable path. Keep it local, import it elsewhere, or replace the source tool later without breaking the concept.
After packaging
Turn the record path into a summary sheet, proof card, structured bundle, structured data export (JSON / ERF), and a read-only verification path.
Sheet / Record
Start from a familiar record.
CSV
Keep the source portable.
Vraimony packaging
Prepare a cleaner output path.
Summary + Proof card
Make review easier for the next step.
JSON / ERF + Verify
Keep structured export portable and verifiable.
Use templates when you need a simple starting surface. Use packs when the real problem is operational clarity, proof reuse, receiver understanding, or third-party-ready packaging.
ERF turns ordinary records into portable, review-ready evidence outputs.
Choose by situation
Real examples, not vague labels
Each card below shows a simple real-world example, what you get, and how the tool is used. This keeps buying and downloading simple.
WordPress Plugin
Stores
Real example: a WooCommerce merchant wants cleaner order evidence when a customer disputes delivery.
What you get: a store-side helper that keeps evidence work closer to the admin workflow instead of scattered across email and screenshots.
How it is used: install the plugin in WordPress, connect it to the right pack flow, and use it as the website-side helper for proof preparation.
Browser Extension
Browser helper
Real example: a support operator keeps opening package links and wants a repeatable, read-only verify helper in the browser toolbar.
What you get: a quick browser-side helper for checks, context, and official package identity review.
How it is used: load the extension, pin it, and open it when you need a fast verification-oriented helper.
Verify Widget
Sites and portals
Real example: a team wants partners or customers to verify a proof path on a site page without sending them into a heavier portal.
What you get: an iframe-first verification surface designed for read-only inspection.
How it is used: open the guide, place the widget where visitors need verification, and keep the rest of the workflow outside the widget.
Word Add-in
Document teams
Real example: a reviewer works in Microsoft Word and wants a lighter helper without leaving the document flow for every small check.
What you get: a document-side helper with manifest-based deployment and Word-first review support.
How it is used: deploy the manifest, open the add-in in Word, and use it as a helper during review and packaging work.
CLI / Local Verify
Local verification
Real example: a technical operator wants a local check path on a controlled machine instead of relying on a browser.
What you get: a local-first helper that keeps verification simple and direct.
How it is used: download the CLI, run local checks, and use it when browser-side flows are not the best fit.
SDK
Developers
Real example: a developer wants to add local helper logic to an internal tool without rebuilding verification-facing pieces from scratch.
What you get: lightweight local helper logic for developer-controlled workflows.
How it is used: extract the SDK in a sandbox, test locally, and keep the integration helper-sized.
What happens after download
A simple three-step path
1. Open the guide
Do not start from the ZIP alone. Open the matching guide first so you know what the tool is for and what it is not for.
2. Install only the helper you need
Each download is narrow by design. Pick the tool that matches your workflow instead of downloading everything.
3. Use packs for operational outcomes
Tools help with installation, verification, and distribution. Packs are where the business outcome, proof packaging, or rollout path lives.
Global clarity
Tools vs packs
Use a tool when
- You need a helper on a browser, site, document, or local machine
- You are evaluating the workflow before committing to a pack
- You need a lighter start path
Use a pack when
- You want a real proof-readiness outcome
- You need structured outputs for disputes, handoff, submissions, or review
- You need a defined buying path, not just a helper download
Official package identity
Download safely
Official sources
- Use this page or the matching per-tool guide on www.vraimony.com
- Do not trust mirrors, reposted ZIPs, or typo domains
- Read the guide before installation
Integrity signals
- Checksum helps detect corruption
- Release wording explains package state
- Final signature, when published, confirms signed release state
Current release wording
READY_TO_SIGN / PENDING FINAL SIGNATURE
This is transparent on purpose. Package identity and source still matter even before final signature is published.
