Compliance calendar
Deadlines are not entered — they are generated. Each form in the catalog carries machine-readable deadline rules (monthly recurrence, days-after-completion windows, renewal cycles, event prerequisites), and the engine projects them across your asset inventory on a 12-month rolling horizon, regenerated ahead of time so nothing appears at the last minute.
- Every calendar row shows its legal basis — the citation the due date is computed from (e.g., Texas production reports under 16 TAC §3.54 timing rules).
- Statuses move only on evidence:
open → submitted → accepted, withoverduecomputed continuously against the clock. - Filters by jurisdiction, agency, form, asset, and days-until-due; a row leaves the calendar only when the agency's acceptance is recorded.
In-form validation
Each form version carries a field schema and cross-field rules mirroring agency edits. Validation runs inside the database transaction that would record the submission — so a filing with blocking errors is never written at all:
→ 422 Unprocessable { findings: [{ code: "PR-014", severity: "blocking",
message: "Disposition volumes must sum to production" }] }
Nothing was saved. Fix the payload and resubmit.
- Blocking findings stop the submission; warnings ride along for reviewer judgment.
- Rules are versioned with the form — an amended agency edit never rewrites the history of what older filings were checked against.
Pre-spud permit gate
Some mistakes shouldn't be findable on a calendar after the fact — they should be impossible to miss before the fact. The catalog types permit requirements as event-before rules: an approved drilling permit must exist before a spud event.
- Record a spud on a well with an approved
W-1on file → clean; the downstream completion-report clock arms automatically. - Record a spud with a missing or rejected permit → the system raises an overdue, blocking obligation instantly: "Approved permit required before spudding — none on file." It screams at the top of the calendar until resolved.
- The same pattern covers other prerequisites, like plugging approval
(
W-3A) before plugging operations.
Validate before drilling. That is the design.
EDI & e-filing output
The EDI engine is spec-driven: each form version can register the agency's exact file format, and accepted payloads render to it line-for-line — fixed-width fields, record ordering, and checksums per the agency's implementation guide. Wherever a state accepts electronic filing, the format is a catalog entry away, not a code change.
- Texas production reports render to RRC EDI today; problems are surfaced per line before you upload.
- Forms without an electronic channel produce portal-ready output instead — the engine tells you which path applies.
- You submit through your own agency credentials; SMEPro never files on your behalf unless separately agreed.
Catalog verification ledger
Regulations change, and a compliance product that hides its own uncertainty is dangerous. Every one of the catalog's forms carries a visible verification status:
- Verified — confirmed against the cited primary source (statute, regulation, agency instructions), with the verification date shown.
- Needs verification — cataloged from secondary knowledge and clearly labeled a draft until our stewardship process confirms it.
- Agency changes and corrections are logged in a regulatory change ledger you can read in the product — what changed, when we noted it, and what action it required.
See the coverage table for verification depth by jurisdiction.
Audit trail
Every state transition on an obligation or submission is recorded by database triggers — who, what, when — so the record exists even if application code never thinks about it. Submissions store the exact form version and the validator findings they were checked against.
- Reconstruct any filing for an examiner exactly as it stood when filed.
- Answer "who changed this and when" without a forensic project.
- Export the trail with your data at any time — it's yours.