A submission is what comes back when someone fills in a form: a client at intake, a counterparty supplying details, a person responding to a public link. Opbox does not park that answer in a separate forms database. The submission body lands as key-bound Facts on the matter’s own record, the same single source of truth that documents read from, so the answers are usable the moment they arrive and the review surface is a view of the real record, not a parallel copy of it.
What it does
The submission body is the matter’s own Facts. When a completed form is taken in, each answer is stored as a key-bound Fact (target_type='submission'), bound to the field key rather than a display label. There is no dedicated submission table: an earlier one was dropped as a fragmentation breach. That means a submitted answer is the same kind of truth as any other fact on the matter, and the same suppression rules apply to it everywhere.
A snapshot, a changelog, and a derived status, in one read. Open a single submission and you get the snapshot body, a field-level changelog, and the lifecycle status. The changelog discloses which fields were submitted and whether each one is sealed, never the protected values themselves: an encrypted fact is returned as a presence marker, not in clear. Status is not stored on the submission. It is derived: until a reviewer acts, a submission reads as received, and from then on the status follows the disposition.
Approval and rejection ride the gate, not a forms-local flow. There is no submission-approve or submission-reject verb. A disposition is a step-acceptance gate over the submission target: the reviewer proposes the gate, then applies it to approve or rejects it to decline, optionally with a review note. The gate is the auditable disposition record, so a submission’s outcome carries the same who, when, and on-what-basis trail as any other approval gate in the system, and reverting an approval unwinds it cleanly through the same machinery.
One merged activity timeline. The review surface stitches the field-level changelog together with the gate decisions for that submission, drawn from the audit log. You see what came in and what was done about it on a single timeline: the fields that were submitted (with their sealed-or-plain marker) followed by the apply and reject events that disposed of them.
Stable submission IDs that resist replay. A submission carries a stable ID. If the caller supplies one it is honoured; otherwise it is derived deterministically from the form and a fingerprint of the data, so a verbatim re-submit is a no-op rather than a duplicate. Combined with the published-form gate (a submission against a form that is not published is hard-rejected, with no row created), this means a leaked public form link cannot be spammed by replay: the second ingest of the same answer simply returns the existing submission.
From submission to work, through the one write path. Taking in a completed form is the canonical submission write chokepoint, and it is an external-tier verb so a person outside the firm can fill the form. When the submission belongs to a matter, the ingest routes through the same step-completion path the rest of the system uses, so a returned form advances the matter rather than writing a shadow record on the side. A submission with no matter is also valid: intake without a spawn simply persists.
How you use it
Open the submission queue. Pick the form whose submissions you want to review (or arrive at it pre-scoped to one form), and the queue lists what has come back: who submitted, when, how long it has been waiting, and its derived status. Filter by status to find what is open, reviewed, approved, or rejected.
Read a submission in detail. Select a row to see the snapshot body alongside the merged activity timeline. Protected fields show as sealed rather than exposing their values, so you can review the shape and disposition of an answer without surfacing the personal data inside it.
Approve or reject it. Add an optional review note and choose approve or reject. Behind the button a step-acceptance gate is proposed over the submission and then applied or rejected, so the disposition is recorded as a real, named decision and the submission’s status follows from it.
Generate the form people fill in. Author a form schema from a prompt or spec. Generated schemas land as drafts only, under a lint and refuse-harmful gate, and are never auto-published: publishing a form for live use is a separate, deliberate, admin step. Only a published form accepts submissions.
Look back at the regulator side. Where a submission is a registry filing, the regulator-side state lives as namespaced facts on the same submission target, read through the matter’s facts, so the filing and its acknowledgements stay on one record rather than a second system.
The kernel verbs behind it
Each goes through the one front door - permission-checked, scope-checked, and audited before it runs. These are the verbs most specific to submissions.
form.generate- AI-generate a form schema from a prompt or spec, draft-only under a lint and refuse-harmful gate, never auto-published.form.ingest- the one canonical submission write chokepoint: external-tier and idempotent, it lands the answers as key-bound Facts and routes a matter-bound submission onward.submission.get- read one submission: the snapshot body, the field-level changelog, and the derived lifecycle status (sealed fields disclosed by presence only).submission.list- list a form’s submissions with their submitter, timing, and aging, reading the key-bound Facts.gate.propose- open the step-acceptance gate over a submission that a disposition runs through.gate.apply- approve the gate, recording the submission’s approval as an auditable decision.gate.reject- decline the gate so the submission is rejected, with a note on the record.fact.list- read the facts for a submission target, including the namespaced registry state of a filing (encrypted facts disclosed by presence only).capture.ingest- the broader intake chokepoint for ambient and transcript capture, redacted at ingest.capture.list- review what came in across the wider capture store, filtered by source type.
See the full set in the form verb reference.