Features
What VRM does
Seven areas, following the pipeline the product is built to run. Every statement on this page traces to the README or to shipped code, and says where something is shown only in the demo or is not yet connected for customers.
Document intake and evaluation
Permits, plans and SOPs go in as files. Compliance obligations come out as structured records, each linked to the document it came from and, where the extraction quoted it, to its source text.
- Each document type is parsed with a prompt written for that type — SPCC, SWPPP, RCRA, Title V, UST and FRP.
- Extraction asks for every compliance requirement's regulatory citation and the verbatim source text it was taken from, and shows the reviewer the citation and the source text the extraction found, where it found them, before the requirement is accepted.
- Extraction returns a typed compliance obligation: authority, requirement type, frequency, criticality and any qualified-person requirement.
- The extraction instructions carry protection against prompt injection — text inside a document that tries to give the AI instructions — because a document is read, never obeyed.
Document evaluation summary across the entire system
One register of every obligation across every facility — the Inspection Requirements Register — each one reviewed by a compliance specialist or an admin before it can generate work. Customers review them in the review queue, and see every one, with its status, in the register.
- Nothing extracted goes live unreviewed — requirements enter the review queue for a compliance specialist or an admin.
- Requirements are versioned with append-only history, so an earlier reading of a compliance obligation is never overwritten.
- Requirements carry a regulatory authority — federal, state, county, municipal or company SOP — so the register reflects who imposed each compliance obligation.
- The register is searchable on title and citation, and filters on authority, type, criticality and status composed together.
Compliance frequency, resolution and scheduling
The part that is genuinely hard: turning "monthly", "within 72 hours of a qualifying rain event" and "every five years" into dated tasks somebody can be assigned.
- Four frequency types are read: calendar, rolling, event-triggered and multi-year. The scheduling engine resolves calendar, rolling and multi-year frequencies into dated tasks; event-triggered ones are not scheduled yet.
- All four support grace periods and qualified-person requirements — PE, Class A operator, accredited inspector.
- A reference copy of the frequency resolver carries 42 tests covering SPCC monthly inspections, RCRA weekly container inspections, a 30-day rolling walkthrough, multi-year integrity and recertification tests, SWPPP post-storm triggers, a fixed deadline and empty date ranges; the scheduling function runs its own port of it.
- Once a requirement is accepted, the daily sweep resolves its frequency into inspection tasks with due dates and compliance windows, which customers see with their status.
- A daily sweep marks an inspection task overdue once its due date is over at its facility.
| Type | Example | How it resolves |
|---|---|---|
| calendar | Monthly visual inspections | Tasks at fixed intervals — weekly, monthly, quarterly, semiannual or annual — with optional fixed deadlines. |
| rolling | Every 30 days from the day it was first scheduled | Due every N days from the day VRM first scheduled the requirement; a late inspection does not move the next due date. |
| event | Post-storm inspection when rainfall exceeds 0.5" | Meant to fall due within a configurable window after the threshold event; VRM has no event source yet, so none is scheduled. |
| multi_year | 5-year integrity test | Tasks at N-year intervals. |
Field checklists and documented evidence of completion
In the demo, the checklist is the inspection. Its verdict buttons are 56 pixels tall, for a gloved hand on a phone; the field app is not yet connected for customers.
- In the demo, checklists are completed on mobile, with photo, document or reading evidence attached to the item it belongs to; the field app is not yet connected for customers.
- In the demo, each item records pass, fail or not-applicable against its own acceptance criteria.
- Every button and control on the demo's field surface is at least fingertip-sized — 44 pixels square on a 375-pixel phone screen — so a checklist can be completed start to finish by touch alone.
- In the demo, pass, fail and N/A are distinguishable without color — three different glyphs, a text label, a fill, a ring and a colored card edge.
- Evidence is append-only at the database level: no UPDATE and no DELETE.
Non-compliance and corrective actions
A non-compliance carries a severity level — low, medium, high or critical — and can be given an owner, a corrective action and a target date for completion. It is recorded automatically for an overdue inspection, at the level its requirement was rated, or by a specialist from the requirements register. Not just a red cell on a spreadsheet.
- A non-compliance is resolved automatically when its inspection is recorded as verified or closed; nothing in the app records that yet.
- In the demo, severity level is rendered as a four-step ramp whose lightness is monotonic, so the level survives color-blindness and a greyscale print of a report.
Reporting
Four templates, each one written to cite the regulations its findings rest on; the app cannot request a report yet. Three of the four templates run for one facility or for the entire company; the site assessment is always for one facility.
- Four report templates: IRR export, non-compliance analysis, compliance roadmap and full site assessment.
- When the app can request a report, report generation will load its context first — requirements, non-compliances, evidence and tasks — then write against it.
- Every generated report carries an advisory notice stating that it is not legal advice.
- Inspection Requirements Register
- Non-Compliance Analysis Report
- Prioritized Compliance Roadmap
- Full Site Assessment Report
User access control, data management and view authority
Who has management authority to use the system for which activities, and who can see data from which facilities.
- Access controls keep each company's records to its own users; regulatory reference data is shared by every company.
- Field staff are scoped at the database to the facilities they are assigned to.
- In the demo, executive leadership sees every facility and every other view sees only its assigned facilities — the rule the product is being built to enforce for every role.
- Evidence, the audit log and requirement versions are append-only, protected by triggers rather than by convention.
- Controls prevent privilege escalation: a user cannot modify their own role, company, active flag or facility assignments.
- The role-to-route matrix is written once and read by both guard layers, and a test re-derives it from the pre-migration source on every run.
- Every AI function call is authenticated with a signed identity token (a JWT), authorized against the caller’s company, and validates its identifiers.
Next step
Open it and look
The demo carries a full worked dataset — a refinery complex, its documents, the requirements extracted from them, the tasks scheduled, the non-compliances recorded and a delivered report.