Job lifecycle, failures, and quotas

A job moves through a small number of states. It is queued when submitted, processing once a worker picks it up, then completed, failed, or cancelled. On Enterprise, a draft job can also sit awaiting your confirmation of the claimed criteria before it continues. Queued jobs are pulled in plan order, with Enterprise work ahead of Pro and Pro ahead of Standard, which is why the same job can start immediately on one day and wait on another.

You can cancel a job that has not started, or one that is waiting on criteria confirmation. Once a worker is running the job, cancel is no longer available, because it does not reach in-flight work. Cancelled jobs are excluded from your monthly counts entirely.

A failed job shows an error message in the matter panel. Rerun starts a fresh run on the same matter and the same uploads, which is the right move for a transient failure. If the message tells you the failure was a packaging problem that has since been fixed, start a new run rather than rerunning the failed one. If the failure happened after drafting had already begun, that run still counts against your monthly quota, so it is worth reading the message before firing off repeated retries.

Some jobs stop earlier and more deliberately, before any drafting happens, and report a short message about a specific exhibit. That is a refusal, not a crash. After Petria reads your exhibits, it checks each one against the label and filename you gave it and against the beneficiary on the matter. Two findings stop the run: an exhibit is not what its label or filename says it is, or an exhibit is not for this beneficiary, which usually means a file from another client's matter made it into the upload. The check is deliberately conservative, so only high confidence mismatches stop a job; if the classifier cannot reach a confident answer, the job proceeds. A refused job does not consume a draft credit. Fix the exhibit, then run again on the same matter.

Separately, an exhibit can be unreadable rather than mismatched: it yields no usable text at all, either because the file is missing or because nothing could be extracted from it. Unreadable exhibits are skipped rather than guessed at, so their content is not available for drafting, citation, or verification. To keep files readable, prefer a searchable PDF or a Word document over a photo of a page, scan straight and in focus if you must scan, avoid screenshots and heavily compressed images, and split or recombine so one exhibit is one document rather than a mixed dump. Petria extracts from a PDF text layer, from tables, from Word, and from images by optical character recognition where it can, so a good scan usually works; a poor one silently loses the exhibit. If a job stops on an exhibit you believe is correct, check whether that file is the version you meant to upload before rerunning.

For notices about job progress, Petria supports three channels: browser notifications, which need permission from your browser and can be checked with the test notification in settings; email on job completion; and Slack, using an incoming webhook from your workspace, on Pro and Enterprise. Notifications go to the person who submitted the job, so on a shared matter the associate who pressed run is the one who hears about it first. Firm-level notification settings are managed by an admin.

Completed matters can be archived once the work is done. Archiving takes the matter out of your active list but keeps its deliverables downloadable, and archived matters cannot start new jobs. If you need the matter gone rather than tidied away, that is a delete, which is a different and irreversible operation covered in the data handling guide.

What all of this costs against your plan: Petria counts two separate monthly buckets. Full draft jobs come out of one; RFE and RFR response jobs come out of the other. Using up one bucket does not touch the other, and both reset at the start of each calendar month in UTC. Standard includes five draft jobs a month and no response jobs, since response jobs are a Pro feature. Pro includes ten draft jobs and five response jobs. Enterprise runs on custom limits set for your firm under your contract, which may be a specific number or no hard cap. Your current usage against both buckets is shown in the workspace.

What counts is narrower than it looks. Cancelled jobs are not counted at all. A job stopped by the exhibit preflight check, before drafting starts, does not consume a draft credit. A job that fails after drafting has begun does count, because the expensive work already ran. On Enterprise, confirming the claimed criteria resumes the same job rather than starting a second one, so it is charged once. Response jobs always count against the response bucket, including ones linked to a petition Petria originally drafted. The practical implication is that reruns are not free: if a job failed after drafting, look at the error and fix the input before running again, rather than retrying repeatedly.

Two ways to add draft capacity on Standard and Pro: buy additional draft jobs directly, which are added to your monthly allowance, or on Pro, purchase an additional team seat, which also raises your draft allowance. If you need a different response quota, that is a conversation with support rather than a self-serve purchase. When you hit a cap, Petria tells you which bucket is exhausted and what your options are: upgrading, buying jobs, or waiting for the reset on Standard and Pro, or a request to adjust your configured limit on Enterprise. Per-job cost is included in your monthly plan on Standard and Pro; Enterprise per-job pricing is quoted with your contract.