Authoring

Objects — Work product · Boilerplate

Authoring is where the case turns into work product — the document the operation produces from it. For an adjudicator that’s a decision; for a representative, a brief; for a benefits operation, a determination. Whatever it’s called, the shape is the same: a document built from the case’s issues and the evidence behind them, assembled on reusable language, and signed. The platform provides this natively, so work product is composed against the live record rather than in a tool that’s been handed a copy of it.

Authoring is the station in the loop that consumes what the Reader produced. The reviewer reads the evidence in the Reader and decides the case’s issues there; authoring picks that work up unchanged — the decided issues become the document’s outline, and every citation carries the page anchor the reviewer set on the evidence. This is the seam from the authoring side: the document is composed from the issues the reviewer decided and the pages they cite, with nothing re-keyed between the two.

Composing from the issue list

The case’s unified issue list is the document’s outline. Each issue carries its scope, type, and disposition; the draft is built with one section per decided issue, in the reviewer’s order, each filled in as its issue is decided. A running count shows how many of the case’s issues are decided and how many remain, so the draft and the record stay aligned as the list resolves. An author writes against the section an issue creates, and the section’s heading carries the issue’s scope and disposition.

Snippet insertion from the boilerplate library

Reusable language lives as boilerplate (next section). Inside a section an author searches the library by keyword, by issue type, or by the disposition they’re writing toward, and inserts a snippet into the section in place. An inserted snippet is a live reference to the library entry: an author edits the inserted text freely on the draft (every operation is line-by-line different), and the underlying entry stays available for the next case to draw from. When the library entry updates, every draft that references it is flagged so the author can pull the change in.

Citations are the connective tissue between the draft and the evidence — and they aren’t re-keyed when the draft is composed. They come straight from the document↔issue link the reviewer already made in the Reader: while reading the file, the reviewer linked the pages that prove each issue to that issue. So each issue’s section opens already carrying its evidence — the document and page behind every disposition — and each citation is a click back to the exact page the reviewer relied on.

A citation carries the case id, the document id, and the page number — the same page anchor a search hit or an annotation uses. It resolves over the search index’s one-text-per-page contract, so when the source document is re-extracted or re-OCR’d the citation still lands on the right page without rewriting the draft. A citation removed from the source (a duplicate document withdrawn, a page redacted out) surfaces in the draft as a broken citation the author resolves — relink the evidence, remove the sentence, or accept the new state of the file.

Citations render in the draft as inline anchors: in the editing surface they show the source document and page as a chip the author clicks to open the Reader there; in the rendered work product they take the deployment’s configured citation style — a footnote, an inline reference, a bracketed annotation. The render is a render of the same record; the underlying citation is one shape, the displayed form is configuration.

Deciding-while-reading and drafting-while-reading are the same motion: authoring is not a separate application sitting beside the Reader but the station that takes the Reader’s output forward — the center where evidence becomes judgment, and the station that turns that judgment into the signed document. The link a reviewer made in the Reader is the same object the draft cites and the signed work product carries through — one record, read in the Reader and composed here.

Boilerplate

The boilerplate library is a configured asset, managed per deployment. A privileged author edits entries to keep them current with policy and regulation; copies entries to derive a variant for a sub-population or a new issue type; and subscribes to entries so that an update to a shared passage reaches every author who relies on it. The library is searchable by tag, by issue type, and by recent use, and each entry carries the dispositions it tends to support — so an author writing toward “remanded” sees the remand boilerplate first.

A deployment that already authors in an external word processor binds it through the authoring port instead — the platform supplies the evidence, the issue list, and the boilerplate, and the document is composed there. Native authoring and an external editor are the same seam, configured differently.

Review and revision

A draft is not signed in isolation. Reviewers leave comments anchored to spans — a sentence, a paragraph, a citation — that travel with the text as the draft revises. A comment carries its author, its time, and the resolution state; resolved comments stay on the record as part of the draft’s history. An author replies to a comment in place; a reviewer resolves it when the change lands.

Each save is a version on the work product, with the author and the time stamped on it. The version history reads as a timeline of who wrote what when, and any version is opened side-by-side with the current draft to see what changed — the same span-anchored comments rendered against the version they were left on.

Routing the draft into review is a task on the case — a quality-review task gates the draft’s completion, assigned to the reviewer the workflow names. The review happens here, against the live draft, and the comments and revisions on it land on the work product’s record like any other edit. When the reviewer marks the task complete, the draft is ready to sign.

Signing fixes the outcome

When the draft is complete, an authorized signer signs it. Signing is one atomic transition: the work product’s status moves from draft to signed, the issue dispositions the work product references are committed as the case’s outcome, and the work product carries the body it was signed against. The signer is the authenticated caller; signedAt and signedBy are stamped by the server — the body’s signer field is ignored, so a signature can’t be forged in the payload.

Signing requires every referenced issue to already carry a disposition — a draft that names an issue without one returns a conflict on sign, so an unresolved issue cannot reach the outcome by accident. The signed work product is a record on the case like any other, carrying its body, its issue dispositions, and its server-stamped signer in the event history, recoverable when the decision is read back.

Routing the signed outcome

A signed work product is then routed onward by the work engine — through a review-for-accuracy task if the workflow requires one, then to the delivery and effectuation ports that assemble the package and send it out. Routing is a rule over the signed work product’s state, so a deployment decides what the signed outcome triggers: a notification, a mailed package, propagation into a downstream system of record, or a follow-on case stream when the disposition opens one.

The shape of the package — the decision, the dispositions per issue, the recipients drawn from the case’s parties — composes from the same record the author wrote against. See the decision package on the Connect page for what the receiving system reads.

Evaluating the work

The same flow carries work-product evaluation — a reviewer scoring an author’s output along defined factors as part of quality review. The scores are records on the case, surfaced through reporting as one of the signals an operation watches. The evaluation rides on the same task and the same review pass; it doesn’t ask for a separate workflow.