EDI-ready in every applicable state 31 jurisdictions cataloged
support@smepro.app
Platform

Six capabilities. One system of record.

Everything below is enforced in the database itself — the application can't skip a rule, miss a deadline, or forget an audit entry.
01 · TRACK

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, with overdue computed 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.
02 · VALIDATE

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:

POST /obligations/{id}/submissions
→ 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.
03 · GATE

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-1 on 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.

04 · FILE

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.
05 · VERIFY

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.

06 · PROVE

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.
Under the hood: a PostgreSQL core where deadline math, validation, tenant isolation (row-level security), and audit all execute, fronted by a stateless API. The application tier can scale horizontally without coordination because it holds no compliance logic to disagree about. Details on the Security overview.